HTTP2的介绍：从独木舟运货”到“细沙流淌”

摘要：HTTP2现在已经几乎是主流版本了，本文介绍了HTTP2对HTTP1的改进，包括切分成更小的二进制包，使用头部压缩算法，资源提前智能推送等。

HTTP/2：从"独木舟运货"到"细沙流淌"的进化

在现代 Web 开发中，我们早已习惯了页面秒开、资源并行加载的流畅体验。但你是否想过，这种"理所当然"的背后，是 HTTP/2 带来的根本性变革？

本文将带你从一个形象的比喻出发，深入理解 HTTP/2 是如何解决 HTTP/1.x 的性能瓶颈，并通过二进制分帧、头部压缩、多路复用和服务器推送等关键技术，彻底改变 Web 资源的传输方式。

一、HTTP/1.x 的困境：一条路上的"大石头堵车"

在 HTTP/1.1 时代，浏览器通常为每个域名建立 6 条左右的 TCP 连接，每个连接一次只能处理一个请求-响应。这就像用 6 条独木舟运货，每条船只能运一块大石头。

问题来了：

这就是典型的 队头阻塞（Head-of-Line Blocking） ------ 一条路上一块大石头卡住，整个路就走不动了。

HTTP/2 的核心思想是：用一条 TCP 连接，承载所有资源的并发传输。

它是怎么做到的？关键在于 二进制分帧层（Binary Framing Layer）。

HTTP/2 不再以完整的文本报文为单位传输，而是将所有数据拆分成小而有序的帧（Frame），每个帧都带有流 ID（Stream ID），标识它属于哪个"逻辑请求"。

这些帧可以在一条 TCP 连接中交错发送，浏览器收到后按流 ID 重新组装。就像把大石头碾成细沙，通过一条河道自由流动，谁先到谁先用。

✅ 效果：彻底解决应用层的队头阻塞，实现真正的多路复用（Multiplexing）。

HTTP 头部往往重复冗长（如 Cookie、User-Agent）。HTTP/2 使用 HPACK 算法进行压缩：

✅ 效果：减少头部体积 80% 以上，尤其对小资源请求极为友好。

HTTP/2 允许服务器在浏览器请求之前，主动推送资源。

比如：用户请求 index.html，服务器知道这个页面一定需要 style.css 和 main.js，于是：

✅ 效果：省去一次 RTT（往返延迟），关键资源"未问先送"，显著提升首屏加载速度。
📌 注意：推送不是盲推，而是基于 HTML 内容、应用逻辑或用户行为预测的"智能预判"。

不是所有场景都适用推送：过度推送会浪费带宽，甚至"抢"走关键资源的带宽。建议只推送关键 CSS、JS 或字体。
TLS 不是强制，但几乎总是启用：主流浏览器只支持 HTTPS 上的 HTTP/2。
HTTP/3 已来，但 HTTP/2 仍是主流：HTTP/3 解决了 TCP 层的队头阻塞，但部署成本更高，HTTP/2 仍是当前最广泛使用的高性能协议。

HTTP/2 不是一次小修小补，而是一次传输范式的转变：

从"整包传输、排队等待"

到

"分帧并发、智能预推"

它让我们摆脱了"资源合并"、"域名分片"等历史包袱，回归更清晰、更模块化的开发方式。

延伸阅读：

挖个坑，后续有机会写写 Nginx 配置 HTTP/2 推送的代码示例，聊聊 HTTP/3 和 QUIC。