文章目录

• * 4.3设置TIME_WAIT状态的目的
  • * 4.3.1 实现TCP全双工连接的关闭
    • 4.3.2 使过时的重复报文段失效
    • 4.3.3 TIME_WAIT状态的自结束
    • 4.3.4 TIME_WAIT状态的影响（补充）

TIME_WAIT状态是TCP中最容易被人误解的特性之一。因为很多的标准文档都没有对该状态做一个详细的说明和解释。设置TIME_WAIT状态的原因主要有以下两个:

• 用来实现全双工的连接关闭；
• 它使过时的重复报文段作废；

下面我们对这两个原因做详细的说明。

4.3.1 实现TCP全双工连接的关闭

下图（图4-4）给出了一般情况下关闭连接时的报文交互流程，也就是我们常说的四次挥手过程；同时也给出了两端连接的状态变迁和服务器端测得的RTT值。

服务器端和客户端都可以是断开连接的发起端，这里我们使用的是客户端作为发起端。

• 关于是由服务器端发起还是客户端发起是很有讲究的，因为首先发起FIN报文(断开连接)的一端会进入TIME_WAIT状态，此状态会占用CPU、内存等资源，对于繁忙的服务器来说可能是很大的负担，因此很多服务器都尽量避免使自己进入TIME_WAIT状态。

​ 现在我们假设最后一个报文段（最后一个ACK）丢失时会发生什么现象。我们把这个现象的结果也以图形的方式显示出来：

​ 从图4-5我们可以看出最后一个ACK报文丢失时，服务器端会重新传输FIN报文。如果是最后一个FIN包丢失，服务器端也会重新传输FIN报文，因为服务器无法确定是FIN丢失还是ACK丢失，他们的处理方法是相同的。

序号

情形

解决方式

1

最后一个ACK丢失

服务器端重传FIN

2

最后一个FIN丢失

服务器端重传FIN

​ 上图从可以得出以下结论：

• TIME_WAIT状态要出现在执行主动关闭的一端：

该端发出最后一个ACK报文段，而如果这个ACK丢失或是最后一个FIN丢失了，那么另一端将超时并重传最后的FIN报文段。因此，在主动关闭的一端保留连接的状态信息，这样它才能在需要的时候重传最后的确认报文段；否则，它收到最后的 FIN报文段后就无法重传最后一个 ACK，而只能发出RST报文段，从而造成虚假的错误信息。

• TIME_WAIT状态定时器重新启动：

在主动关闭的一端仍然处于TIME_WAIT状态时， 如果收到对端超时重传的FIN报文，主动关闭的一端不仅会重新传输ACK报文，也会重新启动TIME_WAIT定时器(时间重新设置为2倍的报文段最大生存时间：2MSL)

• TIME_WAIT时间应该持续多久？：

这个加倍等待时间取决于RTO， 而RTO取决于链路的RTT。这里常使用指数退避算法来使RTO值比上次重传的值更大来实现。RFC 793 指出MSL为2分钟, TIME_WAIT时间为2MSL。然而，实现中的常用值是30秒，1分钟， 或2分钟。

总结下第一个用途如下：
​ 主动关闭的一端为了应对(因最后的FIN或ACK丢失导致的)超时重传，而进入TIME_WAIT阶段以备超时重传。最终目的是为了正常关闭全双工的连接

4.3.2 使过时的重复报文段失效

​ 设置TIME_WAIT状态的第二个原因是为让过时的重复报文段失效。TCP协议的运行基于一个基本的假设：互联网上的每一个IP报文都有一个生存期限。 我们将这个生存期限定义为报文段的最大生存时间（MSL），并规定该值为2分钟。 最后RFC793规定TIME_WAIT时间为MSL的2倍。

​ 图4-6给出的是一个连接关闭后在TIME_WAIT状态保持了 2 倍报文段最大生存时间( 2MSL)，然后发起建立新的连接情景：

总结下第二个原因：

​ 由于新的连接必须在前一个连接关闭 2MSL之后才能再次发起，且前一个连接的过时重复报文段在 TIME_WAIT状态的第 1个MSL里就已经消失，因此我们可以保证前一次连接的过时重复报文段不会在新的连接中出现，也就不可能被误认为是第二次连接的报文段

4.3.3 TIME_WAIT状态的自结束

RFC 793 中规定，处于TIME_WAIT状态的连接在收到RST后变迁到CLOSE状态，这称为TIME_WAIT状态的自结束。 RFC 1337 [Braden 1992a] 中则建议不要用RST过早地结束TIME_WAIT状态。

4.3.4 TIME_WAIT状态的影响（补充）

​ 处理的原则是：当TCP执行一个主动关闭，并发送最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为 2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。

重新发送ACK并不是说重传了ACK, 因为ACK不消耗序列号，因此不会简单重传ACK。而是由于对端重新传输了FIN报文。实际上TCP总是重传FIN，知道它收到最后一个ACK。

​ 这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接（客户的I P地址和端口号，服务器的 I P地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。在连接处于2 M S L等待时，任何迟到的报文段将被丢弃。

​ 客户端执行主动关闭并进入TIME_WAIT是正常的。服务器通常执行被动 关闭，不会进入TIME_WAIT状态。这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题，因为客户使用本地端口是由操作系统分配的临时可用的端口号，而并不关心这个端口号是什么。

​ 然而，对于服务器，情况就有所不同，因为服务器使用熟知固定端口。如果我们终止一个已 经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的 这个熟知端口赋值给它的端点，因为那个端口是处于2MSL连接的一部分。在重新启动服务器 程序前，它需要在1 ~ 4分钟。想象以下：淘宝服务器关闭四分钟，那会是怎样的损失呢！！！

​ 解决办法：地址端口的快速复用

某些实现和A P I提供了一种避开这个限制的方法。使用套接字API时，可说明其中的 SO_RUSEADDR选项。它将让调用者对处于2 M S L等待的本地端口进行赋值，但我们 将看到TCP原则上仍将避免使用仍处于2MSL连接中的端口。