从 Webpack 打包策略看 HTTP 协议的演进：从 1.1 的串行到 2.0 的多路复用
前言
在前端开发中，我们习惯于使用 Webpack 将成百上千个模块打成少数几个 Bundle。这种行为的初衷并非仅仅为了模块化，而是为了规避 HTTP/1.1 协议下的性能瓶颈。本文将深入探讨 HTTP/1.1 与 HTTP/2 在资源传输机制上的本质区别，并解析多路复用（Multiplexing）是如何从根本上改变前端构建规则的。
一、 HTTP/1.1：为何我们必须“打大包”？
1. 域名分片与连接限制
在 HTTP/1.1 时代，浏览器对同一个域名下的并发 TCP 连接数有严格限制（通常为 6 个）。这意味着，如果一个页面需要加载 50 个 JS 文件，浏览器只能同时处理 6 个，剩下的 44 个请求必须在队列中等待。
2. 队头阻塞（Head-of-Line Blocking）
HTTP/1.1 请求是基于文本且线性的。在同一个 TCP 连接上，请求必须遵守“先进先出”（FIFO）原则。如果前一个响应因为体积过大或服务器处理慢而延迟，后续的响应都会被阻塞。
3. 构建侧的应对：Bundle 策略
为了缓解上述问题，Webpack 的核心任务之一就是合并资源。
- 逻辑：减少请求次数 = 减少排队时间 + 减少 TCP 握手损耗。
- 弊端：哪怕只改动一行代码，整个大 Bundle 的缓存都会失效，导致极高的重载成本。
二、 HTTP/2：二进制分帧与多路复用
HTTP/2 的出现彻底打破了“请求必须排队”的物理限制，其核心机制是二进制分帧（Binary Framing）。
1. 帧（Frame）与流（Stream）
HTTP/2 不再以文本为基础，而是将数据拆分为一个个带有编号的二进制帧。
- 流（Stream）：指已建立的连接上的双向字节流，对应一个完整的请求或响应。
- 帧（Frame）：HTTP/2 通信的最小单位。每个帧都包含一个头部，记录了它属于哪一个流。
2. 多路复用的物理本质
虽然在 TCP 管道内部，数据包在物理线路上依然是串行传输的，但由于有了“流 ID”标记，不同请求的帧可以交错排列。
- 并行感知：浏览器可以同时发送 50 个请求，服务器也可以同时返回 50 个文件的帧。
- 乱序重组：接收方根据帧头部的流 ID，将交错的数据重新组装成完整的文件。
三、 核心差异对比：为什么 H2 允许“拆包”？
在 HTTP/2 环境下，Webpack 的构建策略开始向Fine-grained Caching（细粒度拆分）演进。
| 维度 | HTTP/1.1 | HTTP/2 |
|---|---|---|
| 传输单位 | 整个 HTTP 报文（文本） | 多个二进制帧（标记流 ID） |
| 连接利用 | 每个连接同一时刻只能处理一个请求 | 单个连接支持数百个流并行传输 |
| 阻塞风险 | 严重的 HTTP 队头阻塞 | 解决应用层阻塞，仅受限于 TCP 丢包重传 |
| Webpack 策略 | 大 Bundle：减少连接数开销 | 多 Chunk：利用缓存，提高增量更新效率 |
理解误区纠正
误区：“H2 下请求越多越好。”
事实：虽然 H2 解决了连接数限制，但每个请求仍有头信息（Header）开销。过度碎片化（如数千个几百字节的文件）仍会产生不必要的性能损耗。现代最佳实践是保持适度的代码分割（Code Splitting）。
四、 进阶思考：TCP 的局限与 HTTP/3 的逻辑
尽管 HTTP/2 在应用层解决了队头阻塞，但由于它依然运行在 TCP 之上，TCP 协议的可靠传输特性导致了另一种阻塞：
如果 TCP 连接中丢失了一个包，内核会缓存后续的所有包，直到丢失的包被重传成功。这种“传输层阻塞”在弱网环境下尤为明显。
这也是为什么 HTTP/3 抛弃了 TCP，转向基于 UDP 的QUIC协议。QUIC 实现了真正的物理流隔离：Stream A 丢包，Stream B 照样传输。
五、 总结回顾
- HTTP/1.1像单车道，车辆（请求）必须首尾相连，导致我们必须通过“把货装进大卡车（打包）”来提升效率。
- HTTP/2像带编号的传送带，虽然路径是一条，但货物被拆成小件带上标签混装。即便有一件大货，小件也可以插空通过。
- 技术决策：在现代开发环境下，我们应充分利用 H2 的特性，通过
splitChunks等配置增加公共库的拆分，从而获取更好的缓存收益。
下一步：如果你对 HTTP/3 的 QUIC 协议如何利用 UDP 实现可靠性感兴趣，我们可以深入探讨它的序列号机制与 0-RTT 握手过程。
)
