Robin讲HTTP/3 #005#
到现在为止，我们主要对比了QUIC和TCP中的性能特性。那么HTTP/3和HTTP/2之间的区别是什么？我们在第一部分讨论过，HTTP/3实际上是HTTP/2-over-QUIC，所以新版本中并没有推出什么真正重要的新特性。这与从HTTP/1到HTTP/2不同，其中的变化更多，并推出了如头压缩、流优先级和服务器推送等新特性，HTTP/3中依然保留了这些特性。
HTTP/3与HTTP/2之间的重要差异在于它们的底层实现方式。
QUIC的队头阻塞消除在其中起了很大作用。我们之前讨论过，数据流B的丢失不再意味着数据流A和C必须等待B的重传（像它们在TCP上那样）。因此，如果A、B和C每一个都按照那个顺序发送QUIC数据包，那么它们的数据很可能按照A、C和B的顺序传送到浏览器（并由浏览器处理）。换言之，QUIC不再像TCP那样对不同的数据流完全排序！
这成了HTTP/2的一个问题，因为HTTP/2所设计的许多特性（这些特性使用分散在数据块中的特殊控制消息）都要依赖TCP的严格排序。而在QUIC中，这些控制消息可以按照任何顺序到达，甚至可能会使这些特性发挥与预期相反的作用。本文无需详述这其中的技术细节，但这篇论文的前半部分会告诉你它是多么的复杂[1]。
因此，必须针对HTTP/3更改这些特性的内部机制和实现。一个具体的例子是HTTP头压缩，它降低了较大的重复HTTP头（比如cookies和user-agent字符串）所产生的开销。HTTP/2通过HPACK[2]实现了HTTP头压缩，而在HTTP/3中，这一系统被重新设计为更加复杂的QPACK[3]。两个系统以不同方式提供相同的功能（头压缩）。在Litespeed上你可以找到关于这个问题很棒的深度技术讨论和图表[4]。
推动数据流多路复用的优先级特性也是如此，我们在之前的文章中已经简单讨论过。为了实现优先级，HTTP/2使用了一个复杂的依赖树（dependency tree），该设置尝试对所有网页资源及其相互关系建模（想了解更多信息，你可以观看《HTTP资源优先级终极指南》[5]的演讲）。在QUIC上直接使用这个系统很可能导致非常错乱的依赖树布局，因为将每个资源添加到树上都需要一个独立的控制消息。
此外，事实证明，完全没有必要使用这么复杂的方法，因为它会导致实现错误和低效问题[6]，以及许多服务器上的性能不佳[7]。因此，需要为HTTP/3重新设计一种更加简单的优先级系统[8]。这种更直接的设置使得一些高级场景难以或不可能实现（比如，单一连接上代理流量来自多个客户端的情况），但仍然为网页加载优化提供了广泛的选项。
再来重申一下，这两种方法提供相同的功能（引导数据流的多路复用），但HTTP/3更简单的设置将减少实现错误。
最后，还有服务器推送。服务器可以通过这一特性发送HTTP响应，而无需先等待明确的请求。理论上，这会带来出色的性能提升。但实际中却被证实，服务器推送很难被正确[9]使用且无法获得一致的实现[10]。结果就是，它很可能将从Google Chrome中移除[11]。
尽管如此，服务器推送依然被HTTP/3定义为特性[12]（虽然少有实现支持它）。它的内部工作方式并没有像前两个特性那样发生很大的变化，但它同样适应了QUIC的非确定排序。不过遗憾的是，这并不会解决那些长期存在的问题。
这一切意味着什么？
正如我们之前所说，HTTP/3的大部分潜力来自底层的QUIC，而非HTTP/3本身。虽然HTTP/3的内部实现非常不同于HTTP/2，但是它们的高层性能特性和使用方式仍然保持一致。
值得关注的未来发展
在本系列中，我常常强调更快的进化和更高的灵活性是QUIC（以及HTTP/3）的核心概念，所以看到人们已经开始研究协议新的扩展和应用就不足为奇了。下面列出的是你可能会遇到的主要扩展和应用：
• 前向纠错[13]
这一技术的目的是通过发送冗余数据拷贝（经过巧妙的编码和压缩后没有那么大）提升QUIC对丢包的恢复能力。如果出现丢包，但是冗余数据已达到，那么就不需要重传了。
前向纠错最初是Google QUIC的一部分（这也是人们说QUIC能很好地防止丢包的原因），但是它并没有被标准化的QUIC版本1收录其中，因为当时还未证实它是否对性能有影响。研究人员正在积极对它展开试验，你可以通过PQUIC-FEC Download Experiments[14]应用向他们提供帮助。
• 多路径QUIC[15]
我们前期讨论了连接迁移，以及从Wi-Fi迁移到蜂窝网络时连接迁移所发挥的作用。不过，这是否表示我们可以同时使用Wi-Fi和蜂窝网络？同时使用两个网络会让我们获得更多带宽并增加网络的稳健性。这就是多路径背后的主要概念。
Google也曾尝试多路径，但是由于其固有的复杂性，QUIC版本1并没有包含这一技术。不过，科研人员已经展示[16]了它强大的潜力，并很可能在QUIC版本2中实现它。注意，TCP 的多路径已经存在[17]，但花了差不多十几年才可用（审校者注：TCP 多路径已经存在，但一直没有被大规模使用）。
• QUIC上的非可靠数据[18]和HTTP/3[19]
我们已经知道，QUIC是一个完全可靠的协议。不过，由于它运行在不可靠的UDP上，我们可以向QUIC添加一个特性使它可以发送非可靠数据。这一点在提交的数据报进行了描述。当然，你不会使用QUIC去发送网页资源，但对于游戏和实时视频流来说，它可太方便了。这样一来，用户就能获得了UDP带来的所有好处，同时还能获得QUIC级的加密以及（可选）拥塞控制。
• WebTransport[20]
浏览器不会直接向JavaScript暴露TCP或UDP，主要是出于安全考虑。相反，我们必须依赖HTTP级的API，比如Fetch和更加灵活的WebSocket[21]和WebRTC[22]协议。WebTransport是这一系列选项中最新的一个，它允许你以一种更加底层的方式使用HTTP/3以及QUIC（虽然如果需要的话，它也可以回退到TCP和HTTP/2）。
关键在于，WebTransport具备在HTTP/3上使用非可靠数据的能力（见前一点），这样一来，游戏等便更容易在浏览器中实现。对于正常的（JSON）API调用来说，你将（当然）依然使用Fetch（如果可能的话，它会自动使用HTTP/3）。现在，对WebTransport的讨论众说纷纭，因此还不清楚它最终如何。在这些浏览器中，目前只有Chromium正在研究一个公开的概念验证实现[23]。
• DASH和HLS视频流
对于非实时视频（如YouTube和Netflix）来说，浏览器通常使用基于HTTP（DASH）的动态自适应流或HLS协议。基本上，它们意味着你要将视频编码为小块（2~10秒）和不同的质量水平（720p、1080p和4K等）。
在运行时，浏览器估计你的网络可以处理的最高质量（或者一个特定应用场景的最佳质量），然后通过HTTP从服务器中请求相关文件。浏览器无法直接访问TCP协议栈（通常在内核中实现），所以它偶尔会在估计时犯错，或者需要一些时间对变化的网络状况做出反应（导致视频停顿）。
QUIC作为浏览器的一部分被实现，所以通过访问底层协议信息[24]（比如丢包率、带宽估计等）可以有效改善这一状况。其他研究人员也在试验将可靠数据和非可靠数据混合用于视频流[25]，已经获得了不错的成果。
• HTTP/3之外的其他协议
由于QUIC是一个通用传输协议，我们可以期待现在运行在TCP上的多个应用层协议也运行在QUIC之上。这类工作正在进行中，其中包括：DNS-over-QUIC[26]、SMB-over-QUIC[27]甚至SSH-over-QUIC[28]。与HTTP和网页加载相比，这些协议通常有非常不同的要求，所以我们讨论过的QUIC的性能提升也许对这些协议更有效。
这一切意味着什么？
QUIC版本1只是一个开始。谷歌早期试验的更多高级性能向特性都没有进入第一轮迭代。然而，这里的目标是快速发展协议，高频率地推出新的扩展和特性。因此，QUIC（HTTP/3）将逐渐变得比TCP（HTTP/2）更快和更灵活。
结论
在本系列的第二部分，我们已讨论了HTTP/3（特别是QUIC）许多不同的性能特点和特性。我们也已经知道：虽然其中的大部分特性看起来影响很大，但实际中，它们并没有在网页加载方面为用户带来太大的帮助。
比如我们看到，QUIC使用UDP并没有突然获得更多的带宽（与TCP相比）。经常受到称赞的0-RTT特性其实是一种微优化，为你节省了一个RTT，其中你可以发送约5KB的数据（最坏的情况下）。
如果出现突发丢包或者你在加载渲染阻塞资源时，队头阻塞消除的效果并不好。连接迁移非常依赖情境，HTTP/3并不具备任何重要的新特性使它比HTTP/2更快。
你也许希望我建议你跳过HTTP/3和QUIC，为什么这么麻烦？对吧？但我绝不会这样做！即使这些新协议不会为网络较快的用户提供太多帮助，但它们肯定会为经常移动的用户和较慢网络上的用户带来巨大影响。
即使在西方市场中（比如我所在的比利时，我们通常都有很快的设备，并且能够访问高速蜂窝网络），上述情况也会影响到1%甚至10%的用户群（取决于你的产品）。一个例子是：有人在火车上迫切想要查看你网站上的重要信息，但必须等上45秒的加载时间。我就有过这种经历，所以非常希望有人部署QUIC来助我摆脱困境。
但是，其他国家和地区的情况依然非常糟糕，其中普通用户更像是比利时最慢的那10%用户，而最慢的1%用户也许连网页都加载不了。在世界上的很多地方[29]，网络性能是一个可访问性和包容性问题[30]。
这就是我们不该仅在自己的硬件上测试网页的原因（还可以使用Webpagetest[31]等服务），也是你绝对应该部署QUIC和HTTP/3的原因。特别是如果你的用户经常移动，或者不太可能访问快速蜂窝网络，这些新协议也许能够带来很大的帮助（即使你并没有在你的有线MacBook Pro上注意到这些）。关于更多细节，我非常推荐Fastly的这篇文章[32]。
如果这些还不能完全说服你，可以考虑一下QUIC和HTTP/3在未来几年将继续进化且变得更快。使用这些新协议的早期经验将在未来获得回报，使你尽快收获这些新特性的好处。此外，QUIC在后台执行安全和隐私最佳实践，世界各地的用户都会受益于此。
你现在被说服了吗？接下来的第三部分将介绍如何在实际中使用这些新协议。
注释：
[1] https://h3.edm.uhasselt.be/files/HTTP3_Prioritization_extended_3jul2019.pdf
[2] https://datatracker.ietf.org/doc/html/rfc7541
[3] https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack
[4] https://blog.litespeedtech.com/tag/quic-header-compression-design-team/
[6] https://blog.cloudflare.com/nginx-structural-enhancements-for-http-2-performance/
[7] https://github.com/andydavies/http2-prioritization-issues
[8] https://blog.cloudflare.com/adopting-a-new-approach-to-http-prioritization/
[9] https://calendar.perfplanet.com/2016/http2-push-the-details/
[10] https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/
[11] https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ
[12] https://datatracker.ietf.org/doc/html/draft-ietf-quic-http
[13] https://tools.ietf.org/html/draft-swett-nwcrg-coding-for-quic
[14] https://play.google.com/store/apps/details?id=org.pquic.pquic_fec_android
[15] https://tools.ietf.org/html/draft-liu-multipath-quic
[16] https://multipath-quic.org/
[17] https://www.multipath-tcp.org/
[18] https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram
[19] https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram
[20] https://web.dev/webtransport/
[21] https://hpbn.co/websocket/
[23] https://groups.google.com/a/chromium.org/g/web-transport-dev/c/6PwPFy9fVfw
[24] https://dl.acm.org/doi/abs/10.1145/3386367.3431901
[26] https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic
[28] https://datatracker.ietf.org/doc/html/draft-bider-ssh-quic-09
[29] https://infrequently.org/2021/03/the-performance-inequality-gap/
[30] https://hookedoncode.com/2020/07/performance-is-accessibility/
[31] https://www.webpagetest.org/
[32] https://www.fastly.com/blog/how-http3-and-quic-help-long-tail-connections
作者简介：
Robin Marx: IETF贡献者、HTTP/3和QUIC工作组成员。2015年，作为PhD的一部分，Robin开始研究HTTP/2的性能，这使他后来有机会在IETF中参与HTTP/3和QUIC的设计。在研究这些协议的过程中，Robin开发了QUIC和HTTP/3的调试工具（被称为qlog和qvis），目前这些工具已经使来自世界各地的许多工程师受益。
标签：分析,HTTP,QUIC,ietf,特性,https,org,com From： https://blog.51cto.com/u_13530535/6465407