【连接篇】TCP/UDP 与前端性能的物理极限

作者前端小小栈

2026年1月30日 09:24

作为《前端视角下的网络协议》系列的第一篇，我们不聊那些复杂的报文格式，而是聊聊物理规律。

对于前端开发者来说，网络环境是一个“黑盒”。你写了一行 fetch('/api/data')，但在数据到达浏览器之前，它必须跨越数千公里的光纤、路由器和交换机。在这段旅程中，TCP 的连接机制决定了你的首屏加载速度（FP）存在一个无法逾越的“物理极限”。

一、 TCP 三次握手：避不开的 RTT 消耗

每一个 HTTP/1.x 或 HTTP/2 连接在传输数据前，都必须经过 TCP 三次握手。

对于前端性能来说，这意味着：在你的第一个字节（TTFB）发出之前，已经消耗了 1.5 个 RTT（往返时延）。

物理极限： 如果用户在上海，服务器在纽约，单程延迟约 150ms，那么握手就要消耗 450ms。无论你的前端代码优化得多么极致，这近半秒的白屏是物理层面的“死刑”。
优化对策： * CDN 边缘加速： 让握手发生在离用户最近的节点。
- Connection Keep-Alive： 复用长连接，避免为每个请求重新握手。

这是前端开发者最容易忽略的 TCP 特性：拥塞窗口（Congestion Window） 。

TCP 为了防止网络拥塞，不会一上来就全速发送数据。它会从一个很小的初始窗口（通常是 10 个段，约 14.6KB）开始尝试。如果接收方成功确认，窗口才会翻倍（20, 40, 80...）。

前端含义： 你的首屏关键 HTML 和内联 CSS 最好控制在 14KB 以内。
- 如果 HTML 是 10KB：只需 1 个往返即可完成下载并开始解析渲染。
- 如果 HTML 是 20KB：需要 2 个往返。在网络环境差的情况下，这多出来的一个 RTT 可能意味着用户多看 200ms 的白屏。
结论： 极致的性能优化，是从精简首屏 HTML 字节数开始的。

虽然 HTTP/2 实现了多路复用（Multiplexing），让我们可以并行下载资源，但它依然跑在 TCP 上。

问题所在： TCP 是一个“流”协议，它必须保证包的顺序。如果其中一个 TCP 包在传输中丢失，即使后续的包已经到达浏览器，TCP 也必须等那个丢掉的包重传成功后，才能把数据交给浏览器。
性能杀手： 即使你并行下载 10 个图片，只要丢了一个包，所有的图片下载都会被卡住。这就是 TCP 级别的队头阻塞（Head-of-Line Blocking） 。

为了彻底解决 TCP 的顽疾，Google 推出了基于 UDP 的 QUIC 协议（即 HTTP/3）。

0-RTT 握手： UDP 无需握手。QUIC 在建立连接时可以实现 0-RTT 或 1-RTT，比 TCP 快得多。
解决队头阻塞： QUIC 在 UDP 之上实现了自己的流控制。如果一个流丢包，只会影响该流，其他流（其他资源请求）可以继续传输。
连接迁移： 用户从 WiFi 切换到 5G 时，IP 地址变了，TCP 连接会断开。但 QUIC 基于 Connection ID，可以实现无缝切换，不断连。

首屏 HTML 尽量压缩在 14KB 以内： 避开 TCP 慢启动的第二次往返。
利用 Preconnect： 在 HTML 头部加入 <link rel="preconnect" href="https://api.example.com">，让浏览器提前完成那耗时的 TCP 握手。
关注 HTTP/3 普及率： 如果你的用户群网络环境复杂（如移动端、弱网），开启 HTTP/3 将带来质的飞跃。

理解了 TCP 的物理限制，你就明白了为什么“减少请求数”和“减小包体积”永远是前端优化的金科玉律。网络协议不是为了增加难度，而是划定了性能的边界。