写在前面 现在到了第五模块 - 浏览器运行原理 + 前端网络协议与请求模型
在前端性能优化中，我们常说：“带宽决定传输的上限，而延迟决定传输的下限。”
很多开发者有一个误区，认为网页慢是因为文件太大。但在今天的 5G 和千兆光纤时代，RTT（往返时延） 和 队头阻塞（Head-of-Line Blocking） 才是真正的性能杀手。
从 HTTP/1.1 的“Keep-Alive”补丁，到 HTTP/2 的“多路复用”幻象，再到 HTTP/3 (QUIC) 的“推倒重来”，网络协议的进化史，其实就是一部与延迟（Latency）抗争的历史。
本篇我们将潜入网络底层，像架构师一样去审视这条连接用户与服务器的“管道”。
一、 TCP 时代：可靠传输的代价
在很长一段时间里，Web 建立在 TCP/IP 协议栈之上。TCP（传输控制协议）的设计初衷是可靠性，而不是速度。这为现代 Web 埋下了最初的隐患。
1.1 三次握手与慢启动：昂贵的开销
当你发起一个请求时，并不能立即发送数据。TCP 必须先“打招呼”：
- SYN (Client -> Server)
- SYN-ACK (Server -> Client)
- ACK (Client -> Server)
这意味着，在发送第一个字节的数据前，至少消耗了 1.5 个 RTT 的时间。加上 TLS（HTTPS）握手，这个开销会增加到 3-4 个 RTT。如果用户在美国，服务器在中国，光是握手就可能消耗 500ms+，此时页面还是一片白屏。
此外，TCP 还有慢启动（Slow Start） 机制：刚建立连接时，它不敢发太多数据，发一点、等确认、再多发一点。这导致 Web 页面加载初期的带宽利用率极低。
1.2 HTTP/1.1 的挣扎：队头阻塞 (HOL)
HTTP/1.1 引入了 Keep-Alive 复用 TCP 连接，但它本质上是一个 “串行协议” 。 在这个管道里，请求必须排队： Request A -> Request B -> Request C
如果 Request A（比如一个大图）处理得很慢，Request B（关键的 CSS）和 Request C（关键的 JS）就必须等着，即使它们只有 1KB。 这就是应用层的 队头阻塞（Head-of-Line Blocking） 。为了解决这个问题，浏览器只好允许同时建立 6 个 TCP 连接（Domain Sharding），但这又增加了建连的开销。
二、 HTTP/2 的革新：二进制与多路复用
2015 年，HTTP/2 横空出世，试图解决 H1 的瓶颈。
2.1 二进制分帧 (Binary Framing)
HTTP/2 不再传输文本，而是将数据切分成更小的 “帧 (Frame)” 。
- Headers Frame: 头部信息
- Data Frame: 实体数据
2.2 多路复用 (Multiplexing) 的幻象
有了帧，我们就可以在一个 TCP 连接中，乱序发送不同请求的帧，然后在接收端重新组装。 Stream 1 (CSS) | Stream 2 (JS) | Stream 1 (CSS) | Stream 3 (Img)
这看起来完美解决了应用层的队头阻塞。浏览器不再需要 6 个连接，只要 1 个连接 就能并发所有请求。
2.3 致命缺陷：TCP 层的队头阻塞
架构师必须看到的真相是：HTTP/2 解决了 HTTP 的阻塞，但没有解决 TCP 的阻塞。
TCP 是一个字节流协议，它要求数据必须按顺序交付。 想象一下，HTTP/2 在一个 TCP 管道里并行传输 10 个图片流。如果 第 1 个流的一个数据包（Packet）丢了：
- 操作系统内核的 TCP 栈发现丢包，触发重传机制。
- 在重传包到达之前，后续所有的包（即使是属于第 2、3、4 个流的完整包）都必须在缓冲区等待，不能交付给浏览器。
这意味着：在弱网环境下（丢包率高），HTTP/2 的性能甚至不如 HTTP/1.1。 因为 H1 有 6 个连接，一个连接堵了，其他 5 个还能跑；而 H2 只有一个连接，一堵全堵。
三、 QUIC 与 HTTP/3：基于 UDP 的涅槃重生
为了彻底解决 TCP 的问题，Google 决定抛弃 TCP，基于 UDP 打造全新的传输层协议 —— QUIC (Quick UDP Internet Connections)，也就是后来的 HTTP/3。
3.1 为什么是 UDP？
不是因为 UDP 快（其实 UDP 不可靠），而是因为 TCP 太老了，且改不动。TCP 实现在操作系统内核中，要升级全球设备的 TCP 栈是不可能的。 UDP 只是一个空壳，QUIC 在应用层（用户态）重新实现了 TCP 的可靠性、拥塞控制和加密，但抛弃了 TCP 的包袱。
3.2 真正的独立流：消灭 HOL
在 QUIC 中，流（Stream）之间是真正独立的。 Stream A 的包丢了，只阻塞 Stream A，Stream B 的包照样可以被浏览器读取和渲染。这才是真·多路复用。
3.3 0-RTT 建连
QUIC 将传输层握手和 TLS 1.3 加密握手合并了。
- 首次连接：1 RTT。
- 再次连接：0 RTT。客户端缓存了之前的票据（Ticket），可以在发送握手包的同时直接发送加密后的 HTTP 数据。
3.4 连接迁移 (Connection Migration)
你在看视频，从家里的 Wi-Fi 切换到了 4G。
- TCP: 连接断开（因为 IP 变了），视频卡顿，重新握手。
- QUIC: 连接保持。QUIC 不靠 IP+端口识别连接，而是靠 Connection ID (UUID) 。只要 ID 没变，换了网络环境也能接着传。
四、如何适配新协议？
理解了协议原理，我们在架构决策上需要做哪些调整？
4.1 资源打包策略的变更
- H1 时代: 合并文件（雪碧图、大 Bundle JS），减少请求数。
- H2 时代: 适度拆分。因为有多路复用，拆成细粒度文件有利于缓存利用。但不能拆太细，否则压缩率降低（Gzip 字典效应）。
- H3 时代: 更加鼓励细粒度拆分，因为不用担心弱网下的单连接阻塞问题。
4.2 域名分片 (Domain Sharding) 的废弃
在 H2/H3 时代，把资源分散在 img1.cdn.com, img2.cdn.com 是反模式。 这会破坏多路复用，增加 DNS 解析和 TLS 握手开销。应该尽量收敛域名。
4.3 预连接优化 (Preconnect)
利用 Resource Hints 提前建立管道：
<link rel="preconnect" href="https://api.example.com" crossorigin>
这行代码告诉浏览器：“一会儿我要去那个域拿数据，先帮我把 TCP/QUIC 握手和 TLS 握手做完。”
结语：管道的终局
从 TCP 到 QUIC，我们可以看到网络协议进化的核心逻辑：把控制权从底层内核（Kernel）拿回到应用层（User Space），并致力于消除一切不必要的等待。
现在的浏览器和服务器正在大规模迁移到 HTTP/3。作为架构师，你需要确保你的 CDN、Nginx/Gateway 已经开启了对 H3 的支持，这可能是目前 ROI 最高的性能优化手段之一。
Next Step: 既然数据已经通过极速管道到达了浏览器，那么浏览器拿到这些 HTML、CSS、JS 后，是如何把它们“存”起来，又是如何决定谁先“跑”的？ 下一节，我们将深入浏览器的资源管理中心—— 《第二篇：缓存策略、DNS 与请求优先级》 。
