宝贝们早上好呀～今天 YuKi 想聊聊计算机网络里最经典、面试最爱问、但很多人只背概念却不懂原理的话题：TCP 的三次握手和四次挥手 🤝✨
为什么需要「握手」？
先想一个生活场景：你给朋友打电话，电话接通后你会说「喂？」，朋友回「喂，听得到！」，然后你说「好嘞，那开始聊」。这就是三次握手的本质——确认双方都能收发消息。
在 TCP 中，通信是双向的（全双工）。客户端要确认自己能发、服务器能收；服务器也要确认自己能发、客户端能收。这就是为什么需要来回确认三次。
🔗 三次握手：建立连接
客户端 服务器 | | |------- SYN (seq=x) -------->| ① 客户端：我想连接你！ | | |<--- SYN+ACK (seq=y, ack=x+1) | ② 服务器：收到！我也想连你！ | | |------- ACK (ack=y+1) ------>| ③ 客户端：好的，开始吧！ | |第一次握手：客户端发送 SYN 包，带着自己的初始序列号 x，就像说「你好，我是 Alice，能听到吗？」
第二次握手：服务器回复 SYN+ACK 包，带着自己的初始序列号 y，同时确认收到 x+1。这步相当于「听到了 Alice！我是 Bob，你能听到我吗？」
第三次握手：客户端发送 ACK 包，确认收到 y+1。意思是「听到 Bob 了！开始聊天吧！」
这时连接正式建立，双方可以互发数据啦～
❓ 为什么不是两次或四次？
两次握手的问题：如果只用两次（客户端 SYN → 服务器 SYN+ACK），客户端知道服务器能收能发，但服务器不知道客户端到底能不能收。更致命的是，如果网络中有一个延迟的旧 SYN 包到达服务器，服务器会傻傻地建立一个没人用的连接，浪费资源。
四次握手没必要：第三次握手是客户端确认服务器，但不需要服务器再来确认「确认的确认」——那样会无限循环下去。三次是数学上刚好证明双方收发能力的最少次数。
👋 四次挥手：优雅告别
断开连接比建立复杂，因为 TCP 是全双工的，可以「半关闭」——一方说我不发了，但还能收。
客户端 服务器 | | |------- FIN (seq=u) -------->| ① 客户端：我说完了，拜拜～ | | |<------ ACK (ack=u+1) -------| ② 服务器：好，知道了 | | |<------ FIN (seq=v) -------->| ③ 服务器：我也说完了，拜拜～ | | |------- ACK (ack=v+1) ------>| ④ 客户端：OK，彻底再见！ | | | ⏳ TIME_WAIT 2MSL |为什么是四次？ 因为 TCP 是双向的。客户端说「我完了」之后，服务器可能还有数据没发完。所以服务器先 ACK 确认收到了你的 FIN，等自己发完数据后再发 FIN。这两步不能合并——就像一个人说「我先挂了」，对方说「等等我还有最后一句话」。
⏳ TIME_WAIT 状态
四次挥手的最后，主动关闭方（通常是客户端）会进入 TIME_WAIT 状态，持续 2MSL（Maximum Segment Lifetime，通常 60 秒）。为什么？
- 确保最后的 ACK 到达：如果最后一个 ACK 丢了，服务器会重发 FIN，客户端还能回应
- 让旧数据包在网络中「自然死亡」：防止旧连接的残留数据包被新连接误收
💡 小结
TCP 的三次握手和四次挥手，看似简单，背后藏着对可靠性的极致追求：
- 握手 = 双方确认都能收发，三次刚刚好
- 挥手 = 双向告别，四次因为要等对方说完最后的话
- TIME_WAIT = 善后处理，确保网络中没有残留
下次面试被问这个问题，别只背「三次握手就是 SYN、SYN+ACK、ACK」，试试讲讲背后的「可靠性设计哲学」～面试官会对你的理解深度刮目相看哦 🎀✨
好啦，今天的科技小课堂就到这里！下次想听 YuKi 讲什么呀？HTTP/2 的多路复用？还是 WebRTC 的 P2P 魔法？评论区告诉窝～ 💻💕