HTTP/3如何击败了HTTP/2？
译者 | 陈峻
审校 | 重楼
如果你关注数据传输的性能、可靠性、以及在为移动应用布局的话，是时候测试和启用HTTP/3了。
由互联网工程任务组（IETF）于2015年正式发布下一代HTTP协议--HTTP/2，旨在解决当时HTTP/1.1协议存在的性能瓶颈问题，提升网络传输效率。不过，尽管HTTP/2有着诸多承诺，但网络延迟与抖动仍存在于现实的网络世界中。目前，HTTP/3已面市，它并非单纯的升级，而是对用户数据报协议（UDP）的重新设计。下面，让我们来详细了解真实用户的使用感受，以及广泛的互联网性能监控。
HTTP/2的核心限制
当HTTP/2推出时，它通过引入多路复用、二进制帧和标头压缩，来解决HTTP/1.1的局限性。然而，其最大的缺陷在于它仍然与TCP绑定。而TCP是一种并不适合现代多路网络工作负载的协议。其具体表现在：
TCP行头（head-of-line，HOL）的阻塞：尽管HTTP/2允许在单个连接中跑多个传输流，但由于TCP的有序交付要求，一旦丢失的TCP数据包则会阻断掉所有传输流。连接设置的开销：建立HTTP/2连接往往需要经历：DNS解析→TCP握手→TLS握手（通常使用应用层协议进行协商）的过程。恢复处罚：数据包丢失会触发TCP级别的重新传输。由于增加了首字节（TTFB）和交互时间（TTI），因此这往往会影响到整个连接。而用户在真实使用中确实能感受到由HTTP/2代理引发的抖动、丢包、延迟、以及可靠性降低。HTTP/3如何解决TCP的核心瓶颈
其实，HTTP/3并非简单地将HTTP/2应用到UDP上，而是为当前互联网重新构建了HTTP/2，并运行在QUIC（快速UDP互联网连接）上。此处的QUIC是由谷歌设计的传输协议。虽然用到了UDP，但它是一套针对可靠性、加密和性能而自行构建的技术栈。总的来说，HTTP/3的主要优势在于：
无行头阻塞：QUIC支持完全独立的传输流。即使某个传输流中出现了丢失包，也不会阻止其他数据包的传输。更快的握手：QUIC结合了加密和传输设置。TLS 1.3直接被集成到了QUIC中，以允许1-RTT（往返时间）甚至0-RTT的恢复。恢复的改进：QUIC使用了数据包编号和ACK（确认）范围，而非序号，因此具有更智能的拥塞控制和恢复机制。连接的迁移：QUIC连接可以在IP变更中留存下来。这对于在Wi-Fi和LTE之间切换的移动网络来说非常实用。此外，在高丢包率的条件下，HTTP/3仍能缩短现实传输的等待和加载时间。HTTP/3工作原理
为了充分读懂HTTP/3的工作原理，我们需要了解浏览器、DNS和缓存层，并获悉它们是如何相互协同的。
1.初始DNS查询该过程始于客户端对A/AAAA记录执行DNS查询时。该查询会将IPV6映射到相应的域名上。为了让HTTP/3使用UDP之上的QUIC，服务端必须向客户端发出支持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，而不会中断用户的浏览体验。4.TLS握手中的ALPN应用层协议协商（ALPN）会在TLS握手期间被用于协商HTTP的版本：
如果服务端支持HTTP/3，它便会发布h3 ALPN字符串。QUIC握手则会启用a1-RTT连接（如果使用的是会话恢复的话，则启用0-RTT）。如果服务不支持h3，客户端将会自动降回到HTTP/2。5.回退流（可通过Wireshark观察到）以下是HTTP/3在实践中能够发挥的作用：
浏览器根据A/AAAA记录（可能还有HTTPS/SVCB或服务绑定记录）发送DNS查询。它尝试向目标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时可能会带来较小的延迟，特别是在高损耗或高延迟环境中。而在网络状况的影响方面：在出现Aggressive NAT、以及网络抖动或数据包丢失率过高等情况时，QUIC的连接也可能会中断或失败。此类情况在亚太地区和非洲尤为明显。总的说来，HTTP/3的双回退策略（无论是通过DNS的HTTPS记录，还是Alt-Svc标头发起）都能够提供强大、用户透明的协议协商功能。即使在次优的网络条件下，浏览器也可以通过回退到HTTP/2来保持连接，以确保可靠性。
部署注意事项
尽管具有架构优势，但是HTTP/3并非随处可用。在现实世界的网络中，仍然会有如下障碍，可能会影响到它的可靠性，甚至完全阻止其被使用。
关键的环境依赖性：中间层和防火墙：A.许多企业防火墙和一些传统路由器会阻止或降低UDP流量的优先级。B.QUIC（以及h3扩展）使用UDP端口443，但并非所有网络都配置为允许使用该端口。运营商级NAT（CGNAT）：A.在移动和共享IP环境中，QUIC的连接ID是一个很大的优势，但如果NAT映射过期设置太短或被快速重新分配，则会导致QUIC的中断。旧路由器和网络设备：A.一些较旧的路由器可能无法很好地处理高速UDP，导致在高吞吐量QUIC会话期间出现数据包的抖动或丢失。TLS卸载和代理：A.在卸载了TLS的边缘架构处（如一些反向代理或负载平衡器），可能无法原生地支持QUIC，或需要架构的调整。
回退是一项特征，而并非失败当QUIC因上述任何原因被阻止或失败时，现代化的浏览器和CDN会优雅地回退到HTTP/2，这也是h3的精妙之处。下表是两代技术的比较：
特点
HTTP/1.1
HTTP/2
HTTP/3
传输协议
TCP
TCP
UDP + QUIC
多路复用级别
无（每个连接1个请求）
应用层（多个流）
传输层（QUIC原生流）
并发请求/域
约6个（浏览器限制）
通过流媒体且无限制
通过流媒体且无限制
行头阻塞
在应用程序/浏览器级别
是的（TCP级HoL会影响所有流）
否（QUIC避免了传输级的HoL）
性能（多资产）
排队并被封锁
并行加载
并行、更适合在较差的网络中
TLS支持
可选/通过TCP
强制性（TLS 1.2/1.3）
内置（仅限TLS 1.3）
握手RTT
2–3个RTT（TCP + TLS）
2–3个RTT
1个RTT（0-RTT恢复后）
0-RTT支持
不
不
是（在恢复连接时）
IP移动性/NAT重新绑定
不
不
是（通过QUIC连接ID）
连接恢复
TLS会话ID/单
TLS会话恢复
QUIC-原生连接ID
连接重用
有限的
是
是
传输流优先级
不
是
是
需要加密
不
通常强制执行
始终（QUIC通过设计加密）
浏览器/CDN支持
通用
完全支持
快速增加（Chrome、Safari等）
丢包状况
影响整个连接
影响所有多路流
隔离到单个传输流
最佳用例
传统系统，向后兼容
带有常规网络流量的稳定网络
现代应用程序、移动、有损或高延迟网络
现实世界正在加速采用HTTP/3让我们来查看一些基于年份的数据：
年份
HTTP/2的采用
HTTP/3的采用
2022
~63%
~22%（参考QUIC）
2023
~64%
~28%
2024
~50%
~34%
2025（预计）
~62.5%
~41.5%
2026年（预计）
~52.5%
~57.5%
其中：
Cloudflare、Fastly和Akamai等CDN现在已默认启用HTTP/3。Chrome、Firefox、Safari和Edge都支持HTTP/3。支持HTTP/3的网站呈增长趋势，特别是在那些注重性能的地区。HTTP/3的重要特性
根据我们的经验和现实世界的测试，HTTP/3在以下领域意义重大：
高延迟和损包地区：非洲、东南亚偏远的拉丁美洲城市。移动网络：在LTE和Wi-Fi之间频繁切换。密集API的应用：通过非阻塞多路复用受益于多并发调用。性能第一团队：愿意投资于毫秒级改进的团队（如Core Web Vitals）。真实测试洞见我们使用跨多个国家的分布式主干节点，采用强制协议模式在HTTP/2和HTTP/3之间进行并行比较。测量了以下方面：
DNS、连接、SSL、等待、加载时间跨区域的h2和h3之间的性能数据包丢失/抖动与协议回退的相关性在几乎每个涉及非理想条件的情况下，HTTP/3在等待和加载时间上都优于HTTP/2。
性能分析通过对在六个国家运行的性能比较与分析，基于数千次运行结果，我们测量了首字节时间（TTFB）、最大内容显示（Largest Contentful Paint，LCP）和视觉完整性（VC）的中位数与第99百分位的数值，结果表明HTTP/3在关键网络性能指标上始终优于HTTP/2。
测量指标
改进（%）
首字节到达时间的中位数（毫秒）
41.80%
首字节第99百分位到达时间的中位数（毫秒）
7.30%
最大内容显示中位数（毫秒）
10.40%
最大内容显示第99百分位数（毫秒）
9.60%
视觉完成中位数（毫秒）
10.50%
视觉完成第99百分位数（毫秒）
8.60%
如上表所示，HTTP/3大幅减少了TTFB中位数（平均41.8%）。可见，在所有测试区域中，初始服务端的响应时间与HTTP/2相比要快得多。同时，最大内容显示（LCP）和视觉完成（VC）的改进也是一致的（平均约10%）。这意味着用户使用HTTP/3能够更快地看到最多的内容和完整的页面。
国家级细分国家
TTFB Mdn
TTFB 99th
LCP Mdn
LCP 99th
VC Mdn
VC 99th
澳大利亚
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（超过78%）得到了最大的TTFB改进，同时转化为LCP和VC的显著提升。巴西的第99百分位数TTFB和VC显示了负改善。该异常情况表明，在最慢的请求中，HTTP/3的表现不如HTTP/2。日本、英国和美国在大多数指标上，显示出了适度且一致的改善，特别是在中位数方面。其他观察一致性：中位数的改进通常大于第99百分位数，表明HTTP/3对于那些典型（非极端）用户的体验特别奏效。区域差异性：虽然HTTP/3总体向好，但是实际改进程度因地而异，这与各地网络基础设施和延迟有关。实际上，在多个国家的真实骨干测试中，HTTP/3一直优于HTTP/2。这在澳大利亚和德国最为明显。它在减少初始化响应时间（TTFB）和页面渲染速度（LCP、VC）上的合理改善已卓见成效。相关案例也表明，HTTP/3可以为那些延迟敏感的应用程序，带来网络性能上的提升。而在巴西等一些地区的个案中，浏览器连接仍倾向于用HTTP/2来处理最慢的请求。
小结
综上所述，HTTP/3不仅能提供更快的速度，而且具有一定的鲁棒性。如果你关注数据传输的性能、可靠性、以及在为移动应用布局的话，是时候测试和启用HTTP/3了。无论是自运营的基础设施，还是使用第三方CDN，由HTTP/3带来的协议上的演变，必将为现实世界中上亿规模的用户带来更快的互联网浏览体验。
译者介绍
陈峻（Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验。
原标题：HTTP/3 in the Wild: Why It Beats HTTP/2 Where It Matters Most，作者：Wasil Banday
