Spring with AI (): 搜索扩展——向量数据库与RAG(上)悄

先回顾三次握手建立连接核心流程实际版为了让挥手流程衔接更顺畅咱们先快速回顾三次握手的实际核心避免上下文脱节第一步客户端→服务器客户端发SYN报文发起连接内核分配临时端口、创建TCB状态从CLOSED→SYN-SENT第二步服务器→客户端服务器收SYN后发SYNACK报文回应创建TCB状态从LISTEN→SYN-RCVD第三步客户端→服务器客户端收SYNACK后发ACK报文可带数据状态从SYN-SENT→ESTABLISHED服务器收ACK后状态→ESTABLISHED连接正式建立。连接建立后双方就可以愉快传输数据了。而当数据传完要关闭连接时因为TCP是“全双工通信”双方可同时发数据不能像建立连接那样简化为三次必须通过四次交互确认双方都不再发数据这就是四次挥手的由来。前置补充四次挥手的核心前提与关键概念挥手前先明确两个核心点避免理解偏差1. 全双工通信与关闭逻辑TCP是全双工协议客户端和服务器可同时发送数据。因此关闭连接时要分别确认“客户端→服务器”和“服务器→客户端”两个方向的数据流都已终止不能一次性关闭双向连接。2. 新增标记位FIN与状态挥手过程除了用到ACK标记位还会用到新的标记位FINFinish结束同时涉及几个新的TCP状态核心如下【FIN1】表示发送方已无数据要发请求关闭自己这边的数据流【FIN-WAIT-1】发送FIN后等待对方ACK的状态【CLOSE-WAIT】收到对方FIN后确认关闭请求等待自己这边数据发完再发FIN【TIME-WAIT】客户端最后发完ACK后等待2MSL报文最大生存时间确保对方收到FIN的ACK避免报文丢失导致重发。四次挥手全流程社恐式告别实际底层交互咱们依然以“手机退出微信”为例一边用通俗对话理解逻辑一边补充操作系统内核、报文交互等实际细节兼顾易懂性与技术深度。第一步主动方发起告别请求FINACK报文主动关闭场景你点击微信退出登录客户端手机作为主动关闭方告知服务器“我这边数据发完了要关连接了”。实际行为微信客户端程序调用close()接口通知内核关闭连接。客户端内核做两件事停止发送新数据将未发完的数据一次性发完然后构造FINACK报文FIN1表示关闭自身数据流ACK1确认之前收到的服务器数据序号sequu是客户端最后一次发数据的序号1确认号ackvv是服务器最后一次发数据的序号1发送报文后释放部分资源仅保留接收数据的能力防止服务器还有数据要发。拟人对话客户端温和“服务器大佬我这边数据都发完了要关我这边的连接了FIN1你之前发的内容我都收到了ACK1你还有要发的吗”状态变化客户端TCP状态从ESTABLISHED→FIN-WAIT-1开始计时等待服务器的ACK回应。第二步被动方确认告别请求ACK报文等待自身数据发完场景微信服务器收到客户端的告别请求先确认“收到了”同时继续处理自己这边未发完的数据比如最后的登录状态同步。实际行为服务器内核收到FINACK报文后校验序号、确认号无误然后构造ACK报文ACK1序号seqv确认号acku1告知客户端“你的FIN我收到了你可以不用等我回应了”发送ACK后服务器不会立即关闭连接而是继续发送自身未完成的数据此时服务器仅关闭“客户端→服务器”的数据流自身仍可向客户端发数据。拟人对话服务器沉稳“收到你的告别请求了ACK1我这边还有点数据没发完你先等我一下发完了我再告诉你。”状态变化服务器TCP状态从ESTABLISHED→CLOSE-WAIT客户端收到ACK后状态从FIN-WAIT-1→FIN-WAIT-2等待服务器发完数据后发起的FIN报文。第三步被动方发起告别请求FINACK报文被动关闭场景服务器发完所有数据告知客户端“我这边也发完了咱们可以彻底关连接了”。实际行为服务器发完剩余数据后内核构造FINACK报文FIN1表示关闭自身数据流ACK1确认之前的交互序号seqww是服务器最后一次发数据的序号1确认号acku1与第二步的ack一致因为客户端此时已无数据发送发送给客户端。拟人对话服务器完成收尾“我这边数据也发完了要关我这边的连接了FIN1你之前的消息我都收到了ACK1咱们可以告别了。”状态变化服务器TCP状态从CLOSE-WAIT→LAST-ACK开始计时等待客户端的最终ACK确认。第四步主动方最终确认告别ACK报文等待超时场景客户端收到服务器的告别请求确认双方都无数据要发给出最终回应同时等待一段时间确保服务器收到回应。实际行为客户端内核收到FINACK报文后校验无误然后构造ACK报文ACK1序号sequ1确认号ackw1告知服务器“你的FIN我收到了你可以安全关闭了”发送给服务器发送ACK后客户端不立即关闭连接而是进入TIME-WAIT状态等待2MSL通常是2分钟左右确保服务器能收到ACK若服务器没收到会重发FIN客户端可再次回应。等待超时后释放所有资源和TCB。拟人对话客户端放心“收到你的告别了ACK1我等一会儿再挂确保你能收到我的回应咱们下次见”状态变化客户端TCP状态从FIN-WAIT-2→TIME-WAIT等待2MSL→CLOSED服务器收到ACK后状态从LAST-ACK→CLOSED释放所有资源至此双向连接完全关闭。可视化流程图三次握手四次挥手全链路版结合连接建立、数据传输、连接关闭的完整链路用Mermaid图还原内核状态、报文交互全流程暂时无法在豆包文档外展示此内容关键差异与核心疑问解答1. 为啥挥手要四次握手却只要三次核心原因是“全双工通信”与“连接阶段的特殊性”三次握手时服务器的SYN同步连接和ACK确认客户端可以合并为一个SYNACK报文——因为此时服务器还没有数据要发同步和确认可以一次性完成四次挥手时服务器收到客户端的FIN后不能立即发FIN可能还有数据要发只能先回一个ACK确认等数据发完后再单独发FIN因此ACK和FIN无法合并必须分成两步导致总次数变为四次。2. TIME-WAIT状态为啥要等2MSL主要是两个目的避免连接残留问题确保服务器收到最终ACK若第四步的ACK丢失服务器会在超时后重发FIN2MSL的时间足够客户端收到重发的FIN并再次回应避免旧报文干扰新连接2MSL是报文在网络中的最大生存时间等待超时后网络中该连接的所有旧报文都会失效后续新连接用相同端口也不会被干扰。3. 常见坑点实际场景补充【CLOSE-WAIT累积】服务器处于CLOSE-WAIT状态时若应用程序未及时调用close()发FIN会导致连接资源泄露大量CLOSE-WAIT状态会耗尽服务器端口【TIME-WAIT过多】高并发场景下客户端频繁关闭连接会产生大量TIME-WAIT状态可通过调整内核参数如缩短2MSL时间、开启端口复用优化【半关闭连接】若一方发了FIN但另一方还在发数据发FIN的一方会拒绝接收数据导致数据丢失因此关闭连接前需确保双方都无数据要发。总结TCP连接的“始”与“终”核心都是“可靠”TCP三次握手与四次挥手本质都是围绕“可靠传输”设计的流程三次握手通过双向确认确保双方通信能力正常为数据传输铺路四次挥手通过分步确认确保双向数据流都已终止避免数据丢失或残留。吵谑躺食