TCP TIME_WAIT 状态的作用
TIME_WAIT（俗称 2MSL 等待状态）是 TCP 连接主动关闭方在发送最后一次 ACK 确认报文后进入的状态。该状态需等待 2 倍的**最大报文段生存时间（MSL）**后，才会最终进入 CLOSED 状态并释放资源。设计该状态主要有两个核心原因：
原因一：可靠地终止 TCP 连接（确保最后的 ACK 能到达对方）
回顾 TCP 四次挥手流程：
- 主动关闭方（A）发送
FIN，进入FIN_WAIT_1。 - 被动关闭方（B）回复
ACK，进入CLOSE_WAIT。A 收到后进入FIN_WAIT_2。 - B 发送
FIN，进入LAST_ACK。 - A 收到
FIN后回复最后一个ACK，并进入TIME_WAIT。
若没有 TIME_WAIT，A 发送完 ACK 后立即关闭连接：
- 问题场景：A 发出的最后一个 ACK 在网络中丢失。
- 后果：B 未收到 ACK 会超时重传
FIN。此时 A 已处于CLOSED状态，收到重传的FIN后会回复RST报文。B 收到RST会认为连接异常终止，而非优雅关闭。 TIME_WAIT的作用：A 在TIME_WAIT期间若收到 B 重传的FIN，会重新发送 ACK，确保 B 能正常关闭。
原因二：让旧连接的重复报文段在网络中自然消失
TCP 连接由四元组 （源IP，源端口，目的IP，目的端口） 唯一标识。若旧连接关闭后立即用相同四元组建立新连接：
- 问题场景：旧连接中因网络延迟的报文段在连接关闭后才到达。
- 后果：迟到的旧报文会被新连接误认为有效数据，导致数据混乱（迷途的重复报文段）。
TIME_WAIT的作用：等待 2MSL 时间，确保本次连接所有方向的报文段均从网络中彻底消失，为新连接提供干净的网络环境。
服务端 TIME_WAIT 状态过多的原因
传统 C/S 模型中，通常由客户端主动关闭连接，因此 TIME_WAIT 多见于客户端。但若服务端出现大量 TIME_WAIT，说明服务端主动发起了大量连接的关闭。常见原因如下：
原因一：服务端使用短连接并主动关闭
这是最常见的原因。例如传统 HTTP/1.0 服务器处理完请求后主动发送 FIN 挥手。若并发量高，每秒处理大量请求，服务端会积累大量处于 TIME_WAIT 状态的连接，并在系统参数（如 net.ipv4.tcp_fin_timeout，默认 60 秒）规定的时间内等待，导致数量激增。
原因二：客户端异常行为或超时
- 客户端不主动关闭：部分客户端程序未正确实现连接关闭逻辑。服务端为避免资源耗尽，会触发 Keep-Alive 超时机制并主动关闭连接，从而产生
TIME_WAIT。 - 客户端崩溃或网络异常：客户端意外断开后，服务端通过 TCP Keepalive 等机制检测到异常，主动关闭连接。
