CoNEXT 2018:在Facebook上部署IETF QUIC

在12月初举行的CoNEXT 2018 EPIQ研讨会上来自Facebook的Subodh Iyengar详细介绍了Facebook如何在其基础设施中使用IETF-QUIC,并且通过Android和iOS设备上的Facebook应用程序在移动客户端上进行实验。本文来自QUIC-Tracker的博客,LiveVideoStack进行了翻译。

文 / QUIC-Tracker

译/ 元宝

原文

在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做的笔记。

精品文章推荐

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181226A06DG300?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券