关于tcp/ip中time_wait状态的解释

time_wait状态原理

通信双方建立tcp连接后，主动关闭连接的一方在发送最后一个ack包后，进入time_wait状态(而不是直接进入close状态)。time_wait状态持续2msl时间，然后才是进入close状态。
以客户端主动关闭连接为例：

image.png

为什么客户端发送完最后一个ack后，要先进入time_wait状态，等过了2msl时间后，才能进入close状态呢？？
原因有二：

1. 可靠实现tcp全双工连接的终止

tcp协议在关闭连接的四次挥手过程中，最终的ack信号是又主动关闭连接的一方(文中我们统称为A端)发出来的。如果这个ack包丢失，对方(文中统称为B端)将重发出最终的FIN信号，因此A端必须维护状态信息，这样在time_wait这段时间内就可以允许A端对B端重发的fin包进行ack包的回应。如果A端不维持这个time_wait状态而是直接进入close状态，那么A端将响应RST分节，B端收到后将次分解解释成一个错误。
因此，要实现tcp全双工链接的正常终止，必须处理终止过程中四个分节中任何一个分节的丢失情况，主动关闭连接的A端必须维持time_wait状态。

2. 允许老的重复分节在网络中消逝

tcp分节可能由于路由异常而”迷途“，在迷途期间，tcp发送端可能因确认超时而重发这个分节，但是迷途的分节在路由修正后也准确的被送到目的地，这个刺刀的迷途分节达到时可能会引起这么一个问题：在关闭"前一个连接"
后，马上又重新建立起了一个相同的ip和端口之间的”新连接“，此时”前一个连接“的迷途分组在”前一个连接“终止后达到，而被”新连接“收到了。这肯定就有问题了。所以为了避免这种情况的出现，tcp协议不允许处于time_wait状态的连接启动一个新的可用连接，这样的话，靠着time_wait状态持续的2msl时间，就可以保证上一个连接的迷途分节在这个时间内从网路中消亡。

注：TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟。Windows操作系统就是4分钟。

参考