简介:在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 协议的性能也与其实现有关,不同的实现版本可能也会有很大的差距。
所以对 QUIC 的传输性能,通过火焰图进行分析,找出了一些影响 QUIC 性能的关键点:
- SSL加密算法的开销:
对称加解密也10%左右的开销;优化措施,不同场景选择不同加密算法,实验环境下对各加密算法进行性能测试,AES在cpu 指令优化下,性能提升20%,chacha20针对移动端有优化
- UDP 收发包的开销:
针对大文件下载的情况,sendmsg占比很高,可以达到 30%以上;优化措施,开启GSO模式,相比单包发送,性能提升2-3倍
- QUIC协议栈开销:
受协议栈自身实现的影响,如 ACK 的处理,MTU 探测和发包大小,内存拷贝等;优化措施,ACK 合并、调整udp payload size
CDN QUIC协议如何接入使用
1.CDN控制台,先申请开通,用户即可自助开启、关闭QUIC
2.测试工具,浏览器或者一些QUIC开源库工具,curl已经支持HTTP3
3.QUIC监控,可以从CDN内部监控系统查看QUIC连接异常问题
4.QUIC分析工具,wireshark最新版本已经支持QUIC协议分析
CDN QUIC产品的应用效果
CDN QUIC在阿里巴巴集团的一些业务上已经实践落地并取得了一些效果。例如:淘宝短视频业务在开启HTTP3后,客户端分片下载耗时下降 20%,播放器卡顿率下降 10%;支付宝图片下载业务在开启gQUIC后,小程序包下载耗时下降 25%,整体业务下载耗时下降 40%。
从不同业务实践中,CDN QUIC服务针对业务场景进行了全面优化,包括4个方面:
- 连接优化0-RTT连接复用率,降低连接的延迟。
- 加解密优化明文传输,可以减少加解密造成的一些影响。
- 传输优化乱序报文缓存,针对特殊数据优先级需求进行调整。
- 针对线上的不同业务场景调整参数,利用拥塞算法,提升在不同业务场景下的效果。
原文链接
本文为阿里云原创内容,未经允许不得转载。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。