摘要：HTTP/3通过QUIC协议解决HTTP/2的TCP队头阻塞问题，握手更快，丢包恢复更佳。浏览器通过DNS或Alt-Svc标头发现HTTP/3，支持回退至HTTP/2。实际测试表明，HTTP/3在高延迟和丢包区域性能更优，但需考虑防火墙和NAT等因素。
HTTP/3通过QUIC协议解决HTTP/2的TCP队头阻塞问题，握手更快，丢包恢复更佳。浏览器通过DNS或Alt-Svc标头发现HTTP/3，支持回退至HTTP/2。实际测试表明，HTTP/3在高延迟和丢包区域性能更优，但需考虑防火墙和NAT等因素。
译自：HTTP/3 in the Wild: Why It Beats HTTP/2 Where It Matters Most
作者：Wasil Banday
尽管 HTTP/2 承诺了很多，但 Web 仍然在延迟、抖动和真实世界的网络波动中挣扎。因此，HTTP/3 应运而生——它不仅仅是一次升级，而是在 用户数据报协议 (UDP) 基础上进行的一次彻底的重新设计。基于数千个真实用户模拟和 Catchpoint 在六大洲进行的广泛的 互联网性能监控，以下是我们所了解到的。
当 HTTP/2 推出时，它通过引入多路复用、二进制帧和头部压缩来解决 HTTP/1.1 的局限性。然而，它最大的缺陷是它仍然 与 TCP 绑定，而 TCP 协议的设计初衷并非用于现代的、多路复用的 Web 工作负载。
HTTP/2 的核心局限性：
TCP 的队头阻塞 (HoL) 阻塞：即使 HTTP/2 允许在单个连接中存在多个流，但由于 TCP 的按序交付要求，丢失的 TCP 数据包会阻塞所有流。连接建立开销：建立 HTTP/2 连接需要 DNS 解析 → TCP 握手 → TLS 握手（通常使用应用层协议协商）。恢复惩罚：数据包丢失会触发 TCP 级别的重传，这会影响整个连接，从而增加首字节时间 (TTFB) 和可交互时间 (TTI)。我们的测试始终表明，HTTP/2 在抖动和丢失的情况下表现不佳，延迟更长，可靠性降低。
HTTP/3 不是基于 UDP 的 HTTP/2——它是为当前互联网重新构想的 HTTP/2。它运行在 QUIC（Quick UDP Internet Connections，快速 UDP 互联网连接）之上，QUIC 是 Google 设计的一种传输协议，它使用 UDP，但构建了自己的堆栈来实现可靠性、加密和性能。
HTTP/3 的主要优势：
没有队头阻塞：QUIC 支持完全独立的流。一个流中丢失的数据包不会阻塞其他流。更快的握手：QUIC 结合了加密和传输设置。TLS 1.3 直接集成到 QUIC 中，从而允许 1-RTT（往返时间）甚至 0-RTT 恢复。改进的丢失恢复：QUIC 包括更智能的拥塞控制和恢复机制，使用数据包编号和 ACK（确认）范围而不是序列号。连接迁移：QUIC 连接可以在 IP 更改后继续保持（这对于在 Wi-Fi 和 LTE 之间切换的移动网络非常有用）。在高丢失条件下，HTTP/3 在实际测试中始终能够减少等待时间和加载时间。
要理解 HTTP/3 的工作原理，仅仅深入研究协议规范是不够的。要完全理解它的运作方式，我们需要检查浏览器、DNS 和缓存层，并了解它们是如何相互作用的。这种更深入的研究揭示了与 HTTP/2 相比，尤其是在回退机制和网络响应方面的关键行为差异。
该过程始于客户端执行 DNS 查询以获取 A/AAAA 记录，这些记录将 IPV6 映射到相应的域名。对于依赖于基于 UDP 的 QUIC 的 HTTP/3 而言，要使用它，服务器必须向客户端发出 QUIC 支持信号。
有两种主要的方式可以发出此信号：
DNS 级别：服务器可以使用 HTTPS 记录（特别是服务绑定参数或 SvcParams）直接在 DNS 响应中包含 QUIC 支持。这会通知客户端支持 QUIC（以及 HTTP/3）。示例：
_443._tcp.example.com. IN HTTPS 1 . alpn="h3, h2"
浏览器级别：如果未通过 DNS 提供 QUIC 信息，服务器仍然可以在初始 HTTP/2 连接期间的响应头中发出 HTTP/3 支持信号。Alt-Svc 标头（例如，alt-svc: h3=":443"; ma=2592000）包含在服务器的 HTTP/2 响应中。这会通知浏览器 HTTP/3 可用，并且客户端应在将来的连接中使用它。如果存在 Alt-Svc 标头：
浏览器会将其缓存，缓存时间由 ma（max-age，最大期限）参数定义。在将来的访问中，浏览器会直接尝试 HTTP/3，而无需首先通过 HTTP/2 进行协商。一旦缓存了 Alt-Svc：
浏览器将优先使用 HTTP/3 来建立与同一来源的后续连接。如果 QUIC 连接失败（例如，由于 UDP 被阻止或 NAT 问题），浏览器会静默地回退到基于 TCP 的 HTTP/2，而不会中断用户体验。应用层协议协商 (ALPN) 在 TLS 握手期间用于协商 HTTP 版本：
如果服务器支持 HTTP/3，它会广播 h3 ALPN 字符串。QUIC 握手启用 a1-RTT 连接（如果使用会话恢复，则为 0-RTT）。如果服务器不支持 h3，客户端会自动回退到 HTTP/2。以下是它在实践中的运作方式：
浏览器发送 DNS 查询以获取 A/AAAA 记录（以及可能的 HTTPS/SVCB 或服务绑定记录）。它尝试与目标 IP 和端口建立 QUIC 握手。如果在较短的超时窗口（通常为 300–500 毫秒）内未收到 QUIC 响应，浏览器会并行启动 TCP 握手。关键洞察： 浏览器会竞争 QUIC 和 TCP 连接。无论哪个握手先完成，都会被使用：
如果 QUIC 成功，则使用 HTTP/3。如果 QUIC 被阻止或超时，则基于 TCP 的 HTTP/2 会接管。这种双重握手模型可确保有机会尝试 HTTP/3，但如果需要，可以平稳地回退到 HTTP/2，而不会影响用户。
兼容性：
Chrome 和 Firefox 稳健地支持此回退机制。Microsoft Edge 更加保守，可能需要手动启用 HTTP/3 或实验性设置才能进行一致的测试。性能考虑因素回退速度很快，但并非瞬时：虽然 QUIC–TCP 竞争最大限度地减少了中断，但回退到 TCP 可能会引入较小的延迟损失，尤其是在高丢失或高延迟环境中。网络条件的影响：在涉及以下情况的场景中，QUIC 连接可能会中断或失败： 激进的 NAT 具有高抖动或数据包丢失的网络在测试期间，这些问题在亚太地区和非洲尤其明显。
HTTP/3 的双重回退策略——无论是由 DNS HTTPS 记录还是 Alt-Svc 标头启动——都提供了稳健、用户透明的协议协商。即使在非最佳网络条件下，浏览器也会通过回退到 HTTP/2 来保持连接，从而确保可靠性。
通过了解 DNS、缓存和浏览器内部组件如何协同工作，我们可以深入了解 HTTP/3 的弹性、性能优化以及在各种网络环境中的实际行为。
尽管 HTTP/3 具有架构优势，但其性能并非在所有地方都能得到保证。在现实世界的网络中，它仍然需要克服各种可能影响其可靠性甚至阻止其使用的障碍。
中间盒和防火墙： 许多企业防火墙和一些旧版路由器会阻止 UDP 流量或降低其优先级。 QUIC（以及扩展的 h3）使用 UDP 端口 443，但并非所有网络都配置为可靠地允许它。 运营商级 NAT (CGNAT)： 在移动和共享 IP 环境中，QUIC 的连接 ID 是一个很大的优势，但如果 NAT 映射过期速度过快或被快速重新分配，即使是 QUIC 也可能会断开连接。 旧路由器和网络设备： 某些较旧的路由器可能无法很好地处理高速 UDP，从而导致在高吞吐量 QUIC 会话期间出现抖动或数据包丢失。 TLS 卸载器和代理： 在边缘卸载 TLS 的基础设施（如某些反向代理或负载平衡器）可能尚不支持 QUIC 本身，因此需要变通架构。当 QUIC 由于任何原因被阻止或失败时，现代浏览器和 CDN 会平稳地回退到 HTTP/2。事实上，h3 部署的部分巧妙之处在于这种静默回退模型：
当 Alt-Svc 可用并被缓存时，浏览器会尝试 QUIC。如果由于网络原因而失败，用户永远不会看到错误，并且 h2 会弥补不足。特性HTTP/1.1HTTP/2HTTP/3传输协议TCPTCPUDP + QUIC多路复用级别无（每个连接 1 个请求）应用层（多个流）传输层（QUIC 原生流）并发请求/域~6（浏览器限制）通过流无限制通过流无限制队头阻塞在应用/浏览器级别是（TCP 级别的 HoL 会影响所有流）否（QUIC 避免了传输级别的 HoL）性能（许多资源）排队和阻塞并行加载并行 + 在不良网络中更好TLS 支持可选 / 通过 TCP强制（TLS 1.2/1.3）内置（仅 TLS 1.3）握手 RTT2–3 个 RTT（TCP + TLS）2–3 个 RTT1 个 RTT（恢复时为 0-RTT）0-RTT 支持否否是（在恢复的连接上）IP 移动性 / NAT 重新绑定否否是（通过 QUIC 连接 ID）连接恢复TLS 会话 ID / 票证TLS 会话恢复QUIC 原生连接 ID连接重用有限是是流优先级否是是加密要求否通常强制执行始终（QUIC 在设计上已加密）浏览器/CDN 支持通用完全支持快速增长（Chrome、Safari 等）年份HTTP/2 采用率HTTP/3 采用率2022~63%~22%（作为 QUIC）2023~64%~28%2024~50%~34%2025（预计）~62.5%~41.5%2026（预计）~52.5%~57.5%根据我们的经验和实际测试，HTTP/3 在以下方面提供了最大的影响：
高延迟和高丢失地区：非洲、东南亚偏远的拉丁美洲城市。移动网络：在 LTE 和 Wi-Fi 之间频繁切换。API 密集型应用程序：多个并发获取调用受益于非阻塞多路复用。性能至上的团队：投资于毫秒级改进的团队（例如核心 Web 指标）。我们使用了多个国家/地区的分布式骨干节点来运行 HTTP/2 和 HTTP/3 之间的并排比较，并使用了强制协议模式。测量了以下几个方面：
DNS、连接、SSL、等待、加载时间跨区域 h2 和 h3 之间的性能差异数据包丢失/抖动与协议降级的相关性在几乎所有涉及非理想情况的场景中，HTTP/3 在等待时间和加载时间方面都优于 HTTP/2。
一项跨六个国家/地区的比较分析表明，基于数千次测试运行，测量了首字节时间 (TTFB)、最大内容绘制 (LCP) 和视觉完整 (VC) 的中位数和第 99 个百分位数值，HTTP/3 在关键 Web 性能指标方面始终优于 HTTP/2。
HTTP/3 在中位数 TTFB 方面实现了大幅降低（平均 41.8%），表明与所有测试区域的 HTTP/2 相比，初始服务器响应时间要快得多。
LCP 和 VC 的改进是一致的（平均约为 10%），这意味着用户使用 HTTP/3 可以更快地看到最大的内容和视觉上完整的页面。
国家/地区TTFB 中位数TTFB 第 99 个百分位LCP 中位数LCP 第 99 个百分位VC 中位数VC 第 99 个百分位澳大利亚84.10%4.10%14.90%16.40%18.70%16.30%巴西15.80%-11.60%7.60%0.80%3.20%-2.30%德国78.70%13.80%19.10%8.80%21.90%12.50%日本10.90%27.30%4.70%20.70%1.00%11.80%英国47.10%8.80%14.40%7.90%15.70%10.10%美国13.80%1.30%1.70%3.10%2.50%3.30%澳大利亚和德国在使用 HTTP/3 时 TTFB 方面的改进最大（超过 78%），这也转化为 LCP 和 VC 的显著收益。巴西的第 99 个百分位 TTFB 和 VC 显示出负面改进，这表明在某些异常情况下，HTTP/3 对于最慢的请求的性能不如 HTTP/2。日本、英国和美国在大多数指标上都显示出适度但一致的改进，尤其是在中位数方面。一致性：中位数改进通常比第 99 个百分位更强，这表明 HTTP/3 对于典型（非极端）用户体验尤其有效。样本大小：每个国家/地区的测试运行次数都很稳健（从几百次到超过 34,000 次不等），这增加了这些趋势的统计显著性的可信度。区域可变性：虽然 HTTP/3 几乎总是更好，但改进幅度因地理位置而异，这可能是由于网络基础设施和延迟的差异所致。在多个国家/地区的实际骨干测试中，HTTP/3 始终优于 HTTP/2，尤其是在减少初始响应时间 (TTFB) 方面，并且在页面渲染速度（LCP、VC）方面有适度但有意义的改进。在澳大利亚和德国，这些优势最为明显，而在巴西等一些地区，边缘情况下 HTTP/2 对于最慢的请求仍然可能更有利。
这些发现支持采用 HTTP/3 以提高 Web 性能，尤其是在全球受众和对延迟敏感的应用程序方面。
HTTP/3 不仅仅是更快，它也更具弹性。如果您关心性能、可靠性以及为更加移动优先的未来做好准备，那么现在是测试和启用 HTTP/3 的时候了。无论您是运行自己的基础设施还是使用第三方 CDN，这都是一项值得采用的协议演进。互联网的未来不仅仅是更快的页面，而是让 Web 在真实条件下为下一个 10 亿用户服务。
来源：小何论科技