这是一篇来自cloudflare公司的博客译文，阐述了一些HTTP3与HTTP2的性能对比。
我们在去年Cloudflare的生日周宣布支持HTTP/3，它是HTTP/2的继承者。我们的目标是并且一直是帮助建立一个更好的互联网。在标准方面的合作是其中的一个重要部分，我们很幸运能在这里做到这一点。
尽管HTTP/3仍然处于草稿状态，但我们已经看到了很多用户的兴趣。到目前为止，已经有超过113000个区域激活了HTTP/3，如果您使用的是一个实验性的浏览器，那么可以使用新的协议访问这些区域！看到这么多人启用HTTP/3真是太棒了：通过HTTP/3访问真正的网站意味着浏览器有更多不同的属性可以测试。
当我们启动对HTTP/3的支持时，我们与Google合作，后者同时在Google Chrome中启动了实验性的支持。从那时起，我们看到更多的浏览器增加了实验性的支持：Firefox加入了他们的夜间版本，其他基于Chrome的浏览器，如Opera和Microsoft Edge通过底层Chrome浏览器引擎，Safari通过他们的技术预览。我们密切关注这些开发，并尽可能地与之合作；拥有一个拥有许多启用了HTTP/3的站点的大型网络，为浏览器实现者提供了一个极好的测试平台，可以用来测试代码。
那么，现在的情况如何，我们现在在哪里？
IETF标准化过程将协议开发为一系列文档草稿版本，最终目的是生成一个最终草稿版本，该版本可以标记为RFC。QUIC工作组的成员在分析、实现和互操作规范方面进行协作，以便找到工作不太正常的地方。我们在支持HTTP/3的Draft-23的情况下启动了它，并一直在跟上每一个新的草案，其中27是最新的。在每一份草案中，小组都提高了QUIC定义的质量，并更接近于关于其行为方式的“粗略共识”。为了避免永久性的分析瘫痪和无休止的调整，每一个新的草案都增加了对规范提出修改的门槛。这意味着版本之间的更改更小，最终的RFC应该与我们在生产中运行的协议非常匹配。
优点
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稍慢，加载速度为2.33秒，而加载速度为2.30秒。
合成基准很有趣，但是我们想知道HTTP/3在现实世界中的表现。
为了衡量，我们希望第三方可以在我们的网络上加载网站，模仿浏览器。WebPageTest是一个常用的框架，它使用漂亮的瀑布图来度量页面加载时间。为了分析后端，我们使用了 Browser Insights，以捕获我们的边缘看到的时间。然后，我们用一些自动化技术把这两部分结合在一起。
作为一个测试案例，我们决定使用这个博客来监控性能。我们配置了分布在世界各地的webgetest实例，以便通过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并下载一个主要浏览器的夜间版本。关于如何启用HTTP/3的说明可以在我们的开发人员文档中找到。
附录：
原文地址：https://blog.cloudflare.com/http-3-vs-http-2/
Go QUIC库：https://github.com/lucas-clemente/quic-go