小龙虾WorkBuddy技能与插件深度解析

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

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

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

第一步（客户端→服务器）：客户端发送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（报文最大生存时间）。这主要是为了确保对方能收到这个ACK，避免因报文丢失导致连接无法正常关闭。

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

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

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

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

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

首先，停止发送新数据，并将发送缓冲区里未发完的数据一次性发完。然后，构造一个FIN+ACK报文（FIN=1表示关闭自身数据流，ACK=1用于确认之前收到的服务器数据）。报文中的序号seq=u（u是客户端最后一次发送数据的序号+1），确认号ack=v（v是服务器最后一次发送数据的序号+1）。

发送报文后，客户端会释放部分资源，但会保留接收数据的能力——这是为了防止服务器那边还有数据要发过来。

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

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

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

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

实际行为：服务器内核收到FIN+ACK报文，校验序号和确认号无误后，会构造一个ACK报文（ACK=1），序号seq=v，确认号ack=u+1（这个u+1就是在告诉客户端：“你的FIN我收到了，下一个我期待你发u+1序号的数据，不过你既然要关了，那就不用发了”）。

发送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报文，校验无误后，会构造一个ACK报文（ACK=1），序号seq=u+1，确认号ack=w+1（告知服务器：“你的FIN我收到了，你可以安全关闭了”），并发送给服务器。

发送ACK后，客户端并不会立即关闭连接，而是进入一个关键的TIME-WAIT状态，等待2MSL（通常是2分钟左右）。这段时间是为了确保服务器能收到这个ACK——如果服务器没收到，它会超时重发FIN，处于TIME-WAIT状态的客户端可以再次回应。等待超时后，客户端才会释放所有资源和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并再次回应ACK。

避免旧报文干扰新连接：2MSL是一个报文在网络中的最大生存时间。等待2MSL后，属于这个连接的所有旧报文都会从网络中消失。这样，后续的新连接即使复用相同的端口号，也不会被旧的、延迟到达的报文干扰。

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

【CLOSE-WAIT累积】：当服务器处于CLOSE-WAIT状态时，如果应用程序没有及时调用close()来发送FIN，就会导致连接资源无法释放。大量连接堆积在CLOSE-WAIT状态，会耗尽服务器的端口和内存资源。

【TIME-WAIT过多】：在高并发短连接场景下，作为主动关闭方的客户端（也可能是服务器）会频繁关闭连接，产生大量TIME-WAIT状态的连接。这可能会占用大量端口资源。通常可以通过调整内核参数（如缩短2MSL时间、开启SO_REUSEADDR端口复用选项）来优化。

【半关闭连接】：如果一方发送了FIN但另一方还在继续发送数据，那么发送FIN的一方会拒绝接收这些数据，导致数据丢失。因此，关闭连接前，应用层协议需要确保双方都已无数据要发送。

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

说到底，TCP的三次握手与四次挥手，其本质都是围绕“可靠传输”这一核心目标设计的流程。三次握手通过双向确认，确保双方的通信能力正常，为数据传输铺平道路；而四次挥手则通过分步确认，确保双向数据流都已安全终止，避免数据丢失或连接资源残留。理解了这个设计初衷，再回头看这些状态与报文，就会清晰许多。