HTTP/3 性能又大幅度提升！！

在去年 Cloudflare 生日周，我们宣布了初步支持 HTTP/2 的下一代新协议– HTTP/3 。我们的目标是为建立一个更好的互联网而努力。在标准制定上进行协作非常重要，我们很荣幸可以参与到制定标准的工作中来。

虽然 HTTP/3 仍处于草案状态，但是有大量用户对此表现出浓厚兴趣。截至目前，已经有超过 113000 个网络区域激活了 HTTP/3，如果你正在使用实验性的浏览器，则可以使用新协议对这些站点进行访问！有这么多用户启用 HTTP/3，这非常令人欣慰。

在与 Google 的合作下，我们启动了对 HTTP/3 的支持，与此同时，Google 也在 Google Chrome 中启动了对 HTTP/3 的实验性支持。从那时起，我们看到越来越多的浏览器增加对 HTTP/3 的实验性支持：比如 Firefox 的 Nightly 版本，其他基于 Chromium 的浏览器比如 Opera、Edge 以及 Safari 的技术预览版本。

HTTP/3 发展现状

IETF 标准化过程将协议开发为一系列文档草案版本，其目的是确定最终版本，并根据该版本发布 RFC。QUIC 工作组的成员在分析、实施和互操作规范方面进行协作，目的是及时发现问题并优化协议。

我们目前支持了 HTTP/3 的 Draft-23 版本，此后会持续跟进和适配未来新草案版本，在撰写本文时，最新草案版本号为 27 。针对每次草案版本更新，QUIC 协议的内容质量都会有所提升，以保证协议内容与其表现保持“基本共识”。为避免协议迭代发展过程中因为升级分析处于停滞状态，异或是因为变更而出现无休止的调整，随着每个新草案的提出，对已有规范提出修改的门槛一直在提高。这意味着版本之间的更改较小，并且最终的 RFC 应该与我们当前在生产环境中运行的协议紧密联系，差异更小。

HTTP/3 的优点

HTTP/3 的主要优点之一是性能提升，特别是在同时获取多个对象时的性能。使用 HTTP/2，TCP 连接中的任何中断（packet loss）会阻塞所有数据流（Head of line blocking）。因为 HTTP/3 基于 UDP 协议，所以如果数据包丢失，只会中断一个数据流，而不会中断所有流。

此外，HTTP/3 提供了 0-RTT 支持，这意味着在建立连接时通过消除与服务器的 TLS 确认，可以使后续连接的启动速度更快。比起使用完全 TLS 协商的方式，客户端可以更快地开始请求数据，网站可以更早开始加载。

下图说明了 HTTP/2 多路复用两个请求时数据包丢失情况及其影响。客户端通过 HTTP/2 向服务器发送请求，请求两个资源（我们将请求及其关联的响应涂成绿色和黄色）。响应被分解为多个数据包，可惜的是，如果一个数据包丢失，两个请求都会响应失败。

上面显示了使用 HTTP/3 协议多路复用 2 个请求的情况。当丢失一个黄色的响应数据包时，只对黄色数据包的响应造成影响，并不会对绿色数据包代表的响应造成影响。

会话启动方式的改进意味着与服务器的“连接”启动速度更快，这意味着浏览器可以更快地获取数据。我们很想知道改进有多大，所以我们进行了一些测试。为衡量由 0-RTT 支持带来的改进，我们运行了一些基准测试来测量获取第一个字节的用时（TTFB）。平均而言，使用 HTTP/3，我们获取到第一个字节出现在 176ms 之后。使用 HTTP/2，这个时间是 201ms，这意味着 HTTP/3 的性能已经提高了 12.4％！

有趣的是，协议的每个方面并不都受到草案或 RFC 的约束。协议实现方式的选择，例如有效的数据包传输和拥塞控制算法的选择，会影响其性能。拥塞控制是用户计算机和服务器用来适应过载网络的一种技术：通过丢弃数据包，随后的数据传输就会受到限制。由于 QUIC 是一种新协议，因此正确地进行拥塞控制设计和实现需要进行实验和调整。

从简洁性和安全性角度出发，丢失检测和拥塞控制规范建议使用 Reno 算法，但允许用户根据自身情况选择任何算法。我们的实现从 New Reno 算法开始，基于以往经验，我们知道可以通过其他方式获得更好的性能。我们最近已迁移到 CUBIC 算法，在数据传输量大且数据包丢失频繁的网络情况下，CUBIC 算法性能与 New Reno 算法相比有很大提升。

对于现有的 HTTP/2 技术栈，我们目前支持 BBR V1 （TCP）。这意味着在我们的测试中，我们无法进行精确的比较，因为这些拥塞控制算法在较小数据传输和较大数据传输之间的行为会有所不同。虽然如此，与 HTTP/2 相比，我们已经看到使用 HTTP/3 在较小内容传输下的速度更快。对于较大区域，改进后的 HTTP/2 的拥塞控制在性能上大放异彩。

对于 15KB 的小型测试网页，HTTP/3 平均需要 443ms 加载，而 HTTP/2 则为 458ms。但是，一旦我们将页面大小增加到 1MB，优势就会消失：HTTP/3 仅比当今网络上的 HTTP/2 慢一点，HTTP/3 加载花费 2.33 秒，而 HTTP/2 加载花费 2.30 秒。

基准测试很有意思，然而我们更想知道 HTTP/3 在现实世界中的表现。

为进行衡量，我们希望有一个第三方可以像浏览器一样在我们的网络上加载网站。WebPageTest 是一个通用框架，通过漂亮的瀑布图来展示页面加载时间。为了分析后端，我们使用了自家的 Browser Insights 来捕获白屏时间。然后，我们将这两部分数据通过自动化的方式结合在一起。

作为测试用例，我们决定对公司博客进行性能监控。我们在全球范围配置了 WebPageTest 实例，以同时通过 HTTP/2 和 HTTP/3 加载站点。我们还启用了 HTTP/3 和 Browser Insight。因此，每当我们的测试脚本检测到使用支持 HTTP/3 的浏览器访问该站点加载网页时，浏览器就会将报告数据返回。清洗数据并与 HTTP/2 的报告数据进行比较。

下图显示了真实页面（ blog.cloudflare.com ）的页面加载时间，以比较 HTTP/3 和 HTTP/2 的性能。同时我们还从不同的地理位置进行了这些性能评估。

如上图所见，在北美，HTTP/3 性能仍落后于 HTTP/2 性能，性能差距平均水平约为 1-4％，在欧洲，亚洲和南美也得到类似结论。我们怀疑这可能是由于拥塞算法不同所致：BBR v1 上的 HTTP/2 与 CUBIC 上的 HTTP/3 不同。将来，我们将努力在两者上支持相同的拥塞算法，以实现更准确的性能对比。

结论

总体而言，我们很高兴一起参与推动这一标准的发展。我们的实现效果很好，在某些情况下提供了更好的性能，并且在最坏的情况下性能也和 HTTP/2 相近。随着标准的定稿，我们期待浏览器在主流版本中增加对 HTTP/3 的支持。对我们来说，我们将继续支持最新的草案，同时寻找更多的方法，比如拥塞调整、优先级划分或者系统容量（CPU 和原始网络吞吐量），利用 HTTP/3 获得更好的性能。

同时，如果您想尝试一下，只需在我们的仪表板上启用 HTTP/3 并下载支持该协议的浏览器。有关如何启用 HTTP/3 的说明，请参见我们的开发文档。

https://developers.cloudflare.com/http3/intro/

参考阅读：

https://blog.cloudflare.com/http-3-vs-http-2/