TCP 三次握手与四次挥手：可靠传输、状态转换与队头代价

主题边界

TCP 题的重点不是“发三次包建立连接”，而是为什么需要同步序列号、确认收发能力，以及这些设计如何影响 HTTP 延迟和头阻塞。
挥手也不是单纯的“断开四次”，而是因为 TCP 是全双工协议。

机制与流程

三次握手用于同步双方的初始序列号并确认两边都具备收发能力：客户端发 SYN，服务端回 SYN+ACK，客户端再发 ACK。
连接建立后，TCP 通过序列号、确认应答、重传、滑动窗口和拥塞控制提供可靠有序传输。
四次挥手出现的根因是 TCP 全双工：一方发送 FIN 只表示自己不再发送数据，另一方仍可能继续发送未完成的数据。

关键差异

TCP 保证的是字节流顺序和可靠到达，不保留应用层消息边界；HTTP 报文边界由上层协议自己定义。
HTTP/2 虽然在应用层多路复用，但底层仍依赖单个 TCP 连接，因此丢包时多个 stream 仍会受重传影响。

边界条件

不要把三次握手解释成“第三次只是告诉服务端连接成功”就结束；更准确的是双方最终确认序列号和接收能力都已就绪。
TCP 建连成功不代表 HTTP 一定成功，TLS、应用协议和服务端处理都还在后面。

工程落点

高 RTT 环境下，连接建立次数是非常真实的性能成本，这也是 keep-alive、HTTP/2/3、连接池存在的原因。
浏览器瀑布图里的 Initial connection、SSL 等时间段都能映射到不同网络阶段。

相关主题