2026-11-04 · 主题精读：HTTP 演进 —— HTTP/1.1、HTTP/2、HTTP/3 与 QUIC 未开始

题记与说明

• 条目前缀: knowledge-927cp4si-4
• 主题: HTTP 演进：HTTP/1.1、HTTP/2、HTTP/3 与 QUIC（主题形式）
• 研究方式: 主题研究 —— 先检索定位来源，再逐篇全文精读（非仅凭既有知识；W3Techs 采用率数据经搜索引擎摘要交叉验证两次，未直接抓到原页面，已标注）
• 精读日期: 2026-11-04

来源清单

注：Cloudflare 旧的 learning/web/what-is-http3 与 learning/network-layer/what-is-QUIC 两个 URL 本次实测 404，正确页面已迁移至 learning/performance/what-is-http3。

1. 核心问题

Web 页面从最初的几个 HTML 文件膨胀到一次加载动辄上百个资源（JS/CSS/图片/字体），HTTP 的语义（请求/响应、方法、状态码、缓存）三十年来基本不变，但承载方式经历了三次大改。整个演进史要解决的核心问题只有一个反复变奏的主题：

队头阻塞（Head-of-Line blocking, HOL）——Marx 给出的定义："When a single (slow) object prevents other/following objects from making progress"（一个慢对象阻止其他/后面的对象前进）。

围绕它还叠加了三个次级问题：

1. 连接开销：为绕过 HOL 而开 6 条 TCP 连接 + 域名分片，握手与服务器内存成本高；
2. 握手延迟：TCP + TLS 各自握手的 RTT 累积，移动网络尤其痛；
3. 安全滞后：明文 TCP 上跑 HTTP，加密是应用层事后补丁。

MDN 对演进驱动力的概括："Over the years, web pages became more complex. Some of them were even applications in their own right. … Much more data was transmitted over significantly more HTTP requests and this created more complexity and overhead for HTTP/1.1 connections."

2. 主要主张

1. 语义稳定，传输换代：HTTP/3 "supports the same semantics over a new transport protocol: QUIC"（RFC 9114 §1）。每一代 HTTP 改的不是"HTTP 是什么"，而是"HTTP 的比特怎么上线"。Stenberg："What primarily changes with HTTP/3 is how the bits get sent over to the other side of the communication."
2. HTTP/2 只解决了一半 HOL：二进制分帧让应用层能多路复用，但 TCP 只看到一个字节流——丢一个包，所有 stream 一起停。RFC 9114 §1.1 的官方表述："because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet."
3. HTTP/3 的解法是把"流"概念下沉到传输层：QUIC 的 STREAM 帧携带 per-stream 字节区间，丢包只冻结所属流。"Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams."（RFC 9114 §2）
4. 但 Marx 泼冷水：HOL 消除的实际收益可能有限。QUIC 在单流内仍保留顺序（文件必须按序重组）；浏览器希望核心资源顺序发送（JS/CSS 要收完才能执行），而 HOL 消除要求资源交错发送——两个优化目标直接冲突。他的结论："QUIC and HTTP/3's HOL blocking removal probably won't do all that much for Web performance in the majority of the cases." 他认为真正的收益来自 0-RTT 连接建立："especially 0-RTT will provide the most Web performance benefits."
5. HTTP/2 的部署现实：MDN 记录其"使用率在 2022 年 1 月达峰值 46.9%"后回落（被 HTTP/3 侵蚀）；快速普及的原因是"网站和应用无需任何改动"。
6. HTTP/3/QUIC 附带一揽子传输层升级：握手合并（crypto+transport 一次完成）、0-RTT、强制加密（连包头元数据都加密）、连接迁移（换 WiFi 不掉线）、每连接流控（防 Rapid Reset DDoS）。

3. 方法：每一代到底改了什么（技术路线精读）

3.1 HTTP/1.1（1997, RFC 2068）：文本协议的原罪与"6 连接补丁"

MDN 列出的 HTTP/1.1 增量：连接复用（keep-alive）、pipelining、chunked 响应、缓存控制、内容协商、Host 头支持虚拟主机。但它有一个结构性缺陷：纯文本协议只在 payload 前面附加头部，无法区分一段字节属于哪个资源。

Marx 用图 3 演示了强行交错发送的后果：浏览器按 Content-Length: 1000 读 script.js，收到 450 字节后开始读到 style.css 的头部——直接把 CSS 的头和内容当成了 JS 的一部分，JS 解析器拿到的是：

function first() { return "hello"; }
HTTP/1.1 200 OK
Content-Length: 600

.h1 { font-size: 4em; }
func

结论：HTTP/1.1 单连接上响应必须完整传完才能换下一个资源（11112222 串行模式）。浏览器的补丁是每域名开 6 条并行 TCP 连接，再叠加域名分片（img.mysite.com、static.mysite.com…），一页最多 30 来条连接——"This works, but has considerable overhead"（TLS 握手、服务器状态与内存）。

Marx 在 bonus 章节澄清了一个常见误解：pipelining 只解决请求侧的 HOL——HTTP/1.1 规范要求响应必须按请求顺序返回（"A server MUST send its responses to those [pipelined] requests in the same order that the requests were received"），"pipelining solves HOL blocking for requests, but not for responses"，而且现代浏览器干脆不用它（无法中途取消、猜错队列更糟）。

3.2 HTTP/2（2015, RFC 7540/9113）：二进制分帧，但 TCP 不知道

Google SPDY（2010 年代初）→ IETF HTTP/2（2015-05 标准化，MDN）。三个本质变化（MDN）：

• 二进制协议（不再人眼可读，但为优化敞开大门）；
• 多路复用：同一连接上并行请求；
• HPACK 头压缩（请求间头部高度重复）。

机制：每个 chunk 前面加帧（DATA/HEADERS 等），帧携带 stream id + 长度。浏览器据此把交错字节"解复用"回各资源流。响应调度自由度大增：公平交错 12121212、加权 221221221、倒序 22221111、部分发送（中途夭折低优先级流）——由优先级系统驱动。

但是：TCP 不知道自己在运 HTTP/2。TCP 只按字节区间重组一条流——丢包 2 但收到包 3 时，TCP 必须扣住包 3 等重传，即使包 3 里全是 stream 1 的数据、与丢的 stream 2 无关。Marx 总结四条链条：

- HTTP/1.1 had HOL blocking because it needs to send its responses in full and cannot multiplex them
- HTTP/2 solves that by introducing "frames" that indicate to which "stream" each resource chunk belongs
- TCP however does not know about these individual "streams" and just sees everything as 1 big stream
- If a TCP packet is lost, all later packets need to wait for its retransmission… TCP has Transport Layer HOL blocking.

Marx 同时给了定量的缓释：丢包率在高速有线网络约 0.01%，最差蜂窝网络也"很少高于 2%"，且丢包成簇（路由器缓冲溢出）——所以 TCP 层 HOL 远不如 HTTP/1.1 层 HOL 频繁。还有拥塞控制的反直觉账：单条 HTTP/2 连接初始窗口约 14KB，而 HTTP/1.1 的 6 条连接各 14KB ≈ 84KB；HTTP/2 单连接一条流丢包就减速，HTTP/1.1 五条连接照常增长。所以现实中"HTTP/2 as it is currently deployed in browsers and servers is typically as fast or slightly faster than HTTP/1.1 in most conditions"，而在高丢包慢网络下 HTTP/1.1 六连接甚至可能反超——这正是 QUIC 立项的动机。

3.3 HTTP/3 + QUIC（RFC 9000/9110-9114, 2021-2022）：把流下沉到传输层

改 TCP 不可能（中间盒僵化、内核栈改动是十年尺度），于是 IETF 选择在 UDP 上重建一个"TCP 2.0"——QUIC（Marx: "In many ways, QUIC should be seen as a TCP 2.0. It includes the best versions all of TCP's features (reliability, Congestion Control, Flow Control, ordering, etc.)… QUIC also fully integrates TLS … and doesn't allow unencrypted connections."）。

关键动作（Marx 图 8-9）：把 stream id 从 HTTP/2 的 DATA 帧挪进 QUIC 的 STREAM 帧，传输层逐流跟踪字节区间。丢包 2 时：stream 1 的包 3 数据字节区间连续、立即可交付；stream 2 有缺口、扣住等重传。"QUIC retains ordering within a single resource stream but no longer across individual streams"——单流内有序，跨流不再保证全序。

这个"跨流全序消失"直接引爆了三个 HTTP/3 的连锁重设计（RFC 9114 附录 A 是最权威的差异清单）：

1. HPACK → QPACK："Because HPACK relies on in-order transmission of compressed field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK."（RFC 9114 §2）QPACK 用独立单向流维护动态表，编码块只引用表状态而不修改它，让编码者在压缩率与潜在 HOL 之间自选权衡（Stenberg 也强调这一点："the header compression protocol used for HTTP/2 could not be used without it causing a head of block situation"）。
2. 优先级系统整个移除："HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority."（RFC 9114 附录 A.2.1）树形优先级操作依赖跨流有序，QUIC 上无法直接安全，后由独立的 Extensible Prioritization Scheme 草案（Marx 文中链接的 draft-ietf-httpbis-priority，即后来的 RFC 9218）另起炉灶。
3. RST_STREAM/WINDOW_UPDATE/PING/CONTINUATION 等帧删除：流生命周期、流控、保活全部由 QUIC 接管（RFC 9114 附录 A.2.5 逐帧对照表）；SETTINGS 只在控制流开头发一次，不再可变。

连接建立：ALPN token "h3"；发现机制靠 Alt-Svc 头（"Alt-Svc: h3=":50781""）；QUIC 内嵌 TLS 1.3，"offering comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open"（RFC 9114 §1.2）。Cloudflare 补充："QUIC combines the cryptographic and transport handshakes"以及 0-RTT：对连过的服务器"clients can skip the handshake requirement"。

移动性是 QUIC 的第二支柱（Cloudflare）："QUIC separates out the layer 4 transport connection from the layer 3 IP flow, allowing for migration between different networks without disruption"——WiFi 切蜂窝不断连；还用 credit-based stream 系统缓解 HTTP/2 Rapid Reset DDoS。回退路径在规范里写死："Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case."（RFC 9114 §3.1）

3.4 一页对比表

4. 数据与证据

• MDN（官方统计转引）："Officially standardized in May 2015, HTTP/2 use peaked in January 2022 at 46.9% of all websites"；"By October 2022, 26% of all websites were using HTTP/3."
• W3Techs（2026-11，经两次搜索摘要交叉验证，未直接抓到原页）：HTTP/3 覆盖 41.2% 全部网站，Top 1,000,000 站点达 45.4%，是增长最快的 site element 之一（较 2026-10 +0.4%）。
• TechnologyChecker Q3 2026（同上转引）：约 38.8-41% 站点支持 HTTP/3，但实际只有 约 20-21% 的请求真正走 HTTP/3——支持与实际流量之间存在约一倍差距（浏览器回退、UDP 封锁、Alt-Svc 发现慢等）。
• Marx 的定量事实：有线网络丢包率约 0.01%，最差蜂窝 ≤2%；丢包呈突发形态（10 连丢而非均匀散布）；TCP 初始拥塞窗口约 14KB，HTTP/1.1 六连接 ≈84KB；TLS record 最大 16KB ≈ 11 个 TCP 包，最后一个包丢了整条 record 无法解密（TLS 层 HOL 变体，QUIC 逐包加密根治之）。
• RFC 9114 规范性证据：附录 A.2.5 逐帧对照（PRIORITY/RST_STREAM/WINDOW_UPDATE/PING/CONTINUATION 均无 HTTP/3 对应物）；§3.2 要求至少允许 100 个并发请求流、"at least 1,024 bytes of flow-control credit to each unidirectional stream"；§10.9 强制 0-RTT 重放攻击缓解（RFC 8470）。
• Cloudflare 时间线：Google 2012 年开始早期 QUIC，2016 年被 IETF 采纳立项 HTTP/3，标准版发布为 RFC 9000；2021 年对全部 Cloudflare 客户开放。

证据是否充分：机制链条（分帧→流下沉→QPACK/优先级连锁）有 RFC 原文 + Marx 图解双重支撑，非常扎实；"HTTP/3 实际快多少"一问，本次精读未获得 2026 年的最新大规模实测数据（Marx 的量化判断是 2020 年前后早期实验 h3holblockingpaper 的推断，他自己声明"differently, it is a topic of my ongoing research"）；W3Techs 数字未直接核验原页，属搜索摘要转引。

5. 结论

1. HTTP 演进 = 语义不动、承载重造。0.9→1.1 解决"能传什么"，1.1→2 解决"应用层怎么排"，2→3 解决"传输层怎么排"。
2. HOL blocking 是贯穿三十年的主线：HTTP/1.1 应用层 HOL（靠 6 连接补丁）→ HTTP/2 应用层解决、TCP 层遗留 → HTTP/3 在传输层基本解决（单流内除外）。
3. QUIC 不只是"UDP 上的 TCP"：流感知 + 内嵌 TLS 1.3 + 握手合并 + 0-RTT + 连接迁移 + 强制加密，是传输层的整体重设计；HTTP/3 为此付出的代价是 QPACK 重写、优先级外置、大量帧被砍。
4. 对性能要诚实：HOL 消除的理论收益受"顺序发送更利于资源加载"反向牵制，大概率只在高丢包网络兑现；多数场景下 HTTP/3 的真实增益更可能来自 0-RTT/1-RTT 快速握手与连接迁移。采用率（41% 站点支持 vs ~21% 实际流量）说明它已过临界点但远未完成替代。
5. 部署侧几乎零成本（CDN/边缘节点开关即用），这解释了为什么协议换代能以"被动升级"方式完成。

6. 局限

来源自认的：

• Marx：HOL 消除收益的判断基于早期实验与直觉（"my personal gut feeling (which is backed by my results from several early experiments)"），成文时 QUIC/HTTP/3 实现尚未定稿（2020 年 living document），"it's a bit early to tell for sure"。
• Marx：多路复用调度与丢包模式的交互（图 10 三行场景）是他的在研课题，"that's not something I can give you a definitive answer on at this time"。
• Cloudflare 页是厂商内容，隐含推广立场（如"HTTP/3 more secure than HTTP/2"的表述比 RFC 谨慎口径更强）。
• W3Techs 测的是"网站支持率"而非流量占比（TechnologyChecker 明确指出这一点），两者不能混用。

我推断的：

• 未获得 2026 年的 HTTP/3 vs HTTP/2 端到端性能大规模实测（如 Cloudflare Radar/HTTP Archive 最新报告），性能结论停留在 2020-2021 年的定性判断 + 2022 年 RFC 设计意图。
• QUIC 的 CPU 开销（Marx 转引 Fastly 基准："one of the main reasons why QUIC can still be slower than TCP in current implementations"）自 2020 年后实现已大幅优化，该引述可能过时，未核验。
• Stenberg 一书本次只读了 HTTP/3 单页，QUIC 传输细节章未读。
• "h3 直连 http:// 明文场景不可用""0-RTT 不可用于非幂等请求"等安全细节只覆盖到 RFC 摘要层面。

7. 对我的启发

1. 个人站点/服务部署（Windows + CDN 场景）：HTTP/3 是 CDN 上的一个开关，零代码改动——默认打开即可吃到 0-RTT 和移动网络收益，不要再为性能做域名分片（那是 HTTP/1.1 时代的补丁，在 2/3 下反而拆散了连接复用和拥塞窗口）。
2. 排查网络问题时记得有"回退"这回事：企业网/防火墙封 UDP 443 会让 HTTP/3 静默失败，浏览器回退 HTTP/2——表现为"有些网络慢、有些正常"。curl 用 --http3 可显式验证端点是否真支持。
3. 性能优化的元教训：Marx 展示的"两个正确的优化目标互相打架"（多路复用利于抗丢包 vs 顺序发送利于尽早执行）是好架构讨论的范本——先问"这个优化的收益在什么网络条件下兑现"，再决定要不要做。
4. 协议设计的下沉思想可迁移：QUIC 把 HTTP/2 的流概念下沉到传输层、把 TLS 揉进握手，本质是"当某层看不见上层结构时，把结构搬到能看见它的那层"。排查分层系统（数据库索引之于查询、缓存之于检索）时同样适用。
5. 写作素材：Marx 用 11112222 vs 12121212 的字符画讲多路复用、用"单一收银台的超市"类比 HOL——把协议机制翻译成可画图的记号系统，是技术写作的高杠杆动作；我写 HTTP/3 介绍文时可直接借这个框架。
6. 保持对"营销数字"的警惕：41.2% 是支持率不是流量；"QUIC 消除队头阻塞"为真但在多数网页场景收益有限——引用任何协议数据前先分清 measurement 口径。

附录 A：关键原文引述

1. "When a single (slow) object prevents other/following objects from making progress" —— Marx，HOL blocking 定义
2. "because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet." —— RFC 9114 §1.1
3. "Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams." —— RFC 9114 §2
4. "QUIC also incorporates TLS 1.3 … offering comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open." —— RFC 9114 §1.2
5. "Because HPACK relies on in-order transmission of compressed field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK." —— RFC 9114 §2
6. "Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case." —— RFC 9114 §3.1
7. "HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority." —— RFC 9114 附录 A.2.1
8. "In QUIC the streams are provided by the transport itself, while in HTTP/2 the streams were done within the HTTP layer." —— Stenberg《HTTP/3 explained》
9. "QUIC retains ordering within a single resource stream but no longer across individual streams." —— Marx
10. "QUIC and HTTP/3's HOL blocking removal probably won't do all that much for Web performance in the majority of the cases." / "especially 0-RTT will provide the most Web performance benefits" —— Marx
11. "pipelining solves HOL blocking for requests, but not for responses" —— Marx（引 HTTP/1.1 规范："A server MUST send its responses to those [pipelined] requests in the same order that the requests were received."）
12. "Officially standardized in May 2015, HTTP/2 use peaked in January 2022 at 46.9% of all websites" / "By October 2022, 26% of all websites were using HTTP/3." —— MDN
13. "QUIC separates out the layer 4 transport connection from the layer 3 IP flow, allowing for migration between different networks without disruption." —— Cloudflare
14. "Google started work on an early version of QUIC in 2012. In 2016 it was adopted by the Internet Engineering Task Force (IETF) … the now-standard version of QUIC published as RFC 9000." —— Cloudflare

附录 B：本次检索方式说明

• 直接全文抓取（web_reader）：MDN、Marx GitHub README（raw）、RFC 9114（txt 版）、Cloudflare what-is-http3、http3-explained h3 章 —— 共 5 个来源逐篇精读。
• 搜索交叉验证：Cloudflare 正确 URL（旧链接 404 实测两次）、W3Techs 采用率（两次搜索结果一致：41.2% / 45.4% / ~21% 流量）。
• 未做成/未核验：W3Techs 与 TechnologyChecker 原页未直接抓取（已在正文标注转引口径）；未进行任何本地实验。