产品发布 | 阿里云CDN全面支持IETF QUIC
随着互联网飞速发展,用户通过手机看到的内容越来越多,交互形式也愈发丰富。用户对于网络的响应、网络的传输效率提出了更高的要求。传统的TCP传输方式存在一些问题,比如:依赖于操作系统的实现,部署和升级的周期很长;握手时延无法避免;传输效率上会存在对头阻塞等等,这些问题是无法解决的。基于此,QUIC应运而生并且不断发展演进。 QUIC全称Quick UDP Internet Connection,一种基于UDP实现可靠传输的低延时互联网传输协议。 那么QUIC如何在CDN中应用?其技术应用场景可以为业务带来什么样的价值?1月12日,阿里云产品发布会154期,阿里云CDN重磅升级,为网友揭秘了新一代传输协议QUIC如何让CDN更快一步。
首先,让我们一起来回顾下QUIC的发展历史。QUIC是从2013年google开始基于UDP协议的一个研究,在经过2013年到2015年的一些公开的试验之后,2016年提交给IETF,也就是互联网标准,进行整体协议的标准化。众所周知,QUIC具备很多的优势,比如RTT、0RTT多路复用等,比较关键是它实现了从内核态到用户态的转变,整个算法的迭代从可以通过应用层去完成,实现一客一用,极大提升了更新效率。IETF QUIC最终在2021年7月份完成定稿,命名为RFC9000。QUIC时代,现在开始正式到来。
阿里云CDN团队在2018年开始进行QUIC相关调研和支持,且在2019年已经支持了google QUIC的相关内容,包括google的比较广泛的版本,比如3943和46版本已经在支持。在2020年,随着IETF QUIC整个标准化进展加快,阿里云CDN也开始在对IETF QUIC进行兼容和适配。 在2021年,阿里云CDN全部物理节点均支持IETF QUIC 。 为什么大家对QUIC会得到这么多的关注呢?通过互联网一些通用的场景,阿里云CDN产品专家容蓓介绍了QUIC的优势和其与TCP之间的差异化价值。
短视频是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%以上。 0-RTT的握手,减少TCP握手和TLS的握手时间,提升首屏效率 相比于HTTP/2,真正的单通道并行传输,彻底解决TCP协议中队头阻塞问题 拥塞算法灵活,不需要基于内核或操作系统,可直接在应用层改造 频繁切换网络的情况下,不会断线,不需要重连,用户无任何感知 通过阿里云CDN控制台,在每个域名配置下都会有QUIC选项。如果用户已经申请过了白名单,即可直接操控开关来开启或者关闭QUIC服务。没有申请过白名单的用户则需要提交申请,后台审核通过后即可通过控制台来进行操控。 在域名开启之后,用户可以在资源监控中选择相关的协议层,查看QUIC相关数据。同时,QUIC会按照每万次五分钱的一个计费逻辑按日出账,用户可以在用量中查询QUIC的请求数的总数量,来进行账单的核对。
CDN产品关注QUIC协议演进并实践落地,从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点,并在短视频和图片业务场景实践有不错的收益。 下一期,阿里云技术专家淮叶将带来关于QUIC技术基础特性、应用场景及其技术落地实践中的协议库选择、QUIC协议软件实现、性能优化的内容分享,敬请期待!
浏览
91 点赞
评论
收藏
分享
手机扫一扫分享
分享
举报
点赞
评论
收藏
分享
手机扫一扫分享
分享
举报