【阅读原文】戳：深度解读阿里巴巴SIGCOMM2022“可预期音视频网络”技术
作者：马云飞
移动互联网时代的音视频应用如直播购物、远程会议、短视频、云游戏如今已经彻底改变了人们的生活。而这些应用的背后，均离不开音视频网络传输技术的发展与支撑。近日，在国际计算机网络通信顶级学术会议SIGCOMM上，阿里云智能发表了三篇音视频传输相关的论文，向业界展示了阿里巴巴如何通过构建“可预期音视频网络”的基础设施来支撑阿里巴巴如淘宝，钉钉，云游戏，无影等诸多核心业务。本文将对这三篇论文做一个深度的解读。
“可预期音视频网络”要解决什么问题？
视频内容的消费已成为当今人们生活的一个重要组成部分，我们刷剧，购物，玩转社交网络，进行远程会议和办公，打游戏等都离不开通过广域网/移动网络传输的大量音视频内容。随着我们进入元宇宙时代，新一代视频应用的爆发，如AR和VR、6DoF……对于网络速率、时延、连接数量和稳定性等方面都提出了更高要求。在带宽方面，我们从360p视频进化到4K，对带宽需求提升了40倍；在时延方面，以前主流的应用是VoD视频，延时在5s甚至以上，而现在我们更需要实时的音视频服务，端到端的时延需求在100ms以下；在通信规模方面，原来我们开视频会议，主要是2-3人的小方会，而现在我们有很多的应用需要支持千人以上的大方会。所以这里的核心问题就是，我们的需求在过去几年发生了飞快的变化，但我们网络侧的移动连接和传输能力是否已做好准备？
我们经常与视频开发者一起合作，不管是内部还是外部，最常听见的就是视频应用的开发者说：“我看过网络的spec，你们网络应该是可以支持我这个视频业务的。” 但实际实况是，移动互联网其实并不能达到视频开发者的预期。一个很重要的原因就是所有的网络技术都在宣传他们的峰值参数，而这些峰值参数是在非常理想的条件下测量出来的，它代表了当前技术能力上限，并非网络在实际应用中所能够表现出来的。因此，这里面有一个巨大的鸿沟。
图1 | (a) 理想情况下的网络；（b）现实中的网络
举一个例子，图1中（a）是一个理想情况下LTE测速应该达到的效果，可以看作是我们的预期。一个下行270Mbps，上行45Mbps的网络。
而（b）是我在家中测试得到的结果，下行5.5Mbps，上行只有600Kbps。这里可以看出移动网络具有非常大的不确定性，这也给音视频应用带来很大的挑战。
音视频产品的核心竞争力在于其体验，由于它们是承载在云之上的，那么复杂多变的网络环境必然有很大的影响。图2展示了一个简单的音视频传输模型，在推流端将媒体流发送给接收端的过程中会经过上下行的无线网络和广域网络，存在信道质量变化快、资源竞争激烈、网络拥塞严重、丢包率高等情况。
图2 | 一个简单的音视频传输模型
经过长期探索，我们发现：其根本的解决方法就是去演进我们的视频网络传输技术，使服务变得更加的可预期，进而从根本上提升用户体验。为此，在过去几年中，我们针对不同业务场景，在码率控制、路径控制、拥塞控制等不同维度深耕技术，并取得了若干突破（如表1所示）。
表1
ACM SIGCOMM 2022，阿里巴巴在“可预期音视频传输”方向的三个系统所针对的不同音视频应用场景与技术侧重。
GSO-Simulcast:音视频会议的全局码率控制系统
在多人视频会议中，保证低延时、高清晰度、流畅通话体验是最核心的任务。但大规模的实时音视频会议是一个非常具有挑战性的场景，其原因在于多方会议中不同参会者处于截然不同的网络环境，从而导致网络的“瓶颈”效应。
图3 | 多人音视频会议中，不同参会者处于“截然不同”的网络环境，从而导致网络的“瓶颈”效应
如图3所示，图中有三个拉流者(sub1, sub2, sub3) 订阅了推流者（pub1）的视频流，但这三个拉流者处于不同的网络环境，他们的下行侧带宽分别是2Mbps、1Mbps和500Kbps。问题来了，推流者pub1究竟需要推多大的视频流？从图中可以看到，如果pub1推一个2Mbps的流，那么sub1将会得到最好的体验，可这将导致sub2和sub3发生卡顿，因为他们的带宽不足以支持这么高的码率。最终，为了避免拉流卡顿，pub1不得不发送一个低于500kbps的视频流，虽然这样避免了卡顿，但却不可避免地拖累了sub1和sub2的观看体验。从这个简单的例子可以看出，一个多方会议中的音视频体验总是会受限于那个处于“瓶颈”网络环境的参会人。随着会议人数的增加，所有参会人中处于“弱网”环境的参会人概率也在增加。克服多人会议中的瓶颈效应是提供流畅音视频服务的关键。
图4 | Simulcast原理示意图
Simulcast技术可以帮助我们解决不同参会者所处网络环境不一的问题，一个简单的Simulcast原理图如图4所示。在Simulcast中，推流者将同一个视频源编码成不同码率的版本，并将这些视频流并行发送至SFU服务器，SFU服务器接收到这些流以后根据观测到的不同拉流者的下行带宽进而转发不同的码率版本。例如，SFU服务器向拥有高带宽的sub1推送高码率，向拥有中等带宽的sub2推送中码率，向处于弱网环境的sub3推送低码率。这样每一个接收方都能得到自己最适合的码率，同时避免了下行的卡顿。在Simulcast中最关键的部分就是Simulcast Stream Policy，它决定了两件事情：
（1）一个推流者要推送多少条码流；
（2）每一条流的比特率应该是多大。
可以说Stream Policy是Simulcast的核心。目前业界的典型方案如下图所示：
图5 | AWS Chime的Simulcast Stream Policy，https://aws.github.io/amazon-chime-sdk-js/modules/simulcast.html
图5展示了AWS Chime所使用的Stream Policy，它本质上是一个经验表（Empirical Table）。AWS Chime会根据会议的参会人数，上行带宽大小，通过查表定出需要推哪几条流，并且每条流的码率是多少。这样的经验式的Stream策略也有很多局限，特别是在参会人数变多的情况下：
（1）这种通过查表来决定码率数量和大小的过程中只参考了推流者的上行带宽，对于拉流者的订阅需求和相应的下行带宽并没有考虑进去，这样就造成了Stream Policy与下行需求和带宽约束之间的孤立，无法按需推流。
（2）目前的Stream Policy采用的码率档位颗粒度非常粗，而且档位的个数也很少，相邻的档位间码率差异可以达到3-4倍。这虽然简化了table的复杂度，但这样的粗颗粒度也造成了码率与带宽之间失配的问题。
（3）这种经验策略在会议规模扩大之后是很难去扩展和管理的，Chime只对参会人数在6人以下做了细分，而在会议人数大于6人的情况下不做进一步的划分。但是，我们看到，当前的会议通常具有很大的参会人数，可以达到数百甚至上千，而在大方会中要制定出这样一个经验策略是非常困难的，因为变量的维度实在是太大了，这时，我们的测试团队已经无法对于各种case进行枚举来确定出最优策略。
面对这样的问题，我们需要考虑一下Simulcast会议的终局究竟是什么：理想情况下无论参会者人数如何变化，订阅需求如何变化，用户的上/下行带宽条件如何变化，我们都能完美地匹配音视频码率档位与网络环境。首先，这要求我们能够支持尽量多的从细粒度档位去适配不同的网络带宽。但是档位的增加又会导致上行的推流个数增加，盲目地推更多条流又会导致上行拥塞，所以我们决定在上行推流的过程中必须将下行订阅需求与带宽约束条件联合起来，做到按需推流。另一方面，我们需要支持成百上千人的大方会议，这就导致我们无法继续使用基于empirical table的stream policy，而要把stream policy转化为一个可以自动求解的优化问题。所以，我们需要从当前碎片化、孤立化的经验决策中解脱出来，以全局优化的视角重新审视音视频会议码率控制。
鉴于此，阿里巴巴提出了GSO-Simulcast，一个基于全局码率求解器的新一代音视频会议技术。
图6 | GSO-Simulcast简化架构
图6展示了GSO-Simulcast的一个简化架构。GSO-Simulcast将一个会议分为三个平面，位于最下层的是用户面，它由一个会议的所有参会者组成，其中每个参会者都可以作为推流者或拉流者。在用户层上侧的是媒体面，它的作用是为用户提供媒体，接入媒体流的转发。位于最上层的，也是GSO-Simulcast核心的管控面，它的核心模块包括Conference Node和GSO Controller。Conference Node有两个主要功能：
（1）负责与用户与Accessing Node之间的信令通信；
（2）负责捕获整个会议的全局快照，包括某一时刻a）所有用户上下行的网络带宽；b）所有用户间的订阅关系；c）所有用户编解码器codec的能力。
然后Conference Node将这些收集的信息作为输入条件传递给GSO Controller，GSO Controller是整个会议的大脑，它会以整个会议的全局体验QoE为优化目标去求解一个全局优化问题，同时满足所有约束条件。在GSO-Simulcast中，我们可以支持多达15个细粒度档位的码率，从而实现对各种带宽条件都能做很好的适配。而整个优化问题也使得Stream Policy的扩展性大大提升，因为问题的formulation是一致的，面对不同的情况只需变化输入，GSO就会自动求解出对应的输出，这样我们就可以轻松地处理甚至千人以上的会议策略。
图7 | GSO-Simulcast在钉钉音视频会议的部署效果（百万次/每天的会议抽样数据）
部署效果：2021年11月20号，GSO-Simulcast开始在钉钉音视频会议进行部署，并于2021年12月20号达到了全量部署。图7展示了钉钉会议大盘数据对比变化（数据基于每天百万次会议抽样统计）。结果显示，随着GSO-Simulcast的规模扩大，视频卡顿率、音频卡顿率和视频帧率分别改进35%、50%和6%，另外最关键的是在GSO-Simulcast上线以后，钉钉音视频会议的用户满意度也同期改进了7%。
LiveNet：低时延CDN Overlay直播网络
第二篇文章是LiveNet，LiveNet是阿里巴巴推出的一个面向直播的低延迟CDN Overlay网络。与音视频会议需要的～100ms级别的时延不同，直播对于时延的要求在～1s级左右。另一方面，一场直播所要服务的用户数量可能达到千万甚至上亿，所以直播网络对于成本更加敏感，直播内容的分发需要用到CDN网络提供的就近接入与缓存（Caching）服务。阿里巴巴的第一代直播分发网络采用了分层（Hierarchical）架构，又可以称之为HIER，其架构如图8所示。
图8 | 阿里巴巴第一代直播内容分发网络HIER
HIER由流媒体中心（Streaming Center）和L1、L2两级CDN内容分发节点（node）组成，L1、L2节点负责分发视频内容，流媒体中心负责对上传的视频进行处理。在直播当中，一个典型的内容分发过程如下：上行侧，主播上传直播内容到相应的L1节点（通常，这个节点和用户的物理距离很近），之后由L1节点将内容继续上传到一个L2节点并由L2节点将内容提交给流媒体中心。如果有需要，流媒体中心会对视频内容进行转码等处理。下行侧，经过流媒体中心处理过的视频再通过L2、L1两级节点进行分发。同时，L1、L2节点会对视频的内容进行缓存。观看的用户通过L1节点接入拉取相应的视频，如果L1上没有缓存的视频，则L1节点会向L2节点发起请求。节点之间的数据传输是基于RTMP over TCP实现的。HIER架构于2016年在阿里上线并支持淘宝直播，多年的实践和应用需求的发展也让阿里发现HIER架构存在的若干问题：
（1）随着业务的发展，用户对于直播时延的要求越来越苛刻，为了能够实现<1s的时延，CDN的传输时延必须控制在300-400ms，可是目前HIER所能提供的时延在400ms左右，因此，我们需要一个更低时延（扁平化）的直播内容分发网络。
（2）直播业务的兴起也使直播的会话（session）数量爆发式增长，而HIER架构当中，所有的视频流都需要经过流媒体中心，这大大增加了媒体中心的处理压力和处理时间，也间接导致了端到端时延的增加。
（3）阿里云同时也为第三方应用提供直播内容分发服务，而HIER的分层架构缺乏灵活性，这为不同用户提供不同优先级造成了一定的困难。内容分发网络的组网应该可以更加灵活（flexible）。
图9 | LiveNet的系统架构
所以，阿里巴巴打造了新一代直播内容分发网络LiveNet，其系统架构图如图9所示。与HIER的分级架构不同，LiveNet是一个基于扁平化结构的Overlay网络CDN内容分发网络。在LiveNet当中，每一个节点可以通过中心化的控制中心（又称作流媒体大脑）配置。在LiveNet中，一个典型的直播内容分发过程如下：主播通过访问阿里云DNS服务就近接入一个边缘节点，这个节点又称为Producer节点。Producer节点会直接对视频内容做转码等相关的媒体处理。当观众需要观看视频时，观众会向一个边缘节点，又称作Consumer节点发起请求，如果请求的视频内容已经被缓存在相应的Consumer节点，那么该节点直接返回被请求的视频GoP。如果Consumer节点没有相关的视频内容，那么该节点会向中心控制器发起一个路径请求。中心控制器会返回一条最优的overlay路径，这条路径决定了视频内容该如何从一个Producer节点，通过中继节点（Relay）传输到一个Consumer节点。Consumer节点和Relay节点都可以对视频内容进行缓存，节点之间的流媒体传输由原先的RTMP over TCP演进为基于RTP/RTCP的传输。
LiveNet架构与SDN有很多相似之处，这个系统可以被进一步划分成控制面与数据面。控制面的主要任务是计算出一条全局最优的overlay路径。中心控制器会根据全局对网络信息，并考虑各个节点的负载与链路带宽，来计算出一条时延最短的overlay路径。数据面则负责按照控制面计算出来的路径传输媒体流，为避免WebRTC协议栈带来的处理开销过大的问题，在数据面上，LiveNet采取了Fast-slow path设计，快路径（fast path）采用尽力而为的转发方式将数据包传递给下一跳，而丢包和拥塞控制的逻辑则由慢路径（slow path）处理。
图10 | LiveNet与HIER的关键指标对比
如今LiveNet已经在超过600个CDN节点进行了部署，支持着淘宝直播等线上业务，图10展示了LiveNet与HIER架构在关键指标上的对比。LiveNet大幅度降低了CDN的路径时延，从原先的393ms降低到188ms。其中最关键的因素是扁平化的CDN overlay网络，将视频内容分发需要经过对节点跳数从过去的4跳普遍降低为现在的2跳。路径时延的降低也使直播时延降低了17%，卡顿率和快启动等指标也均有提升。
Zhuge：更快的反馈，更低的时延
无线网络因为信号强度的变化、射频干扰、多人竞争等原因经常表现出不稳定的时延。在游戏环境中，时延波动通常对玩家体验有非常大的伤害。如何在复杂的无线环境中实现低时延的视频传输一直以来都是一个难题。
为了降低时延，一个办法是当网络带宽降低时，及时地减少发送端的发送速率。我们都知道一旦出现丢包，发送端的拥塞控制器会降低发送窗口。但丢包现象往往是在路由器队列已经被“塞满”的情况下发生的，可是这个时候再去降低发送端的发送速率往往“为时已晚”。所以问题的关键就在“及时”二字。在第三篇文章中，阿里巴巴推出了一个新的原型系统诸葛（Zhuge），它是一个可以被集成在WiFi 路由器的低时延视频传输方案。
图11 | Zhuge系统原理图
Zhuge的原理图如图11所示，它的核心在于当下行无线带宽变化时，如何将反馈信息更快地传递给发送端。Zhuge在原理上采用了基于时延（Delay-based）的拥塞控制（Congestion control）。简单来说，这类拥塞控制会观察数据包之间的时延（Inter-packet delay）变化，当Inter-packet delay增加时，就可以认为链路的带宽减小，排队时延增加。此时，发送端就可以开始降低速率用来避免排队时延的继续升高。但这类拥塞控制的反馈速度受到整个上下行环路的制约。具体来说，下行链路（Downlink）的数据包发生排队后，这个数据包所历经的传输时延变大，但发送端是如何感知到这个信息呢？通常，发送端会对数据包对应的ACK报文的到达时间进行测量，再通过ACK报文的到达时间来间接推测下行链路排队时延，也就是说，我们必须要等一个round-trip才能感知到这个反馈，并且这个round-trip有可能已经包含了一个很大的拥塞队列的排队时延。
Zhuge原型系统提出了一个将反馈信号与拥塞队列解藕的解决方法。一个重要的insight就是当下行的数据队列开始堆积时，Zhuge可以不等被阻塞的数据包的ACK信息来反馈拥塞，而是利用比这个数据包更早的数据报文对应ACK提前将这个信息反馈给发送端。
图12 | Zhuge的拥塞信号反馈原理
具体的操作如图12所示，拥塞发送在数据包k和k+1之间，此时，因为AP可以测量自身的拥塞队列（图11 Fortune-teller模块），AP可以将这个排队时延的信息调制在更早的数据包j+1，j+2（这里j）相应的ACK报文上。简单来说，WIFI AP可以主动增大ACK j+1，ACK j+2之间的时延。当接收方观测到ACK j+1，ACK j+2时，便会主动降低发送速率从而以更快的响应速度降低排队时延。在实验结果上，Zhuge可以将RTC的长尾时延降低17%至95%。
结语
低时延视频在我们的生活中变得越来越重要，为上层视频业务保驾护航，提供可预期的音视频传输服务与技术是网络基础设施中的关键一环。特别是随着元宇宙时代的来临，视频传输会变得更具挑战性。GSO-Simulcast、LiveNet、Zhuge分别就音视频会议、直播、游戏等核心业务场景阐述了实现“可预期”目标的三种重要技术手段。未来，阿里云将继续秉持 “做深技术”的理念，为用户提供更可靠的视频服务和创造更大的业务价值。
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
