产品发布 | 阿里云CDN全面支持IETF QUIC

共 3354字,需浏览 7分钟

 ·

2022-01-16 06:19


随着互联网飞速发展,用户通过手机看到的内容越来越多,交互形式也愈发丰富。用户对于网络的响应、网络的传输效率提出了更高的要求。传统的TCP传输方式存在一些问题,比如:依赖于操作系统的实现,部署和升级的周期很长;握手时延无法避免;传输效率上会存在对头阻塞等等,这些问题是无法解决的。基于此,QUIC应运而生并且不断发展演进。
QUIC全称Quick UDP Internet Connection,一种基于UDP实现可靠传输的低延时互联网传输协议。那么QUIC如何在CDN中应用?其技术应用场景可以为业务带来什么样的价值?1月12日,阿里云产品发布会154期,阿里云CDN重磅升级,为网友揭秘了新一代传输协议QUIC如何让CDN更快一步。




01

QUIC 发展史回顾


首先,让我们一起来回顾下QUIC的发展历史。QUIC是从2013年google开始基于UDP协议的一个研究,在经过2013年到2015年的一些公开的试验之后,2016年提交给IETF,也就是互联网标准,进行整体协议的标准化。众所周知,QUIC具备很多的优势,比如RTT、0RTT多路复用等,比较关键是它实现了从内核态到用户态的转变,整个算法的迭代从可以通过应用层去完成,实现一客一用,极大提升了更新效率。IETF QUIC最终在2021年7月份完成定稿,命名为RFC9000。QUIC时代,现在开始正式到来。



02

阿里云CDN QUIC的演进



阿里云CDN团队在2018年开始进行QUIC相关调研和支持,且在2019年已经支持了google QUIC的相关内容,包括google的比较广泛的版本,比如3943和46版本已经在支持。在2020年,随着IETF QUIC整个标准化进展加快,阿里云CDN也开始在对IETF QUIC进行兼容和适配。在2021年,阿里云CDN全部物理节点均支持IETF QUIC
为什么大家对QUIC会得到这么多的关注呢?通过互联网一些通用的场景,阿里云CDN产品专家容蓓介绍了QUIC的优势和其与TCP之间的差异化价值。




03

QUIC 在CDN中的应用



 

短视频是CDN加速的经典场景之一。对于平台而言,希望给用户创造更好的观看体验,视频卡顿、延迟都是不利因素,平台会监控播放完成率、互动率等指标,用于评估短视频是否具备吸引力。拆分到技术层面,要看一个视频平台技术好不好,指标就包括首屏时间、卡顿率、下载速率等等。
QUIC为什么会在这些核心指标上面比TCP的效果更好?我们逐一来看。
第一,首屏时间通常是指用户观看到视频或者是观看到图片的第一帧的时间。这个时间越快、延迟越小,用户的体感就会越好,就不会有延迟。
从下图中里面来看到。如果通过HTTP的协议去访问视频,会有一次建联,建联之后再进行数据传输。此外,因为HTTP是明文传输,可能存在如数据篡改、劫持的风险,所以在客户端,大家倾向于选择使用HTTPS来传输。而HTTPS因为有证书存在,它的握手又会增加,至少要通过三个RTT才能获取到第一帧的内容。假设平均的握手时间是200毫秒,那这200毫秒首屏延迟是完全无法避免的。并且,在这一次访问结束之后,这个连接会关闭。下一次用户再访问同样的东西时,又要再去建联,这就意味着200毫秒是持续存在的,在TCP里面没有办法改善。
而因为QUIC用的是这个UDP的协议,它的建联方式会更优化一些。QUIC中的握手从第一次开始就是加密的状态,第二次就可以传输一个数据,所以在QUIC中,用户第一次访问一个资源,那么需要一个RTT,就可以获取到数据内容。而再次访问同样的内容,数据如果已经存在本地,无需再建联,就能实现0RTT的逻辑。当然,首屏时间也会有其他的影响因素,但是这三个握手时间的节省,确实是QUIC在首屏时间上能拿到的实打实的性能提升。
第二,在传输层面上QUIC也比TCP相对改进。从下图中可以看到,假设TCP在传三张图片,会把它分成不同的报文去进行传输。图一是TCP的传输方式,可以看到1234报文都被成功传输完了,应用层也可以读取到客户端并进行展示了,那么5的报文丢掉了,实际上6789在服务端也已经传成功了,但因为5丢掉了,所以678应用层都是没有办法去接收的,必须要等到5重传之后,后面的数据才能被传完。
在QUIC里面,通过多路复用的方式来进行数据传输,也就意味着1234传输成功之后,5丢掉了,678依旧可以被传输过去。这几个报文数据包中只有5需要重传,其他的都可以被应用层读取。那么在相同的网络吞吐量的前提下,在相同时间内会传更多的内容。所以,QUIC在下载耗时、卡顿率这个层面,会取得比较大的优势。
第三,拥塞机制。QUIC基本上继承了TCP的拥塞算法在里边。但为什么QUIC会要比TCP的优势更明显呢?那是因为QUIC的控制层在应用层,应用层最大特性就是很灵活,比如说我客户A去配cubic,客户B去配BBR,这个都只需要在服务端去做一个配置,然后几个小时、几分钟快速生效。在TCP里边,整个算法的优化需要在内核层中去做更新,更新是非常缓慢和慎重的,并且内核层面部署时间、发布时间都很长。举个栗子,我们要把阿里云CDN 2800个节点的内核层都更新一次,这个时间是非常漫长的,并且可能会存在一些不可控的因素在里面。所以QUIC协议在拥塞控制层面非常灵活,这也是它的核心优势之一。
第四,弱网优化。其实这也跟QUIC的建联方式有关系。TCP如果要建联,会有四要素,就是客户端这个源IP、端口,服务端的目的IP、目的端口。通常目的IP和目的端口相对来讲比较稳定,不太容易发生变化。但是源IP这一侧就不一定了。网络变了、设备变了都会导致IP和端口的变化,在发生变化之后,哪怕我们看的都是同样的内容,也肯定要重新建联。那么刚刚提到的TCP的握手又出来了,产生了中间的消耗和不确定性。那么,QUIC的建联方式是通过一个connection ID来完成的,connection ID是一个64位的随机数,相对更灵活。无论网络发生什么变化,只要connection ID不变,那连接就不会断掉,这就保证了用户在观看同样内容时更加顺畅,性能体感更好。
阿里巴巴集团应用在QUIC在CDN的实践上已经取得了一些效果,比如:手淘今年双11已经将部分流量切到了IETF QUIC之上,短视频业务卡顿率比TCP降低10%,下载分片耗时降低20%;优酷长视频业务,平均播放卡顿时长降低15% - 32.5%(强弱网区分);支付宝图片业务使用google QUIC,下载耗时降低25% - 40%以上。



04

总结:QUIC的核心优势

 
第一、快速建联
0-RTT的握手,减少TCP握手和TLS的握手时间,提升首屏效率
第二、多路复用
相比于HTTP/2,真正的单通道并行传输,彻底解决TCP协议中队头阻塞问题
第三、拥塞算法
拥塞算法灵活,不需要基于内核或操作系统,可直接在应用层改造
第四、持续在线
频繁切换网络的情况下,不会断线,不需要重连,用户无任何感知



05

如何开通CDN QUIC服务


通过阿里云CDN控制台,在每个域名配置下都会有QUIC选项。如果用户已经申请过了白名单,即可直接操控开关来开启或者关闭QUIC服务。没有申请过白名单的用户则需要提交申请,后台审核通过后即可通过控制台来进行操控。
在域名开启之后,用户可以在资源监控中选择相关的协议层,查看QUIC相关数据。同时,QUIC会按照每万次五分钱的一个计费逻辑按日出账,用户可以在用量中查询QUIC的请求数的总数量,来进行账单的核对。




06

内容预告


CDN产品关注QUIC协议演进并实践落地,从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点,并在短视频和图片业务场景实践有不错的收益。
下一期,阿里云技术专家淮叶将带来关于QUIC技术基础特性、应用场景及其技术落地实践中的协议库选择、QUIC协议软件实现、性能优化的内容分享,敬请期待!


往期推荐





浏览 95
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报