淘宝杨宽：淘宝直播低延迟架构演进和实践丨ECUG Meetup 回顾

本文根据杨宽（阿里巴巴淘系技术 音视频技术专家）于 2021 年 6 月 26 日举办的 ECUG Meetup 第 1 期 | 2021 音视频技术最佳实践·杭州站上的分享整理而成。本文长达 5500 余字，主要结构如下：

• 传统直播技术痛点
• 低延迟架构演进
• 互动体验升级
• 关键技术

获取「讲师完整版 PPT」 ，请添加 ECUG 小助手微信（微信ID：ECUGCON）并备注「ECUG PPT」。其余讲师的分享也将于后续陆续放出，敬请期待。

---

以下为分享正文：

大家下午好！首先自我介绍一下，工作以来主要是在音视频相关领域，安防监控，互动直播、CDN 等，目前在淘宝做直播低延迟架构和 QoS 相关工作。

一、传统直播技术痛点

大家看，这是线上的一些直播场景。第一张图主要是服饰的场景，下面有观众与主播的评论交互。在传统直播的场景下，可能观众看的是 5-10 秒以后的画面，当观众评论提问的时候，主播可能已经不介绍这款商品了，所以会有一个延迟的 Gap，交流就比较困难。第二个场景是珠宝的场景，介绍完镯子以后可能会换下一款，但是观众可能看的还是上一款镯子。第三个是宠物直播场景。

传统直播的主要痛点有三个：

第一，延迟高，5-10 秒的延迟；
第二，主播和观众互动不及时；
第三，直播和连麦场景切换复杂。

二、低延迟架构演进

这是传统的一个直播架构。中间是 CDN 的分发网络，最左边是自建的 SFU 和 MCU 集群。最右边是支持的一些系统，比如说日志、监控、配置、调度，最下面的图是推拉流的 SDK。最上面是一个直播中心，有截图，转码，录制，切片等服务。

传统的直播分发网络是一个树状的结构。因为直播的量很大，树型结构分发可以控制成本。上行协议主要是 RTMP/WebRTC/私有 RTC，推到自建集群，然后通过 rtmp 推到 CDN。下行协议主要是 HTTP-FLV/RTMP/HLS。

这是我们和 CDN 共建做的低延迟直播架构的改造，改造的点主要是 CDN 和观众播放器之间采用了 RTC 相关的技术，把延迟从 7 秒降到 1.5 秒左右。在业务上不仅延迟降低了，方便观众和主播间的交流。而且在线上分行业AB显示，在促进电商成交转化方面也取得了不错的效果。

这个架构大概是我们 2019 年开始和 CDN，视频云, 企业智能，XG 实验室共建的架构，也是目前正在开始大规模使用的。可以看到，中间 CDN 框架那边全部走的是 RTC 的链路，不再是树型的结构，是去中心化的架构。L1 和 L1 之间可以互通。如果 L1 和 L1 之间的通信有问题，可以走 L2 中转。MCU 合流服务可以像客户端一样直接连接到 RTC 的网络上，把需要处理的流拉下来，处理完之后再重新推给 RTC 网络。

主播通过 RTC 可以和网络直接通信，如果需要它做一些实时流的处理的话，比如说加一些 AI 的特效，可以通过实时流处理，处理完之后直接推给 RTC 整个网络。观众也是通过 RTC 链路直接和这张网交互。

整个全链路 RTC 架构有几个比较好的点。它是一个直播、通话、连麦、会议共用的一张网。不同的业务高峰使用的时间段不一样。比如说直播，一般晚上观看的人数比较多。会议基本上是白天开会。这样不同业务就可以错峰地使用这张网。

因为 CDN 一般是根据每天峰值带宽来计费，这样白天可以跑通话会议的业务，晚上会有一些直播的带宽上来。通过错峰，不同的业务错峰来降低整体的成本。双向实时通信这块儿，因为 RTC 既可以推流也可以拉流，在同一个链接里可以走多路流，这是不限制的。比如说，推一路流，拉十路流，都是可以的。

三、互动体验升级

基于直播场景的互动体检，主要对两大部分进行了升级。

第一点，提高互动效率。消费者通过直播间和直播交流的时候，原来老的系统观众看到的画面是 5-10 秒前的画面，所以主播和观众互动的时候时间点是对不上的。升级以后的延迟优化为 1 秒左右，使消费者和主播互动更及时。

第二点，指标优化。从延迟上说，可以做到 1 秒以内，在通话会议场景可以做到 200 毫秒左右。秒开率相对于原有的传统直播系统能提升 32%，卡顿率降低 79%，卡顿 vv 降低 44%。

这里要讲一下互动连麦直播原来的架构和目前架构的区别。

可以看到，原来的架构主播是通过 RTC 自建集群来转发 RTC 的流，保证低延迟，然后连麦。观众是通过 CDN 来拉流观看，中间走的是 rtmp 链路。如果是主播和主播之间的连麦，基本上是主播自己拉到对方的流，然后合流推到 CDN，然后再分发给观众看，这样的一个流程。如果是主播和观众连麦，观众本来是在 CDN 这条链路上。在传统的链路上，中间有一个延迟差，这个延迟差大概是 6-7 秒左右。通过 RTC 发起连麦的时候，通过 RTC 来连到自建集群，然后和主播互相通信的时候，画面是有延迟差的，这样体验就非常不好，有一些等待切换的逻辑在里面。

在新架构下，可以做到自建集群和 CDN 是完全融合为一体。也就是说，CDN 内部也是走的全链路 RTC，不管是主播和主播的通信，还是观众和主播的通信，完全走的是 RTC 的链路。RTC 链路可以通过一些传输优化保障，还有一些其他技术的优化，能够保障它所有的体验是统一的，比如说延迟、卡顿、流畅性等等。

下面是一个 MCU，就是合流服务器。如果主播或者说观众的设备是低端机的话，它的性能不太好，所以需要通过 MCU 来合流，这个合流服务器也是类似于客户端的方式来接入这张网。然后通过把流拉下来，合完之后再推出去，因为我们延迟优化的很低，基本上能做到无感的切换。

这个架构模糊了观众、主播以及其他一些服务的角色。作为 RTC 的这张网来说，其实都是一个统一的接入者角色，既可以推流，也可以拉流。协议的话，都统一为私有的 RTC 协议。我们 RTC 的私有协议可以做到一个 RTT 就可以快速地拉流建连。场景这块儿，目前直播场景、连麦场景、会议场景以及通话场景，可以做到无缝切换。通过配置系统，针对不同的场景会启用不同的策略。

还有一个好处是，从自建集群加 CDN 统一为了一个集群，节省了自建集群的成本。整体的延迟也是比较低的。业务融合网络，刚才介绍了一部分，不同的业务可以跑在同一张网上，因为业务主要使用的时间段不一样，我们可以通过错峰使用来降低整体的带宽成本。

四、关键技术

我们这边和 CDN 是共建的关系。RTC Module 提供 RTC 相关的核心处理能力，以模块化的方式嵌入到系统。

内部的模块大概有以下这些：RTP/RTCP、BWE、QOS、PACE、PACKER、trickle/jitter、frame buffer、SRTP、setting 等等。BWE，主要是一些拥塞控制算法，QOS 这块会有一些 QOS 的策略，像重传，SVC，FEC 以及大小流相关的。trickle/jitter 主要作用是去抖和组帧。PACKER，有一些场景需要从视频帧或者音频帧打包成 RTP 格式。SRTP 主要是提供加解密的模块。目前支持 grtn 私有协议和 webrtc 标准协议的交互。

在管理层，主要是有以下四种：

• 回调管理
• 订阅管理
• session 管理
• 推拉流管理

回调管理在系统和 RTC 核心处理层之间，通过一些回调函数来处理它们之间的交互，做到这两层之间的隔离。

基础能力总结一下，主要是五点：

第一，多协议的框架。支持 webrtc、grtn 协议。通过 grtn 私有协议接入的话，可以保证整体接入效果。还有其他一些私有扩展功能，比 webrtc 标准的交互效率会高很多。rtmp 和 http-flv 在这块儿上也是支持的。

第二，音视频 Pub/Sub 原子能力，方便使用扩展。

第三，Data Channel 单独 Pub/Sub 管理，业务灵活定制。Data Channel 目前主要应用在控制信令和一些云游戏的场景。比如说观众和主播会通过 Data Channel 通道发一些控制信令，控制一些摄像机的动作或者说游戏里人物的控制。设计的时候也考虑了它的灵活性，也是提供单独的 Pub/Sub 的能力，可以单独使用。也就是说，如果在一个 URL 下只单独做一个数据的通道，这也是没问题的。Data Channel 通道的特点，我们会提供单独的传输保障。延迟可以控制在全国范围内大概 100-200 毫秒左右。如果是同一地域的话，基本上是一个 RTT。线上的话，平均大概的 RTT 是 20 毫秒左右。

还有一个运营场景是一些直播间的消息，如果通过传统的消息系统基本上是秒级订阅，或者是推拉的模式。我们现在可以做到百毫秒延迟以内。业务这块可以灵活定制，比如说可以单独挂消息通道的服务器，通过这个服务器各个端可以单独订阅这个消息通道。做一些业务的活动，还有一些实时消息的下发，可以做单独的灵活定制。

第四，媒体和信令通道统一，可靠信令。信令我们会保证它的可靠到达。大家都知道，UDP 在公网上是很容易丢的，所以我们有一些保证它快速可达的策略，会有一些快速的重传逻辑以及冗余的逻辑。

第五，全网灵活切流能力，Url/Stream 级别。大家都知道，连麦的场景下，主播推直播间的流，他和别人连麦的时候，原来的方式是走 RTC 的自建集群，RTC 自建集群会处理切流的动作。因为所有的主播流都会走自建集群，他在切流的时候，因为数据源可控，可以做到切流的时候不会影响后面所有的播放。在全链路 RTC 的时候，其实是一个分布式的系统，主播和主播要连麦的时候，接入点不同，整体是分布式的系统，切流能力就会保证他在切换过程中，能够保证全网的观众在同一时刻切到合流的画面。可以做到 Url 和 Stream 级别，也就是说不同的 Stream 也可以自由切换。

传统的直播链路中间是走 TCP，因为 TCP 在内核层，系统会提供一些策略，定制优化很难。我们现在用全链路 RTC，用的是 UDP，UDP 是不可靠的。全链路 QoS 策略这块就显得很重要。

音视频系统有一个特点，从采集到前处理到编码，到传输然后到解码、渲染，其实是一个串行的过程，中间任何一个环节有问题都会影响整体的体验。
指标的话，有成功率、卡顿率、秒开、延迟等等一系列指标。

场景有直播、连麦、通话、会议，会议也要做，去做直播电商内部多人的互动。我们做 QoS 要考虑多场景，要考虑 RTC 整体的传输链路，还有一些核心指标的优化。

目前用到的算法，主要是BBR 和 GCC 算法。这两个算法最开始是从 WebRTC 模块化拿来使用。后来我们几乎重写、重构了，提升了性能。并且针对直播的场景，深度定制优化。直播强调吞吐量，和会议场景的算法强调流畅还是有些区别的。

另外，我们会针对不同的算法，在不同的业务场景去做大规模的AB。根据数据系统搜集上来的不同指标、延迟等，来动态调整它的参数，不断优化改进。带宽分配算法，比如说服务器有音频 带宽、重传带宽、视频带宽，还有 SVC 的一些分层带宽，还有小流。这些带宽怎么分配，在什么样的场景下用什么样的策略，带宽分配算法要解决这些问题。

策略控制这块儿，主要有 FEC、ARQ、SVC 等等。RED 是为了保证音频的低延迟，JitterBuffer 也做了一些优化，Pacer 也针对直播大的吞吐量做了改进。比如说我们会做用多包发送的策略，以及中间链路的整体改进，还有 NetEq、延迟控制等等。

分阶段延迟优化我大致说一下。

做延迟优化的话，如果只是一个简单的场景，比如说一些数据量比较少的场景，这是比较简单的，但是我们的用户量，包括主播的用户量、观众的用户量，每天上亿的观看，如何保证全网平均延迟降下来，这个挑战是很大的。

延迟这块我们是这么思考的：直播系统主要分为推流端和播放器，中间走的是传输网络，需要针对每个阶段单独优化。传输网络部分，在网络比较好的情况，延迟还是比较可控的，如果网络不好，会启用一些 QoS 的策略。采集、前处理、编码，编码这块又分硬编、软编，还有一些自研的编码器。

发送缓存，也会动态的有一些策略。接收侧的话，延迟比较大的主要是接收缓存，接收缓存这块儿，如果和上行的网络之间有丢包、抖动，接收缓存都会动态调整，把整个延迟加上去，为了对抗前面的一些问题。解码这块，包括解码速度、解码缓存以及不同的解码器，比如说硬解、软解之类的。还有一些后处理，解码数量后处理的一些算法处理延迟。最后是渲染的延迟。

不同的平台是不一样的，IOS、Android、PC。比如 IOS 平台前处理、编码是怎么样的，大致的延迟分布是什么样的，都要有数据报表，在线上采集出来，去做针对性的优化。Android，PC 也是同样的。

每个阶段会有针对性的优化，比如说编码这块，我们会和算法团队一起优化，也会分不同平台进行编码部分的处理。编码这块儿也会放在线上，根据数据埋点系统分不同的平台，分不同的编码器，不同的版本做展示。

第二点，中间链路部分，主要是应用一些 QoS 的策略。还有一些调度，调度是和 CDN 合作的。规划出根据不同链路之间的网络质量、成本，规划出一条最短的传输路径。是质量、成本的一个综合策略。再加上 QoS 策略，保证传输的这块的延迟。

第三点，用户量比较大，会统计分析每一阶段的大盘延迟分布，每天都会不同的报表展示。

数据系统部分主要介绍四个：

第一，全链路跟踪质量展示分析。根据这个系统可以跟踪每一条链路中间经过的每一跳的服务器，它们之间的链路状况是怎么样的，包括错误码以及码率，这是一个全链路的分析。从每个用户到主播这条链路，根据唯一的一个 ID 就能查到这条链路上每一跳的质量，这样就可以针对线上不同的问题进行详细地分析。

第二，分段延迟分析展示。这个系统会根据不同的平台、不同的主播、不同的阶段，比如说编码、解码、缓存、渲染、传输等阶段延迟的情况。

第三，配置 AB 系统。不管是端上的推流端还是播放器端，都有大量的配置，比如说一些时延性的算法，一些业务的策略，可以做到根据不同的业务进行分析，对比效果。举个例子，要证明一下我们优化的延迟对电商成交有没有正向效果。我们会选比如珠宝类的一些直播，还有一些衣服类的直播等等，根据不同的行业去做 AB，到底提升效果是怎么样的。

第四，RTC 质量大盘。针对不同的地域、不同的域名会有一个整体的质量展示。包括推流质量、拉流质量，以及一些中间链路的质量等等。

以上是我今天的分享内容，谢谢大家！

---

关于七牛云、ECUG 和 ECUG Meetup

七牛云：七牛云成立于 2011 年，作为国内知名的云计算及数据服务提供商，七牛云持续在海量文件存储、CDN 内容分发、视频点播、互动直播及大规模异构数据的智能分析与处理等领域的核心技术进行深度投入，致力于以数据科技全面驱动数字化未来，赋能各行各业全面进入数据时代。

ECUG：全称为 Effective Cloud User Group（实效云计算用户组），成立于 2007 年的 CN Erlounge II，由许式伟发起，是科技领域不可或缺的高端前沿团体。作为行业技术进步的一扇窗口，ECUG 汇聚众多技术人，关注当下热点技术与尖端实践，共同引领行业技术的变革。

ECUG Meetup ：ECUG、七牛云联合打造的技术分享系列活动，定位于开发者以及技术从业者的线下聚会，目标是为开发者打造一个高质量的学习与社交平台，期待每一位参会者之间知识的共创、共建和相互影响，产生新知推动认知发展以及技术进步，通过交流促进行业共同进步，为开发者以及技术从业者打造更好