【Linux】中TCP的握手与挥手

三次握手的原因：

TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。
如果采用两次的话，会出现下面这种情况。 
比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。

结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。

三次握手改成仅需要两次握手，死锁是可能发生
考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的***，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

四次挥手的原因：

TCP协议是全双工通信，这意味着客户端和服务器端都可以向彼此发送数据，所以关闭连接是双方都需要确认的共同行为
假设是三次挥手时，首先释放了A到B方向的连接，此时TCP连接处于半关闭（Half-Close）状态，这时A不能向B发送数据，而B还是可以向A发送数据。如果此时A收到了B的确认报文段后，就立即发送一个确认报文段，这会导致B向A还在发送数据时连接就被关闭。这样会导致A没有完整收到B所发的报文段