原创展示 Original Show
首页
首页 / 技术教程

HTTP/2 与 HTTP/3：多路复用、QUIC 与部署影响

2026-09-17 管理员 94 阅读 0 评论
技术教程 网络 / HTTP / DNS
预计阅读 10 分钟·最后更新 2026-10-21

为什么已经有 HTTP/2，还需要 HTTP/3？

打开一个现代网站时，浏览器通常不只请求一个 HTML 文件，还会同时加载 CSS、JavaScript、图片、字体以及 API 数据。页面性能因此不仅取决于服务器有多快，也取决于这些资源如何通过网络传输。

HTTP/2 和 HTTP/3 都在解决同一个核心问题：怎样让大量 Web 请求更高效地完成。但它们采用的底层传输方式并不相同。

可以先记住一个最重要的区别：

HTTP/2 通常运行在 TCP + TLS 之上；HTTP/3 运行在基于 UDP 的 QUIC 之上。

先看 HTTP/1.1、HTTP/2、HTTP/3 的核心差异

  • HTTP/1.1：一个连接同时处理请求的能力有限，浏览器往往需要建立多个 TCP 连接。
  • HTTP/2：在一个 TCP 连接中并发传输多个 Stream，并加入头部压缩等机制。
  • HTTP/3：把 HTTP 的多路传输能力建立在 QUIC 上，不再依赖 TCP 作为传输层。

因此 HTTP/3 并不是简单把 HTTP/2 的版本号加一，而是更换了底层传输机制。

HTTP/2 的多路复用到底解决了什么？

在 HTTP/1.1 时代，浏览器为了并发加载多个资源，通常会对同一站点建立多个 TCP 连接。连接越多，握手、拥塞控制以及资源竞争也会增加。

HTTP/2 引入 Stream 概念，让多个请求和响应能够在同一条连接上交错传输。

同一个 HTTP/2 连接

Stream 1  → HTML
Stream 3  → CSS
Stream 5  → JavaScript
Stream 7  → 图片
Stream 9  → API

这就是 HTTP/2 多路复用最直观的意义：不再要求一个请求完整结束以后才能开始处理下一个请求的数据。

与此同时，HTTP/2 还使用 HPACK 对 HTTP 头部进行压缩，减少大量重复 Header 带来的传输开销。

HTTP/2 为什么仍然会受到队头阻塞影响？

HTTP/2 虽然解决了 HTTP 层面的请求排队问题，但它仍然依赖 TCP。

TCP 必须按照字节顺序向上层交付数据。如果一个 TCP 数据包丢失，即使后面的数据已经到达，也可能需要等待丢失的数据重传完成。

HTTP/2 Streams
↓
同一个 TCP Connection
↓
某个 TCP Packet 丢失
↓
等待重传
↓
多个 Stream 都可能受到影响

这就是讨论 HTTP/2 性能时经常提到的 TCP 层队头阻塞。网络稳定、丢包很低时影响可能并不明显；移动网络、跨境网络或高延迟链路中，它可能更加突出。

HTTP/3 为什么改用 QUIC？

HTTP/3 使用 QUIC 作为传输协议。QUIC 基于 UDP 构建，但不能把它简单理解为“HTTP 直接使用普通 UDP”。QUIC 自己实现了可靠传输、拥塞控制、加密以及多路 Stream 等机制。

一个关键变化是：不同 QUIC Stream 可以更独立地处理数据丢失。

QUIC Connection
├─ Stream A → HTML
├─ Stream B → CSS
├─ Stream C → API
└─ Stream D → Image

如果 Stream D 的某些数据丢失，不必像 TCP 字节流那样让其他所有 Stream 都等待同一处缺失数据恢复。

这也是 HTTP/3 在高延迟、无线网络以及存在一定丢包的环境中具有潜在优势的重要原因。

QUIC 和 UDP 是什么关系？

经常有人看到 HTTP/3 使用 UDP/443，就认为 HTTP/3 是“不可靠的 UDP”。这种理解并不准确。

UDP 提供的是基础数据报能力，而 QUIC 在 UDP 之上实现了 Web 传输需要的大量能力，包括：

  • 可靠数据传输
  • 丢包恢复
  • 拥塞控制
  • 流量控制
  • 多路 Stream
  • TLS 1.3 加密
  • 连接迁移

所以从应用角度看，QUIC 并没有放弃可靠性，而是把过去由 TCP 和 TLS 分别承担的一部分能力重新组合到了 QUIC 中。

HTTP/3 一定比 HTTP/2 快吗？

不一定。

这是部署 HTTP/3 时最容易产生的误区。

如果用户与服务器距离很近、网络稳定、丢包率极低，而且页面本身的瓶颈来自数据库、后端 API 或巨大的 JavaScript，那么启用 HTTP/3 不会神奇地让网站瞬间变快。

HTTP/3 更可能体现优势的场景包括：

  • 移动网络频繁切换
  • 网络存在一定丢包
  • 高 RTT 或长距离链路
  • 页面需要并发加载大量资源
  • 用户网络环境变化频繁

因此判断 HTTP/3 是否有价值，最好结合真实用户网络、TTFB、LCP、请求耗时以及协议协商结果，而不是只看服务器是否显示“已开启 HTTP/3”。

0-RTT 是不是 HTTP/3 最大优势？

QUIC 可以减少建立安全连接所需的往返过程，并支持恢复既有连接状态时的 0-RTT 数据。

但 0-RTT 并不意味着每一次访问都可以零延迟建立连接，也不能把它简单宣传成“HTTP/3 无需握手”。首次连接、会话恢复条件、安全策略和服务器实现都会影响实际行为。

对于可能产生副作用的请求，还必须考虑重放风险。因此 0-RTT 应该作为协议能力谨慎使用，而不是为了追求一个漂亮的性能数字而盲目开启。

部署 HTTP/3 时服务器需要满足什么条件？

要真正提供 HTTP/3，仅仅修改网页代码是不够的。Web 服务器、TLS、网络和防火墙都必须支持。

  • Web 服务器或前置 CDN 支持 HTTP/3 / QUIC。
  • 服务器开放 UDP 443，而不仅仅是 TCP 443。
  • TLS 配置满足 HTTP/3 所需条件。
  • 防火墙、安全组和上游网络没有阻断 QUIC。
  • 服务器能够通过 Alt-Svc 等机制向客户端声明 HTTP/3 能力。

很多“已经开启 HTTP/3 但浏览器仍然使用 HTTP/2”的问题，实际上就出在 UDP 443、防火墙、代理/CDN 或协议声明上。

如何检查网站是否真正启用了 HTTP/3？

方法一：使用浏览器开发者工具

打开 Chrome、Edge 等浏览器的开发者工具，在 Network 面板中显示 Protocol 列。重新加载页面后，可以观察请求实际使用 h2 还是 h3。

看到 h3 才表示该次请求实际使用了 HTTP/3；服务器配置里写了 HTTP/3 并不等于客户端一定已经协商到 HTTP/3。

方法二：检查响应头

支持 HTTP/3 的站点经常会通过 Alt-Svc 响应头声明 HTTP/3 服务，例如：

alt-svc: h3=”:443″; ma=86400

但 Alt-Svc 的存在主要表示服务器在声明 HTTP/3 能力，最终是否使用 h3 仍应结合客户端实际协议结果确认。

方法三：使用支持 HTTP/3 的 curl

如果本机 curl 编译时包含 HTTP/3 支持，可以测试：

curl –http3 -I https://example.com/

如果 curl 本身没有 HTTP/3 能力，即使网站支持 HTTP/3，这条命令也无法完成测试。因此要先确认 curl 的构建特性。

HTTP/2 和 HTTP/3 可以同时开启吗？

可以，而且通常应该同时保留。

实际网站不会因为启用 HTTP/3 就完全关闭 HTTP/2。支持 HTTP/3 的客户端可以协商使用 h3；不支持 HTTP/3、UDP 被限制或协商失败时，客户端仍可以回退到 HTTP/2。

客户端支持 HTTP/3 → 尝试 h3
↓ 失败或不可用
回退 HTTP/2 → h2

这种兼容方式能够避免为了新协议牺牲旧设备或特殊网络环境的可访问性。

启用 HTTP/3 后应该观察哪些数据？

不要只检查“协议是否开启”，还应该观察真实效果。建议至少比较：

  • TTFB
  • 页面完整加载时间
  • LCP 等核心性能指标
  • 静态资源请求耗时
  • 不同地区访问延迟
  • 移动网络表现
  • 错误率与协议回退情况

如果启用 HTTP/3 前后真实用户体验几乎没有变化，也并不意味着配置失败。它可能说明当前网站的主要性能瓶颈根本不在传输协议层。

常见误区

误区一：HTTP/3 一定比 HTTP/2 快很多

错误。协议优化不能替代后端优化、缓存、图片压缩、CDN、数据库优化和前端资源治理。

误区二：开放 TCP 443 就能使用 HTTP/3

错误。HTTP/3 的 QUIC 通常需要 UDP 443 能够正常通信。

误区三：看到 Alt-Svc 就证明正在使用 HTTP/3

不完全正确。Alt-Svc 可以表示服务端声明了 HTTP/3 能力，但应继续确认实际请求协议。

误区四：启用 HTTP/3 后就应该关闭 HTTP/2

没有必要。HTTP/2 仍然是重要的兼容和回退路径。

误区五：HTTP/3 能解决所有网站速度问题

不能。如果真正的瓶颈是慢 SQL、PHP 执行时间、第三方 API 或未优化图片，升级协议并不会消除这些问题。

应该优先优化协议，还是优先优化网站本身？

对于普通网站，建议先判断瓶颈在哪里。

  • TTFB 很高：优先检查服务器、PHP、数据库、缓存和后端接口。
  • 图片和静态资源很大：优先做压缩、缓存和 CDN。
  • JavaScript 执行阻塞明显：优先优化前端资源。
  • 跨地区、高延迟或移动网络表现较差：HTTP/3 更值得测试。

HTTP/3 应该是整个性能优化体系中的一环，而不是替代其他优化工作的万能开关。

总结

HTTP/2 的核心进步之一，是通过 Stream 和多路复用提升单连接并发能力；但因为底层仍使用 TCP，数据丢失时仍可能受到 TCP 字节流队头阻塞的影响。

HTTP/3 则把 HTTP 建立在 QUIC 上。QUIC 基于 UDP，同时实现可靠传输、TLS 1.3、多路 Stream、拥塞控制和连接迁移等能力，从传输层设计上减少不同 Stream 之间因单个丢包产生的相互影响。

但 HTTP/3 并不是“开启以后网站一定更快”。真正应该关注的是用户实际网络环境和性能数据。

对于生产网站，更合理的方案通常是：保留 HTTP/2 作为兼容与回退，同时启用并验证 HTTP/3，再通过真实监控数据判断它是否改善了用户体验。

相关阅读

发表评论