HTTP/3如何击败了HTTP/2？-优快云博客

本文链接：https://blog.youkuaiyun.com/java_cjkl/article/details/149087807

目前，HTTP/3已面市，它并非单纯的升级，而是对用户数据报协议（UDP）的重新设计。下面，让我们来详细了解真实用户的使用感受，以及广泛的互联网性能监控。

如果你关注数据传输的性能、可靠性、以及在为移动应用布局的话，是时候测试和启用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可用，客户端需将其用于后续的连接。

2.Alt-Svc广告

如果存在Alt-Svc标头，则：

浏览器在ma（max-age）参数所定义的持续时间内对其缓存。
在后续访问时，浏览器直接尝试HTTP/3，而无需先通过HTTP/2进行协商。

3.浏览器的缓存行为

一旦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。

HTTP/3的主要改进

测量指标	改进（%）
首字节到达时间的中位数（毫秒）	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来处理最慢的请求。