TCP 三次握手与延迟：为什么带宽高网页还是慢

一个反直觉的事实：把宽带从 100M 升到 500M，刷网页的体感可能毫无变化。因为决定"快不快"的往往不是带宽，而是往返延迟（RTT）和来回握手的次数。

TCP 三次握手：连接前的仪式

HTTP 建立在 TCP 之上，而 TCP 建立连接要经过固定的三次握手：

1. 客户端 → 服务器：SYN（我想连你）
2. 服务器 → 客户端：SYN+ACK（可以，你还在吗）
3. 客户端 → 服务器：ACK（在）

三次往返缺一不可，因为 TCP 要确认双方的收发能力都正常。注意一个细节：第一个数据包要等握手完成才能发出——也就是说，光是建立连接，就先花掉一个 RTT。

加上 HTTPS：仪式更长

HTTPS 在 TCP 握手之上还有 TLS 握手，旧协议（TLS 1.2）需要再两个 RTT；现代的 TLS 1.3 优化到 1 个 RTT，恢复会话（session resumption）甚至能 0-RTT。

所以打开一个 HTTPS 网站的最小开销：

阶段	消耗
TCP 握手	1 × RTT
TLS 1.3 握手	1 × RTT
请求 + 响应首字节	1 × RTT

三个 RTT 之后你才看到第一个字节。 RTT = 20ms 的同城站，60ms 出头就有响应；RTT = 300ms 的跨洲站，光握手就接近 1 秒——带宽再大也救不了，因为瓶颈在"来回的次数 × 每次的等待"。

为什么带宽救不了延迟

带宽决定"管道多粗"——一次能推多少数据；延迟决定"每个来回多久"。它们是正交的两个维度：

• 看 4K 视频：主要吃带宽（持续大流量），对延迟不敏感（提前缓冲就行）
• 刷网页 / API 调用 / 游戏：主要吃延迟（大量小请求，每个都要等往返），带宽 50M 就已绰绰有余

一个形象的比喻：带宽是高速公路的车道数，延迟是从家到公司的通勤时间。车道从 4 条扩到 20 条，你上班还是要开 40 分钟。

CDN 为什么能提速

CDN 的本质就是缩短 RTT：把内容缓存到离你物理位置最近的节点，300ms 的跨洲往返变成 30ms 的本地往返，三段握手 + 首字节的 3 × RTT 从 900ms 降到 90ms。

HTTP/2 与 HTTP/3 的价值在另一个维度——减少往返次数：

• HTTP/2：一条连接上并行跑多个请求，不用每个资源单独握手
• HTTP/3（QUIC）：把 TCP 换成基于 UDP 的 QUIC，握手与 TLS 合并，0/1-RTT 建连
• Keep-Alive：复用已建立的连接，后续请求省掉全部握手

测量你的真实 RTT

想看你到某个目标的真实往返延迟：

• Ping 延迟探测：从本站服务器（新加坡）出发测量，适合测机房线路质量
• 网速测试：同时给出下载速度和延迟，两个维度的健康度一眼看清

注意 ping 的 RTT 是网络层的，浏览器里实际体验的 TTFB（首字节时间）≈ 3 × RTT + 服务端处理时间。延迟 300ms 的站点，TTFB 很难低于 1 秒。

小结

• 建立一个 HTTPS 连接最少要 3 个 RTT 才能见到首字节
• 带宽管大流量（视频），延迟管交互体验（网页、游戏）
• 提速思路：缩短 RTT（CDN 就近接入）+ 减少握手次数（HTTP/3、连接复用）
• 判断瓶颈：测延迟和测带宽要分开做

你的网络到新加坡机房的延迟和带宽各是多少？测一下。