HTTP/2 vs HTTP/3 一文搞懂

HTTP/2 在 2015 年标准化，让 Web 第一次拥有了真正的多路复用、二进制分帧、首部压缩；HTTP/3 在 2022 年定稿，把整个传输栈搬到 QUIC over UDP，彻底告别 TCP 队头阻塞。两个协议看起来都是 HTTP，但底层完全不同。本文用通俗的语言系统对比帧结构、多路复用、TLS、Server Push、0-RTT、连接迁移、部署率、回退机制，并给出 2026 年的工程实践建议。

1. 协议演进：从 1.1 到 2 到 3

HTTP/1.1 是 1997 年的产物，请求和响应都是文本格式，一个 TCP 连接同一时间只能处理一个未完成的请求，浏览器靠并行打开 6 条连接来模拟多路复用，效率低、资源浪费。HTTP/2 引入二进制分帧层，把请求和响应拆成 Frame，多个 Stream 共享一条 TCP 连接，理论上一条连接就能并行下载所有资源。

但是 HTTP/2 仍跑在 TCP 上，TCP 的字节流模型导致一旦某个段丢失，所有逻辑流都被阻塞，形成所谓 TCP 层队头阻塞。HTTP/3 把整套机制下沉到 QUIC：QUIC 自己实现流、加密、拥塞控制、丢包重传，单条流的丢包只影响该流自身，其他流继续推进。这正是 HTTP/3 性能优势的根源。

从协议历史看，HTTP/2 是对 HTTP 语义层的革命，HTTP/3 是对传输层的革命。两者并不互斥，浏览器与服务器协商最高可用版本，没法 HTTP/3 就退回 HTTP/2。

2. 二进制分帧与多路复用

HTTP/2 把消息拆成 Headers Frame、Data Frame、Settings Frame、WindowUpdate Frame 等多种二进制帧。每个 Stream 有唯一 ID，客户端发起的 Stream 用奇数，服务端用偶数。多个 Stream 的帧可以交叉发送，接收方按 Stream ID 重组。

多路复用大幅提升 TCP 连接利用率，但前提是 TCP 层面顺利。一旦丢包，TCP 必须等重传到达才能向应用交付后续数据，所有 Stream 一起停摆。HTTP/3 的 QUIC 把每个 Stream 看成独立的可靠通道，单流丢包只影响自己，其他流继续读写，这是 HTTP/3 的核心卖点。

实测中，弱网环境（高延迟或丢包率超过 1%）下 HTTP/3 的页面加载时间比 HTTP/2 快 15% 到 40%，强网下差异不大。这意味着移动网络、跨境访问、卫星网络是 HTTP/3 受益最明显的场景。

3. 首部压缩：HPACK 与 QPACK

HTTP/2 引入 HPACK：客户端和服务端各维护一个动态表，相同的 Header 名/值只发送索引而不是全文。第一个请求 Cookie 完整发送，后续请求只发索引，节省大量带宽，对移动端尤其重要。

但 HPACK 依赖严格顺序，不适合 QUIC 的乱序流。HTTP/3 采用 QPACK，把动态表更新放在独立的单向流上，避免阻塞数据流。QPACK 在多路复用和压缩之间做了更精细的权衡，开发者一般不直接接触，但要知道它是 HTTP/3 性能的重要支撑。

如果你想分析自己网站的请求头大小，欢迎使用 curl 命令生成器构造请求并对比启用与不启用 HTTP/2 时的字节差异。

4. TLS 1.3 与加密前置

HTTP/2 在规范上不要求 TLS，但所有主流浏览器只在 HTTPS 下启用。HTTP/3 进一步强制加密：QUIC 把 TLS 1.3 直接编织进握手流程，没有明文 QUIC 这种东西。这意味着所有连接都自动加密，省去了独立的 TLS 握手 RTT。

TLS 1.3 把握手压缩到 1 个 RTT，加上 QUIC 把传输握手和加密握手合并，新连接首字节时间显著缩短。对配合了 0-RTT 的回访请求，握手开销甚至接近零。Cloudflare 公布的真实数据显示，HTTP/3 平均握手时间比 HTTP/2 over TLS 1.2 快 50% 以上。

加密前置带来的副作用是中间盒（防火墙、负载均衡、抓包工具）很难再窥视应用层。运维抓包要切换到 SSLKEYLOGFILE + Wireshark QUIC 解码、CDN 提供的边缘日志、或 eBPF 抓取明文等新方法。

5. Server Push 的兴衰与 Early Hints

HTTP/2 当年宣传亮点之一是 Server Push：服务端可以在客户端请求 HTML 时主动推送 CSS、JS。理想很美好，现实却很骨感：浏览器已缓存推送资源时纯属浪费、推错了同样浪费、跨进程推送难以与 Service Worker 配合，最终 Chrome 在 2022 年完全移除了实现，Firefox 和 Safari 也跟进停用。

HTTP/3 直接没有内置 Push 机制。取而代之的是 Early Hints（HTTP 状态码 103）：服务端可以在还没准备好完整响应前，先返回一个 103，告诉浏览器关键资源的 URL，让浏览器并行预加载。再配合 link rel=preload、preconnect 等指令，性能提升更稳定。

简而言之：2026 年别再讨论 Server Push 了，请使用 Early Hints + preload/preconnect 的现代组合。

6. 0-RTT 与连接迁移

QUIC 支持 0-RTT 数据：客户端在第一次连接成功后会缓存一份恢复票据，下次连接同一服务器时可以在握手包里直接捎带应用数据，省掉一个 RTT。对于跨洲访问每次省 100 多毫秒，体验提升明显。

代价是 0-RTT 数据可能被重放。规范明确要求服务器只对幂等请求允许 0-RTT，非幂等请求要拒绝或降级到 1-RTT。多数 CDN 已经默认实现这层防护，但自建的应用要自己注意区分。

连接迁移是 HTTP/3 的另一个杀手级功能：QUIC 用 Connection ID 而不是 IP+端口标识连接，移动端从 WiFi 切换到 4G、IP 改变时，连接不中断，正在传输的请求自然继续。这对手机用户的视频流、游戏、长会话尤其重要。

7. 部署、回退与运维

浏览器与服务器使用 Alt-Svc 头协商：服务端在 HTTP/2 响应里附带 Alt-Svc: h3=":443"，客户端记住后续直接尝试 QUIC，失败则回落 HTTP/2。这是无缝升级的核心机制。

企业网络、老旧防火墙常默认阻断 UDP 443。CDN 都会智能探测，UDP 不通就让用户走 HTTP/2 over TCP。运维要监控 QUIC 成功率、UDP 丢包率、握手失败原因。Linux 内核要调高 net.core.rmem_max 与 wmem_max，开启 GSO/GRO，对高 QPS 服务必不可少。

负载均衡层面，原生支持 QUIC 的方案有 NGINX 1.25+、Envoy、HAProxy 2.6+ 实验版、Caddy。云厂商 ALB/CLB 通常要显式开启 HTTP/3 监听，证书与 TLS 1.3 必须就位。配合 JSON 格式化工具调试 API 响应可以快速验证回退逻辑。

8. 2026 年选型与升级路径

新建站点：直接 HTTP/2 + HTTP/3 双开，CDN 替你处理细节，几乎零成本。老旧站点：先升级到 HTTPS + HTTP/2 拿到首层红利，再开启 HTTP/3。性能敏感型业务（直播、游戏、跨境电商）应优先评估 HTTP/3 的弱网增益，常常能直接降低跳出率。

监控指标：握手时间、首字节时间、TTFB、QUIC 协议占比、0-RTT 命中率、连接迁移触发率、UDP 重传率。配合真实用户监控（RUM）观察分位延迟，比合成测试更接近用户体感。

别忘了 SEO 与可访问性：HTTP/3 让首屏更快，对 Core Web Vitals 三项指标（LCP、INP、CLS）都有正向影响，尤其是移动端 LCP，2026 年 Google 已把它视作排名信号。从纯技术升级转化为业务收益，HTTP/3 是少数性价比极高的改造之一。

常见问题

HTTP/2 和 HTTP/3 最关键的区别是什么？

HTTP/2 仍然跑在 TCP 之上并复用 TLS 1.2 或 1.3，受 TCP 队头阻塞限制；HTTP/3 完全切换到基于 UDP 的 QUIC，把流多路复用、加密、拥塞控制全部下沉到 QUIC 层，单流丢包不再阻塞其他流，并支持连接迁移与 0-RTT 重连。

HTTP/2 的 Server Push 为什么被弃用了？

Chrome 在 2022 年彻底移除了 Server Push，原因是实践中收益小于成本：浏览器缓存、开发者预测错误、推送资源浪费带宽都比想象中严重。Early Hints 103 状态码 + preload/preconnect 被证明效果更好，HTTP/3 不再原生提供 Push 能力。

0-RTT 重连真的安全吗？

0-RTT 允许客户端在握手未完成时携带早期数据，省下一个 RTT，但对重放攻击敏感。规范要求服务器只允许幂等请求（GET、读操作）使用 0-RTT，非幂等请求（POST 写入、扣款）必须拒绝或降级。CDN 层一般有内置防护，应用侧也要配合。

2026 年 HTTP/3 的部署率和兼容性如何？

截至 2026 年初，全球前一千万站点中约 35% 已支持 HTTP/3，主流 CDN（Cloudflare、Akamai、Fastly、阿里云、腾讯云）默认开启。所有现代浏览器（Chrome、Edge、Firefox、Safari）原生支持，企业网络和老防火墙仍可能阻塞 UDP 443，需要 Alt-Svc 协商失败后回退到 HTTP/2。

迁移到 HTTP/3 有哪些坑？

常见问题包括：UDP buffer 默认太小导致丢包率上升、负载均衡器或 WAF 不识别 QUIC、企业代理阻塞 UDP 443、监控工具无法解码加密载荷、连接迁移触发的 NAT rebinding、cipher 套件配置错误。建议先在 staging 环境压测，逐步扩大灰度比例。