Qcon演讲实录 | XQUIC与多路径传输技术Multipath QUIC

大家好，我是阿里巴巴淘系技术部的刘彦梅（花名喵吉），今天给大家介绍的演讲内容是, 下面是我在Qcon 2020上海站大会上的演讲内容，收录于专题。这个演讲内容围绕XQUIC与多路径传输技术Multi-path QUIC，其中面向5G的多路径传输协议，算法和技术由淘系架构团队与达摩院XG实验室/ 阿里云AIS网络研究团队的研究人员共同研发(XG实验室/网络研究主要参与同学包 括：马云飞，郑智隆，刘洪强)，之前有一篇介绍XQUIC的相关内容 < 面向5G的阿里自研标准化协议库XQUIC > ，大家有兴趣可以对照阅读。

背景

首先让我们从5G的时代背景推导下对传输通信协议技术可能产生的影响。由于5G空口技术带来的信道能量效率的大幅提升，使得单位流量（Byte）的传输开销下降。其次由于5G基站采用的频段相对于4G更高，由于高频段在链路上损耗更多，使得单个基站的覆盖范围更小，因此也更容易出现信号覆盖空洞的问题。

由于基础设施建设带来的带宽提升，媒体类业务大规模发展，又进一步要求传输技术能够提供有效带宽的保障。

这里大家可以发现，增强型UDP（类似QUIC/RTP/SRT等等）出现百花齐放的发展状态，背后最大的原因有两个：第一个原因是内核态的TCP演进周期慢，难以满足业务发展的诉求；第二个原因是一套实现在内核态的传输协议和拥塞控制算法，也难以满足各类业务场景下差异化的业务诉求。

关于传输通信协议的发展过程，这里还是要多说两句。这张图上展示了QUIC的发展历程，以及我们在手淘上实践的传输通信协议的发展过程。在过去，我们也曾经因为标准化的TLS/1.2握手流程相对于无线端太慢，当时TLS/1.3标准也还在演进过程中，于是我们上线了私有加密协议SlightSSL并快速解决了业务流量加密通信的问题。当后续的TLS/1.3出现之后，我们同样面临升级并替换掉过去的私有方案的问题。

关于私有协议还是标准化协议的取舍，我的观点是，如果标准化协议并没有适合当下的业务场景诉求的解决方案，那么设计一套私有协议并快速满足业务诉求是完全合理的；当标准化方案演进到能够提供对应能力时，采用标准化的解决方案会是更合理的选择。

2021年注定将会是不平凡的一年。在这一年里，IETF QUIC经历了工作组四年的草案修订，终于将要Release成为RFC。我们实现的XQUIC也将在这一年里开源。

QUIC本质上是一个灵活的Reliable / Unreliable传输协议框架。关于QUIC的特性大家都了解的很多，需要纠正的几个经典认知误区：

1. “QUIC是TCP的替代品，所以只支持可靠传输” —— 实际上QUIC在UDP之上可以提供可靠 以及 非可靠传输的双向流能力。有一篇工作组草案< An Unreliable Datagram Extension to QUIC >[1]专门描述非可靠传输协议设计。

2. “QUIC只在弱网场景有提升效果” —— 实际上我们在RPC请求（MTOP请求）场景切量到QUIC之后，大盘首包耗时以及整体请求耗时都降低了15%以上。同时QUIC在弱网长尾场景下的效果确实是更加明显的。

3. “QUIC是HTTP/3的一部分，所以只能使用HTTP作为应用层协议” —— 实际上由于QUIC协议族良好的分层设计，QUIC-Transport传输层上是可以承载任意其他的应用层协议的，例如像上传协议、RTMP等。

XQUIC是阿里自研的标准化QUIC实现协议库。关于XQUIC的整体架构和传输框架设计，在上一篇文章中有比较详细的介绍，这里也不再赘述。

多路径传输技术 Multi-path QUIC

关于前面提到的5G NSA的信号覆盖空洞问题，我们也可以考虑结合非蜂窝网络的通道进行多通道传输。多通道（Multipath）技术的核心在于通过多条（物理）链路来保障网络通信的可靠性和稳定速率。

由于手淘是无线端APP，我们主要考虑的场景还是复用Wi-Fi和Cellular双通道，同时在单边信号强度弱的情况下，通过另一边通道进行补偿，并保障整体的通信质量和带宽。过去在TCP基础上也有Multipath TCP[2]的协议，以及内核态实现。Apple等手机厂商也将MPTCP应用于Siri / APNS消息推送 / Apple Music等场景下，用来优化体验。

我们很自然地考虑将QUIC和多路径技术进行结合，也就是多路径QUIC（Multipath QUIC）。该项技术是淘系架构团队、达摩院XG实验室/AIS网络研究团队联合研究并实现的多路径传输技术。

Multipath QUIC[3]是实现在QUIC传输层内部的多路径协议栈。相较于在应用层建立多条连接并在应用层进行分配流量和调度的方案，在协议栈内部实现多路径的好处是对于应用层透明，使用方便；同时多路径packet调度需要紧密结合路径传输层的信息（RTT/丢包率等测量信息），这在应用层也是很难做到的。相较于传统的内核态多路径解决方案MPTCP，Multipath QUIC也有易于部署迭代等优势，同时作为用户态协议栈，也更容易结合应用层需求进行调度算法的优化。

传输协议设计与系统架构设计有很多异曲同工之处。好的传输协议设计与系统架构设计都具备简洁、灵活、便于扩展等特点，每一个新概念的引入都应当有其必要性。我们在设计Multipath QUIC协议的过程当中，进行了大量的讨论和反复推敲。

QUIC-v1[4]提供了良好的协议扩展性，其中QUIC-Transport已经支持连接迁移（connection migration）能力，所以我们仅对QUIC-v1进行了最小化扩展，使得传输层可以支持同时在多条路径上发送数据。在协议穿透性的方面，考虑到为了避免被仅识别QUIC-v1报文格式的middle box丢弃报文，我们选择尽量不修改QUIC-v1的header格式。由于不同路径的报文需要有路径唯一标识进行区分识别，我们使用Connection ID的编号（sequence number）来做路径的唯一标识，并以此区分来自于不同路径的packet。此外，我们需要针对每条路径分别维护拥塞控制算法的上下文，RTT测量信息，以及路径的MTU发现等信息。

最新Multipath QUIC版本草案的新建路径流程

由于手淘在大力发展内容生态，我们将这项技术应用于手淘短视频的上传和下载场景（目前在灰度中），可以同时使用Wi-Fi和LTE进行传输，并提供更好的QoE体验。在视频场景下，主要的效果是可以加速视频的上传和下载，同时可以降低在弱网场景下视频的卡顿率和re-buffering时间。

我们来实际看一下多路径传输技术的效果如何。下面的视频内容是我们在手淘灰度版本集成Multipath QUIC技术的效果展示。其中左边的手机是集成了多路径传输的版本，可以同时使用Wi-Fi和LTE，右边是单路的版本，只能使用Wi-Fi。可以看到，当Wi-Fi出现带宽波动，右边播放的短视频会出现卡顿，与此同时左边能够流畅播放。

在多路径技术的演进过程中，还有很多问题需要解决，例如MP-HOL[5]问题：当两条路径的传输能力差异较大，慢的一条路径可能拉长分片整体的传输时长。对于路径调度的算法，以及与拥塞控制算法的结合，也还有很多值得探索之处。

标准化相关

在上次介绍XQUIC的内容发出后，我们收到IETF QUIC标准化工作组主席Lars Eggert邀请，XQUIC加入到IETF QUIC实现的互通性验证中。前段时间我们也参加了工作组组织的Multipath QUIC主题Interim Meeting，介绍Alibaba对Multipath QUIC的应用场景以及我们的草案和实现相关情况[7]。

在IETF草案方面我们也与XG实验室/阿里云网络研究团队、集团标准化部，以及原Internet Architecture Board的主席Christian Huitema进行了深度论证与合作，目前阿里巴巴的Multipath QUIC草案[6]已经演进到02版本，期望收到更多的应用场景的需求说明。如果你对多路径技术也感兴趣或者想使用在你的场景下，欢迎邮件与我们交流。

开源计划

上一篇介绍XQUIC的文章发出后，有不少内部和外部的小伙伴，联系我们询问XQUIC的开源计划。这里首先感谢大家的支持和关注，要跟大家说一声特别抱歉，我们在开源进度上有一些delay。由于QUIC 6个基础草案的最新版本又做了一些更新，我们仍然在努力完善最新的draft版本功能。我们最新的计划是在2021年的Q1能够正式开源XQUIC。

附录：参考文献 

✿  拓展阅读

作者| 刘彦梅(喵吉) 

编辑| 橙子君

出品| 阿里巴巴新零售淘系技术