InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开：直播高峰期卡顿可降低 30%

XQUIC 是阿里巴巴淘系架构团队自研的 IETF QUIC 标准化协议库实现，在手机淘宝上进行了广泛的应用，并在多个不同类型的业务场景下取得明显的效果提升。本文，阿里巴巴淘系架构团队首次对外公开该技术，并计划今年底开源整个项目。
XQUIC 为手机淘宝 APP 的用户带来丝般顺滑的网络体验：

在 RPC 请求场景，网络耗时降低 15% ；
在直播高峰期场景，卡顿率降低 30%、秒开率提升 2% ；
在短视频场景，卡顿率降低 20%。

这是我们首次将这项新技术对外公开分享。
从以上提升效果可以看出，对 QUIC 的一个常见认知谬误：“QUIC 只对弱网场景有优化提升”是不准确的。实际上， QUIC 对于整体网络体验均有普遍提升，弱网场景由于基线较低、提升空间更显著。此外，在 5G 推广初期，基站部署不够密集的情况下，如何保证稳定有效带宽速率，是未来 2-3 年内手机视频应用将面临的重大挑战，而我们研发的 MPQUIC 将为这些挑战提供有效的解决方案。
QUIC网络分层模型及 QUIC 进化史本文将会重点介绍 XQUIC 的设计原理，面向业务场景的网络传输优化，以及面向 5G 的 Multipath QUIC 技术（多路径 QUIC）。

InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开：直播高峰期卡顿可降低 30%

本文插图

图 1. 网络七层 / 四层模型和 QUIC 分层设计为了方便说明 QUIC 在网络通信协议栈中所处的位置及职能，我们简单回顾一下网络 OSI 模型（七层模型）和 TCP/IP 模型（四层模型）。从两套网络模型中可以看出，网络传输行为和策略主要由传输层来控制，而 TCP 作为过去 30 年最为流行和广泛使用的传输层协议，是由操作系统控制和实现的。
QUIC 是由 Google 从 2013 年开始研究的基于 UDP 的可靠传输协议，它最早的原型是 SPDY + QUIC-Crypto + Reliable UDP ，后来经历了 SPDY [1] 转型为 2015 年 5 月 IETF 正式发布的 HTTP/2.0 [2]，以及 2016 年 TLS/1.3 [3] 的正式发布。 QUIC 在 IETF 的标准化工作组自 2016 年成立，考虑到 HTTP/2.0 和 TLS/1.3 的发布，它的核心协议族逐步进化为现在的 HTTP/3.0 + TLS/1.3 + QUIC-Transport 的组合。
QUIC 带来的核心收益是什么众所周知， QUIC 具备多路复用 /0-RTT 握手 / 连接迁移等多种优点，然而在这些优势中，最关键的核心收益，当属 QUIC 将四 / 七层网络模型中控制传输行为的传输层，从内核态实现迁移到了用户态实现，由应用软件控制。这将带来 2 个巨大的优势：
(1) 迭代优化效率大大提升。以服务端角度而言，大型在线系统的内核升级成本往往是非常高的，考虑到稳定性等因素，升级周期从月到年为单位不等。以客户端角度而言，手机操作系统版本升级同样由厂商控制，升级周期同样难以把控。调整为用户态实现后，端到端的升级都非常方便，版本迭代周期以周为计（甚至更快）。
(2) 灵活适应不同业务场景的网络需求。在过去 4G 的飞速发展中，短视频、直播等新的业务场景随着基建提供的下行带宽增长开始出现，在流媒体传输对于稳定高带宽和低延迟的诉求下， TCP 纷纷被各类标准 / 私有 UDP 解决方案逐步替代，难以争得一席之地。背后的原因是，实现在内核态的 TCP ，难以用一套拥塞控制算法 / 参数适应快速发展的各类业务场景。这一缺陷将在 5G 下变得更加显著。 QUIC 则可将拥塞控制算法 / 参数调控到连接的粒度，针对同一个 APP 内的不同业务场景（例如 RPC/ 短视频 / 直播等）具备灵活适配 / 升级的能力。
在众多增强型 UDP 的选择中， QUIC 相较于其他方案最为通用，不仅具备对于 HTTP 系列的良好兼容性，同时其优秀的的分层设计，也使得它可以将传输层单独剥离作为 TCP 的替代方案，为其他应用层协议提供可靠 / 非可靠传输能力（是的， QUIC 也有非可靠传输草案设计）。