策划、翻译：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（请参见：
developer.apple.com/videos/play…
假如你只是想经过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的合集中，你能够在qvis.quictools.info/ 上检查。这是一组可视化东西，它们显现了跨协议层的拥塞操控、流多路复用和具体分包等高档特性。我现已发现，关于这些杂乱的特性而言，Wireshark这种成熟的东西还没有强壮到足以为协议完成者和底层调优人员供给快速和可操作的协助。关于一般用户来说，我期望他们永久不会用到Wireshark，不过那样的话，qvis对他们来说也会变得愈加遥远。
另一个需求着重留意的当地是，qvis运用了一个专门针对QUIC和HTTP/3的数据logging格局：qlog （qlog为qvis抓包格局：github.com/quicwg/qlog…
应战和未来
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_上宣布的技能文章：
www.smashingmagazine.com/author/robi…
称谢：
感谢刘连响、李超、王盛三位教师供给问题线索。
更多人物对话：
-
对话Justin Uberti：RTC的过去、现在和未来
-
对话RTP作者Ron Frederick: 我十分等候QUIC的开展
-
对话MPEG创始人Leonardo Chiariglione: MPEG精力将在MPAI中连续
▲扫描图中二维码了解音视频技能大会更多信息
