这个问题问到点子上了——刚啃TCP四次挥手的时候，几乎所有人都会有这个疑惑，我来给你把逻辑掰碎了说：

先搞懂TIME_WAIT的核心作用 #

TIME_WAIT状态本质是TCP设计里的「保险机制」，核心解决两个问题：

• 确保主动方发出的最后一个ACK能让被动方收到，避免被动方因为收不到ACK而一直重发FIN，浪费资源
• 等待网络中旧连接的延迟数据包彻底消失，防止这些残包干扰后续使用相同四元组的新连接

为什么只有主动关闭方需要等？ #

我们结合四次挥手的流程来拆解：

1. 主动方发FIN → 被动方回ACK+FIN → 主动方回ACK → 主动方进入TIME_WAIT；被动方收到ACK后直接关闭连接

第一：被动方不需要为「最后一个ACK的可靠性」负责 #

被动方发完FIN之后，它的核心诉求是：确认主动方已经收到自己的FIN。一旦它收到主动方的ACK，这个诉求就满足了——就算后续ACK丢了（比如网络波动导致ACK没传到被动方），被动方会重发FIN，但这时候处于TIME_WAIT的主动方还保留着连接状态，能重新发一次ACK，让被动方正常关闭。

如果主动方不进入TIME_WAIT，直接关闭连接，那收到被动方重发的FIN时，只能回复RST（复位），被动方会认为连接是异常关闭的，而不是正常完成挥手流程。

反观被动方，它收到ACK后就没有后续需要处理的「确认任务」了，自然不需要等待。

第二：被动方不会面临「旧残包干扰新连接」的风险 #

TCP连接是用**四元组（源IP、源端口、目的IP、目的端口）**唯一标识的：

• 主动关闭方如果是客户端，它的端口是临时端口，下次发起新连接时如果复用这个端口，四元组和旧连接完全一致。如果旧连接的延迟数据包还在网络里，就会被新连接错误接收，导致数据混乱。TIME_WAIT的时长是2MSL（最长报文段寿命），足够让所有旧残包在网络中消失。
• 被动关闭方如果是服务器，它用的是固定监听端口（比如80/443），新连接的客户端端口是随机的，四元组和旧连接不一样，旧残包过来会被直接丢弃；就算被动关闭方是客户端，它下次发起新连接时要么换端口，要么就算复用端口，服务器那边已经没有旧连接的状态了，收到残包会回复RST，不会影响新连接。

关于你提到的「被动方也可能收到错误数据包」 #

没错，但这些数据包不会造成实质问题：被动方关闭连接后，所有针对旧连接的数据包都会触发它回复RST，而RST会告诉发送方「这个连接已经不存在了」，不会干扰任何新连接的正常运行。

内容的提问来源于stack exchange，提问作者Myrfy