TCP 三次握手：高延迟下建连为什么慢
打开网页前，TCP 要先握三次手。小够讲清三次握手的过程、高延迟如何放大建连时间、不同延迟下的实测体感差异，以及 HTTP/2 和 QUIC 的优化思路。
我是小够。今天讲个协议层的小知识：TCP 三次握手，以及它和高延迟的关系。
握手的过程
两台机器建立 TCP 连接，要先"对上暗号"，来回三趟：
- 你 → 服务器：SYN（我想连你）
- 服务器 → 你：SYN+ACK（行，我也在）
- 你 → 服务器：ACK（好，开始吧）
三趟跑完，连接才算建立，数据才能传。这个过程在每次新建连接时都要来一遍。
高延迟的放大效应
看出问题了吗？建连本身就要 1.5 个来回（RTT）。算笔账：
| 延迟（RTT） | 建连耗时 | 体感 |
|---|---|---|
| 30ms（同城） | 约 45ms | 无感 |
| 150ms（美国西海岸） | 约 225ms | 轻微等待 |
| 300ms（晚高峰拥堵） | 约 450ms | 明显卡顿 |
更惨的是 HTTPS，还要再加 TLS 握手的 1–2 个来回。一个高延迟下的 HTTPS 请求，光"打招呼"就可能花掉一秒多，网页内容还没开始传。
谁最受伤
- 短连接多的应用：一个网页几十个小请求（图片、CSS、JS），每个都建连，高延迟下慢得明显。这就是为什么高延迟 VPS 打开网站，总觉得"转圈多一会儿"。
- API 调用：每次请求都建连，延迟直接加到响应时间上。150ms 的延迟，API 响应至少慢 200ms 起步。
- SSH 首次连接：每次 SSH 连上去，也要经过握手，高延迟下会感觉"连上有个明显的停顿"。连上之后打字是另一回事，那是延迟本身的影响。
优化的思路
协议层面早就想到了这些问题：
- 长连接（Keep-Alive）：一次建连，多次复用，别每次都握手。网页和 API 都应该开。
- HTTP/2 多路复用：一个连接并行传多个请求，建连次数大幅减少。
- QUIC（HTTP/3 的基础）：基于 UDP，握手更快，还支持 0-RTT 恢复连接——断线重连几乎不用重新握手，是弱网高延迟场景的救星。截至撰写时（2025 年 4 月），主流网站和 CDN 已广泛支持。
和买VPS的关系
延迟低的机器，不只是"ping 值好看"，每次建连都快一截。做网站、做 API 服务，选延迟低的线路，省的是每一次握手的时间。积少成多，这就是"跟手"的感觉的来源之一。
反过来，如果你的业务是长连接（比如 WebSocket、游戏服），建连慢一次之后影响就小了，这时延迟本身比握手更重要。看场景下菜，别一概而论。
四次挥手：断开也要打招呼
建立要三次握手，断开要四次挥手：FIN、ACK、FIN、ACK。好消息是，断开慢没人感知；坏消息是，短连接频繁建连断连，握手的开销会被放大好几倍。
这也是为什么高并发的短连接场景（比如抢购、秒杀）对延迟极度敏感：每次请求都要经历"握手慢 + 挥手"，延迟的每一毫秒都会被放大。
TCP 慢启动：刚开始都保守
TCP 还有个"慢启动"机制：连接刚建立时不敢 full speed，先小批量发，确认没丢包再加速。高延迟下，慢启动的爬坡更慢，短传输还没爬到顶就结束了。
所以高延迟影响的不只是建连那一下，是整个传输的前半段。长连接+大文件传输受影响小，短连接+小文件受影响大。
挥手为什么是四次
建立要三次，断开要四次，因为关闭是"双向"的：A 说"我发完了"，B 回"收到"，B 再说"我也发完了"，A 回"收到"。两边都要确认，所以多一次。
好消息：断开慢没人感知。坏消息：短连接频繁建连断连，握手+挥手的开销会被放大。这也是高并发短连接对延迟极度敏感的原因。
一句话总结
三次握手把延迟放大了 1.5 倍，HTTPS 还要再加码。高延迟下，建连慢是协议决定的，谁都躲不掉；能做的就是选延迟低的线路，以及用好长连接和新协议。