TCP三次握手与四次挥手：两个“社恐”程序的破冰与告别仪式

在网络世界里，TCP协议绝对是“严谨派”代表——不像UDP那样“发完就跑”，TCP要让两个设备传数据，非得先走一套“确认三连”的破冰流程；而聊完收场时，也得按规矩来一套“告别四步走”，绝不敷衍离场。这两套流程，就是咱们今天要扒透的TCP三次握手（建立连接）与四次挥手（关闭连接）。

其实说白了，三次握手是客户端和服务器的“破冰仪式”，就像两个社恐网友第一次打电话，反复确认信号通不通才敢开唠；而四次挥手则是“体面告别”，好比聊天结束后，双方要反复确认“你说完了吗”“我说完了，你可以挂了”，生怕挂早了漏了重要内容。前面咱们用生活化场景拆解了三次握手的实际流程，接下来就顺着节奏，把四次挥手的通俗逻辑和底层原理一并讲透。

先回顾：三次握手（建立连接）核心流程（实际版）

为了让挥手流程衔接更顺畅，咱们先快速回顾三次握手的实际核心，避免上下文脱节：

• 第一步（客户端→服务器）：客户端发SYN报文发起连接，内核分配临时端口、创建TCB，状态从CLOSED→SYN-SENT；

• 第二步（服务器→客户端）：服务器收SYN后发SYN+ACK报文回应，创建TCB，状态从LISTEN→SYN-RCVD；

• 第三步（客户端→服务器）：客户端收SYN+ACK后发ACK报文（可带数据），状态从SYN-SENT→ESTABLISHED；服务器收ACK后状态→ESTABLISHED，连接正式建立。

连接建立后，双方就可以愉快传输数据了。而当数据传完要关闭连接时，因为TCP是“全双工通信”（双方可同时发数据），不能像建立连接那样简化为三次，必须通过四次交互确认双方都不再发数据，这就是四次挥手的由来。

前置补充：四次挥手的核心前提与关键概念

挥手前先明确两个核心点，避免理解偏差：

1. 全双工通信与关闭逻辑

TCP是全双工协议，客户端和服务器可同时发送数据。因此关闭连接时，要分别确认“客户端→服务器”和“服务器→客户端”两个方向的数据流都已终止，不能一次性关闭双向连接。

2. 新增标记位（FIN）与状态

挥手过程除了用到ACK标记位，还会用到新的标记位FIN（Finish，结束），同时涉及几个新的TCP状态，核心如下：

• 【FIN=1】：表示发送方已无数据要发，请求关闭自己这边的数据流；

• 【FIN-WAIT-1】：发送FIN后等待对方ACK的状态；

• 【CLOSE-WAIT】：收到对方FIN后，确认关闭请求，等待自己这边数据发完再发FIN；

• 【TIME-WAIT】：客户端最后发完ACK后，等待2MSL（报文最大生存时间），确保对方收到FIN的ACK，避免报文丢失导致重发。

四次挥手全流程：社恐式告别+实际底层交互

咱们依然以“手机退出微信”为例，一边用通俗对话理解逻辑，一边补充操作系统内核、报文交互等实际细节，兼顾易懂性与技术深度。

第一步：主动方发起告别请求（FIN+ACK报文，主动关闭）

场景：你点击微信退出登录，客户端（手机）作为主动关闭方，告知服务器“我这边数据发完了，要关连接了”。

实际行为：微信客户端程序调用close()接口，通知内核关闭连接。客户端内核做两件事：

1. 停止发送新数据，将未发完的数据一次性发完，然后构造FIN+ACK报文（FIN=1表示关闭自身数据流，ACK=1确认之前收到的服务器数据），序号seq=u（u是客户端最后一次发数据的序号+1），确认号ack=v（v是服务器最后一次发数据的序号+1）；

2. 发送报文后，释放部分资源，仅保留接收数据的能力（防止服务器还有数据要发）。

拟人对话：客户端（温和）：“服务器大佬，我这边数据都发完了，要关我这边的连接了（FIN=1），你之前发的内容我都收到了（ACK=1），你还有要发的吗？”

状态变化：客户端TCP状态从ESTABLISHED→FIN-WAIT-1，开始计时，等待服务器的ACK回应。

第二步：被动方确认告别请求（ACK报文，等待自身数据发完）

场景：微信服务器收到客户端的告别请求，先确认“收到了”，同时继续处理自己这边未发完的数据（比如最后的登录状态同步）。

实际行为：服务器内核收到FIN+ACK报文后，校验序号、确认号无误，然后：

1. 构造ACK报文（ACK=1），序号seq=v，确认号ack=u+1（告知客户端“你的FIN我收到了，你可以不用等我回应了”）；

2. 发送ACK后，服务器不会立即关闭连接，而是继续发送自身未完成的数据，此时服务器仅关闭“客户端→服务器”的数据流，自身仍可向客户端发数据。

拟人对话：服务器（沉稳）：“收到你的告别请求了（ACK=1），我这边还有点数据没发完，你先等我一下，发完了我再告诉你。”

状态变化：服务器TCP状态从ESTABLISHED→CLOSE-WAIT；客户端收到ACK后，状态从FIN-WAIT-1→FIN-WAIT-2，等待服务器发完数据后发起的FIN报文。

第三步：被动方发起告别请求（FIN+ACK报文，被动关闭）

场景：服务器发完所有数据，告知客户端“我这边也发完了，咱们可以彻底关连接了”。

实际行为：服务器发完剩余数据后，内核构造FIN+ACK报文（FIN=1表示关闭自身数据流，ACK=1确认之前的交互），序号seq=w（w是服务器最后一次发数据的序号+1），确认号ack=u+1（与第二步的ack一致，因为客户端此时已无数据发送），发送给客户端。

拟人对话：服务器（完成收尾）：“我这边数据也发完了，要关我这边的连接了（FIN=1），你之前的消息我都收到了（ACK=1），咱们可以告别了。”

状态变化：服务器TCP状态从CLOSE-WAIT→LAST-ACK，开始计时，等待客户端的最终ACK确认。

第四步：主动方最终确认告别（ACK报文，等待超时）

场景：客户端收到服务器的告别请求，确认双方都无数据要发，给出最终回应，同时等待一段时间确保服务器收到回应。

实际行为：客户端内核收到FIN+ACK报文后，校验无误，然后：

1. 构造ACK报文（ACK=1），序号seq=u+1，确认号ack=w+1（告知服务器“你的FIN我收到了，你可以安全关闭了”），发送给服务器；

2. 发送ACK后，客户端不立即关闭连接，而是进入TIME-WAIT状态，等待2MSL（通常是2分钟左右），确保服务器能收到ACK（若服务器没收到，会重发FIN，客户端可再次回应）。等待超时后，释放所有资源和TCB。

拟人对话：客户端（放心）：“收到你的告别了（ACK=1），我等一会儿再挂，确保你能收到我的回应，咱们下次见～”

状态变化：客户端TCP状态从FIN-WAIT-2→TIME-WAIT（等待2MSL）→CLOSED；服务器收到ACK后，状态从LAST-ACK→CLOSED，释放所有资源，至此双向连接完全关闭。

可视化流程图：三次握手+四次挥手全链路版

结合连接建立、数据传输、连接关闭的完整链路，用Mermaid图还原内核状态、报文交互全流程：

暂时无法在豆包文档外展示此内容

关键差异与核心疑问解答

1. 为啥挥手要四次，握手却只要三次？

核心原因是“全双工通信”与“连接阶段的特殊性”：

• 三次握手时，服务器的SYN（同步连接）和ACK（确认客户端）可以合并为一个SYN+ACK报文——因为此时服务器还没有数据要发，同步和确认可以一次性完成；

• 四次挥手时，服务器收到客户端的FIN后，不能立即发FIN（可能还有数据要发），只能先回一个ACK确认；等数据发完后，再单独发FIN，因此ACK和FIN无法合并，必须分成两步，导致总次数变为四次。

2. TIME-WAIT状态为啥要等2MSL？

主要是两个目的，避免连接残留问题：

• 确保服务器收到最终ACK：若第四步的ACK丢失，服务器会在超时后重发FIN，2MSL的时间足够客户端收到重发的FIN并再次回应；

• 避免旧报文干扰新连接：2MSL是报文在网络中的最大生存时间，等待超时后，网络中该连接的所有旧报文都会失效，后续新连接用相同端口也不会被干扰。

3. 常见坑点（实际场景补充）

• 【CLOSE-WAIT累积】：服务器处于CLOSE-WAIT状态时，若应用程序未及时调用close()发FIN，会导致连接资源泄露，大量CLOSE-WAIT状态会耗尽服务器端口；

• 【TIME-WAIT过多】：高并发场景下，客户端频繁关闭连接会产生大量TIME-WAIT状态，可通过调整内核参数（如缩短2MSL时间、开启端口复用）优化；

• 【半关闭连接】：若一方发了FIN但另一方还在发数据，发FIN的一方会拒绝接收数据，导致数据丢失，因此关闭连接前需确保双方都无数据要发。

总结：TCP连接的“始”与“终”，核心都是“可靠”

TCP三次握手与四次挥手，本质都是围绕“可靠传输”设计的流程：三次握手通过双向确认，确保双方通信能力正常，为数据传输铺路；四次挥手通过分步确认，确保双向数据流都已终止，避免数据丢失或残留。

从社恐式的破冰到体面的告别，TCP用看似繁琐的步骤，弥补了网络传输的不可靠性。实际应用中遇到的“连接超时”“连接重置”“端口耗尽”等问题，本质都和这两套流程的某个环节异常有关——看懂了握手与挥手的底层逻辑，就能快速定位问题根源，再也不是只知现象不知本质的“调包侠”啦～