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 的破局：把大石头碾成“细沙”，一条河里自由流淌

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

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

1. 分帧：大资源切成“细沙”

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

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

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

2. 头部压缩：只传“变化的部分”

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

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

3. 服务器推送：主动“预发”资源

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

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

1. 先发送一个 PUSH_PROMISE 帧，告知：“我将推送 /style.css”；
2. 紧接着发送该资源的 DATA 帧；
3. 浏览器收到后，若缓存中已有该资源，可立即发送 RST_STREAM 拒绝，避免浪费。

效果：省去一次 RTT（往返延迟），关键资源“未问先送”，显著提升首屏加载速度。

注意：推送不是盲推，而是基于 HTML 内容、应用逻辑或用户行为预测的“智能预判”。

三、HTTP/2 的实际收益

连接数

多连接（6~8）

单连接复用

并发能力

有限并发，易阻塞

多路复用，无队头阻塞

头部传输

明文重复，体积大

HPACK 压缩，节省带宽

资源加载时机

被动等待请求

可服务器主动推送

开发复杂度

需域名分片、合并资源

可回归“一个资源一个文件”

四、一些注意事项

五、结语

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

从“整包传输、排队等待”

“分帧并发、智能预推”

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