TCP的三次握手和四次挥手及相关问题解答

字段含义

seq： 报文序列号，4个字节，用来标记数据段的顺序，每个报文对应一个序列号
ack： 确认号，4个字节，表示期待收到的下一个报文段的序列号，确认号当前序列号+1
SYN： 请求建立连接，SYN=1表示请求建立连接
ACK： ack确认号标志位，ACK=1表示确认号有效
FIN： 请求终止连接，FIN=1表示请求终止连接

三次握手

第一次握手：
A向B发送连接请求，SYN=1，并且随机生成一个序列号seq=x，发送完毕后进入同步已发送状态
第二次握手：
B收到A发送的连接请求，首先确认A向B的连接请求，确认号ack=x+1，确认号有效ACK=1，B也向A发送连接请求SYN=1，随机生成序列号seq=y，，发送完毕后进入同步收到状态
第三次握手：
A收到B发来的确认请求，确认B向A的连接请求，确认号ack=y+1，确认号有效ACK=1，seq=x+1，，发送完毕后进入已建立连接状态，B收到A发来的报文后也进入已建立连接状态

四次挥手

第一次挥手：
A向B发送终止连接请求，FIN=1，随机生成序列号seq=u，发送完毕进入终止等待1状态
第二次挥手：
B收到A发送的终止连接请求，确认号ack=u+1，确认号有效ACK=1，这时B向高层应用程序通知A已经没有数据要发送了，A往B的方向就被释放了，这时处于半关闭状态，随机生成序列号seq=v，发送完毕后B进入关闭等待状态，A进入终止等待2状态，在这时，A会持续接收B最后的数据，直到B的数据全部发送完毕
第三次挥手：
B的数据发送完毕后，就要告诉A它想要终止连接了，向A发送FIN=1，确认号ack=u+1，确认号有效ACK=1，随机生成序列号seq=w，发送完毕后进入最后确认状态
第四次挥手：
A收到B发送的终止连接请求，ack=w+1，确认号有效ACK=1，序列号seq=u+1，发送完毕后进入时间等待状态，在2MSL这段时间内，A要确认B是否接收到了自己的最后一次发送的报文，如果没有B在这段时间内没有应答，说明B已经进入close状态了，A在时间过了之后才会进入close状态，至此，双方都已终止连接

相关问题

1.为什么连接的时候是三次握手，关闭的时候却是四次握手？
B收到A发送的建立连接请求SYN=1后，也会直接发送一个建立连接请求SYN=1，并且还可以确认ACK=1，但是在终止连接时，B收到终止连接请求FIN=1，不能也发送FIN=1，因为自己还有一些数据没有发送完毕，等自己的全部数据都发送完毕之后才能发送FIN=1，因此需要4次挥手
2.为什么不能用两次握手进行连接？
如果将三次握手改为二次握手，B收到A的建立连接请求，发送了自己报文来应答，可能在这次发送的过程中发生了丢失的情况，这时A就不知道B是否已经准备好了没有，还可能怀疑是自己第一次就没有发送成功，但是因为没有第三次握手，B就会认为双方都已经准备好了，开始向A发送数据，但是A这时并没有准备好，不能接收到数据，B发送数据超时后就会一直重复发送数据，产生死锁
3.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
在第四次挥手完毕后，可能这一个片段会丢失，A要确认B是否接收到了自己的第四次挥手发送的片段，而确认过程就在2MSL内，如果没有接收到，B还会再向A不断重复发送FIN片段，所以A要在这段时间内确认B发送的片段，并且重新等待2MSL，如果B接收到了最后一次挥手，就会直接进入close状态，A在等待2MSL后也就会进入close了。
所谓2MSL就是两倍的MSL，MSL是一个片段在网络中的最大存活时间，A和B一个发送一个应答，就是2倍的MSL，如果在这么大的时间内A都没有收到回复，说明了已经B已经收到了A发送的最后一次挥手。
4.如果已建立连接，但客户端突然出现故障了怎么办？
TCP有一个保活计时器，通常是2小时，B每次收到A的数据都会复位这个计时器，如果A出现故障，B在2个小时都没有收到A发来的数据后，B就会发送一个探测报文段，之后每隔75秒发送一次，若连续10个探测报文段都没有收到应答，就会认为A出现故障了，之后就会关闭连接