写点什么

阿里正式开源自研 XQUIC:已服务手淘上亿用户,网络耗时降低超 20%

  • 2022-01-07
  • 本文字数:4135 字

    阅读完需:约 14 分钟

阿里正式开源自研 XQUIC:已服务手淘上亿用户,网络耗时降低超 20%

采访嘉宾 | 喵吉


1 月 7 日,阿里巴巴大淘宝技术团队主导自研的 IETF QUIC 标准化协议库 XQUIC 正式开源,其中多路径传输能力与达摩院 XG 实验室联合研发。XQUIC 采用了目前应用较为广泛的 Apache License 2.0 许可证,并将代码托管在 GitHub 上。


XQUIC 项目链接:https://github.com/alibaba/xquic


据 XQUIC 项目负责人、阿里巴巴架构师喵吉介绍,XQUIC 协议的整体架构遵循 IETF QUIC 协议分层的设计理念,阿里团队针对传输层和应用层做了解耦实现。当前的 XQUIC 开源版本与之前发布的版本相比,新增了对 IETF RFC 版本的 QUIC v1 支持,对 QPACK 等部分功能模块进行了重构,增加了多路径支持等功能。到目前为止,XQUIC 已经在手淘正式版本为上亿用户提供了网络请求加速的体验优化。

XQUIC 特点

阿里巴巴大淘宝技术团队在 2018 年底开始研发 XQUIC 实现,去年 8 月正式对外发布。如今,XQUIC 针对 IETF QUIC 协议的实现已相对成熟,并且在手淘体系里也做了大规模应用来验证其稳定性。


据悉,目前手淘里面的导购场景 RPC 请求、短视频下载与文件上传等核心场景中应用了 XQUIC 实现网络加速。团队也在应用实践中,不断做新功能迭代 / AB 实验和 Congestion Control 算法调优等工作。


此外,阿里内部其他 APP,如闲鱼、AliExpress 等,也开始尝试使用 XQUIC 进行网络体验优化。


喵吉表示,XQUIC 本身服务手淘场景,目前更多地聚焦在短视频传输、视频/图片上传等典型的可靠传输场景,但 XQUIC 也将非可靠传输 / 半可靠传输场景纳入研发计划,未来也将结合社区开发者诉求,逐步纳入更多传输需求场景。


据喵吉介绍,目前开源版本的 XQUIC 主要具备以下两个优势:


  • 协议设计方面,XQUIC 是按照 IETF QUIC 标准[1]进行的协议栈能力实现,在互通性方面,XQUIC 也在 IETF 开发者社区进行了比较充分的互通性验证[2]。在 QUIC V1 标准的基础之上,XQUIC 添加了对多路径传输的能力支持。

  • 协议实现方面,XQUIC 是跨平台的 C 库实现,当前提供对 Android/iOS/Linux 平台的支持。在移动端 APP 场景,XQUIC 在 Android / iOS 双端的包大小在 300~400KB 之间,相对轻量化。同时,XQUIC 也具备高性能传输能力,针对移动性场景优化也会持续进行。关于 multipath 技术演进,具体可以点击查看大淘宝技术团队与达摩院 XG 实验室联合发表的论文


据喵吉透露,XQUIC 将手淘导购 RPC 的网络耗时缩减了 17.52%~20.26%,短视频/图片的上传速度提升了 22.61%,并减少了短视频下载场景下 7~16%的视频分片下载耗时。

研发一年半,终于发布

XQUIC 的研发从一定程度上来说是一件不得不做的事。


如今的电商早已是移动端的天下。2020 年,亚洲移动端电商已经占到了整个电商行业的 78%。在这一趋势下,网络传输协议可以有一个端到端的良好实现,能在安卓和 IOS 系统上有良好的适配、在服务端有高性能协议栈的实现,成了电商业务场景提升网络体验的核心需要。


面对该业务需求,有两种可以选择的方案:一是基于其他的开源实现做轻微改进并直接使用,但开源实现是否能够满足各方面需求是个疑问;二是基于某个开源方案做大量的优化和改进,但这样又会导致修改后的版本难以回归到主干,以致出现版本分裂的问题。


2018 年底的时候,除了国外的一些大厂,相对成熟且开源的 IETF QUIC 协议实现并不多。而时至今日,虽然很多国外厂家的 QUIC 协议实现已经开源,但仍存在一些问题:有的实现相对较重,有的对移动端跨平台的适配不在高优先级支持,有的则与自己生态结合比较紧密,对所在企业的实现库依赖性很大。此外,国内的大厂一直都没有太多的 QUIC 开源实现。这种情况下,阿里大淘宝技术团队开始自研 QUIC 协议。


在 18 年底到 20 年中的一年半时间里,团队都在做 XQUIC 的研发。据喵吉介绍,整个研发过程可以分为三个阶段:


  • 第一个阶段,团队主要任务是完整地去理解整个协议的设计和很多内部细节。

  • 第二个阶段,团队先针对整体协议设计去做模块的拆解,再针对协议框架和拆解出来的模块去做合理的流程设计。

  • 第三个阶段,团队才开始进行各个功能模块的细节性编码,考量性能、效率等问题。“整个过程中,相对比较困难的主要有三个地方。一是前期大家对 QUIC 协议认知的对齐,二是在设计阶段对模块功能和报文处理流程的合理抽象,三是后期的传输性能和服务端性能优化。”喵吉说道。


团队要跨过的第一个门槛是要完全理解 QUIC 协议的细节。在研发各个模块之前完全吃透设计原理至关重要。但协议栈本身的设计和各方面机制的建设相对比较复杂,这从 350 多页的协议说明可见一斑。


但在实际中,业界的很多协议介绍资料并不是特别准确,而看原版 RFC 资料可能存在门槛,不看的话又很难达成统一的认知,甚至会导致传播错误信息的情况。据喵吉透露,他们团队为了完整吃透协议内容,在前期把 IETF QUIC 6 个核心草案内容进行了翻译和学习(沉淀约 200 多页的中文资料),并在研发过程中定期组织学习讨论最新草案版本,以此来保证团队内的认知对齐。这些中文资料也已经在开源社区贡献出来,帮助国内开发者更好地理解协议栈原理。


XQUIC 协议本身就是一个技术栈的实现,因此在研发实践中,阿里大淘宝技术团队先从底层开始向上做能力的叠加。早期先在传输层做了实现,并针对传输层做场景优化,之后在此基础上叠加 HTTP3 的实现等,然后再面向各个业务场景做贴合业务场景的 QoS 优化。

填补国内开源空缺

“在我的理解中,现在不是存在很多开源的 QUIC 协议,而是有很多开源的 QUIC 协议的实现,因为 QUIC 协议只有一个版本。”喵吉说道。


QUIC 最早是 Google 提出的一种基于 UDP 的低时延的互联网传输层协议。2016 年 11 月,国际互联网工程任务组(IETF)召开了第一次 QUIC 工作组会议,QUIC 开始进行标准化,成为新一代传输层协议。


当前的 QUIC 协议主要有两个流派:一派是 IETF 业务标准化工作组的 QUIC 协议,目前已释放了传输层的四个核心协议,预计今年将释放应用层 HTTP3.0 协议;另一派则是基于 Google 早期开源的 QUIC 版本演进后的各种协议版本。这两个流派的协议演进仍然有不少差异,体现在协议设计和实现两个层面,但是整体的行业大趋势还是往 IETF QUIC 的方向演进。


协议层更多关注协议交互,具体实现上,各家会有比较大的差异。虽然从协议层面上来看,IETF QUIC 传输层的通用性设计,使得它可以适配各类业务场景,但在实践中,每个企业都有自己的侧重点。比如,谷歌会更多从浏览器角度出发,微软则更侧重于 Windows 等的适配,而像阿里手淘这样的 App 厂商则需要更多考虑移动端适配和性能问题。


“XQUIC 是一个适配移动端、轻量且高性能的传输协议库。”喵吉说到,“除了想让 IETF QUIC 在移动端上得到更好的应用外,我们也想弥补当前国内缺少相对成熟的开源实现这一空缺,现在比较成熟的开源实现大部分还是以 Google、Facebook 等国外企业为主。”


此外,喵吉表示,开源可以让更多开发者参与进来,团队也可以得到使用者基于场景的反馈,能更好地对协议做持续迭代。喵吉也呼吁各企业网络研发团队能够一起为协议栈发展贡献力量。


事实上,XQUIC 协议原本计划开源的时间要更早些。喵吉表示,开源的时间节点首先受 IETF QUIC 最终 RFC 的定稿时间影响,其次在这段时间内开发支持的新功能,也希望在内部场景经过充分验证。5 月底,IETF 发布了 QUIC 正式版 RFC 8009 ~ 9002,这一时间已经临近 618,团队决定先将工作重点放在 618 的保障上。之后,我们又针对内部模块做了一些功能重构,并且经历了 21 年电商双十一的大规模考验,稳定性和性能方面都比较成熟,才最终确定在 22 年初的 1 月完成开源。


XQUIC 与其它开源方案的一个最大不同就是增加了 QUIC 对于多路径的支持,该方案由手淘与达摩院 XG 实验室联合研发,相关草案已经更新到04版本。基于 XQUIC,阿里巴巴首次实现了基于用户体验驱动的多路径传输 XLINK 并在手淘短视频场景做了规模化灰度验证,是业界第一个完成大规模灰度验证的多路径 QUIC 传输方案,相关成果发表于网络领域的 Top1 会议 SIGCOMM 2021。


开源后,除了内容分享,XQUIC 社区会进行定期的 Review,以把控代码的整体质量。

未来还有很多可能

“QUIC 是一个通用的传输层协议框架,未来的趋势是各个典型场景驱动的 QoS 优化,而面向业务场景的 Congestion Control 优化可能是关键的突破点。”喵吉表示。


QUIC 整体设计具有通用性和完备性。与 TCP 相比,更快、安全性更高,有 0-RTT 的握手能力,还提供了非可靠传输能力。很多基于 TCP 应用层协议的场景,已经开始考虑切换到 QUIC 协议上。根据 Cloudflare 分析,现在互联网上使用 QUIC 的 HTTP/3 流量约有 12%。


但是,不同业务对底层网络传输的诉求有很大的差异。例如,RPC 请求、视频点播场景以及实时音视频传输的场景,对底层传输能力的要求就不一样。因此,如何在相同的协议框架基础上针对自己的业务做优化,就成了业内非常关注的话题。


很多企业开始自研 QUIC 协议也与此有关。虽然大家有一个通用的协议设计,但由于各企业关注点不同,研发的重点也各不相同,协议的实现也就不同。“很难有一个可以满足所有业务场景的通用解决方案。”


一方面,企业们都够清晰地看到 QUIC 带来的收益。现在,用户体验越来越受重视,而对整体传输质量非常关键的网络传输层必然是需要重视的。另一方面,过去 TCP 实现在内核态,APP 应用对网络传输层的演进和掌控上相对比较薄弱,很多时候要依赖内核升级,但内核升级并不容易,客户端依赖厂商版本,而服务端的内核版本迭代则有一个很长的升级周期。


“QUIC 把过去依靠内核实现的网络传输能力转移到了用户态,这样我们可以面向业务场景做更多的调优,甚至结合应用层的一些特性做 QoE driven 的优化,这对所有 APP 厂商来说都很关键,实践中大家也确实感受到了传输能力提升带来的体验收益。”喵吉表示。QUIC 诞生 8 年,第一个版本已经相对成熟,传输层能力也有基本保障,但在非可靠传输领域 和 应用层方向上还有很多新的尝试和机会。


相对 TCP 来说,目前所有的 QUIC 实现在服务端性能上与来源内核态实现的差别不大,在加解密、本身协议处理等方面也还存在性能损耗和额外性开销,因此,服务器性能优化是不少开源实现都在重点研究的方向之一。


“Google 做这件事坚持了 7、8 年,这种对底层技术的长期投入是非常值得敬佩的,并且他们也确实拉动了整个网络技术行业的发展。”喵吉说,“我们希望通过开源等方式,也可以为行业尽一份微薄之力。”

参考文献

[1] IETF QUIC 标准:RFC 8999 - RFC 9002

[2] XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services, https://dl.acm.org/doi/pdf/10.1145/3452296.3472893

2022-01-07 14:437046

评论

发布
暂无评论
发现更多内容

认识RocketMQ4.x架构设计

Java-fenn

Java

VS Code settings.json 10 个高(装)阶(杯)配置!

掘金安东尼

9月月更

重磅来袭!腾讯T7手写高并发实战手册,GitHub热度一直不下

Geek_0c76c3

Java 数据库 spring 开源 架构

使用 WebAssembly 打造定制 JS Runtime

Java-fenn

Java

VScode中配置 C/C++ 环境

c vscode 9月月更

JAVA代码审计之java反序列化

Java-fenn

Java

ESP32-C3入门教程 网络 篇(一、 Wi-Fi 使用入门 — 初始化及STA、AP模式)

矜辰所致

wifi ESP32-C3 9月月更

AWS CloudFormation简介

冯亮

DevOps AWS Cloud IaC

阿里顶配版 Spring 全家桶高级笔记+学习路线图+硬核资料库,跪着啃完了。。。。

Java-fenn

Java 程序员 面试 Java面试题

JS 模块化 - 02 Common JS 模块化规范

Java-fenn

Java

抽丝剥茧看时间序列预测

CnosDB

IoT 时序数据库 开源社区 CnosDB infra

安卓项目架构设计-梳理现有项目的混乱

Java-fenn

Java

ESP32-C3入门教程 网络 篇(二、 Wi-Fi 配网 — Smart_config方式 和 BlueIF方式)

矜辰所致

wifi ESP32-C3 9月月更 BlueIF Smaart_config

很不起眼的6个bug,90%的程序员就算写了10年代码也肯定都踩过!

Java-fenn

Java

国际聋人周 | 聋健人群无界融合,看见手语的力量

HarmonyOS SDK

手语

探索商业细分市场,中海打造北京南中轴首座家庭购物中心 | 商业地产

E科讯

如何保证数据库和缓存双写一致性?

Java快了!

Alibaba架构师内部最新发布SpringCloud开发手册,Github限时开源

Geek_0c76c3

Java 数据库 spring 开源 架构

前端也要懂算法,不会算法也能微调一个 NLP 预训练模型

Java-fenn

Java

Kafka:可靠!可靠!还是xx的可靠!

程序知音

Java kafka 编程 后端技术

MySql的InnoDB的三层B+树可以存储两千万左右条数据的计算逻辑

Java-fenn

Java

[架构实战]学习笔记

爱学习的麦子

名震GitHub!字节跳动内部顶级数据结构刷题学习笔记根本停不下来

程序知音

Java 数据结构 算法 后端开发 数据结构与算法

华为帐号自拟形象上线 打造手机里的另一个你

HarmonyOS SDK

react中的diff算法,通俗易懂的解读

flyzz177

React

20 条 Chrome DevTools 使用建议,盲猜这几个你不知道~

掘金安东尼

前端 9月月更

阿里高工内产的 SpringBoot 实战派手册仅发布一天霸榜Github

Geek_0c76c3

Java 数据库 开源 架构 开发

2022互联网寒冬期这套Java面试突击宝典助你破局,直击大厂!

了不起的程序猿

Java 编程 程序员 编程语言 java编程

基于electron+vue+element构建项目模板之【自定义标题栏&右键菜单项篇】

Java-fenn

Java

Tomcat架构之为Bypass内存马检测铺路(内存马系列篇四)

Java-fenn

Java、

初识设计模式 - 原型模式

Java-fenn

Java

阿里正式开源自研 XQUIC:已服务手淘上亿用户,网络耗时降低超 20%_开源_褚杏娟_InfoQ精选文章