一张「多元融合」的网络。

黄海宇｜演讲者

大家好，我是阿里云视频云的黄海宇，今天分享主题是 MediaUni——面向未来的流媒体传输网络设计与实践。

下面我将会从应用对流媒体传输网络的要求、MediaUni 定位与系统架构、MediaUni 技术剖析、基于 MediaUni 的应用落地和流媒体传输网络的未来 5 个方面展开介绍。

01 应对流媒体传输网络的要求

如图所示，不同场景延时从左往右依次升高。最右侧，超过 30 秒的延时，通常被认为是一个可传播的场景，例如视频点播，行业内会通过一张 CDN 点播网，服务这样的传输需求。

3~10 秒的延时区间多见于直播，会使用如 RTMP、HTTPFLV 和 HLS 等协议，进行一些流式或小分片的传输，可满足 3~5 秒的延时需求，通常适用于弹幕互动的场景。在行业内，通常使用 CDN 直播网络进行这样的传输服务。

最近兴起的 800 毫秒到 1 秒左右的延时，通常可以满足体育赛事直播中的传输延时需求，例如，在世界杯直播场景中，该延时的直播让用户不再会感受到进球时刻的明显差异。另外，通过淘宝等电商场景的实践发现，该延时级别的直播，相对于 3~10 秒的普通直播，可以有效提升 GMV。

视频会议、直播连麦、语音聊天的延时通常在 250 毫秒到 400 毫秒之间，行业内通常会采用如 BGP 带宽或者三线带宽，构建一张低延时的音视频通讯网络，来进行实时音视频传输支持。

更低延时的场景，我们将其称为可操控和可沉浸场景，延时在 50~80 毫秒，可操控的典型场景是平行驾驶，当自动驾驶出现问题时，可以通过远程指令操控汽车、接管驾驶。而云游戏、云渲染则是典型的可沉浸场景。

从上面可以看到，延时的降低带来了更多的业务场景和更多新的玩法。

以延时最低的云渲染场景为例，通过其顶层架构图，可以发现，用户产生一系列的操作指令，通过传输网络传输到相关的业务服务器，再控制渲染服务器进行渲染，渲染后的数据会经过流媒体服务器，再通过流媒体传输网络进行传输，最终达到用户终端。

相比传统的媒体传输，该架构有两个特点：第一，视频来自于渲染而非拍摄，会涉及到大量的计算环节；第二，传输网络不仅要传输媒体，还要传输控制指令，需要保证控制指令的低延时和可靠的交付。

成本和质量是传输网络绕不开的两个话题。左图展示了一个阿里云典型直播 APP 客户的云上成本构成，70%左右来自于传输，这意味着在当下企业降本的大环境下，需要对传输提出更低成本的要求。

右图是另一个典型视频 APP 的播放时长与卡顿率的关系数据，通过 AB 测试我们发现，随着卡顿率的逐步降低，播放时长也会有明显的提升。

综合来看，应用对流媒体传输网络的要求来自于四个方面：第一，延时的降低可以催生更多业务场景；第二，低成本，媒体传输是视频应用成本的重要组成部分；第三，更高质量的视频可以提升用户的观看时长；第四，多维度，除了媒体传输之外，还需要支持互动消息的传输、控制信令的传输，同时也要支持与计算的紧密相连。

02 MediaUni 定位与系统架构

基于以上思考，阿里云设计并实现了 MediaUni，其中 Uni 取自单词 unified，意为通过一张统一的网络，服务各种业务场景。

MediaUni 是阿里云全球实时传输网络 GRTN 的升级，是基于广泛的异构节点，构建的全分布式、超低延时、多业务支撑的多元融合流媒体传输网络。

MediaUni 的核心理念在于融合，这主要出于如下三方面的思考。

第一、业务混跑带来的资源利用率提升。云厂商的基本商业逻辑是：云是弹性服务，大家可以按需付费，即买即用，那么，由于不同用户使用的时间段是不同的，购买的固定资源则可分时服务到不同的厂商，使得云服务的资源利用率大于客户自行购买的的资源利用率，从而降低成本。与普通的云计算不同，流媒体的一大特点是业务的聚集，例如，单一的互联网娱乐直播，大部分都会发生在晚上 8:00~11:00 的晚高峰之间，而大部分的会议分布在白天上班时间，体育赛事则可能出现在任一时间段，如果我们仅仅支持其中一种业务，则无法达到资源复用的目的。

这背后的理论依据是概率论最基本的中心极限定理：大量独立的随机变量之和服从正态分布，随机变量越多，他们的和将越聚集在平均值之和附近。对应到流媒体传输业务，每个客户对资源的使用就是一个随机变量，他们对资源的总需求就是服务商需要保障的资源总量。为了达到更高的复用率，我们需要尽可能扩大业务的规模与多样性，从而达到综合降本的目的。

第二、技术复用带来的研发边际成本降低。不管是音视频点播的传输网络，还是直播的传输网络，还是实时音视频通讯，都会涉及一些相同的技术，比如协议的优化、QoS 优化、调度等，而在一张网上实现这些技术，可以带来更好的技术复用，将单点技术做得更加深入，从而带来更大的业务价值。

第三、云产品更加便捷与高效。从云厂商的角度来说，把各种传输能力进行融合，意味着用户在使用产品时会更加便捷，比如通过一张网的融合，用户在阿里云上可以通过一键升级，将自己的普通直播（3~5 秒延迟）升级为低延时互动直播（400 毫秒）。

图为 MediaUni 的架构

可以看到，MediaUni 构建在阿里云广泛的异构资源上，包括 3200+的边缘计算节点，以及 29 个 region，同时也包括超过 180T 的带宽，涉及的计算资源类型包括 CPU、GPU、ASIC。

这里有两个很重要的系统，第一个是感知系统。感知系统需要具备三方面的感知能力：

① 感知业务信息，在直播时有些应用信息是在真正发生之后才知道的，例如，某个直播流观看人数突然增多，我们必须有能力实时感知到，从而提供一些差异化的服务；

② 感知资源信息，包括基础资源的水位、CPU 与内存的状态、带宽的使用情况、以及网络的延迟、丢包率等；

③ 感知服务质量，例如各种业务的卡顿率、视频首帧的延时、推拉流成功率等。

第二个是决策系统，这些感知信息在收集以后，会推送给决策系统，并基于成本与质量的平衡，进行调度决策：包括接入的调度、路由的选择、实时的逃逸策略以及算力的调度等等。

MediaUni 的整体架构具有几个明显的特点：

l 可以支持多种协议。这些协议是在边缘支持的，在边缘节点进行一层卸载，卸载以后中心会采用统一的内部传输协议，这样利于我们扩展业务场景，同时又不影响内部核心系统；

l MediaUni 支持混合组网。延时要求不高的场景，会采用树状组网，而对于音视频通讯这样延时要求高的场景，会采用对等组网的方式；

l 网络之间的路由会基于源选择动态路径服务用户；

l 全链路可编程。很多业务在同一张网上运行以后，可能会存在业务之间相互影响的问题，为了减少系统的变更，我们支持了全链路的可编程，让大部分业务需求能够通过可编程的方式实现；

l 算网结合。计算部署在网络节点上，能够提高资源利用率，同时也降低为了计算而传输数据带来的成本与延迟；

l 异构网络、计算资源支持。系统支持单线、多线、BGP 多种网络资源类型，也支持 CPU、GPU、ASIC 多种计算类型；

l 持续迭代的 QoS。系统支持 QoS 算法的可插拔，并具备完善的 AB 测试能力，帮助 QoS 不断迭代。

融合带来诸多好处，但也会带来额外的挑战。首先是异构资源的适配和纳管。其次是基于不可靠的资源提供可靠的服务，这是这张网络最大的挑战，通常的音视频通讯网络，采用更加优质的资源以达到更低的延迟及稳定性，对于统一的网络，如何在更多的节点里面优选出节点，进行更好的服务则至关重要。

另外的挑战来自于多业务混跑带来快速迭代的需求，运行的业务越多，系统更新也会越来越快，如何满足系统的快速迭代以及缓解随之而来的稳定性冲击，也是一个很大的挑战。最后是标准化和智能化带来的挑战。

03 MediaUni 技术剖析

下面简要介绍 MediaUni 对不同场景的支持。

直播场景有几个特点，一个是大规模会带来高并发和成本敏感，另外一个是突发的直播事件。对此阿里云采取了以下措施：首先是混合组网。在 3~10 秒延迟的直播中采用树状组网，如果延迟需求达到 400 毫秒左右，将会采用对等组网。其次是热流的秒级感知，当一个流突然从冷流变成热流时，将迅速动态扩大服务资源。另外，目前行业内直播业务仍以基于 TCP 的协议为主，我们对协议栈进行了深度优化，以达到更好的服务质量。最后是质量与成本可运营，能够根据业务的质量、成本偏好进行调节。

实时通讯场景有两个特点，一个是低延时，一个是场景化。在低延时的实时通讯场景下，为了保障低延时，通常会采用各种 QoS 策略，但不同场景的 QoS 策略是千差万别的。例如，视频会议和普通的语音聊天传输，采用的 QoS 技术差别非常大，为此 MediaUni 采用动态组网、就近接入、可插拔 QoS 和秒级逃逸几个技术来解决上述问题。

就近接入，意味着能够快速感知用户和节点之间的链路状态，服务器可以很快做出一些 QoS 策略的调整。可插拔的 QoS 能够帮助团队应对各种不同场景化的 QoS 需求。阿里云的传输依靠大量边缘节点，各个边缘节点的可靠性不尽相同，所以需要对这些节点进行更快速的感知，预防故障的发生以及服务质量的下降。

云渲染场景伴随超低延时和控制信令传输两个特点。这里采用就近接入和就近异构计算两种方式，选择距离用户最近的计算节点和传输节点进行接入，并采用异构的计算方式服务用户。

数据传输场景，通常延时低、可靠性高，而且数据传输量相对较少。通过协议复用与扩展，支持数据的传输，同时采用多径和 FEC 技术，提升数据传输可靠性，减少重传。

针对不可靠资源的高质量是传输网络面临的巨大挑战，也是关键技术。

传输网络的不可靠主要来源于两个方面，一是资源的不可靠：一方面边缘节点的可用性不尽相同，另一方面大部分的传输都基于公网，而公网建立在 IP 之上，是一张尽力而为的网络，经常会遇到网络抖动，如何去对抗网络质量的抖动也是一个很大的挑战。

二是流媒体传输的业务特点，包括长链接和热点突发。为了保障低延迟，流媒体的传输通常采用长链接方式，需在建立连接时就分配系统资源，但视频的特点是音视频码率会动态波动，例如世界杯，开始时视频的码率可能只有一兆，但是进球时可能会波动到四兆、五兆甚至更高；另一方面，热点事件突发时会对资源的需求迅速扩大，这都意味着用户业务对资源有很大弹性的要求。

针对上述问题，我们进行了两方面的优化。一方面是弱网对抗。从生产端到传输端，再到播放端，会有很多的优化策略，例如，在前处理时进行降噪、通过阿里云窄带高清技术降低码率、支持多流、SVC 等；传输侧相应的策略有动态路由、协议栈优化、FEC、多径等；播放侧会有 jitterbuffer、neteq、后处理等方式。

另一方面的优化是感知与逃逸。因为构建在不可靠的资源上，所以非常需要实时感知资源的状态以及业务的状态，再通过智能的决策做秒级的逃逸。

在感知与逃逸的关键技术方面，以下分享一些细节。

我们设计了多维感知评分系统。通常的流媒体传输只感知服务节点的可用性，为了能够支持多种业务，同时提供更好质量，我们引入了评分的概念，对每一个节点进行评分，同时也对节点之间的链路进行评分。

评分来自于三个方面：首先是节点的日志，包括资源的信息、资源的水位和软件运行的状态；其次是端边探测系统，我们不能够仅仅相信服务端的日志，因为可能存在服务质量或服务可用性问题，一些客户没有访问到服务就失败了，从而导致幸存者偏差，为此我们构建了几十万的端设备，用于不断探测系统，探测的结果也是评分的重要依据；最后，是业务层的一些质量数据，比如卡顿率、首帧，以及拉流成功率这类核心的服务质量指标，也将作为评分的一大依据。

在多维感知系统得到这些评分之后，会输出每个节点以及每条链路的评分，并根据评分结果，把相应的信息传输到智能决策系统。智能决策系统会依据业务类型、服务等级、资源的成本以及水位这三方面信息作出决策，包括节点的管控、用户接入的调度、路由动态切换以及无损切换等。由于音视频采用长链接，其可调度性较差，当发生故障或感知到质量下滑后，需要对原有的长链接进行迁移，其中包括处理任务的无损迁移和传输链路上链接的无损迁移。

这里面有三个难点，一是感知的速度，我们采用了两种手段，一方面做业务分级，对系统资源利用率非常大的数据，会使用高优先级通道传输；另一方面进行节点上的计算，将很多计算，包括评分，放在节点上完成，这样传输的数据会大幅减少，从而提升传输速度。第二个难点是如何实现无损切换，要保证音视频的无感切换需要进行帧级别的续接，同时也要处理时间戳连续性、分布式系统调用异常等细节。第三个难点是如何做决策，因为拥有大量的信息，而不同的业务对质量的要求又不尽相同，如何进行智能决策，同时又满足成本的需求，就存在着很大的挑战。

经过技术上的迭代优化，阿里云成功实现在节点故障时的秒级切换，并保障了在质量恶化时的分钟级逃逸。

另一个关键技术是协议栈的应用层联动，这里主要针对 TCP 场景。

TCP 场景一直都有一个优化手段叫做单边加速，这是因为服务器的协议栈由自己控制，可以修改内核进行优化，但是客户侧的 TCP 协议栈由客户端操作系统提供，不能进行修改，而最近几年出现的 Quic，可以在应用层进行拥塞控制以及协议栈优化，但由于 TCP 仍然是流媒体传输的主要协议，我们进行了深度的优化。传统的单边加速采用通用的加速方法，修改传输的拥塞控制策略，但传输层与应用层相互独立，4 层的 TCP 协议不能感知到 7 层的应用信息，同时 7 层也感知不到 4 层的网络传输变化。产生这样的问题，主要是因为 4 层在设计上是一个通用协议，不区分流媒体，也不区分文件。为此，我们将 4 层和 7 层的信息打通，实现 4 层和 7 层的联动以及 7 层和 4 层的联动。

右图上面为流媒体传输引擎 Tengine-Live，处于应用层，能够获得相应的业务信息、码率信息，同时也会控制一些丢包的策略。在传输时可以通过 4 层的通道，把业务的偏好、带宽的需求、码率波动以及带宽的大小，传递给操作系统，而操作系统则根据传输的不同阶段采取不同的应对措施。

具体来说，操作系统可以根据应用层的信息选择拥塞控制算法类型，如我们自研的类 Cubic 算法和类 BBR 算法，也可以进行子算法的选择，同时，操作系统还可以根据应用层传入的具体信息对算法进行微调，例如，可以根据码率的大小选择首窗窗口，可以根据播放的阶段来均衡策略的激进性，也可以对算法的参数进行调节。

相应的传输信息也会通过 4 层到 7 层的通道，把底层拥塞控制里面的实时带宽、网络拥塞状态、网络 RTT 丢包率等信息传递给应用层，如果应用层发现底层网络已经严重拥塞，则可以采取更激进的丢包策略。

该技术上线以后，实现了播放首帧降低 12.1 毫秒、卡顿率降低 32.5 毫秒、拉流成功率提升 0.101%的显著效果。

全链路可编程，是为了应对多链路混跑所带来的挑战，多业务混跑会使得需求爆炸性增长，需要一种尽量减少侵入的方式来满足需求的快速迭代。

为此我们开发了全链路可编程系统，对流媒体传输和流媒体处理都进行了可编程扩展，把 C 代码进行原子能力的抽象，抽象到相应 Lua 的 API，通过调用这些 API，可以组合出各种不同的业务能力，以满足播放行为、时间戳、QoS 算法迭代以及转码动态规则调整等需求。Lua 代码实现以后，会通过配置中心传输到流媒体的传输网络和处理网络，以满足新功能或优化快速迭代的需求。

这里有几点需要注意：高性能，对于传输节点来说，Lua 的性能非常重要，因为传输节点的吞吐量非常大，我们大量使用 Lua FFI 而非 Lua Cfunction，减少 Lua 栈数据交互操作，同时也对其中的热点进行性能优化；安全性，需要严格控制 Lua 的可操作范围，避免对系统造成影响；此外，灵活性是我们采用可编程的目的，实现中也考虑了动态下发，支持灰度、AB 实验、热更新，可插拔等能力，以提高可编程的灵活性。

04 基于 MediaUni 的应用落地

在卡塔尔世界杯期间，我们支持了超低延时的直播，将端到端直播延时降低到一秒以内。此外，我们还带来了更好的播放体验，卡顿率显著下降，从 3.19%降低至 2.13%。

在一些云渲染的场景，通过就近传输和就近处理，我们实现端到端延时降低到 58 毫秒。目前，这项技术已经应用在央博的云庙会，以及去年双 11 淘宝未来城中。

云上艺考则综合使用了多项能力。在远程监考场景，当老师对一个学生感兴趣时，可以单击进入电视直播模式，达到 400 毫秒延时的直播。如果老师有问题需要和学生进行沟通，开启连麦，也可以做到 400 毫秒之内的通信。同时，媒体处理服务可以对这些流进行实时的合流，形成一个老师面对多个学生的画面。另外，基于数据传输的能力，应用层可以实现口播的功能，将数据通过网络传给学生，进行考场规则的宣读与显示。

05 流媒体传输网络的未来

流媒体传输网络的未来主要有 4 个方向，分别是更低延时、更智能、更开放和算网融合。

随着 AIGC 的发展，越来越多的视频内容，不再局限于拍摄产生，而可以通过 AIGC 来生成。当如此多内容通过 AIGC 的方式生产时，更低的延时毫无疑问会带来更多的玩法。

无论是前面提到的调度系统，还是 4 层 7 层联动的策略，都有很多的智能逻辑在里面。从更大的范围讲，传输系统内部存在大量参数与逻辑组合，这些组合目前是经验性的，或者是通过 AB 测试选择出来的，但对这些参数与组合的衡量结果是确定的，通过衡量视频核心的播放参数，可以构成一个监督学习系统。如何根据反馈，调整网络里面复杂的参数，更智能无疑是更好的解决办法。

在视频领域，两个最重要的方向就是视频的处理和视频的传输。视频处理已拥有很多国际标准，例如 H.265、H.266、AV1。但在视频传输上，标准并没有这么被广泛定义或者使用，例如，音视频底层的 RTP 这样的传输协议标准，只规定了非常基础的包格式，而在大部分偏向应用的场景下，例如 RTMP、HLS 等标准都是由一些公司自己制定的，这些标准并没有进行很好的统一，随着 AIGC 的到来，整条视频链路的分工更加细化，行业需要更多的标准帮助不同工具、服务的提供方进行数据交互。阿里云也在积极参与一些协议的标准化，促进协议更加开放。

最后一点是算网融合，正如刚才所说，AIGC 的出现，会让更多的视频通过计算的方式产生，这个时候就需要更多地把计算能力融合到网络能力中，通过算网融合，综合调度，进一步降低整体的资源消耗，同时也带给用户更高质量的服务。

谢谢大家！