TCP的TIME_WAIT状态为什么要等待2MSL的时长

  • TCP四次挥手的第四次挥手后为什么要经过TIME_WAIT状态?
  • TIME_WAIT状态为什么是2MSL的时长?为什么不是等待其他时长?

TCP第四次挥手后为什么要经过TIME_WAIT状态?

第四次挥手后为什么要经过TIME_WAIT状态之后才进入CLOSED状态,为什么不直接进入CLOSED状态?
因为客户端发送的第四次挥手的ACK应答数据包,服务端可能没有收到,如果服务端在发送第三次挥手的FIN数据包后,等待一段时间后没有收到ACK应答,那么会重新发送第三次挥手的FIN数据包,客户端收到后再次发送第四次挥手的ACK数据包。

这TIME_WAIT状态的等待时间就是为了防止服务端没有收到客户端发送的第四次挥手的ACK数据包,从而向客户端重新发送第三次挥手的FIN数据包时,客户端能正常接收到FIN数据包并且向服务端发送第四次挥手的ACK应答数据包。

TIME_WAIT状态一般等待的是2MSL的时长。

TIME_WAIT状态为什么是2MSL的时长?为什么不是等待其他时长?

MSL,Maximum Segment Lifetime,最大报文段生存时间。即任何TCP报文在网络中存在的最大时长,如果超过这个时间,这个TCP报文就会被丢弃。
2MSL,即两个最大报文段生存时间。
TIME_WAIT状态为什么是2MSL的时长?因为客户端不知道服务端是否能收到ACK应答数据包,服务端如果没有收到ACK,会进行重传FIN,考虑最坏的一种情况:第四次挥手的ACK包的最大生存时长(MSL)+服务端重传的FIN包的最大生存时长(MSL)=2MSL

https://tools.ietf.org/html/rfc793 里也说了 TIME-WAIT的作用

 TIME-WAIT - represents waiting for enough time to pass to be sure
    the remote TCP received the acknowledgment of its connection
    termination request.

为了确保远端TCP端能够收到它发出的终止连接请求的ACK应答包。

还有这一段:

        TIME-WAIT STATE

          The only thing that can arrive in this state is a
          retransmission of the remote FIN.  Acknowledge it, and restart
          the 2 MSL timeout.

TIME-WAIT状态唯一可能收到的是服务端发送的FIN数据包,每次收到FIN数据包,回送ACK应答,并且重置2MSL的等待超时时间。

如果客户端不经过2MSL时长的TIME_WAIT状态,发送ACK之后就立马关闭TCP链接,释放端口号和内存资源,会出现什么情况?
可能会出现服务端并没有收到ACK,然后重新发送第三次挥手的FIN包,而此时客户端又新建了到服务端的TCP链接,并且客户端使用的还是之前的端口号,那么网络中延迟到达的FIN包就会被这个新的TCP链接接收到,这不是客户端希望接收到的数据,因此要等待2MSL的时长,确保网络中的FIN包全都不存在了,才关闭TCP链接,释放端口号和内存资源,这个时候客户端就可以重新使用这个端口号连接任何服务器,包括刚断开的这台服务器。

因此,上次TCP连接的依然存活的报文对未来的新TCP连接是会产生很大影响的,为了防止这种情况的出现,除了TIME_WAIT状态的2MSL时长机制,TCP协议中还有 The TCP Quiet Time Concept (在 3.3. Sequence Numbers 章节中)的概念,按照这个理念,2MSL时长的设定是一比较宽裕的值。

因此,TIME_WAIT状态需要等待2MSL的时长,确保本次TCP连接的四次挥手的关闭流程的正确可靠。

总结,TIME_WAIT状态的时长设置为2MSL的主要原因:

  • 确保被动关闭TCP连接的一端能收到第四次挥手的ACK
  • 避免上一次TCP连接的数据包影响到下一次的TCP连接。

参考:
为什么TCP4次挥手时等待为2MSL?
聊聊tcp四次挥手中的TIME_WAIT状态存在的理由
Time-wait状态(2MSL)一些理解
TCP释放连接时为什么time_wait状态必须等待2MSL时间
为什么tcp的TIME_WAIT状态要维持2MSL
深入浅出TCP协议的2MSL TIME_WAIT状态

你可能感兴趣的:(计算机网络,Android)