图 1：本文封面，点明题目与「TIME_WAIT 的两个理由」这条主线。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料（见文末来源说明），与任何公司的当前招聘无关。「TCP 为什么是四次挥手」人人会背，面试官真正的杀招是下一句：「主动关闭方最后为什么要等一个 TIME_WAIT？等多久？」
想象面试现场，面试官问：「说说 TCP 关闭连接的过程，以及 TIME_WAIT 这个状态是干什么的。」
第一步，审题：题目有两层。
第一层是流程：四次挥手各自谁在发、谁在收，状态怎么迁移。第二层是设计动机：TIME_WAIT 为什么是 2MSL，不等会怎样。只答第一层，等于承认自己会背不会想；第二层才是区分度所在。
第二步，基础回答：四次挥手的时序。
TCP 是全双工的，两个方向各自独立关闭，所以关闭需要四个动作。一，主动关闭方发 FIN，表示「我的数据发完了」，自己进入 FIN_WAIT_1。二，被动方回 ACK，进入 CLOSE_WAIT——注意此时它可能还有数据没发完，所以不能立刻跟着发 FIN，这就是四次而不是三次的原因。主动方收到 ACK 进入 FIN_WAIT_2。三，被动方把剩余数据发完，再发自己的 FIN，进入 LAST_ACK。四，主动方回 ACK，进入 TIME_WAIT；被动方收到这个 ACK，连接彻底关闭。而主动方还要在 TIME_WAIT 里停留 2MSL——MSL 是报文段在网络中的最长存活时间，2MSL 就是两倍。
第三步，进阶回答：等 2MSL 的两个理由。
理由一，让最后一个 ACK 有重发的机会。如果主动方回完 ACK 立刻消失，而这个 ACK 丢了，被动方等不到确认就会重发 FIN——此时对端已经没人应答，被动方只能异常收场。留着 TIME_WAIT，收到重发的 FIN 就再补一个 ACK，对端才能正常关闭。RFC 9293 把这个等待列为协议要求：进入 TIME-WAIT 的端点必须停留 2 倍 MSL。
理由二，让这条连接的旧报文彻底消失。网络里的报文可能迷路、迟到。如果不等就重用同样的地址和端口建立新连接，上一个连接迟到的报文可能恰好落进新连接的接收窗口，造成数据串扰。等足 2MSL——去程一个 MSL、回程一个 MSL——这条连接的所有报文都已在网络中寿终正寝，新连接拿到的是一张干净的桌子。RFC 9293 也明确把「限制同地址连接的复用速率」列为 TIME-WAIT 的职责。
图 2：四次挥手时序与 TIME_WAIT 存在的两个理由。
第四步，可能的追问。
「为什么是 2MSL 而不是 1MSL？」因为要考虑往返：FIN 或 ACK 在路上最多耗一个 MSL，对端的回应回来再耗一个 MSL，两个 MSL 之后，这条连接相关的报文无论正走反走都已超期。顺带一提，规范中 MSL 取值为两分钟，并注明这是工程取值、可按经验调整——所以不同操作系统上的实际等待时长不同，属于实现细节而非协议承诺。「大量 TIME_WAIT 一定是故障吗？」不是，它只是主动关闭方的正常驻留状态；真正要警惕的是短连接比例过高这个事实本身。
第五步，工程视角：TIME_WAIT 多了怎么办。
高并发短连接场景里，主动关闭的一方会堆起大量 TIME_WAIT 连接，占着端口与内存不放。很多人第一反应是调内核参数把时间调短，但这两个理由告诉我们：TIME_WAIT 不是缺陷，是协议在帮你兜底。正解是减少短连接本身——开 keep-alive、用连接池复用，让连接不要频繁建了拆、拆了建。内核参数（如端口范围、时间戳选项下的复用）是最后手段，而且要清楚自己在削弱哪一层保护。
易错点清单。
一，把四次挥手背成三次——中间那次 ACK 和 FIN 分开发，恰恰是因为被动方还有数据要发。二，答不出 2MSL 的两个理由，只说「防止丢包」这种模糊话。三，认为 TIME_WAIT 是异常状态、应该彻底消灭。四，把「谁主动关谁等 TIME_WAIT」记反——被动方收到最后的 ACK 就直接关闭，不进 TIME_WAIT。
回到面试现场，建议的答题节奏：先画四次挥手时序（顺便点破为什么不是三次），再讲 2MSL 的两个理由，最后补一句工程上的正确应对是连接复用。流程、动机、实战三层都有，这题就答满了。
高频调用大模型 API 的服务， TIME_WAIT 堆积是真实会遇到的现象。你在生产里见过 TIME_WAIT 引发的问题吗，最后是怎么解的？欢迎分享。
参考资料
- RFC 9293: Transmission Control Protocol (TCP)（IETF 标准文档：TCP 状态机；进入 TIME-WAIT 的端点必须停留 2 倍 MSL；TIME-WAIT 限制同地址连接的复用速率，防止旧报文串扰新连接） — https://www.rfc-editor.org/rfc/rfc9293