淘宝杨宽：淘宝直播低延迟架构演进和实践

本文根据杨宽（阿里巴巴淘系技术 音视频技术专家）于 2021 年 6 月 26 日举办的 ECUG Meetup 第 1 期 | 2021 音视频技术最佳实践·杭州站上的分享整理而成。本文长达 5500 余字，主要结构以下：- 传统直播技术痛点- 低延迟架构演进- 互动体验升级- 关键技术获取「讲师完整版 PPT」 ，请添加 ECUG 小助手微信（微信ID：ECUGCON）并备注「ECUG PPT」。其他讲师的分享也将于后续陆续放出，敬请期待。

---

如下为分享正文：

 

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

 

1、传统直播技术痛点

 

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

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

 

---

2、低延迟架构演进 

 

这是传统的一个直播架构。中间是 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 既能够推流也能够拉流，在同一个连接里能够走多路流，这是不限制的。好比说，推一路流，拉十路流，都是能够的。 

 

---

 3、互动体验升级 

基于直播场景的互动体检，主要对两大部分进行了升级。 第一点，提升互动效率。消费者经过直播间和直播交流的时候，原来老的系统观众看到的画面是 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 统一为了一个集群，节省了自建集群的成本。总体的延迟也是比较低的。业务融合网络，刚才介绍了一部分，不一样的业务能够跑在同一张网上，由于业务主要使用的时间段不同，咱们能够经过错峰使用来下降总体的带宽成本。 

---

4、关键技术 

 

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