为什么要有 TIME_WAIT 状态？
TIME_WAIT，俗称 2MSL 等待状态，是 TCP 连接主动关闭一方（通常是客户端，但也可能是服务端）在发送最后一次 ACK 确认报文后进入的状态。它需要等待 2 倍的最大报文段生存时间（2MSL），之后才会最终进入 CLOSED 状态并释放资源。
设计这个状态主要是为了保障 TCP 协议的可靠性，核心原因有两点：
1. 确保最后的 ACK 能到达对方
这是最关键的原因。回顾一下 TCP 四次挥手的流程：
- 主动关闭方（A）发送
FIN报文，进入FIN_WAIT_1。 - 被动关闭方（B）收到
FIN后回复ACK，进入CLOSE_WAIT。A 收到 ACK 后进入FIN_WAIT_2。 - 被动关闭方（B）发送自己的
FIN，进入LAST_ACK。 - 主动关闭方（A）收到 B 的
FIN后，回复最后一个ACK，并进入TIME_WAIT。
如果没有 TIME_WAIT，A 发完最后一个 ACK 就立即关闭连接，一旦这个 ACK 在网络中丢失：
- B 收不到 ACK，会认为自己的
FIN丢了，于是超时重传FIN。 - 此时 A 已经彻底关闭（
CLOSED），不认识这个连接了。 - A 收到重传的
FIN只能回复RST（重置）。 - B 收到
RST会认为连接异常终止，无法优雅关闭。
有了 TIME_WAIT，A 在等待期间能识别出旧连接的 FIN 重传，重新发送 ACK，确保 B 正常关闭。
2. 防止旧连接报文干扰新连接
TCP 连接由四元组（源 IP、源端口、目的 IP、目的端口）唯一标识。如果连接刚关闭就立即用相同四元组建立新连接，而旧连接中有延迟报文'姗姗来迟'，新连接就会误收脏数据，导致灾难性后果。
TIME_WAIT 等待 2MSL 的时间，足以让本次连接所有还在网络中'游荡'的延迟报文因生存时间到期而消失，为新连接提供一个干净的环境。
服务端 TIME_WAIT 状态过多是什么原因？
在传统模型中，通常客户端主动关闭，所以 TIME_WAIT 多在客户端。但服务端也可能成为主动关闭方，从而积累大量 TIME_WAIT。
简单来说，服务端 TIME_WAIT 过多，是因为服务端主动发起了大量连接的关闭，且这些连接正在等待 2MSL 超时。
常见原因分析
1. 服务端使用了短连接，并且是它主动关闭
这是最常见的原因。例如一些服务端程序（如传统 HTTP/1.0 服务器）处理完请求响应后，直接主动发起 FIN 挥手。
- 场景：高并发下，服务端每秒处理成千上万个请求，每个请求都新建一个连接并在结束后主动关闭。
- 结果：大量连接进入
TIME_WAIT，受系统参数net.ipv4.tcp_fin_timeout（默认 60 秒）控制，高峰期积压数量可能非常庞大。
2. 客户端的非正常行为
有时候问题并非服务端自身引起，而是客户端异常导致的。
