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

传统直播技术痛点

大家看，这是线上的一些直播场景。

第一张图主要是服饰的场景，下面有观众与主播的评论交互。在传统直播的场景下，可能观众看的是 5-10 秒以后的画面，当观众评论提问的时候，主播可能已经不介绍这款商品了，所以会有一个延迟的 Gap，交流就比较困难。

第二个场景是珠宝的场景，介绍完镯子以后可能会换下一款，但是观众可能看的还是上一款镯子。

第三个是宠物直播场景。

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

1. 延迟高，5-10 秒的延迟；
2. 主播和观众互动不及时；
3. 直播和连麦场景切换复杂。

低延迟架构演进

这是传统的一个直播架构。中间是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标准协议的交互。

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

1. 回调管理
2. 订阅管理
3. session 管理
4. 推拉流管理

回调管理在系统和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 质量大盘。针对不同的地域、不同的域名会有一个整体的质量展示。包括推流质量、拉流质量，以及一些中间链路的质量等等。

本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/rsUP4sZqtt7Et5Kt76mNeQ