只有主动断开的那一方才会进入 TIME_WAIT 状态，且会在那个状态持续 2 个 MSL（Max Segment Lifetime）。

MSL：Max Segment Lifetime

MSL（报文最大生存时间）是 TCP 报文在网络中的最大生存时间。这个值与 IP 报文头的 TTL 字段有密切的关系。

IP 报文头中有一个 8 位的存活时间字段（Time to live, TTL）如下图。 这个存活时间存储的不是具体的时间，而是一个 IP 报文最大可经过的路由数，每经过一个路由器，TTL 减 1，当 TTL 减到 0 时这个 IP 报文会被丢弃。

image.png

image.png

从上面可以看到 TTL 说的是「跳数」限制而不是「时间」限制，尽管如此我们依然假设最大跳数的报文在网络中存活的时间不可能超过 MSL 秒。Linux 的套接字实现假设 MSL 为 30 秒，因此在 Linux 机器上 TIME_WAIT 状态将持续 60秒。

构造一个 TIME_WAIT

只需要建立一个 TCP 连接，然后断开某一方连接，主动断开的那一方就会进入 TIME_WAIT 状态，我们用 Linux 上开箱即用的 nc 命令来构造一个。过程如下图：

image.png

  1. 在机器 c2 上用nc -l 8888启动一个 TCP 服务器
  2. 在机器 c1 上用 nc c2 8888 创建一条 TCP 连接
  3. 在机器 c1 上用 Ctrl+C 停止 nc 命令，随后在用netstat -atnp | grep 8888查看连接状态。
  1. $ netstat -atnp | grep 8888
  2. tcp        0      0 10.211.55.5:60494       10.211.55.10:8888       TIME_WAIT   -

TIME_WAIT 存在的原因是什么

  • 第一个原因是：数据报文可能在发送途中延迟但最终会到达，因此要等老的“迷路”的重复报文段在网络中过期失效，这样可以避免用相同源端口和目标端口创建新连接时收到旧连接姗姗来迟的数据包，造成数据错乱。

image.png

  • 第二个原因是确保可靠实现 TCP 全双工终止连接。关闭连接的四次挥手中，最终的 ACK 由主动关闭方发出，如果这个 ACK 丢失，对端（被动关闭方）将重发 FIN，如果主动关闭方不维持 TIME_WAIT 直接进入 CLOSED 状态，则无法重传 ACK，被动关闭方因此不能及时可靠释放。

image.png

如果四次挥手的第 4 步中客户端发送了给服务端的确认 ACK 报文以后不进入 TIME_WAIT 状态，直接进入 CLOSED状态，然后重用端口建立新连接会发生什么呢？如下图所示:

  • 主动关闭方如果马上进入 CLOSED 状态，被动关闭方这个时候还处于LAST-ACK状态，主动关闭方认为连接已经释放，端口可以重用了，如果使用相同的端口三次握手发送 SYN 包，会被处于 LAST-ACK状态状态的被动关闭方返回一个 RST，三次握手失败。

image.png

为什么时间是两个 MSL

1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达

2MS = 去向 ACK 消息最大存活时间（MSL) + 来向 FIN 消息的最大存活时间（MSL）

TIME_WAIT 的问题

在一个非常繁忙的服务器上，如果有大量 TIME_WAIT 状态的连接会怎么样呢？

  • 连接表无法复用
  • socket 结构体内存占用

应对 TIME_WAIT 的各种操作

针对 TIME_WAIT 持续时间过长的问题，Linux 新增了几个相关的选项，net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle。下面我们来说明一下这两个参数的用意。 这两个参数都依赖于 TCP 头部的扩展选项：timestamp

TCP 头部时间戳选项（TCP Timestamps Option，TSopt）

image.png

由四部分构成：

  1. 类别（kind）
  2. 长度（Length）
  3. 发送方时间戳（TS value）
  4. 回显时间戳（TS Echo Reply）

时间戳选项类别（kind）的值等于 8，用来与其它类型的选项区分。长度（length）等于 10。两个时间戳相关的选项都是 4 字节。

image.png

是否使用时间戳选项是在三次握手里面的 SYN 报文里面确定的:

image.png

  1. 发送方发送数据时，将一个发送时间戳 1734581141 放在发送方时间戳TSval中
  2. 接收方收到数据包以后，将收到的时间戳 1734581141 原封不动的返回给发送方，放在TSecr字段中，同时把自己的时间戳 3303928779 放在TSval中
  3. 后面的包以此类推

image.png

有几个需要说明的点:

  • 时间戳是一个单调递增的值，与我们所知的 epoch 时间戳不是一回事。这个选项不要求两台主机进行时钟同步
  • timestamps 是一个双向的选项，如果只要有一方不开启，双方都将停用 timestamps。比如下面是curl www.baidu.com得到的包

image.png

tcp_tw_reuse 选项

缓解紧张的端口资源，一个可行的方法是重用“浪费”的处于 TIME_WAIT 状态的连接，当开启 net.ipv4.tcp_tw_reuse 选项时，处于 TIME_WAIT 状态的连接可以被重用。下面把主动关闭方记为 A， 被动关闭方记为 B，它的原理是：

下面的两个原理都是针对 TIME_WAIT 存在的原因想出的立即重用端口的方法.

  • 第一个, 克服旧包
  • 第二个, 克服重传 FIN
  • 如果主动关闭方 A 收到的包时间戳比当前存储的时间戳小，说明是一个迷路的旧连接的包，直接丢弃掉
  • 如果因为 ACK 包丢失导致被动关闭方还处于LAST-ACK状态，并且会持续重传 FIN+ACK。这时 A 发送SYN 包想三次握手建立连接，此时 A 处于SYN-SENT阶段。当收到 B 的 FIN 包时会回以一个 RST 包给 B，B 这端的连接会进入 CLOSED 状态，A 因为没有收到 SYN 包的 ACK，会重传 SYN，后面就一切顺利了。

image.png

tcp_tw_recyle 选项

tcp_tw_recyle 是一个比 tcp_tw_reuse 更激进的方案， 系统会缓存每台主机（即 IP）连接过来的最新的时间戳。对于新来的连接，如果发现 SYN 包中带的时间戳与之前记录的来自同一主机的同一连接的分组所携带的时间戳相比更旧，则直接丢弃。如果更新则接受复用 TIME-WAIT 连接。

这种机制在客户端与服务端一对一的情况下没有问题，如果经过了 NAT 或者负载均衡，问题就很严重了。

NAT:

image.png

当 tcp_tw_recycle 遇上 NAT 时，因为客户端出口 IP 都一样，会导致服务端看起来都在跟同一个 host 打交道。不同客户端携带的 timestamp 只跟自己相关，如果一个时间戳较大的客户端 A 通过 NAT 与服务器建连，时间戳较小的客户端 B 通过 NAT 发送的包服务器认为是过期重复的数据，直接丢弃，导致 B 无法正常建连和发数据。