TCP 四次挥手详解
TCP 协议作为一种可靠的面向连接的传输层协议，不仅在连接建立时需要"三次握手"，在连接断开时更需要严谨的机制来保证数据完整、双方协同------这就是著名的"四次挥手"。
一、四次挥手流程图解
服务器 客户端 服务器 客户端 FIN (主动关闭，第一次挥手) ACK (对FIN确认，第二次挥手) FIN (被动关闭，第三次挥手) ACK (对FIN确认，第四次挥手)
二、详细步骤说明
1. 第一次挥手（客户端 -> 服务器，FIN）
- 客户端 发送一个
FIN报文通知服务器："我没有数据要发了，要关闭连接了"，但还有能力继续接收数据。 - 客户端 状态转为
FIN_WAIT_1。
2. 第二次挥手（服务器 -> 客户端，ACK）
- 服务器 收到
FIN后，放回一个ACK报文，告知客户端："我已知晓"。 - 此时服务器还可以继续向客户端发送数据。
- 客户端 状态转为
FIN_WAIT_2，服务器 转为CLOSE_WAIT。
3. 第三次挥手（服务器 -> 客户端，FIN）
- 等服务器数据也发送完毕后，主动向客户端发送
FIN报文，通知客户端："我这边也已经没有数据要发了"。 - 服务器进入
LAST_ACK状态。
4. 第四次挥手（客户端 -> 服务器，ACK）
- 客户端 收到服务器的
FIN后，回复ACK报文，表示"我知道了"。 - 客户端进入
TIME_WAIT状态，等待2个MSL（最长报文寿命）后才真正关闭，确保服务器收到 ACK。 - 服务器收到 ACK 后就彻底关闭连接。
三、为什么是四次挥手，而不是三次？
- TCP连接是全双工：双方的数据流独立关闭，单靠一方关闭并不意味着另一方也可以立即关闭。
- ACK 与 FIN 分离 ：
- 当客户端请求关闭时，服务器可能还有数据没发完，不能在确认FIN（ACK）后马上也发送FIN。
- 所以服务器需先单独回复一个 ACK，然后等自己把剩余数据都发送完毕，再发出 FIN。
- 这就导致 FIN 和 ACK 不能合并到一个包里完成，所以需要四次挥手。
四、四次挥手流程简表
| 步骤 | 方向 | 报文 | 客户端状态 | 服务器状态 |
|---|---|---|---|---|
| 1 | 客户端 → 服务器 | FIN | FIN_WAIT_1 | ESTABLISHED |
| 2 | 服务器 → 客户端 | ACK | FIN_WAIT_2 | CLOSE_WAIT |
| 3 | 服务器 → 客户端 | FIN | TIME_WAIT | LAST_ACK |
| 4 | 客户端 → 服务器 | ACK | CLOSED | CLOSED |
五、相关问题解答
Q: 为什么客户端进入 TIME_WAIT 状态要等 2MSL？
- 避免上一次连接的残留报文影响下一次连接。
- 确保服务器收到最后的 ACK 报文；如果丢失，服务器会重发 FIN，客户端可以再次发送 ACK。
Q: FIN 和 ACK 能合并为一个包吗？
- 理论上能，但通常不能。原因是双方是否可以"同时"关闭连接无法保证。
- 很多时候一方 ACK 后还有未发完的数据，不能立即发送 FIN。
六、总结
TCP 四次挥手是保证双方完全、可靠关闭连接的重要机制。它使得每一端都能独立关闭自己的数据发送，并通过分开的 FIN 和 ACK，避免数据丢失或误关闭，体现了 TCP 的健壮性与严谨性。
参考阅读：