四次挥手

四次挥手是 TCP(传输控制协议)终止一条连接时所采用的标准流程:通信双方通过依次交换四个报文段,分别关闭各自方向的数据通道,从而在保证数据不丢失的前提下安全释放连接。

概述

TCP 是全双工协议,一条连接包含两个独立的传输方向。断开连接时,任何一方发送 FIN 报文只表示「我这边不再发数据了」,并不影响对方继续发送。因此双方需要各自完成一次「FIN + ACK」的交互,总共四个报文,这就是「四次挥手」名称的由来。它与建立连接时的「三次握手」相对应,共同构成 TCP 连接生命周期的两端。

挥手过程中,主动关闭方会经历 FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT 等状态,被动关闭方则经历 CLOSE_WAIT、LAST_ACK 等状态。理解这些状态迁移,是排查服务器连接堆积、端口耗尽等线上问题的基础。

挥手过程

• 第一次挥手:主动关闭方发送 FIN,表示己方数据发送完毕。
• 第二次挥手:被动关闭方回复 ACK 确认,此时连接处于半关闭状态,被动方仍可继续发送剩余数据。
• 第三次挥手:被动关闭方数据发完后,也发送 FIN 请求关闭。
• 第四次挥手:主动关闭方回复 ACK,并进入 TIME_WAIT 状态,等待一段时间后连接彻底关闭。

为什么需要 TIME_WAIT

主动关闭方在发出最后一个 ACK 后并不立即释放连接,而是等待约两倍报文最大生存时间(2MSL)。这样做一是保证最后的 ACK 若丢失,对方重发 FIN 时还能再次确认;二是让旧连接的报文在网络中自然消亡,避免干扰之后复用相同地址端口的新连接。

常见问题

问:为什么建立连接是三次握手,断开却要四次挥手?答:握手时,确认与同步请求可以合并在一个报文里发送;而挥手时,被动方收到 FIN 后可能还有数据没发完,ACK 与自己的 FIN 通常无法合并,只能分开发送,所以多出一次。

问:服务器上出现大量 CLOSE_WAIT 是什么原因?答:说明对端已关闭连接,而本端应用程序没有及时调用关闭操作,通常是代码中遗漏了关闭连接或资源回收的逻辑,需要排查程序而非网络。

问:四次挥手一定是四个报文吗?答:不一定。若被动方没有数据要发,部分实现会把 ACK 与 FIN 合并发送,表现为「三次挥手」;这属于协议允许的优化,不影响正确性。