网络设计第十三问：连接管理------三次握手四次挥手的设计逻辑
两个不知道对方状态的进程------要建立一条可靠通道------靠的是几轮消息。不是随便选几个数字------是在确认双方的收发能力之后才信任这条通道。
文章目录
一、三向握手的本质
TCP 三次握手回答了三个问题：
- 你的发送→我的接收链路畅通吗？
- 我的发送→你的接收链路畅通吗？
- 双方的初始序列号已交换！
三句消息：
- SYN → 对方：我发起连接------我的序列号是 X
- SYN-ACK ← 对方回复：接受------我的序列号是 Y------确认收到你的 X
- ACK →对方确认：收到你的 Y
三句话之后------两个端点都知道对方的初始序列号------现在可以双向发送有序数据了。
但如果其中某一方不可达------只发 SYN------不等 ACK------超时重发------三次后放弃------这就是连接超时的根源。如果你在省平台调市县库------市县库没回复------全栈无响应------不是拥堵------是对方系统不可达的三大行标志。
二、四次挥手
TCP 是全双工------可以双向同时关。四次挥手------两方各自独立地关闭自己的发送：
一方发 FIN 端关闭请求------另一方回 ACK------确认收到------告对端已不再发------但对方可能还没发完------还得发完后再关------于是结束时------每条端的 FIN 和 ACK 是分开的------所以四个段才完成------这是对称的优雅关闭。
但在日常的 HTTP------客户端最后关------FIN 一发------服务器 ACK 回------然后服务器也发 FIN------这一整段经常被合并进同一个段的 ACK 部分------实际是三段也常见------不一定是四个独立段。
超时跟等待------TIME_WAIT------保证最后一个 ACK 对方如果收不到------可以重发 FIN------不会因过早释放连接而产生端口复用冲突。在 Windows 上 TIME_WAIT 默认是 120 秒。
三、连接管理的应用------业务层的握手
TCP 只保证连接到。但如果一个社保查询接口要求先登录------那你在 TCP 之上还要做一次"业务握手"：
- 发 JWT Token 到服务器
- 服务器验证→回 200→开始发业务请求
- 失败→回 401→客户端不继续请求
这是应用层的连接管理 ------它在 TCP 握手之后------确认身份的合法性------而不是只确认网络层的可通信性。在社保系统------这层握手在 TLS 双向认证之上------再加一次接口层鉴权------所以一个社保查询请求从发起至最终落库要经历 TCP 握手 + TLS 握手 + 接口鉴权------每一层都是"发请求→收确认→下一层继续"。
✅ 亮点：三次握手 = 验证双向可通 + 交换初始序列号；四次挥手 = 全双工两方各自独立的关闭；对接社保查询接口的真实多层握手链条。扩展方向：TCP Fast Open 如何省一次 RTT、QUIC 如何把 TLS 握手里内建连接建立。