XQUIC与多路径传输技术Multipath QUIC在Qcon大会上的分享实录
背景
首先让我们从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的特性大家都了解的很多，需要纠正的几个经典认知误区：
-
“QUIC是TCP的替代品，所以只支持可靠传输” —— 实际上QUIC在UDP之上可以提供可靠 以及 非可靠传输的双向流能力。有一篇工作组草案<An Unreliable Datagram Extension to QUIC>[1]专门描述非可靠传输协议设计。
-
“QUIC只在弱网场景有提升效果” —— 实际上我们在RPC请求（MTOP请求）场景切量到QUIC之后，大盘首包耗时以及整体请求耗时都降低了15%以上。同时QUIC在弱网长尾场景下的效果确实是更加明显的。
-
“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等场景下，用来优化体验。