【杭州云栖】AliQUIC：场景化高性能传输网络实践-CSDN博客

如今，阿里云CDN服务了全球数十万家客户，这些客户来自于不同行业、不同场景，有移动短视频、有互动直播，有视频会议，也有海外的内容分发，那么如何深入场景，针对性优化，实现高性能的传输网络呢？在杭州云栖大会飞天技术汇-CDN与边缘计算专场中，阿里云高级技术专家卢日为观众分享了阿里云CDN在CDN网络的last mile和middle mile这两段链路上，所构建的一个高性能的传输网络。

这个主题有两个关键词：第一个是场景化，和传统OSI网络不太一样的地方是。该传输网络针对业务场景进行了深度优化。第二个关键词是高性能，怎么定义高性能，是传输速度？卡顿率？实时性？对，也不对，因为每个场景所追求的KPI是不一样的，所以卢日老师认为这个高性能一定是最大化契合各个场景KPI需求的一个综合指标。

卢日用一张著名的网络漫画“How Standards Proliferate”也就是“标准是如何激增”的来作为开场，标准激增这种现象在很多领域里都有，比如电源插座，字符集编码等等，在漫画的最左边框里的文字表示的是现状，意思是在某个领域目前一共有14个完整的标准，漫画中间是两个人的对话，上面一大段文字大概意思是：这位男同学说，什么，14个？太搞笑了，不行，我们需要开发一个通用的标准来覆盖所有的需求，然后旁边的妹子很高兴的说：yeah，太好了。右边的框里表达的意思是，在不久以后，在该领域一共有15个完整的标准。这就是标准激增。漫画总是发人深省的，其实在计算机领域何尝不是呢，在网络传输标准化领域尤其是这样的。

协议逐渐深入垂直化领域

首先来看看Internet传输协议的一个现状，这是以OSI模型进行分类的的数据传输协议象限图，纵轴是标准化程度，这里不单单是RFC或是W3C或是ISO的标准，也包括被业界所接受的事实标准以及普及的程度，横轴是这些协议对内容感知的程度。乍一看很像刚刚漫画里的情况，这幅图里大概是20个，再过几年估计还会增加。

联系到今天的第一个关键词：场景化，通过这幅图可以看到一个趋势：越来越多的协议开始往红色区域的右下角集中，也就是说越来越多的传输协议开始向垂直化的领域发展了。比如这里的RakNet就是针对游戏行业的一个可靠UDP协议，SRT是在电视台领域的视频传输协议，QUIC最初是针对网页浏览设计的传输协议，还有HLS，DASH是OTT场景下的传输协议，WebRTC-RTP是视频会议下的传输协议，其实这些协议并不一定有很好的标准化程度，但并不妨碍这些协议在相应的垂直领域的广泛应用。

正所谓分久必合，合久必分，互联网发展到今天，HTTP似乎已经开始慢慢离群了，一种通用的应用层协议越来越难满足业务场景的需求了，为了解决多场景需求，我们是应该搞出一个比如类似OSI第八层协议来覆盖所有场景还是应该另辟蹊径呢？

构建高性能传输网络尽量契合各场景的KPI

阿里CDN的解法并不是通过再发明一种协议来覆盖所有场景，而是通过构建一个高性能的传输网络来尽量契合各场景下的KPI，大家知道，CDN的核心是解决网络延时和带宽问题，决定CDN效果好坏有很多指标，比如：精细化的调度，精准的覆盖，优质的资源，缓存命中率，网络传输优化等。

如今网络传输优化有哪些关键技术呢？

卢日老师大概总结了5点，这5点主要集中在CDN针对last mile和middle mile的网络传输上。

其中，动态选路是利用CDN的优质多线机房节点来构建一层overlay的网络，这个相较于数据包直接在Internet下传输会带来相对短的延时和少的丢包；链路QoS保障，这是last mile的技术，通过运营商在4G或是未来5G的链路层上进行资源预留等技术来提高链路层的传输质量；协议栈优化是通过优化TCP拥塞控制算法来提高传输效率和控制成本；私有协议是通过设计激进的传输协议以提高传输效率；多路径传输则是通过在条多路径互备传输来提高传输的可靠性。

传输层优化实践

目前业界在协议栈优化和私有协议方面的研究和实践主要集中在传输层优化上，比如从TCP转换到UDP，拥塞控制算法的研究，比如前段时间比较热的BBR算法，甚至学术界还有利用AI来对拥塞控制参数进行调优的尝试。

传输层优化，在传输层优化上目前业界都是围绕下面三个指标进行博弈：公平性Fairness，交付效率Efficiency，成本Cost，都取首字母总结下来就是FEC。

第一公平性，这个其实是运营商比较关注的，如果一个传输协议不考虑公平性，完全是疯狂的发包，那么这个一旦被发现，很可能是会被运营商封禁的，更不要说标准化了；第二交付效率，用更高的速度交付更多的数据，提高业务的QoS是CDN厂商和客户关心的；最后一个是成本，CDN发展到今天，成本已经是决定CDN厂商生死存亡的大事了，如果一个传输协议只是一味地追求效率，也不追求公平性，那很简单，最傻的办法是每个包多发几遍就好了，这样效率上基本上没什么问题了，但成本肯定扛不住，CDN厂商需要为发出的每个字节买单。

在这个图里列举了几种传输协议和拥塞控制算法在这三个指标下的大概位置，这个只是会意性的，但可以直观让大家感受一下理论上最好的协议会是什么样的，那就是成本线无效趋近于0点，公平和效率最大化。

为什么叫做FEC困境呢？

那是因为随着技术的发展到今天，在总带宽固定的情况下，在兼顾公平性和成本的情况下提高交付效率已经越来越难了，由于参数的复杂性，国外甚至有在利用AI来对拥塞控制算法进行调优中尝试，就像在一个封闭的猎场打猎一样，猎物只会越来越少。

如何跳出FEC困境，开阔一片新的猎场？

卢日老师认为需要传输协议去理解业务，不同的业务有不同的KPI，有不同的内容优先级，比如网页浏览文字比图片优先级高，比如实时通信声音比图像高，图像里关键帧比非关键帧高，由业务根据KPI来定义内容传输的优先级，从而提高内容的有效传输，另外就是业务也是有实效性的，并不是我们交付的每个字节都有意义。

在跳出FEC困境上业界在做的两个尝试：第一个是WebRTC-RTP，了解媒体传输的同学都知道RTP是媒体传输领域的一个普及和接受度都很高的媒体传输协议，WebRTC为了能够适配短延时的场景选取了一系列针对性的RFC来集成到WebRTC中，比如在拥塞的情况下通过降低帧率和分辨率来换取实时性，比如只传输关键帧等，所以WebRTC的传输不是一个协议，而是一系列协议的集合。

再看QUIC，QUIC最初是Google为了解决网页浏览问题而提出的一套传输解决方案，后来扩展到视频领域，根据Google的报告，在YouTube上面使用了QUIC传输以后，卡顿率有下降大约30个百分点，这些都得益于在QUIC中引入了优先级传输，Multiplexing 基于UDP的流复用，还有更好的Loss Detection and Recovery丢包监测和恢复机制等。

通过上述的两个例子，大家应该可以感觉到业界在场景化传输所作出的尝试和落地实现，卢日老师总结了五个典型场景和6个KPI维度。从这个图可以看到每个场景所追求的KPI是有差异的，如何来定义一个传输网络是否是高性能的在这张图下就一目了然，虽然很难兼顾每个维度，但可以针对某个场景进行深耕，在相应的维度上追求极致。

阿里视频云的传输网络AliQUIC

接下来，卢日老师介绍了阿里视频云的传输网络AliQUIC：“首先澄清一下我们不是在创造一种新协议, AliQUIC简称aQUIC不是一个协议, 而是一种CDN last mile和middle mile的网络传输解决方案。”在这个网络方案里，aQUIC不仅仅针对Web类应用，而是扩展到游戏，实时音视频通信，互动直播和IM弹幕等一系列的场景，针对不同的场景，使用不同的算法和技术。

aQUIC仍然把QUIC作为一个关键词，QUIC有一系列非常好的技术，比如Loss Detection and Recovery，它吸取了很多TCP协议中的精华来设计它的Loss Detection and Recovery机制，从而形成了一套自己的封帧协议。卢日老师说：“我们把QUIC更多的是看做一个框架，在这个框架之上我们设计了场景化的拥塞控制算法，场景化的流控，还有多路径传输以及流复用规则等等。除此之外，我们还设计了一套类socket的API编程接口，方便上层应用进行编程。同时，我们还利用QUIC的multistreaming功能，将控制信令和数据分离，对于UDP加速场景来说，可以做到在不改变UDP MTU的情况下进行UDP数据包的透传。“

aQUIC的特色

首先是场景化，前文有详细讲解；
第二个是模块化，每个算法和功能点都是模块化设计，可以自由拼凑，而且会提供一套编程接口，方便上层调用；
第三个是扁平化，在最开始的数据传输协议象限中的另外一个趋势，就是传输层和应用层之间的界限开始越来越模糊了，只做传输层不考虑上层业务，就会有FEC困境，而只做应用层的优化不考虑传输层，这个是Google最早做http/2的思路，结果做完http2.0以后发现还是不够极致，因为下面的TCP还是有HOL的问题，所以开始要替换TCP，变成UDP，四层-七层全部打通。aQUIC也是如此，不仅四、七层打通，而且和业务打通，整体是扁平化的。
第四点是软硬一体化，这个主要是单机性能的考虑，在现有的kernel/userspace体系架构下，UDP编程的效率其实是比不上TCP的，大概的性能损失相较于TCP是1倍左右，为了提升单机性能我们采用软硬一体化的设计方案。

aQUIC是如何来解FEC困境的？

针对这6个维度，分别采用了针对性的技术和算法，从而也达到的场景化高性能的目的。

在分享的最后，卢日老师同现场开发者一起展望未来，场景化并不是终极目标，他认为还可以更进一步，做内容感知的传输。

比如在城市大脑这个场景下，目前把城市各个角落的摄像头都接入到AI系统，AI系统进行抠图然后进行分析和结构化，那么AI需要的是视频流吗？其实并不是，AI需要的是视频中的对象，比如车，人，物，那么是否可以做一个传输网络来传输视频中的对象呢？卢日认为：“这就需要我们理解所传输的内容，最终构建一个基于内容感知的端到端传输网络，基于内容感知的端到端传输网络，这是我们未来努力的方向。”