HTTP2 VS HTTP3

摘要

作为HTTP/3标准制定的参与者之一，Cloudflare公司从标准制定者的角度描述了HTTP/3当前的发展状况，以及对HTTP/3与HTTP/2的性能做了对比。

标题

HTTP/3与HTTP/2性能对比

正文

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

虽然HTTP/3仍处于草案状态，但是有大量用户对此表现出很大兴趣。到目前为止，已经有超过113000个网络区域激活了HTTP/3，如果你正在使用试验性的浏览器，则可以使用新协议对这些站点进行访问！看到如此多用户启用HTTP/3非常令人欣慰：真实的用户通过HTTP/3访问网站，浏览器可以获得多方位的测试数据，这对浏览器未来适配新的协议十分有益。

在与Google的合作下，我们启动了对HTTP/3的支持，与此同时，Google也在Google Chrome中启动了对HTTP/3的试验性支持。从那时起，我们看到越来越多的浏览器增加了对HTTP/3的实验性支持：比如Firefox的Nightly版本，其他基于Chromium的浏览器比如Opera、Edge以及Safari的技术预览版本。我们密切地关注HTTP/3的发展，并尽力为参与设计新协议的合作伙伴提供帮助；众多的支持HTTP/3的网络环境也为浏览器提供了极好的代码测试环境。

HTTP/3发展现状

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

HTTP/3的新特性

HTTP/3的主要优点之一是性能的提升，特别是在同时获取多个对象的时性能。使用HTTP/2，TCP连接中的任何中断（数据包丢失）会阻塞所有数据流（行头阻塞）。因为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的说明，请参见我们的开发文档。

作者介绍

Sreeni Tellakula

Sreeni brings 25 years of experience building systems and solutions in the areas of both wired and mobile networking technology. Serving in roles as software engineer, architect and product management leader, he has executed products and SaaS services from slides to production.

Specialties: Web and mobile performance acceleration, System Architecture, Mobile Wireless, Mobile network backhaul, IP Networking Platform Software, High Availability, Operating Systems / Real Time Kernels, Embedded Systems, Offshore development.

原文链接

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