为什么TCP的TIME_WAIT状态要保持2MSL?_为什么tcp的time_wait状态要维持2msl

TIMEWAIT状态也称为 2MSL等待状态。
每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)。
它是任何报文段被丢弃前在网络内的最长时间。

我们知道这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。

RFC 793 [Postel 1981c] 指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟。

在实际应用中，对IP数据报TTL的限制是基于跳数，而不是定时器。

对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIMEWAIT状态停留的时间为2倍的MSL。

这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)。
这种2MSL等待的另一个结果是 这个TCP连接在2MSL等待期间，定义这个连接的插口(客户的IP地址和端口号，服务器的IP地址和端口号)不能再被使用。
这个连接只能在2MSL结束后才能再被使用。

遗憾的是，大多数TCP实现(如伯克利版)强加了更为严格的限制。
在2MSL等待期间，插口中使用的本地端口在默认情况下不能再被使用。

某些实现和API提供了一种避开这个限制的方法。

使用插口API时，可说明其中的SOREUSEADDR选项，它将让调用者对处于2MSL等待的本地端口进行赋值。
但我们将看到TCP原则上仍将避免使用仍处于2MSL连接中的端口。

在连接处于2MSL等待时，任何迟到的报文段将被丢弃。
因为处于2MSL等待的、由该插口对(socket pair)定义的连接在这段时间内不能被再用，因此当要建立一个有效的连接时，来
自该连接的一个较早替身(incarnation)的迟到报文段作为新连接的一部分不可能不被曲解

(一个连接由一个插口对来定义。一个连接的新的实例(instance)称为该连接的替身)。

参考：《TCP IP详解卷一》18.6.1

《UNIX网络编程(卷1)：套接字联网API(第3版)》2.7

为什么TCP的TIME_WAIT状态要保持2MSL?