手机淘宝在短视频、图片等多个场景下会用到CDN内容分发网络，手机淘宝技术和阿里云CDN技术有非常多的共建合作，其中包括在IETF QUIC加速产品方向。本文以CDN产品为例，为您介绍手机淘宝使用IETF QUIC加速产品的应用场景和效果，以及配套的XQUIC库的情况。
背景信息
随着互联网的快速发展，基础网络环境也在发生变化，Web网络协议也经历了HTTP1.0、HTTP1.1、HTTP2.0以及即将迎来HTTP3.0。HTTP3.0将以QUIC协议替代TCP作为传输层，具备stream多路复用、握手0RTT、连接迁移以及用户态拥塞算法诸多优势。CDN产品关注QUIC协议演进并实践落地，从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点，并在短视频和图片业务场景实践有不错的收益。
QUIC（全称：Quick UDP Internet Connection），是基于UDP的多路复用且安全的新一代传输协议，具有更低的连接和传输延迟，拥有极佳的弱网性能，在丢包和网络延迟严重的情况下仍可提供可用的服务。本次发布会，阿里云产品技术专家从QUIC技术特性、应用场景及客户价值等维度进行全面阐述，并邀请手淘宝技术人员分享技术实践。阿里云长期致力于推动QUIC的发展和落地，从而为客户提供最佳体验。
QUIC协议介绍
当我们访问视频网站和APP应用时，经常会遇到各种各样的性能问题，网页加载慢、视频卡顿、网络出错，其中关键影响因素就是网络协议。
HTTP协议重要升级
HTTP协议作为互联网Web协议，经历了几次重要的升级：
HTTP1.0 → HTTP1.1：支持长连接，请求pipeline特性，通过减少了TCP三次握手，降低连接建立的开销。
HTTP → HTTPS：增加TLS层握手，传输内容加解密，因增加安全特性，故增加建连延迟。
HTTP1.1 → HTTP2：H2特性是请求数据流的多路复用与头部压缩，提高了单连接的并发能力。
从HTTP1.0升级到HTTP2，其中传输层协议没有变化都是基于TCP协议。TCP协议是可靠传输协议，需要三次握手状态，还有队头阻塞问题，为了解决这些问题，基于UDP设计实现的一种可靠传输协议——QUIC协议应运而生。因此，HTTP协议再次升级。
HTTP2 → HTTP3：HTTP3基于QUIC协议，因此具备QUIC协议的传输特性，解决TCP队头阻塞问题，具备TLS1.30-RTT、H2多路复用能力，还具备连接迁移能力。QUIC协议已于2021年05月正式标准化，编号为RFC9000。
QUIC协议解决了哪些问题
低连接延时：QUIC基于UDP，无需TCP连接，在理想情况下，QUIC可以做到0RTT开启数据传输。而基于TCP的HTTPS，即使在TLS1.3的early data下仍然需要1RTT开启数据传输。然而对于常见的TLS1.2完全握手的情况，则需要3RTT开启数据传输。
无队头阻塞：虽然 HTTP2实现了多路复用，但是传输层依然使用的是TCP，一旦出现某个报文丢包，将会影响多路复用下的所有请求流。然而QUIC基于UDP，在设计上就解决了队头阻塞问题。同时HTTP3使用 QPACK编码替换HPACK编码，在一定程度上也减轻了HTTP请求头的队头阻塞问题。
用户态拥塞控制：QUIC的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上。这意味着可以根据不同的业务场景，实现配置不同的拥塞控制算法以及参数，甚至同一个业务的不同QUIC连接也可以使用不同的拥塞控制算法。
连接迁移：当实际用户的网络发生变化时，从WIFI网络切换到4G网络时，用户地址发生变化，基于TCP的 HTTP协议无法保持连接的存活；而QUIC基于连接CID作为连接标识, 仍然可以保证连接存活和数据正常收发。
QUIC协议与TCP协议对比
既然QUIC协议设计初衷是解决传输层协议问题，与其竞对的就是TCP协议，那么从传输协议特性分析两种协议设计差异，可得出以下对比：
QUIC为每个加密级别使用单独的包号空间，除了0-RTT和1-RTT密钥使用相同的包号空间，隔离的包号空间可以确保使用一种加密级别发送包的ACK, 不会引起使用其他加密级别发送的包的虚假重传问题。
QUIC的包号严格按照包号空间递增，直接编码传输顺序。报文号越高表示报文发送时间越晚，报文号越低表示报文发送时间越早。当一个包含应答帧的包被检测到丢失时，QUIC会在一个新的包中包含必要的帧，并添加一个新的包号，从而消除了当收到应答时确认哪个包的不确定性。因此，可以进行更精确的进行RTT测量，可以轻松地检测到虚假重传。
Quicack帧包含类似于TCP选择性应答（sack）的信息。然而QUIC不允许数据包的确认被违背，这大大简化了双方的实现，并降低了发送方的内存压力。
与TCP的三个SACK范围相反，QUIC支持许多ACK范围。在高丢包环境中，这种方法可以加快恢复速度，减少虚假重传。
TCPRTT测量使用发送包和确认包时间戳计算，未考虑主机延迟问题，QUIC使用ACKDelay机制，使得路径RTT测量更加准确。
QUIC使用PTO探测超时机制，代替TCP的RTO&TLP。
TCP使用一个包的最小拥塞窗口。如果丢失单个数据包意味着发送方需要等待PTO来恢复，当接收方延迟确认时，发送一个单一的ack-eliciting包也增加了引起额外延迟。因此，QUIC建议最小拥塞窗口为两个包。虽然这增加了网络负载，但它被认为是安全的，因为在持续拥塞的情况下，发送方仍然会以指数方式降低发送速率。
QUIC协议可以加速哪些场景
动态请求（API和信令传输场景）：降低动态交互耗时。
短视频：提升首屏秒开率，降低卡顿率。
图片文件下载：降低文件下载总耗时。
直播：降低播放卡顿率，提升推流稳定性。
QUIC协议的核心优势
快速建联：0-RTT的握手，减少TCP握手和TLS的握手时间，提升首屏效率。
多路复用：相比于HTTP/2，真正的单通道并行传输，彻底解决TCP协议中队头阻塞问题。
拥塞算法：拥塞算法灵活，不需要基于内核或操作系统，可直接在应用层改造
持续在线：频繁切换网络的情况下，不会断线，不需要重连，用户无任何感知。
阿里云CDN QUIC的演进
早在2018年左右，基于GQUIC，手机淘宝和阿里云就开始合作，主要应用在手机淘宝的图片和短视频等内容分发的场景。在2019年初，当时大家有一个共同的判断是要走标准化道路，一方面是因为从商业化产品角度，私有协议解决方案更难被用户认可，另一方面整个标准化协议的设计和安全性都有更完备的考量。
在决定选择标准化道路之后，当时市面上也没有特别成熟并适用于移动端的IETF QUIC协议栈实现，所以手机淘宝就启动了自研XQUIC项目，经过1年半的研发和打磨，于2020年的6月份开始全面上线，并且在2021年初与阿里云CDN IETF QUIC产品实现对接，并在短视频场景上开始逐步应用IETF QUIC技术。在2021年的9月份阿里云CDN实现了IETF QUIC整套协议栈在短视频场景下的规模化应用。之后，CDN产品经历了同年双十一的考验，XQUIC和CDN产品的性能和稳定性都有了很好的验证，因此在2022年的1月7号CDN完成了XQUIC开源，同时也在此支持CDN IETF QUIC新品发布。
更多内容请点击回顾发布会直播。
目前主要在手机淘宝短视频场景使用阿里云CDN QUIC加速产品，最佳实践的技术方案是端侧XQUIC协议栈和阿里云CDN QUIC加速产品配套使用。针对手机淘宝短视频场景，带来的网络体验优化效果，体现在短视频分片下载耗时优化20%，卡顿率整体优化在10%。考虑到整体的优化效果非常明显，阿里云CDN团队后续也会进一步在图片等场景下应用这一套加速技术，同时也把这一套最佳实践贡献给大家，希望能给云产品的客户带来更好的网络加速体验。
最佳实践端侧使用的XQUIC库
XQUIC是一个轻量、高性能、标准化的跨平台协议库。
在轻量方面， XQUIC在Android和iOS双端的编译产物均小于400 KB，为了减少新用户的安装成本，尽量减少移动端App的包大小，因此XQUIC很适用于需要高性能但同时又对包大小敏感的移动端App场景。
在高性能传输方面，XQUIC已经在手机淘宝实现核心导购、短视频链路大规模使用。例如，我们打开手机淘宝的首页，或搜索我们感兴趣的商品，亦或是打开淘宝逛逛浏览达人的视频，XQUIC都为这些场景的提供更快的网络数据传输。
在标准化方面，XQUIC实现了整套IETF QUIC标准协议，包含传输层、加密层、应用层协议栈。
在跨平台方面，我们的网络库支持Linux、Android、iOS、Mac等平台，后续也会支持Windows平台适配，客户端可以通过SDK方式很方便地接入并使用。
XQUIC提供IETF QUIC标准包含的3层协议栈能力，它在客户端以SDK的方式运行，在服务端，可以通过module对接到tengine/nginx框架使用。此外，针对移动端使用内容分发网络的场景，产品针对协议互通性、0-RTT比例提升、明文和密文模式兼容等方面做了很多优化。例如，明文和密文模式兼容方面，CDN除了支持标准TLS/1.3推荐的加密套件之外，也额外提供了明文模式，并且在握手阶段可以实现自适应的协商，通过握手阶段的alpn参数实现协商，并保证对标准密文模式的兼容性。在0-RTT比例提升方面，CDN也针对server config以及token的缓存策略进行了优化，0-RTT比例在无线端可以达到68%以上。
相信XQUIC协议库与CDN QUIC加速产品的配合，能够整体给用户带来更丝滑的网络传输体验。配置QUIC协议，请参见配置QUIC协议。