为了全面提升淘宝直播体验和互动能力，淘系技术团队联合阿里云经历三年时间打造了首个全链路RTC实时传输网。在时延、成本、抗弱网等指标均取得巨大提升。本次邀请到阿里巴巴淘系技术资深技术专家陈举锋老师（丰火），为我们介绍GRTN的技术演进路线及未来规划。
文 / 陈举锋（丰火）
整理 / LiveVideoStack
我从2016年开始做淘宝直播，在2017年也做了很多分享。从2016年启动到现在这几年内淘宝直播还是有了很多技术沉淀，记得2017年当时最早说的是在直播上行上通过RTC优化直播链路，这个方案当时在业界还比较少被谈到，因为当时大部分方案都是传统的上行走RTMP，下行走FLV，没记错的话我们应该是较早在直播上引入RTC的技术，当时来看淘宝直播在技术上还是具备一定的前瞻性。技术一直在进步，说明从2016年到现在RTC技术在直播的应用越来越广，研究也越来越深入。
从淘宝的经验来看，引入RTC技术后对整个淘宝直播的体验、核心的业务指标都带来很大的帮助。GRTN是淘宝直播和阿里云团队共建的RTC网络，我会分享GRTN在淘系内容业务上的落地和规划，也会介绍下GRTN的关键技术点。
#01 淘宝的业务数据
回顾淘宝直播以往的业务数据，2016年启动淘宝直播，到2020年双十一为止整个数据的增速非常惊人，这是一个从0到1的业务，刚启动时既没有业务基础也缺少技术储备，唯一有的是2016年淘宝直播在手淘首页的“爱逛街”有一个很小的版块，只有60万DAU，但较好的点是在主播供给有一些沉淀。实际在逛逛的业务之前，淘系在一些小的内容赛道上如有好货、必买清单上还是做了不少尝试。爱逛街也是其中一个典型例子，当然后面遇到了很多困难，DAU跌得比较厉害，在首页的位置也往下移。但在早期为淘系积累了一大批优质的内容生产者，达人、写手，这些积累为淘宝直播在最早启动时带来了帮助。
回到2016年的启动淘宝直播的时间点，早期对整个直播的业务模式定义很清楚，2016年市场并没有电商直播的概念，所谓的“百播大战”，其实大家提到的都是秀场、游戏、或是传统的YY直播厂商将直播平台移动化的产物，基本没有提到电商或“卖货”在直播场景中的模式。这里可以重点提一下，确实是淘宝直播定义了整个电商直播的标准——边看边买：主播讲、用户问问题、主播回答问题形成的购买链路，这其实是2016年淘宝直播的第一个版本上线后，这个核心的商业模式已经建立。后续我们做了很多工作，低时延、互动能力优化、在多媒体互动上大量的玩法，都是在模式边缘性的扩充和升级，本质并没有变，过去4年内的核心还是“边看边买”，并且非常好的将直播互动能力应用起来。在很长一段时间，整个淘宝直播的转换率仅次于“手猜”，对大部分人逛淘宝都是具备极强的目的性，很少逛“猜你喜欢”，大部分还是打开手淘搜索栏直接搜索。互动+电商直播对整个购买链路的转换率提升影响很大，这就是创新的力量。
整体数据基本是连年翻倍的增速，无论是直播间DAU、还是整个直播开播场次、成交规模在去年全年已经突破4000亿。
覆盖的内容形态上也发生了很多变化，早期典型场景是女装类和美妆类，但最近几年如珠宝、美食，包括村播各种形态都涌现出来，数据表现还不错，除了内容的多样化之外，成交规模上也有33个过亿的直播间（双11期间），整体呈现出非常健康的状态，这也是我们过去在生态多样性努力的成果。
在供给侧，开播链路也做了大量的简化。原来电商平台上较为复杂的开店、上新、认证安全机制导致淘宝直播在很长一段时间在开播、入驻、发送商品的整个流程会相当复杂，所以从业务方面去年在开播链路上做了极简：一键开播、一键入驻、一键上架，整个商家开播的场次、频次得到大幅提升。技术上，去年双11单个直播间同时在线人数突破200万，这是真实连接的同时在线（淘宝直播间的口径是严格意义上的真实在线，一定是长连接能够维持在播放态），在200万的真实在线中，单个直播间的播放时延在1.2s以内，更大的困难在于极低时延的同时要确保画面和消息的同步，要保证画面中上链接时，链接能够同时弹出来，这是很关键的。而且因为“抢到就是赚到”，目前直播间内的购买模式已经变成了强实时的“秒杀模式”，意味着推送的宝贝链接一定要第一时间与画面同步且最低时延推送给直播间的所有用户，才能够实现“看到就抢到”。这其实是规模所带来的最大技术挑战。
另外规模的上升如果没有编解码、码率层面的优化，会带来成本线性的增加。所以我们也做了基于H.265的全链路、包括H.266的预研。利用带宽95峰值计费的特性通过削峰填谷的手段做一些智能的调度，以达到两个目的：第一个是使峰值降下来。第二个是在峰值不变（总成本不变）的条件下，把日常码率提上去。
我的主题也会围绕以上几个方面展开。
#02 玩法介绍
大家平常看直播间时，除了观看之外，会给主播侧提供一些营销类能力包括抽奖、打赏、倒计时红包。我会从业务角度重点介绍“情景互动”。
其实在我们做整个直播间的实时内容理解之前，直播间的内容分发链路是很困难的，因为直播间具有强实时性，可能存在两个小时就结束了，意味着内容只有在两个小时内分发价值最大。比如在主播卖货结束后再进行分发，此时货已经没有了，分发的价值不大，只剩下简单的内容介绍价值。
第二个点是在直播的过程中，如何最大链路将分发价值发挥出来。分发网络的实时性是没有问题的，这是阿里巴巴集团最大的优势。困难是直播间内发生的事情无法预测，不像视频、图文，有大量已知的前置内容，在上线内容分发之前就有许多预处理可以将它做到结构化。但直播不一样，也是刚才所说的结合图像识别，语音信息甚至上下文信息将整个直播间内容做到结构化。最佳状态是主播正在卖连衣裙，而我们希望用户在主搜中搜索“连衣裙”时命中的就是主播此时介绍的连衣裙，现在也已经很接近这个状态了。
#03 技术架构
介绍一下我们的技术架构。
首先从层次上看，最底层的基础设施主要基于阿里云的多媒体体系，包括边缘推流、中心转码、时移、录制能力。第二点包括播放侧的分发机制，这是阿里云的技术应用。直播的一个比较大的不同点在于，淘宝直播在阿里云的基础之上建立自己的分法体系——RTC分发体系，这是有一个过程的，不是一步到位的，它们共同构成了淘宝直播底层基座。
直播开放平台层核心分成三方面，一方面分为两头。一头是生产侧，包括编解码体系、主播APP、前处理（美颜处理）、场景识别、端侧推流能力、上线的处理包括流控。另一头是观看侧，整个淘宝直播的房间应用了自研播放器，做了大量后置电路处理包括画面增强、自研的H.265软件解码器，值得一提的是淘宝直播间大概率是唯一一家实现了全链路H.265覆盖，意味着整个链路没有转码（生产、推流、分发侧、播放侧）完全支持全链路H.265，而且覆盖比例非常高。有同学疑惑软解H.265在端侧实现的难度，解决了这个问题也就解决了整个H.265在端侧解码的覆盖，结合硬解链路做到极大的提升，也会节约很多转码成本。
在流媒体链路之上，分装了整个直播间直播业务领域模型的概念，比如流状态、互动能力、商品管理能力、弹幕、营销型玩法。我们分装了整体的一套API支撑核心业务。
直播底层最核心的两个传输链路：一个是流媒体链路，另一个是消息点链路。消息点链路是整个评论消息和营销型类玩法怎么和流媒体链路同时向下做分发、同步。这是我们核心的几个技术点。
#04 技术演进
直播在过去几年除了基础性优化，最大的底层改造是从传统基于CDN的中心化分发机制转化为去中心化网络上。我们先介绍一下原始网络特点及问题。
首先在第一个阶段（上方左图），是迄今为止大部分直播厂商所用的最典型方案。大家基于CDN最传统的中心分发网络，主要以FLV文件为主。这样的好处是一方面对整个CDN改造低，其二是无论是RTMP还是FLV，在两端业务方面支持是最完备的。而且底层协议流控方面，都走TCP，不需要做太多优化改造，是最快从0到1直播业务构建体系，但这个模式存在的问题是什么？虽然这个模式很快，包括淘宝直播第一期也是这样做的，但是整个链路一定会从L1到L2到中心节点，存在回源机制，这是不可避免的。因为这是静态的结构，不存在任何动态感知能力，会带来大量回源成本和时延问题。时延问题一方面与回源有关系，也与整个流控协议缺少更精细力度的控制有关系，RTMP和端侧的FLV是典型的TCP底层协议，在业务上能优化的点有限，调调本地的Cache，L1缓存的GOP大小，手段有限，会带来很多额外的成本。
我们在淘宝直播发现了这种体系下更为严重的一个点，淘宝直播的主播相对秀场、游戏等比较分散。秀场上热门主播是比较集中的状态，可能占了头部整个流量的60%甚至80%，这样它的中心化分发可以将成本摊平，而淘宝大部分主播在线处于平均水位线以下，和头部差别很大，但这一部分用户占了绝大多数。刚刚中心化机制主要解决热点集中的问题，但在淘宝直播中，100万的在线人数可能分布在上万个直播间中，所以这个机制会进一步放大成本高的问题。
以上就是为什么会演化出淘宝会向GRTN去中心化方式走，这里有一个形成过程。
第一个阶段起源于一个很简单的问题，当时通过线上数据分析，绝大多数在播放侧引发的卡顿大多是因为上行网络的抖动，基本上在第一跳（主播的RTMP到L1节点之间的波动引发了大多数卡顿），但在当时情况下无法对链路重新做优化，很典型的设计机制是我们在与L1同级的节点中部署了淘宝直播自己的上升节点，与主播走的是私有的RTC协议，从RTC协议节点上直推到L1，中间走的是同一个地方，走专线或者GRTN，也就是最前面的一公里用私有协议走掉，这是第一步的RTC。
第二步先走的下行，就是主播的下行和下行的L1节点之间，把它改造成了RTC。改造后的效果比较好，但这里的效果更多的是解决卡顿问题。基于WebRTC的上行，整个RTMP上行改造之后对卡顿的优化非常明显，卡顿降了接近1/3，尤其在弱网场景以及海外推流场景下表现非常突出。但是后面经过时延统计，两头编解码大概在60ms，整个发送在不到100ms，播放侧也类似，核心在整个分发链路时延占的最多。所以说两头问题解决的话可以解决卡顿问题，但并不能解决时延的问题，这就回到了如何真正做到全链路RTC。
这不是业务型决策，中间的整个分发机制一定要跟整个CDN的原来的技术贴近。因为原来的CDN分发机制并不是流媒体的分发网络，它本质是文件的分发网络。那么如何改造它，我们联合了多个团队，最终完成了GRTN全链路RTC的升级。这里带来的优势几乎基本可以解决前面的问题，一方面它是完全去中心化不存在任何回源的逻辑，对一些区域非常接近的房室的话，利用整个动态路由的策略，完全可以不经过中心的浪费。
全链路的RTC带来的好处是节点和节点之间的感知以及传输做到更细密度的控制，甚至是一些针对流媒体传输的特殊性。流媒体传输中有些包可以丢，策略上面可以做一些更细力度的控制，不一定是可靠到达；在提出多网融合之前，我们在整个直播、视频会议、连麦场景等很多时候其实走的是独立的通道，播放的时候可能走FLV，用户之间连麦用RTC。
目前为止大部分在线教育厂商因为成本问题还是采用的这个策略，但是如果完成了整个RTC全链路网络，任何一个节点都可以做上行或下行，同时下行直播链路和它成为双向的通话场景本质上没有任何区别，这意味着我们可以在同一个通道完成连麦和直播播放场景。当然视频会议在整个外围系统增加了MCU或SIP网关中其实也是类似，也就是说在直播、连麦、视频会议和点对点通话做到了四网合一。今天来说这个方向得到了普遍意义的认可。
成本上面包括回源成本、链路过长的成本都会得到解决，全双工和多网融合是一个概念，同时具备上行和下行的逻辑。
以上基本是网络演进的一个过程。
#05 低延时直播
回到刚刚提到的直播间里主播上链接的机制，本质上包括几个问题：
消息到达率：消息超过百万级在线的话其实跟原来几千几万在线分发所面对的困难完全不是一个技术体系。做法上除了对原来的Push模式大量的改造，包括分统机制、饱和机制，这里最大的技术改造是把消息做到分层，包括主播推送给用户的消息，这个到达率及对业务的价值我们认为是最大的。这类采用Push消息，把原来的进出直播间、评论、扩散的消息更多在CDN静态化。最终其实是把整个消息机制做成了推拉结合机制，把整个5s消息到达率做到高于三个9，大概是3s的三个9。
单纯的消息稳定到达率及时效性，它如果不能和画面的到达率结合起来，效果是不能发挥出来的（上链接之后，画面要更短时间看到，同时抢宝贝的链接在主播侧尽可能短的看到并且时延要缩短，这里一方面依赖消息链路的改造，一方面依赖整个GRTN低时延传输之外，两者的同步方面主要是基于帧的染色，目前走的SEI，或者是特殊帧的附加信息保证两者同步，关键在于同步的时间窗要尽可能小；上链接过大的话，极有可能是画面到了，用户通过提前画面的截选把链接解出来），这也是需要关注的点。2018年，有一个场景是“点题成金”-冲关答题分奖金，即使这种技术在“点题成金”模式下会更为迫切，但画面和题目一定要高度一致，这就是直播和消息的强同步。
依赖于整个RTC的全链路，时延基本可以做到小于1s，这是一个均值，在一些更为非盲情况下，时延可以做到更低。
#06 淘宝直播连麦
双通道带来的优势是RTC通道可以同时承接直播推流与连麦，再借助于外围系统的配套，视频会议也可以承接（MCU），这也是我们正在做的方向，希望四个场景（直播、通话、视频会议、连麦）各有一个真实的业务能够承接起来，并具有一定的规模。
淘宝目前的端合流与云合流分别有一个演进阶段，但最终走向了融和型。因为端合流会带来成本上的优势，但云合流在调度和扩展性更有优势，所以两种方向我们都做了支持。演进的路径上基本也是从早期的RTMP支持连麦的时候，后面因为上行和下行RTMP的阶段化，已经有了融和态，最后走了全链路RTC彻底解决了直播连麦通道上不统一的问题。
#07 GRTN动态路径规划
GRTN的动态路径规划中有几个重点。
一个是动态路由规划，这里核心是每一个节点对任一个节点的到达路径都是可感知的，有很多衡量的指标，比如任何两个节点之间的丢包率、时延、抖动、容量、成本都有动态预估。因为中间整个网络会持续发送探测包把信息记录下来，所以节点1方面它对自己可连接的节点到任意一个节点的路由都是有动态的策略表并记录的。根据策略方式，有些质量最优，那在丢包、时延、抖动方面有权重的设计，保证它一定处于最低时延及最小卡顿率下传输；另一种成本最优，可能中间的链路比较长，走的节点成本消耗不同，有些走专线，有些走LTN，会产生成本的不同，这块也会计算成本还是质量最优。
目前GRTN真正在线上跑的版本还是融合了各种策略，典型的一个例子如果是RTC通话连麦场景，它对时延也就是质量要求最高，卡顿要求最低，这就会选择质量最优的策略。所以这块也会根据不同场景做一些设计。
#08 参数自学习
在整个网络上面，很多参数是此消彼长的（卡顿和时延），但这只是最终的表现。如果在细粒度，如编码侧、解码侧、端侧的缓存设置上面，整个系统目前有超过400个参数，这些参数的最优解是什么，在收敛过程中很难确定也很难证实。
所以我们做了参数自学习的方式，前期有人工剪枝，之后利用线上大量的AP系统对400个参数的收敛做了非常快的设计。纯粹通过参数优化方式带来收益，在底层机制不变的条件下纯粹的参数优化已经对卡顿和时延带来明显的优势。
#09 游戏玩法
去年我们做了大量了基于玩法型的优化，包括营销类优化（抽奖、发红包）和社区互动型玩法或游戏类玩法，可以拉近主播和用户之间的连接（如：抖音前段时间的潜水艇），既有乐趣也有内容的产出。但这个模式在之前没有很好的应用在直播中，会遇到几个问题：
首先，用到大量端侧推理模型，在手淘无论是MN还是端侧的网络小样本训练都没有完全跟上。今年基本可以做到和业界对齐。
其次，有很多探索靠单纯端侧的算力无法满足。比如3D直播间、虚拟主播技术，对一些算力的诉求是综合的单纯放在端上是不现实的，如何用更好的方案一方面把端侧和云端的算力一致化运用起来，去除差异。本质上来说，前处理的模式就识别或是画面特效配合，在端侧或云侧处理对于用户侧和主播侧是无感知的。举个例子，比如人脸识别或是特效识别，我们既可以把这个模型放在主播侧推优之前，完全用主播侧APP或PC处理，也可以完全放在GRTN的某个节点处理完成后通过实时回显链路放到主播侧APP上。所以对主播来说，如果可以解决时延的问题，回显来自本地还是云端是没有任何区别的。解决如何充分灵活地调动云端算力，并结合GRTN实时回显链路解决直播的流内互动玩法问题是我们的根本目的。
简单介绍一下，上图中的几个玩法。第二个“打年兽”，主播通过人脸控制屏幕下方炮台的左右移动，打上方小蜜蜂，通过人脸输入控制道具。游戏基于两种机制，人脸的识别、流的处理、渲染和最终合成完全是一个端上的版本，同时我们也做了云端的版本。
3D直播间，人员站在绿幕前，后面的场景是3D数字直播间，通过抠图、合成方式做成。在3D场景下，完全放在端侧不现实，没有很好的算力，它和后面的3D场景完全不交互，但做到完全的3D化后，可以和场景中的元素交互，解决直播间里的远程机样的问题。
#10 多媒体处理中心
整个的设计模式上述介绍的差不多，最重要的的几点是把前置的能力作为GRTN的算子挂接上去，还可以挂在端上调度的系统上。另外GRTN整个实时回显模式也做到了云端一体化设计。
#11 智能控制
最后一部分的核心是针对目前带宽的水位或是业务数据上的策略，对于整个线上码率、根据更细粒度人群的投放，我们做整个成本和画质的平衡，在双11期间发挥了很好的作用，晚上可以做到分装级降码率，还会自动根据线上的变化提升整个画质。