图解 TCP 四次挥手｜深度解析｜为什么是四次

写在前面

今天我们来图解一下TCP的四次挥手、深度解析为什么是四次？

上一片文章我们已经介绍了TCP的三次握手
在这里插入图片描述

解析四次挥手

数据传输完毕之后，通信的双方都可释放连接。现在客户端A和服务端B都处于ESTABLISHED状态。
在这里插入图片描述

第一次挥手

客户端A的应用进程先向TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。客户端A把链接释放报文段首部的终止控制位FIN置为1，其序号为seq=u，它等于前面以传送过的数据的最后一个字节的序号加1。这时候A进入了FIN-WAIT-1(终止等待1)状态，等待B的确认。

注意：TCP规定：FIN报文段即使不携带数据，也消耗掉一个序号！！

在这里插入图片描述

第二次挥手

服务端B收到链接释放报文段后即发出确认，确认号是ack = u + 1，而这个报文段自己的序号v是等于B前面已传送过的数据的最后一个字节的序号加1，然后B就进入CLOSE-WAIT(关闭等待)状态。

在这里插入图片描述
TCP服务器进程这时应通知应用进程，因而从A到B这个方向的链接就释放了。这时的TCP链接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收，也就是说，从B到A这个方向的连接并未关闭，这个状态要维持一段时间。

第三次挥手

A收到来自B的确认后，就进入了FIN-WAIT-2(终止等待2)状态满等待B发出的连接释放报文段。若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接，这时B发出的连接释放报文段必须使FIN = 1，现假定B的序号为w，B还必须重复上次已发送过的确认号ack = u + 1.这时B就进入LAST-ACK(最后确认)状态，等待A的确认。

在这里插入图片描述

第四次挥手

A在收到了B的链接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1，而自己的序号是seq=u+1(根据TCP标准，前面发送过的FIN报文段要消耗一个序号)，然后进入到TIME-WAIT(时间等待)状态。

注意： 现在TCP连接还没有还没有释放掉。必须经过时间等待计时器设置的时间2MSL后，A才能进入CLOSED状态。

MSL叫做最长报文段寿命，RFC793建议设在两分钟，但TCP允许不同的实现可以根据具体情况使用更小的MSL值。

在这里插入图片描述

为什么要2MSL时间呢

1. 为了保证A发送的最后一个ACK报文段能够到达B。

这个ACK报文段有可能丢失，因而使处于在LAST-ASK状态的B收不到对己发送的FIN-ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计时器，最后的A和B都正常进入CLOSED状态。

在这里插入图片描述

如果A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。

2. 防止了已失效的连接请求报文段。

A 在发送完最后一个ACK报文段后，在经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样就可以使下一个连接中不会出现这种旧的连接请求报文段。B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接，所以B结束TCP连接的时间要比A早一些的。