HTTP/3 与 HTTP/2 的性能对比 _HTTP

文章插图

在去年 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 的拥塞控制在性能上大放异彩。