HTTP / 3和HTTP / 2性能比较

去年9月 ，Cloudflare 在庆祝自己的9岁生日时宣布了对HTTP / 3的支持。我们的目标一直是改善互联网。标准领域的协作是该过程的重要组成部分，我们很幸运能够参与HTTP / 3的开发。

尽管HTTP / 3仍处于起草阶段，但我们注意到用户对新协议的浓厚兴趣（Cloudflare基础结构为超过10％的Internet站点提供服务-大约Per​​。）。迄今为止，已有113,000多个区域激活了HTTP / 3支持，如果您使用的是实验性浏览器，现在可以使用新协议访问这些区域！如此之多的人包括它真是太好了：在大量真实网站的HTTP / 3上工作意味着您可以从浏览器中测试更多各种属性。

我们最初与Google合作推出了HTTP / 3，其中还包括对Chrome Canary的实验性支持。从那时起，越来越多的浏览器增加了实验性的支持：它出现在Firefox Nightly版本中，各种基于Chromium的浏览器中，例如Opera和Edge（通过Chromium基本引擎），以及Safari的早期版本中。我们会密切关注这些进展，并在任何可能的地方提供帮助。拥有启用HTTP / 3的大型站点网络为浏览器开发人员提供了绝佳的测试平台来验证代码。

那么，目前的状态是什么？

IETF标准化过程涉及一系列草稿，以准备“最终草稿”，以准备将其标记为RFC标准。 QUIC团队成员一起进行分析，实施和互操作性，以发现潜在问题。我们在第23版草案的阶段启动了协议支持，然后我们进行了所有更改，在撰写本文时（2020年4月14日），最后一个是第27版。对于每个草案，QUIC定义的质量都会得到改善，并接近该协议应如何运行的“大致共识”。为了避免不断进行dopilivaniya设置到理想状态的永久分析，对于每个新版本的草稿，对规格进行更改的标准都会增加。这意味着每个版本的更改都更少，最终的RFC将与我们已经在生产环境中启动的协议紧密对应。

好处

HTTP / 3的主要优点之一是性能的提高，尤其是在同时请求多个对象时。在HTTP / 2中，TCP连接中的任何干扰（数据包丢失）都会立即阻止所有流（阻止行的开头）。由于HTTP / 3基于UDP，因此在丢失数据包时仅中断一个流，但不是全部。

此外，HTTP / 3支持0-RTT（零接收-发送时间），也就是说，后续连接的启动速度比第一个更快，从而消除了在建立连接时从服务器确认TLS的需要。这意味着客户端开始请求数据的时间比完全TLS协商要早得多，也就是说，网站更早开始在浏览器中加载。

下面的动画显示了丢包的影响。在第一个示例中，请求是通过HTTP / 2从客户端接收到服务器请求的，以接收两个资源。请求和相关响应以绿色和黄色显示。响应分为几个数据包。 ,，一个数据包丢失了-结果，这两种资源的传输都被延迟了。



在第二个示例中，通过HTTP / 3接收对两个资源的请求。一个数据包丢失了，从而阻止了黄色资源的传输，但又不影响绿色资源的传输。



协商会话过程的改进意味着与服务器的“连接”建立得更快，也就是说，数据在浏览器中的到达速度更快。我们很好奇这在实际流量中反映了多少，因此我们进行了一些测试。为了评估0-RTT的贡献，我们启动了一些控制测试以测量到第一个字节的时间（到第一个字节的时间，TTFB）。平均而言，在HTTP / 3上，第一个字节在176毫秒后出现。在HTTP / 2的情况下，我们看到的时间是201 ms，也就是说，HTTP / 3在这里将延迟降低了12.4％！



有趣的是，草案和RFC并未规范协议的所有方面。例如，数据包传输方法会影响性能。和交通拥塞控制算法。拥塞控制是一种适应客户端和服务器端拥塞网络的方法：当数据包丢失时，通信质量会下降。由于QUIC是新协议，因此需要进行实验和调整才能正确设计和实现过载管理系统。

作为简单安全的起点，“丢失检测和拥塞控制”规范建议使用Reno算法，但也可以使用其他算法。我们从New Reno算法开始，但是根据经验，我们认为它不是最佳算法。我们最近改用了CUBIC -在传输超大且丢包率更高的网络中，CUBIC的表现要优于New Reno。很快，我们将进一步讨论这一点，敬请关注博客更新。

在当前的HTTP / 2堆栈中，我们拥有BBR v1（TCP）。这意味着测试无法对苹果与苹果进行精确的比较，因为这些拥塞控制算法在不同的齿轮尺寸下表现不同。但是，从HTTP / 2切换到HTTP / 3时，我们已经在较小的站点上看到了改进。在大范围内，我们经过微调和优化的HTTP / 2堆栈显示了出色的性能。

一个小的15K测试页平均在443毫秒内通过HTTP / 3加载，而HTTP / 2则为458毫秒。但是，如果将页面大小增加到1 MB，此优势就会消失：特别是在我们的网络中，HTTP / 3协议的工作速度现在比HTTP / 2-2.33 s和2.30 s慢一些。







合成基准测试很有趣，但是有趣的是HTTP / 3如何在现实世界中展示自己。

为了进行比较，我们希望吸引第三方服务，该服务可以模拟网络浏览器从我们的网络下载站点。 WebPageTest是用于度量页面加载时间的通用框架，具有良好的级联图（瀑布）。为了分析后端，我们使用了自己的Browser Insights系统，将时间固定在网络边缘。然后他们通过一点自动化将两个部分连接起来。

作为衡量性能的测试案例，我们选择了自己的博客。我们设置了WebPageTest实例，以通过HTTP / 2和HTTP / 3从世界各地加载站点。包括HTTP / 3和浏览器见解。因此，每次具有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支持。对于我们而言，我们将支持最新的草案，并将寻找优化HTTP / 3以进一步提高性能的新方法，无论是设置拥塞控制，优先级设置还是系统配置（CPU和通道带宽）。

同时，如果您想尝试使用HTTP / 3，只需在我们的仪表板上激活它并下载任何主要浏览器的测试程序集（Nightly，Canary）。有关启用HTTP / 3的说明，请参阅我们的开发人员文档。