策划、翻译：Alex
技术审校：刘连响
人物对话 #004#
6月7日，IETF贡献者、HTTP/3和QUIC工作组成员Robin Marx在推特上宣布：“历时五年，HTTP/3终于被标准化为RFC 9114！”
图片来源：推特
这是互联网的重要时刻。
作为HTTP的最新版本，HTTP/3将带来重大机遇和挑战。
为了更好地理解这一新发布的标准，LiveVideoStack邀请了Robin Marx加入我们的访谈，请他来跟大家详细聊聊HTTP/3。
照片由Robin Marx本人提供
2015年，作为PhD的一部分，Robin开始研究HTTP/2的性能，这使他后来有机会在IETF中参与HTTP/3和QUIC的设计。在研究这些协议的过程中，Robin开发了QUIC和HTTP/3的调试工具（被称为qlog和qvis），目前这些工具已经使来自世界各地的许多工程师受益。
在这次邮件采访中，Robin谈论了HTTP/3和QUIC带来的优势、设计HTTP/3时所遇到的挑战、HTTP/3的采用问题以及他对互联网未来发展的看法。
Robin还告诉了我们他是如何踏上“协议之路”的，并谈到了他对即将入职Akamai公司的期待。
以下是LiveVideoStack和Robin Marx的对话。
LiveVideoStack： 你好，Robin。非常感谢你能来到我们的人物对话栏目。在正式访谈开始之前，你可以先简单介绍一下自己吗？
Robin Marx： 非常高兴参与这次的访谈！2015年，作为我PhD学业的一部分，我开始研究HTTP/2性能，并参与到网络协议的相关工作中。这次研究为我提供了宝贵的机会，使我后来可以在IETF（Internet Engineering Task Force，互联网工程任务组）中参与HTTP/3和QUIC的设计。我专门开发了一系列调试和测试工具（被称为qlog和qvis），这些工具对于协议的实战测试实现很有帮助，并发现了协议规范中的很多bug和问题。过去所积累的一切最终使我获得了一份Akamai提供的解决方案架构师/网络性能专家的工作，我将在今年8月份入职。
HTTP/3和QUIC
LiveVideoStack： 与HTTP/2相比，HTTP/3中有哪些重大改进？
图片由Robin提供
Robin Marx： 作为网络协议，HTTP/3其实和HTTP/2非常相似，它提供相同的特性，如头部压缩（header compression）、服务器推送（server push，虽然依然不推荐普遍使用）、数据流优先级（stream prioritization，尽管以一种更简单、更易用的使用方式）。最主要的变化是HTTP的底层协议：HTTP/2所使用是TCP+TLS，而HTTP/3使用的是QUIC——这是一个与TLS深度集成的新型传输协议。相较于HTTP/2，QUIC和TLS的使用为HTTP/3提供了很多优势，尤其是在（网页加载）性能方面。
首先，QUIC拥有更快的连接设置，原因是它将传输层握手（TCP的SYN+SYN/ACK+ACK bootstrap）和加密握手（TLS设置）合并到一次RTT中（而HTTP/2需要2~3个RTT）。除此之外，HTTP/3可以受益于TLS 1.3的0-RTT特性，意味着可以发送HTTP请求，并能够在第一次握手期间接收到（部分）响应。尤其当客户端和服务器在地理上相距遥远时，快速连接十分有帮助。
图片由Robin提供
其次，QUIC使用了HTTP/2中的多路复用概念，并将它应用到传输协议层。这一点在技术上不太好理解，不过结果就是QUIC（也指HTTP/3）对于丢包和重新排序的恢复能力得到了提升。这解决了TCP长期存在的“队头阻塞”问题：其中HTTP/2连接上的一个丢包就可能导致其后的数据在等待重传的时候遭到阻塞。在某些情况下，HTTP/3可以解决某些数据的阻塞，以便更早地处理、提交或者执行这些数据。
再次，QUIC还有很多其他性能上的优势。比如，新的“连接迁移”特性将使切换网络（如从Wi-Fi切换到4G）更加无缝（虽然目前少有部署支持）。QUIC在如何确认接收的数据包方面也更加智能，从而更容易决定如何/何时重传丢失的数据包并调整拥塞控制逻辑。这一优势对于HTTP/3并没有太大用处，但是它可以允许其他协议（比如WebTransport或者MASQUE代理）在QUIC之上运行。
总结一下，HTTP/3主要受益于重要的新型QUIC协议，并将随着不断添加新的优化和特性而继续获益。
LiveVideoStack： 对于那些将要配置该协议的人，你有什么建议吗？
Robin Marx: 因为它的一些高级特性和基于0-RTT的安全策略以及负载均衡，HTTP/3和QUIC是出了名的复杂。在这一点上，我强烈建议你不要自己部署HTTP/3，而是选择大型CDN公司（如Akamai、Cloudflare或者Fastly）已有的部署。很快，你将能够使用AWS和Azure中开箱即用的HTTP/3，到那时，它应该已经成为谷歌托管选项了。
LiveVideoStack： HTTP/3会影响到上层的应用吗？上层应用会做更改吗？
Robin Marx: HTTP/3与HTTP/2太相似了，所以网站想在HTTP/3上正常运行几乎不需要任何更改。这与我们从HTTP1.1迁移到HTTP/2非常不同，后者通常需要进行大量的更改。
对于应用程序（以原生应用为例）来说，你将为了HTTP/3（通常也包括QUIC的实现）而使用完全不同的软件库。这里我会推荐Cloudflare的quiche、ngtcp2或quickly，它们全部开源并且在GitHub上都能找到。在一些不常见的场景中，你可以使用一个内置平台实现：iOS/OSX已经在它的网络库中支持了HTTP/3和QUIC（请参见：
https://developer.apple.com/v...），而.NET在其最新版本中也有了HTTP/3和QUIC的初步实现。
如果你只是想通过HTTP/3或者QUIC发送、接收一些数据，那么使用上述实现应该不会太难。不过当你真的想为了优化高级性能（如0-RTT或者连接迁移）而调整应用时，情况就会变得困难起来。为此，你需要真正理解HTTP/3和QUIC的工作原理、它们的局限性以及如何从各类实现的API中正确启动它们。这个时候你就得拿出几天时间深入研究源代码了。（笑）
LiveVideoStack： 对于其他应用场景，比如视频流媒体，QUIC意味着什么？它与WebRTC相比如何？新的WebTransport呢？
Robin Marx: 因为QUIC是一个通用传输协议，所以我们确实可以在更多的应用场景使用它（而不仅仅将它用于网页加载）。IETF中有一个特殊的“Media over QUIC”工作组正在认真思考视频传输（包括直播和点播）问题。然而，目前还不清楚如何能够/应该/将会以最佳方式实现，因为该领域中现有的产品（如WebRTC）已经相当强大并获得广泛部署，而QUIC是否（如何）将带来更多优势也未可知。除此之外，仅将现有的协议运行在新的QUIC上也相当困难，这些协议通常都需要某些更改。目前还在非常早期的阶段，但是学术界已经展示了一些有趣的概念：比如将可靠（关键帧）和非可靠（delta压缩帧）视频数据在单一QUIC连接中合并。我想我们将不会看到WebRTC-over-QUIC，但是未来肯定会出现它的替代。
WebTransport是另一个有趣的方向，目的是向Web开发者展示更广泛的网络特性。虽然我们在网页中被限制在HTTP（通过fetch()）或者长连接（通过WebTransport），但WebTransport将允许对网络性能进行更底层的访问。我们仍旧不能发送裸的UDP数据，但WebTransport至少允许在多人游戏以及自定义流媒体方面做更多的优化。
LiveVideoStack： 你一直在为QUIC和HTTP/3协议开发调试工具，你可以向我们介绍一下这些工具吗？对工程师而言，这些工具会带来哪些帮助？
Robin Marx: 我所开发的主要工具都在一个被称为qvis的合集中，你可以在https://qvis.quictools.info/ 上查看。这是一组可视化工具，它们显示了跨协议层的拥塞控制、流多路复用和具体分包等高级特性。我已经发现，对于这些复杂的特性而言，Wireshark这种成熟的工具还没有强大到足以为协议实现者和底层调优人员提供快速和可操作的帮助。对于一般用户来说，我希望他们永远不会用到Wireshark，不过那样的话，qvis对他们来说也会变得更加遥远。
另一个需要着重注意的地方是，qvis使用了一个专门针对QUIC和HTTP/3的数据logging格式：qlog （qlog为qvis抓包格式：https://github.com/quicwg/qlog），而非标准的抓包格式（.pcap文件）。这么做主要有两个原因：第一、QUIC在传输层被深度加密，如果不解密，封包号码等信息就无法查看（与TCP非常不一样）；第二、抓包不包括当前拥塞控制窗口、预估往返时间和丢包标记原因等信息。通过让端点（客户端和服务器）直接记录这些深度信息，我们能够创建更加强大的工具，用来帮助调试实现方式，并避免在部署场景中解密抓包（不仅可以获取QUIC数据包的元数据，还可以获取密码等用户个人信息）。因此，qlog为网络内抓包提供了一个保护隐私且更加强大的替代方案。目前，IETF正在将它进行标准化。
挑战和未来
LiveVideoStack： 你们在设计HTTP/3时面临的最大挑战是什么？最终是是如何克服的？
Robin Marx： 最初，我们本来打算将HTTP/2稍作更改直接运行在QUIC之上。但当我们这样尝试的时候，很快发现HTTP/2对TCP的工作方式做出了太多假设，而这些假设在QUIC中发生了变化。最主要的变化就是队头阻塞问题；虽然它导致了数据传输的低效，但是也保证了所有数据按照发送时的准确顺序到达。而在QUIC中，这种保证却不复存在：如果发送方发送了数据包A和数据包B，第二个数据包B很可能在数据包A之前被传送给接收方应用程序。这种情况与HTTP/2的很多假设都不符，所以我们不得不重新设计其中的很多底层机制，从而可以在HTTP/3中提供相同的高级特性。QPACK头部压缩设置和优先级系统是两个几乎完全重新设计的系统，而如何处理后者实际上也是我PhD研究的主要内容。
对于QUIC来说，当时必须解决的挑战非常多。这耗费了相当长的时间，来自谷歌、Facebook（现更名为Meta）、微软和Mozilla等各大互联网公司才能卓越的工程师们进行了多次讨论。比如，我们当时的一个目标是尽量缩小协议开销（协议元数据而非实际用户数据的数据量），而我们通过在很多地方使用巧妙的压缩技术实现了它，这些地方包括：从“可变长度整数编码（Variable-Length Integer Encoding）”到“如何发送确认”以及“QUIC如何将64位的封包号编码为一个字节（对大多数数据包来说）”。我还想到一件事，QUIC对每个数据包进行了两次加密：一次用于负载，一次用于数据包头。这里主要需要在连接周期（对于长时间运行的对话非常重要）内添加对更新加密密钥的支持，为此我们耗费了相当长的时间。
LiveVideoStack： 虽然HTTP/3采用在不断增长，但是依然面临很多重大挑战。你可以跟我们谈谈这些挑战吗？
Robin Marx： 正如我之前所说，正确、安全地设置和配置HTTP/3和QUIC极其复杂。有几家大公司为此付出了巨大努力，现在他们将它作为一种易用的商业服务提供。然而，让小公司或者个人自己部署HTTP/3和QUIC将需要相当长的时间才能实现（至少如果你想使用0-RTT、连接迁移或强大的负载均衡等高级特性的话）。
除此之外，许多网络管理员仍在犹豫是否要将QUIC部署在他们的网络之上。这其中有两个原因：
首先，QUIC之所以部署在UDP之上，主要就是为了更容易地部署在互联网上（大部分中间件已经熟悉UDP，但却不知道如何处理QUIC直接运行在IP协议上的情况）。然而，UDP经常遭受各种（阻断服务）攻击，许多允许它的网络也仅用于少数几个应用场景（如DNS）。虽然QUIC集成了大部分已知UDP攻击的缓解措施（比如内置的放大攻击限制），但大部分网络管理员对于部署缺乏适当防火墙支持的QUIC依然犹豫不决。由于协议的复杂性，防火墙厂商也一直在支持上行动缓慢；而且如果QUIC被阻止，大部分终端用户软件（如浏览器）就会自动回退到HTTP/2。
其次，QUIC加密了太多的数据包元数据，所以很难（无法）为QUIC流量提供TCP式的防火墙或者网络健康追踪服务（如追踪往返时间或者丢包统计）。因此，网络所有者将会在很大程度上失去对于允许哪种类型的网络连接的控制，并且在没有额外步骤（比如，这里qlog可以提供帮助，但为了提取数据需要与内部服务器端点交互，TCP则不需要这种操作）的情况下，引导此流量的选项也会少很多。这种增加的复杂性将再次成为中短期内更广泛部署的障碍。
LiveVideoStack： 在你看来，QUIC最终将取代TCP还是仅仅改进它？
Robin Marx： 我认为QUIC并不会完全取代TCP。总会有人选择TCP更简单的设置或者运行那些无法轻松更新、相对陈旧的应用。我能想到的一个例子就是Netflix，这家公司已投入大量资金来优化他们的TCP+TLS+HTTP/2技术栈，用以直接从Linux内核传输视频。短时间内，他们不太可能切换到HTTP/3。我确实觉得随着时间的推移，大部分应用都将迁移到QUIC上，新的应用级别的协议也将被设计为只与QUIC一起使用（同时弃用TCP）。
LiveVideoStack： 你如何看待互联网协议的未来发展？如你所见，未来的互联网将会是什么样的？
Robin Marx: 如此重度加密QUIC的主要原因之一就是防止它变得陈旧且难以发展——这是TCP的致命缺陷。TCP被广泛地部署与实现于如此多的不同设备中，核心协议的任何更改都要求大部分设备的更新，而这种更新可能需要10年以上的时间。
使用QUIC的话，好处就在于只有客户端和服务器将添加新功能用以更新，而其他（如防火墙和负载均衡器）仍保持稳定（至少在添加最初的QUIC支持后）。我并不十分确定这种情况是否真的会发生（你依然可以使用QUIC进行TLS拦截/代理），但我确实认为这是朝正确方向迈出的重要一步。
接下来几十年，我想我们很可能都将使用QUIC和HTTP/3（或者至少是它们的升级版本），然后再决定我们需要新的协议来应对量子网络和星际通信所带来的新机遇。（笑）
了解Robin
LiveVideoStack： Robin，多年来你一直致力于HTTP/2、HTTP/3 和QUIC协议的发展。你最初是怎么参与进来的？
Robin Marx： 我最开始的工作就是从HTTP/2开始的，在我加入之前，这个项目就已经存在了。当时是2015年，HTTP/2协议刚刚被IETF标准化，并开始广泛部署。
我的研究主要集中在HTTP/2性能的提升程度，当时人们声称HTTP/2的性能相比HTTP/1.1大幅提升了50%。但即使是我早期的测试也显示HTTP/2几乎从没有过如此大的性能提升。事实上，HTTP/2甚至很多时候还要慢一些。这促使我不断发现流行浏览器实现中的一些bug和问题，并将它们发布出来，这也使我的团队在圈子里收获了“street cred（指被圈子里的其他人所接受并获得尊重）”的称号。
然后在2017年左右，我当时在争论是否继续坚持HTTP/2的使用（很可能不会有更多有趣的发现），还是切换到完全崭新的协议上。然而这个时候，IETF正式开始了QUIC的实现工作。我给我的一位研究生布置了一个作业：尝试创建一个简单的QUIC协议实现，看看这个过程是否有趣。事实证明，这比预想要困难得多，我不得不加入一起来完成这个作业。在这个过程中，我们一直和IETF的工程师保持联系，他们当时也在GitHub上进行QUIC的实现。
很快我们就意识到，我们并不是唯一努力实现QUIC（后来是HTTP/3）并验证一切可以正确运行的人。那个时期，协议一直在发生大的变化，我们经常不得不重写代码库中的大部分代码。因此，我开始研究一些工具和可视化技术来帮助调试和验证我们自己的协议实现。
这个方法对我们来说非常有效，所以我们决定将它与其他协议实现者分享。令我们没想到的是，很多来自Facebook和Cloudflare等大公司的实现者对这些工具非常感兴趣。许多技术栈决定实现我们提出的qlog格式，并开始使用我们的qvis工具调试他们的系统。随着时间的推移，我们扩展了这些工具并帮助发现了许多实现中的bug和低效问题，这也使我们能够在学术场合发表这些内容，我也因此完成了博士学位 。（笑）
长话短说，我想正是我们看到解决具体问题的需求，并能够深入参与到IETF工作中而做到了这一切。
LiveVideoStack： 对于刚开始参与网络协议工作的人，你可以提供一些有用的建议吗？
Robin Marx： 我会强烈建议大家与已经加入IETF的人建立联系[通过邮件列表、GitHub、或者（远程）参与IETF会议]。这些人几乎都是来自大公司的工程师，拥有非常深厚的技术积累，并且平易近人。他们非常欢迎新人，而且出人意料地友好，乐于回答即使是非常基础的问题。
你自己也应该准备好做出承诺……协议工作很有可能会非常复杂，如果你想参与协议的设计并产生影响，你需要花一些时间了解IETF的工作方式以及它的历史。
LiveVideoStack： 你在推特上说，不久之后你将成为Akamai的网络性能专家，你对这个新的角色有什么样的期待？
Robin Marx: 自从开始PhD研究，我就一直想加入一家像Akamai这样的CDN公司。CDN是最有趣的技术公司之一：得益于其固有的全球性和对网络性能和安全的高度关注。为了保持竞争力，它们必须处于（比如）新协议实现的最前沿，因此它们需要专家来帮助内部团队和外部参与者（比如客户）理解新技术。
在Akamai，我的主要职能是帮助客户与内部专业知识建立连接，并以一种易于理解的方式向他们解释协议和其他Web（性能）相关技术的内部工作原理。这有助于将客户的业务需求转化为我们的技术实现。
对我来说，这份工作对技术的要求没有以往工作那么高，但它更注重我的其他一些强项，比如我在PhD期间发展起来的技术写作和公共演讲技能。我对这份工作非常期待！（笑）
LiveVideoStack： 最后一个重要问题，如果你有一个机会和一位互联网先驱对话，你最想和谁对话？你想和他谈论什么？
Robin Marx： 我非常希望和Van Jacobson对话，我还希望能够和Sally Floyd聊聊（不过非常遗憾的是，她在几年前去世了）。他（她）们都是为拥塞控制算法相关工作做出开创性贡献的人。
当我越深入了解各类协议和网络性能，就越清楚底层拥塞控制机制[不仅内置于TCP和QUIC协议，还存在于使用AQM（Active Queue Management，主动队列管理）的网络]的重要性。
虽然拥塞控制算法本身通常在概念上并不难理解，但是真正、深入地理解它们实际的工作原理，以及它们在真实、全球范围内的现代网络中的运行方式并不容易。我非常希望能从早期以及见证了这些协议发展的人们那里得到一些启示，来帮助我理解其中的细节之处。
比如，一些谷歌的工程师就曾告诉我，他们公司内部早就存在和我的qvis可视化非常相似的工具，并且在某些方面要比我的版本好很多，而这些工具就是由Van Jacobson本人实现的。（笑）我非常希望向Jacobson先生请教如何改进我的工作，以及如何最终超越他所实现的工具（也许）。
最后，大家如果想深入了解HTTP/3，还可以阅读Robin在_Smashing Magazine_上发表的技术文章：
https://www.smashingmagazine....
致谢：
感谢刘连响、李超、王盛三位老师提供问题线索。
更多人物对话：
- 对话Justin Uberti：RTC的过去、现在和未来
- 对话RTP作者Ron Frederick: 我非常期待QUIC的发展
- 对话MPEG创始人Leonardo Chiariglione: MPEG精神将在MPAI中延续
▲扫描图中二维码了解音视频技术大会更多信息
