网络设计第十三问连接管理——三次握手四次挥手的设计逻辑两个不知道对方状态的进程——要建立一条可靠通道——靠的是几轮消息。不是随便选几个数字——是在确认双方的收发能力之后才信任这条通道。文章目录网络设计第十三问连接管理——三次握手四次挥手的设计逻辑一、三向握手的本质二、四次挥手三、连接管理的应用——业务层的握手一、三向握手的本质TCP 三次握手回答了三个问题你的发送→我的接收链路畅通吗我的发送→你的接收链路畅通吗双方的初始序列号已交换三句消息SYN→ 对方我发起连接——我的序列号是 XSYN-ACK← 对方回复接受——我的序列号是 Y——确认收到你的 XACK→对方确认收到你的 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 握手里内建连接建立。
