在12月初举行的CoNEXT 2018 EPIQ研讨会上来自Facebook的Subodh Iyengar详细介绍了Facebook如何在其基础设施中使用IETF-QUIC，并且通过Android和iOS设备上的Facebook应用程序在移动客户端上进行实验。本文来自QUIC-Tracker的博客，LiveVideoStack进行了翻译。
文 / QUIC-Tracker
译/ 元宝
原文
https://quic-tracker.info.ucl.ac.be/blog/epiq-2018/2018/12/10/epiq-2018-keynote-facebook.html
在12月的第一周，第一届QUIC的演变，性能和互操作性研讨会在克里特岛Heraklion的CoNEXT 2018上举行。我们展示了我们的论文，观察了QUIC实现的演变，并与参加研讨会的研究人员和工程师进行了讨论。在这一系列的博客文章中，我们报告了研讨会每个会议的摘要以及我们做的一些笔记。
主题演讲：大规模快速移动
在Facebook上部署IETF QUIC的经验（Subodh Iyengar - Facebook）
经过两位主持人约尔格·奥特(Jorg Ott，慕尼黑TU)和拉尔斯·埃格特(Lars Eggert, NetApp)简短的介绍，当天的第一位主讲人是来自Facebook的Subodh Iyengar。鉴于宣布了一个有趣的标题，但没有摘要，这个主题演讲将成为研讨会的一个很好的起点。在大约一个小时内，主讲人详细介绍了Facebook如何在其基础设施中使用IETF-QUIC，以及如何通过Android和iOS设备上的Facebook应用程序在移动客户端上进行实验的。
主讲人概述了有关使用QUIC代替TCP的几个要求。
能够在不中断连接的情况下更新其代理。
能够始终如一地连接路由到应用程序服务器。
能够使用QUIC进行连接，但回退到TCP不会影响延迟。
能够检测QUIC并获取日志以分析性能问题。
QUIC中的零停机重启
基于Proxygen的 Facebook代理会不断重新启动以更新其软件。理想情况下，在更新期间不应关闭现有的连接。在代理更新期间建立新连接时也不会发生停机。为了实现这一点，将服务器ID编码到所选服务器的ConnectionID中。一个位就足以区分旧服务器和新服务器。新代理实例使用此位来区分新的传入连接与现有连接。这些现有连接是UDP封装的，并路由到旧实例。
一旦所有旧连接终止，代理更新就完成了。此操作大约需要15分钟。
QUIC数据包的稳定路由
在部署的初始阶段，Facebook工程师注意到使用QUIC的连接超时率很高。他们首先怀疑是死连接导致的，但由于他们没有实现无状态重置机制，他们选择这样做是为了保证每个对等端的连接状态视图是同步的。他们发现他们无法将这些重置发送到正确的连接，这表明存在数据包路由问题。为了调试此问题，他们再次利用服务器选择的ConnectionID，并保留了第二部分来指示服务器主机ID。现在，每个服务器都能够记录到达错误目的地的数据包。
在实现了对Facebook的L3负载均衡器katran中的服务器主机ID的支持后，他们观察到错误路由数据包的数量降至0。请求延迟降低了15％，表明此问题影响了相当多的连接。主讲人指出，他们打算在实现多路径和任播QUIC等期货功能时使用这个ID。
汇集连接
他们首先分析了允许UDP连接的网络数量。在25000家运营商中，大约有4000家没有使用QUIC。主讲人表示，这些携带者没有统计学意义，但他没有提供更准确的数字。他们的团队联系了他们中的一些人，询问关于这个堵塞的问题。他们报告称，一些运营商故意将UDP屏蔽在众所周知的使用之外，例如DNS。其他一些人意外阻止了它。
鉴于这种观察，他们选择竞争QUIC和TCP，以便在回退到TCP的情况下，延迟不会受到影响。他们使用TCP和TLS 1.3 0-RTT与QUIC进行比较，因此两者都需要相同数量的RTT才能建立连接。他们一开始采取了一种幼稚的方法，即同时启动展位，一旦获胜就取消另一个展位。使用这种方法，他们报告了QUIC的70％使用率。主讲人指出了概率损失和TCP中间件加速可能是导致这个结果的原因。
赛车算法的第二个版本进行了实验。在TCP连接的开始处添加了100ms的任意延迟，但没有观察到QUIC使用率的改善。建立连接的客户端是移动设备，他们怀疑无线电唤醒延迟会影响他们的结果。在QUIC连接开始时，再次观察到更高的随机损失，它们可能归因于中间盒。
他们的第三个版本的算法更复杂，但将QUIC利用率提高到93％。首先，如果QUIC失去竞争，则删除TCP延迟，如果QUIC获胜，则在后续连接上添加TCP延迟。其次，当TCP获胜时，QUIC不再被取消，如果建立了连接，则通过QUIC发送新请求。
在结束这一节时，演示者展示了他们在汇集TCP和QUIC连接时使用的0-RTT数据。他们选择了保守的方法，即如果TCP + TLS 1.3 0-RTT成功，则取消通过QUIC发送的请求。在QUIC上失败的请求将在TCP上重播。
在生产中调试QUIC
就其可能的操作数量而言，QUIC是一个复杂的协议。回答为什么在Y时刻发送X帧的问题？因此，在观察其行为时至关重要。为了解决这个问题，主讲人介绍了Facebook的QUIC跟踪格式，它记录了实现的内部状态。它允许它们诊断连接生命周期中发生的几个事件，例如拥塞窗口阻塞和丢失恢复持续时间。
他们发现恢复的ACK阈值，例如触发快速重传，在其使用情况下的大部分时间是不够的，因为在接收到足够的数据包以触发它之前可能需要几个RTT。他们还发现大多数时候HTTP连接都处于空闲的状态。
结果
主题演讲的最后一部分是关于性能结果的。主持人首先介绍了他们的实验装置。
Facebook的QUIC实现mvfst是通过Facebook应用程序和他们的proxygen服务器部署在移动客户端上的。他们实施了草案-09，主讲人指出该草案相当稳定，可以追溯到2018年1月。在进行实验时使用了Cubic拥塞控制器，我假设它在TCP和QUIC中都有，但我的注释中缺少这方面的内容。他们专注于API风格的请求和响应，而不是完整的HTML页面和资产。请求大小介于247字节和13 KB之间，而响应大小则包含64字节和500 KB。
结果显示，第75个百分位数的延迟减少了6％，第90个百分位数减少了10％，第99个百分位数减少了23％。在隔离后续请求(即在连接生命的后期发送的请求)的性能结果时观察到这些百分比的延迟降低分别为1%、5%和15%。主讲人注意到，在隔离RTT小于500ms的连接时，延迟也有类似的降低。
只显示了相对数字，没有给出绝对数字。主讲人解释说，他不允许分享这些数字，但他保证这些数字在实践中具有重要意义。他在总结主题时解释说，虽然使用早期版本的QUIC和HTTP/1.1的这些初始结果是有前途的，但是还有很多实验需要进行。如本主题所述，大规模使用QUIC还需要对基础设施进行重大更改。
最后，主讲人展望了一些未来的工作，例如将mvfst更新为最新的QUIC规范草案，添加HTTP / 3和0-RTT支持。他们的团队还将探索新的用例，例如实时视频的部分可靠性和低延迟视频传输。
问答环节
观众提出的第一个问题涉及到mvfst在TCP方面的公平性，以及如何负责大规模部署QUIC。主讲人解释说他们没有详细查看。总体而言，他们没有观察到与拥堵和公平相关的问题，因为通过QUIC交换的数据相对较小。主讲人指出，很多连接不会退出慢启动，因为它们的时间非常短。
观众还提出了一个关于CPU性能的问题。他解释说，他们没有调查移动客户端对电池寿命的影响，但他们观察到整体CPU使用率有所增加，部分原因是sendmsg调用。
下一个问题涉及在客户端代理通信之外在其主干网内使用QUIC，以及他们在两者之间观察到的两者之间的差异。主讲人解释说，他们没有观察到主干网CPU使用率的差异。他指出，损失率接近于0，并且连接经常在主干网中重复使用。
一个关于mvfst可用性的简短问题被提出，主讲人宣布客户端和服务器最终都将是开源的。
观众席上的一个人对他们使用ConnectionID领域表示担忧，他指出这是滥用，并且鼓励了分层违规。主讲人评论说，IP层正在开展一些工作来应对这些问题。他指出，ConnectionID除了数据包路由之外，它还可以用于其他目的。
最后一个问题是关于主干内外的QUIC如何共存。主讲人介绍了边缘代理终止与客户端的QUIC连接，并在主干中建立新的连接的方法。
致谢
我要感谢FrançoisMichel在本文中提供的照片，Quentin De Coninck在研讨会上做的笔记，以及Robin Marx做的笔记。
精品文章推荐
技术干货：
本文分享自微信公众号 - LiveVideoStack（livevideostack）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
