纵然HTTP 3仍处于草稿状态，我们的用户对此也有很大兴趣。到目前为止，已经有超过113,000个区域激活了HTTP/3，如果您利用的是实验性浏览器，则可以利用新协议。看到如此多的人启用HTTP/3真是太棒了：通过HTTP /3访问真实的网站意味着浏览用具有更多可测试的属性。
当我们和Google互助启动对HTTP / 3的支持时，后者同时在Chrome中启动了HTTP/3实验特性。从那时起，我们看到更多的浏览器增加了实验性的支持：Firefox在其nightly版本中支持，其他基于Chromium的浏览器（例如Opera和Microsoft Edge）以及Safari 。我们会密切关注其发展，并在我们尽可能帮助互助伙伴；许多站点支持且启用了HTTP / 3也为浏览器实现者供应了一个出色的测试平台。
现状如何
IETF标准化过程将协议开拓为一系列文档草稿版本，其终极目的是天生RFC。QUIC事情组的成员在剖析，履行和互操作规范方面进行协作，以创造不得当的特性。在我们启动时，我们支持HTTP / 3草案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慢一点，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的支持。对付我们而言，我们将连续支持最新的草案，同时探求更多的方法来使HTTP / 3得到更好的性能，无论是拥塞调度，优先级划分还是系统容量（CPU和原始网络吞吐量）。
如果您想考试测验一下，只需在我们的仪表板上启用HTTP / 3并利用支持的该特性的浏览器。有关如何启用HTTP / 3的解释，请拜会我们的开拓职员文档。
原文地址：
https://blog.cloudflare.com/http-3-vs-http-2/
末了再给大家先容一场直播
本周三晚19：00，博文视点直播间聚拢云风、陈皓、唐巧、孙玄、程军5位海内神级程序员大咖，现场论道，妙解趣谈。
进行关于传奇程序员修炼之道主题的分享，扫码直通直播现场。
mini-redis，一个精简版Redis实现，基于Rust开拓
当不懂某项技能时候，如何口试工程师？
空想的DevOps流程怎么做？看看Slack的代码支配实
新项目用 Rust 还是 Go ？
如何快速定位 Redis 热 key?
如何处理代码中的邪术术字(Magic Number)
本文由高可用架构翻译。技能原创及架构实践文章，欢迎通过"大众年夜众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建办法
