QUIC技术创新让视频和图片分发再提速

简介：在1月12日的「阿里云CDN产品发布会-新一代传输协议QUIC让CDN更快一步」之上，阿里云技术专家淮叶分享了QUIC技术及其应用落地实践，内容包含：QUIC协议介绍、相比TCP有哪些优势、应用场景以及技术落地实践中的协议库选择，QUIC协议软件实现、落地技术架构和性能优化。

随着互联网的快速发展，基础网络环境也在发生变化，WEB网络协议也经历了HTTP1.0、HTTP1.1、HTTP2.0以及即将迎来HTTP3.0; HTTP3.0将以QUIC协议替代TCP作为传输层，具备stream多路复用、握手0RTT、连接迁移以及用户态拥塞算法诸多优势。CDN产品关注QUIC协议演进并实践落地，从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点，并在短视频和图片业务场景实践有不错的收益。

在1月12日的「阿里云CDN产品发布会-新一代传输协议QUIC让CDN更快一步」之上，阿里云技术专家淮叶分享了QUIC技术及其应用落地实践。本文根据分享内容梳理，包括以下三个部分：

QUIC协议介绍，包括协议诞生历史、基础特性、相比TCP有哪些优势，以及QUIC协议可以应用在哪些业务场景
CDN QUIC技术落地实践，包括协议库选择，QUIC协议软件实现以及QUIC落地技术架构，以及QUIC性能优化，QUIC产品如何接入使用
CDN QUIC技术落地场景，主要介绍阿里巴巴集团业务使用QUIC加速后的收益，以及背后的一些优化措施

QUIC协议介绍

当我们访问视频网站和APP应用时，经常会遇到各种各样的性能问题，网页加载慢、视频卡顿、网络出错，其中关键影响因素就是网络协议。

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年5月正式标准化，编号为RFC9000。

QUIC 协议解决了哪些问题

1. 低连接延时

QUIC 基于 UDP，无需 TCP 连接，最好情况下，QUIC 可以做到 0RTT 开启数据传输。而基于 TCP 的 HTTPS，即使在TLS1.3的early data下仍然需要 1RTT 开启数据传输。然而对于常见的 TLS1.2 完全握手的情况，则需要 3RTT 开启数据传输。

2. 无队头阻塞

虽然 HTTP2 实现了多路复用，但是传输层依然使用的是TCP，一旦出现某个报文丢包，将会影响多路复用下的所有请求流。然而QUIC 基于 UDP，在设计上就解决了队头阻塞问题。同时HTTP3使用 QPACK 编码替换 HPACK 编码，在一定程度上也减轻了 HTTP 请求头的队头阻塞问题。

3. 用户态拥塞控制

QUIC 的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上。这意味着可以根据不同的业务场景，实现配置不同的拥塞控制算法以及参数，甚至同一个业务的不同QUIC连接也可以使用不同的拥塞控制算法。

4. 连接迁移

当实际用户的网络发生变化时，从 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和信令传输场景)：降低动态交互耗时
短视频：提升首屏秒开率，降低卡顿率
图片文件下载：降低文件下载总耗时
直播：降低播放卡顿率，提升推流稳定性

CDN QUIC技术落地实践

关于协议库如何选择？

QUIC 协议栈的实现版本库很多，但协议功能实现的全面性各有不同，通过QUIC协议互通性测试报告，可以了解各协议库的QUIC特性支持程度。

CDN在QUIC协议上的实践路线，是从gQUIC版本开始调研实现，然后跟进QUIC标准化进度，然后支持 IETFQUIC标准，并实现HTTP3接入服务。选择gQUIC的原因是GOOGLE是QUIC协议的开创者，基于chromium实现的QUIC协议栈最早，功能最齐，实现上也最为标准，因此选择了它。

关于IETFQUIC协议版本，NGINX官方已实现了一个基础版本，生产环境使用仍然存在很多问题没解决，拥塞控制算法没有实现；但从QUIC协议互通测试报告看，QUIC协议实现比较全面，并且性能也不错，相信NGINX官方很快就会把QUIC分支合入主干。同时，补全了其缺失功能，比如拥塞算法。

gQUIC&IETFQUIC兼容架构

我们选择了两套不同的QUIC协议栈实现版本，来分别支持gQUIC和IETFQUIC，其中gQUIC版本支持Q039,Q043,Q046，IETFQUIC支持h3-29quicv1。

gQUIC协议库，自从2018年调研嵌入到CDN服务，我们从chromium裁剪出net网络库部分，开发QUIC模块，以及自研拥塞算法。随着IETFQUIC协议草案逐渐成熟，2020年RFC草案基本定稿，CDN也开始IETFQUIC实现调研，我们基于NGINX官方QUIC版本进行深度开发，解决QUIC加密库、拥塞算法、资源运维等问题，达到CDN上线标准。现在CDN QUIC同时支持gQUIC和IETFQUIC两种版本，客户接入无需更换域名，更换调度域。（CDN实现已经做了协议分流）

CDN QUIC技术架构实现

技术架构实现分为两个组件：QUIC-LB 和 QUIC-Server

QUIC-LB: 主要实现根据QUIC连接CID选择后端QUIC-Server逻辑

QUIC-Server：实现QUIC协议栈特性，并且根据连接CID选择已建立会话的worker进行服务

在 CDN QUIC 技术落地实践中，我们面临一个难题是QUIC传输带来的CPU资源损耗高于TCP协议栈的CPU消耗，QUIC 协议将 TCP协议栈的特性从内核移到了应用层，从目前开源 QUIC 实现版本来看，性能相比 TCP 还有差距。因为TCP长期使用以来，从协议栈到网卡经过了非常多的优化，相比之下，UDP的优化很少。除了内核和硬件外，QUIC 协议的性能也与其实现有关，不同的实现版本可能也会有很大的差距。