2MSL TIME_WAIT状态存在的原因：
TIME_WAIT状态的存在有两个理由。 (1)进一步落实4次握手闭锁流程； 第四次握手的最后一次ACK是从主动关闭端发送的，如果此ACK丢失，被动关闭端将再次发送FIN。 如果主动关机侧能够维持2MSL的TIME_WAIT状态，则重新发送丢失的ACK的机会增加。 )2)防止丢失复制对后续新正常链路的传输造成伤害。 丢失部署在实际网络中非常常见。 由于路由器出现故障且路径不收敛，一个包经常在路由器a、b和c之间进行类似于死循环的跳转。 IP标头有TTL，限制了一个包在网络中的最大跳数。 因此，这个数据包有两个命运。 也就是说，最后TTL变为0，在网络中消失。 或者在TTL变为0之前路由器的路径收敛，并在剩下的TTL跳数上终于到达目的地。 但是，遗憾的是，TCP通过超时重发机制，在较早的时候发送了与其相似的分组，在此之前到达了目的地，因此其命运也注定要被TCP协议栈抛弃。 另一个概念称为incarnation connection，是指与上次socket pair相同的新连接，称为incarnationofpreviousconnection。 丢失部署与非中断连接结合使用时，传输会发生致命错误。 众所周知，TCP是流式传输，所有分组到达的顺序不一致，根据序列号TCP协议栈进行顺序的拼接； 假设incarnation connection此时收到的seq=1000，lost duplicate为seq=1000，len=1000，则tcp认为该lost duplicate合法，并将其接收
这种状态为什么被设计为积极关闭这一方：
)1)发出最后ack的是主动关闭的一方
)2)如果任何一方保持TIME_WAIT状态，就可以避免incarnation connection在2MSL内的重构，不需要两者都有
2如何正确处理2MSL TIME_WAIT
在RFC中，必须确保socket pair在TIME_WAIT中时无法重新启动incarnation connection。 但是，大多数TCP的实现受到了更严格的限制。 等待2MSL时，默认情况下套接字使用的本地端口不可用。 如果A 10.234.5.5:1234和B 10.55.55.60:6666建立了连接，并且a主动关闭，则在a端，无论对方端口和ip是1234，服务重新启动都是很明显，这是比RFC更严格的限制，RFC只是要求套接字包不匹配，在实现过程中只要该端口在TIME_WAIT，就不允许连接。 此限制与主动打开的一方无关，因为它通常使用临时端口，但对于被动打开的一方，它通常是服务器，非常悲剧。 因为服务器一般都熟悉端口。 例如，对于http，一般端口为80，不允许此服务在2MSL内发生。 解决方案是在服务器套接字上设置SO_REUSEADDR选项。 这样，即使熟悉端口处于TIME_WAIT状态，也可以在此端口上启动服务。 当然，有SO_REUSEADDR选项，但仍然存在sockt pair限制。 例如，在上面的示例中，a通过SO_REUSEADDR选项在1234端口上监听，但如果从b开始通过6666端口连接，则TCP协议会指出由于地址不正确而导致连接失败