Unix网络编程关于time_wait状态的解释

面试网络编程的同学基本上都会被问到对time_wait状态的理解，今天记录一下。
TIME_WAIT状态解释：
    毫无疑问,TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态，我们可以知道
是执行主动关闭的那端经历了这个状态。该端点停留在这个状态的持续时间是最长分节声明期的两倍(2MSL)
    任何TCP实现都必须为MSL选择一个值，一般伯克利的实现为30秒(标准建议两分钟)，这意味着TIME_WAIT状态的持续时间是在
一分钟到四分钟之间。MSL是任何IP数据包能够在因特网中存活的最长时间。我们知道这个时间是有限的，因为每个数据报含有一个
称为跳限的8位字段，它的最大值为255，尽管这是一个跳数限制而不是真正的时间限制，我们仍然假设：具有最大跳限的分组在网络中存在的时间不可能超过MSL秒.
    分组在网络中“迷途”通常是路由异常的结果。某个路由器崩溃或某两个路由器之间的某个链路断开时，路由协议需花数秒钟到数分钟的时间才能稳定的找出另一条通路，在这段时间内有可能发生路由循环(路由器A->路由器B,路由器B->路由器A),我们关心的分组可能就此陷入这样的循环,假设迷途的分组是一个TCP分节,在他迷途期间，发送端tcp超时并重传该分组,而重传的分组却通过某条候选路径到达最终目的地,然后不久后路由循环回复,早先迷失在这个循环中的分组最终也被送到目的地,这个原来的分组被称为迷途的重复分组。TCP必须正确的处理这些重复的分组。
    TIME_WAIT状态有两个存在的理由:
    (1)可靠地实现实现TCP全双工连接的终止。
    (2)允许老的重复分节在网络中消逝
    第一个理由可以通过查看图2-5并假设最终的ACK丢失了来解释。服务器将重新发送它的最终那个FIN,因此客户必须维护状态信息，以允许它重新发送最终那个ACK,要是客户不维护状态信息,它将响应一个RST,该分节将被服务器解释成一个错误,如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流(即全双工关闭),那么它必须正确处理连接终止序列4个分节中的任何一个分节丢失的情况。本例子也说明了为什么执行主动关闭的那一端是处于TIME_WAIT状态的那一端：因为可能不得不重传最终那个ACK的就是那一端。
        为理解存在TIME_WAIT状态的第二个理由：我们假设在128.1.1.1的1500端口和206.1.1.1的21端口有一个TCP连接,我们关闭这个连接，过一段时间后在相同的ip地址和端口之间在建立另一个连接,后一个连接称为前一个连接的化身，因为他们的IP地址和端口号都相同,TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现,从而被误解成属于同一连接的某个新的化身，为做到这一点，TCP将不给处于TIME_WAIT状态的连接发起新的化身,既然TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活MSL秒即被丢弃,另一个方向上的应答最多存活MSL秒也被丢弃,通过实施这个规则,我们就能保证每成功建立一个TCP连接时,来自该连接先前化身的老的重复分组都已在网络中消逝了。

附一张TCP状态图：