TC的连接释放

TCP的连接释放

1、释放的过程
四次挥手释放连接
数据传输结束后，通信的双方都可释放连接。假设A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

1. A主动发送连接释放报文段，终止控制位FIN=1，序号seq = u,上一个已发送数据的最后字节的序号加1,。这时候A进入FIN-WAIT-1(终止等待1)状态，等待B的确认。
2. B收到连接释放报文段后即发出确认，ACK=1，确认号ack = u+1,这个报文自己的序号seq = v。然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时通知高层应用进程，因而从A到B这个方向的连接就是放了，TCP连接处于半关闭状态。A仍可接收B发送的数据。
3. 假如B在接下里的时间里又发送了一些数据，然后发送连接释放报文段，FIN=1，ACK=1，确认号ack = u+1, 序号seq = w，等于已发送数据的最后的字节的序号 加1。这时候B进入了LAST-ACK(最后确认)状态，等待A的确认。
4. A收到B的连接释放报文段后，必须对此发出确认。ACK=1，确认号ack = w+1,序号seq= u+1。这时候A进入TIME-WAIT (时间等待)状态。时间为2MSL（2个最长报文段寿命）。等待了2MSL后连接才释放掉。

2、为什么要等待2MSL的时间？必须是2MSL吗？不能是1MSL，或者3MSL等吗？

• 第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN + ACK报文段，而A就能在2MSL时间内收到这个重传的FIN + ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后
  立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。

• 第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL， 就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

• B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早
  一些。

TIME-WAIT 的时间一定要是2MSL吗？
假设客户端客户端发送的最后一个ACK丢失，服务端将重传FIN，为了能够收到这个超时重传的FIN，客户端需要TIME_WAIT状态；那TIME_WAIT状态就必须是2MSL了吗？其实这个要看服务端FIN的超时重传时间RTO，如果RTO小于MSL，那TIME_WAIT状态MSL就够了，如果RTO大于2MSL那么TIME_WAIT状态2MSL也是不够的，所以只有RTO在MSL和2MSL之间的时候，TIME_WAIT状态存在的理由1才是TIME_WAIT的时间是2MSL的原因。其实一般情况下，RTO都是远远小于MSL的，但考虑到最糟糕的情况，RTO是为2MSL，所以TIME_WAIT状态为2MSL可以保证最糟糕情况也可以收到超时重传的FIN。

TIME_WAIT的时间是2MSL另外一个重要原因理由2，为了保证本连接持续的时间所产生的所有分组都从网络中消失，也就是保证新建立一个TCP连接时，来自该连接老的重复分组都已经在网络中消失了。这里可能有的人会有个疑问：客户端回复最后一个ACK之后，感觉一个MSL就可以所有分组消失了啊，为什么还要2MSL所有分组才消失呢？

假设客户端发送ACK刚刚过了一个MSL时间，而服务端在收到这个ACK之前一瞬间刚好启动超时重传FIN，所以要等这个FIN也消失，就是2MSL了。文中所指的另一个方向的应答应该就是这个超时重传的FIN。

参考链接：
https://blog.csdn.net/a3192048/article/details/85414502