直播已深刻每家每户，以淘宝的直播为例，在粉丝与主播的连麦互动中如何实现无感合屏或切屏？阿里云GRTN核心网技术负责人肖凯，在LVS2022上海站为咱们分享了GRTN核心网的运作机制、使用方面以及QOE的网络模型在业务板块的实际优化。

阿里云寰球实时传输网络GRTN
GRTN是阿里云全球化的实时通信网，构建在核心云原生和边缘云原生的基础设施之上，并将技术有机交融，借鉴 SDN 的设计理念，进行 CD 拆散，将管制放在核心，将数据面散布下沉到阿里云边缘云 2800 多个节点之上。GRTN具备场景化的 QOS 能力、400 毫秒以内的实时通信能力和超低延时能力，同时具备了全链路的 RTC 和动静组网能力。GRTN提供一体化解决方案，不仅反对视频上云，视频散发的流媒体个性，同时具备分布式计算、分布式存储解决能力。

本次分享围绕GRTN分为两个局部：

  • GRTN的理念和提供的能力。
  • GRTN在商业落地中，怎么优化QOE的指标。

GRTN的理念

简略来说，当初的阿里云的GRTN基于笼罩寰球的2800多个边缘节点，咱们把这些节点和网络资源使用起来，做成了一张通信级的SFU的传输网络。

这些节点，包含解决跨洲的网络问题，都有专门的线路，整个零碎都是从直播演进过去，过来很多的CDN直播网络个别都是树状的构造。但阿里云的GRTN是一张树状和网状联合的动静网络，目前阿里云GRTN反对的屏到屏提早是100毫秒左右，满足云游戏或者云渲染等场景。

GRTN提供的是内容的传输和散发，任何一个用户应用RTP协定，把媒体推到阿里云GRTN的节点，它就能够在寰球的任何中央就近地从GRTN将内容散发。同时，GRTN还会解决动静组网、就近接入等问题。

GRTN业务模式

GRTN以后的业务模式，是目前很多客户接入的阿里云的RTS 1.0。

RTS 1.0是阿里云从18年左右开始研发的，它的核心理念是为了帮忙客户在无限革新的前提下，接入GRTN，把提早降下去。

传统的直播FLV提早大略在5秒， HLS更多，提早达到20s左右。RTS就是对推流侧或者播放侧进行革新，最重要的还是播放侧协定换成RTP，可能做到提早在1秒左右，这个技术在19年左右淘宝直播就已全量落地。

RTS 1.0之后，阿里云就进入到了RTS 2.0的时代。

在RTS 2.0时代，咱们对实时流媒体场景的预期是没有RTC和直播的辨别，能够让所有的业务都建设在全链路RTP的协定上。全链路应用通信级的传输，是GRTN的技术理念。目前的RTS 2.0，它具备通信级的服务能力。

RTS 2.0的传输提早在国内根本是在100毫秒左右，即为节点的传输耗时，剩下的提早就能够放在编码侧或者放在播放侧，用来抗抖动。这样的场景可用于一对一的视频通信、多人会议包含连麦直播一体化。

那在GRTN上怎么把一对一通信做进去呢？

阿里云GRTN的对外服务包含两种模式：一对一通信和多人会议。

一对一通信

第一种是阿里云的SDK，通过应用GRTN的公有协定，同时也反对浏览器，所以GRTN的生态是齐全凋谢。用户能够应用浏览器，以规范的SDP信令交互的形式与GRTN的对接，把媒体推动来，再通过GRTN选择性地把媒体拉出去。两个客户端跟GRTN能够抉择通过单PC或者多PC的模式替换音频、视频或自定义的音讯，通过GRTN实现通信级的传输，这就是一对一通信。

这个模型并不仅限于通信，还可用于云渲染，云游戏。

多人会议

在一对一通信的根底上，GRTN反对多人会议，如上图所示。

通常而言，在参会人比拟多的时候，选择性的订阅对端的视频、音频是一个很麻烦的问题，因为波及到Audio Ranking。很多业务方为了做这种多人会议，不得不把音频放到一个专门的Ranking Server下来做。

而GRTN提供了大规模的Audio Ranking能力，也就是说任何一个端在GRTN上生产音频，都能够做到为它进行Audio Ranking。这个人订阅了什么，GRTN就在这个人订阅的音频中进行Audio Ranking，不波及Ranking server, 不减少提早。

GRTN的另一个重要能力是切流。GRTN能够为任何观众实现他的媒体替换，在云合流的连麦场景，这是一个很外围的能力。在一个浏览器上，观众通过GRTN看到的画面，通过切流的指令，能够让这个观众在齐全无感的状况下实现画面的切换。

这就是GRTN的切流能力，能够为GRTN上某一个主播的所有观众实现媒体画面的实时切换，能够从a画面切到b画面，从a主播切到b主播，观众是齐全无感的。

如何用切流能力实现云端连麦合流？

在连麦这个场景上，如果是客户端的连麦，那就是ab两个主播进行连麦，观众在看a主播的过程中他们一连麦，观众看的画面就实时变成了a和b合屏的画面。这种场景可能简略的实现，通过端合流，即a主播在端上间接把本人的画面更改，观众看的内容相应进行变动。然而存在一些场景端合流是无奈做到的，例如端的性能不够，这样场景下就须要通过云合流。

如上图所示，一个主播流的画面推送到GRTN之后，有一个观众在看主播的画面，当这个主播和别的粉丝产生了连麦，连麦之后有一个业务方的合屏服务器，合屏服务器会把两个媒体合成一个。

在这个时候就须要实现客户端的画面切换，而且全副都要切过去，这个时候咱们提供的能力是切流指令，即后面所讲的切流的能力。切流指令传输到GRTN之后，GRTN将主播所有观众的画面无感地切换成合屏流的画面。

这个能力目前是实现淘宝直播在GRTN上直播连麦齐全一体化的根底解决方案。

并且，这是一个通用的计划，在前面随着GRTN和后续RTS 2.0服务的对外输入，这个能力会间接对外开放。

目前淘宝直播实际上曾经实现全量通过GRTN进行，任何一场直播里观众和主播之间的提早，基本上都在1秒以内的。这是目前GRTN在RTS2.0上的典型业务场景。

QOE概述及优化难点

QOE的优化实际上是基于阿里云的内部客户的数据，为什么讲QOE而不是QOS？

因为咱们在接待客户的过程中发现，QOE通常都是客户自身制订的一系列的指标，比如说渗透率、观播时长、业务转换率，这些指标不是把QOS某个指标做好了，QOE就能变好。

例如GRTN在客户场景中，咱们的首帧卡顿、百秒卡登时长、提早、画质全方位的当先。（RTS的QOS肯定是全方位的比FLV好，也就不必比HLS了。）

但在面对不同的客户的时，有的客户的QOE正了，有的客户的QOE有问题，因在客户从传统的FLV过渡到RTS以及RTS 2.0之后，会因为客户端的适配没有做好，或者业务场景的磨合没有做好，遇到了问题。

例如WebRTC来进行通信，播放器的buffer的机制能够做得十分的激进，然而在直播场景时，观众的体验可能比你的激进的提早管制更加重要，所以在直播场景下更多的是要去做一个均衡。

在这个过程中，咱们发现有时客户把QOS全做正了，然而QOE却还须要花很多的工夫去解决，所以在把QOE做正的过程中，要用什么办法？

这是在QOE里阿里云要继续投入的。想要做好QOE肯定要有业务输出，没有业务的输出，没有业务的反馈，QOE必定是做不正的，所以阿里云有继续的基于业务的数据驱动技术投入。

这里最重要的一点是客户端的数据，在做QOE的过程中，咱们认为服务端是没有资格说QOE的，只有客户端和业务才有资格说本人的QOE这么正。所以在这个过程中，GRTN的办法是先失去业务方的脱敏数据，而后去做QOE。

GRTN QOE 优化理念

GRTN优化QOE的一个理念是：GRTN做到了无感的链路切换。

GRTN外部是一个全SFU网络，上游的网络随时切换，对观众来说是齐全无感的。同时还有强实时的主备链路，在很多直播、通信场景下，会有重保的概念，或是强实时的双路保障。如果节点之间呈现问题，可能立马把它切到另外的节点链路上，这样观众齐全无感。

还有GRTN节点和客户端之间的mobility的计划，例如某个节点可能网络有问题，或者客户端的网络产生了WiFi到4G的切换，那么应用一个mobility的计划霎时可能切换节点，同时GRTN的上游消费者齐全不受影响。

GRTN另一个优化QOE的办法，就是可编程策略。

可编程实际上是阿里云近一年做进去的成绩。传统的QOS优化能力，例如启用BBR还是启用GCC或者是别的拥塞控制算法，会发一堆的配置上来，配置外面全是开关。

然而当初的GRTN，能够在边缘间接用可编程的策略执行模块，相似CDN有可编程的能力，包含边缘脚本之类，GRTN也相似，然而做的比拟彻底。当初的能力是能够在节点间接下发策略，运行语言，能够间接对发帧和发包逻辑做管制，能够染指到重传逻辑中，间接编程GRTN的对每一个客户端的行为，即通过策略配置零碎间接把代码发下来，无需软件发版降级。

因为像2800多个节点，是无奈高频降级软件版本的，然而利用GRTN可编程能力能够实现一天几个策略迭代，联合客户端的数据，可能实现数据的买通。这样发策略下来，客户端拿到QOE的数据反馈给GRTN，GRTN的调优人员就晓得如何去进一步的优化。

如图是GRTN的多场景的随机配置，也是基于阿里云线上海量的业务数据来进行的。

例如阿里云线上的配置管理系统会把配置集下发，这是做AB的根底能力。前面配置管理系统会将n组配置实时发到全网所有的边缘节点，针对的是某一个域名。

针对这个域名，同时给他收回三组配置上来进行随机，可能会配肯定的权重。例如阿里云认为conf_1 是个高风险的配置，一个高风险的新型的性能，收回去之后，把conf_1指配全网1%的业务量去做 AB。发到节点之后，当任何一个消费者来到GRTN生产内容时，将对它进行一个随机加权的抉择，它有肯定的概率应用conf_1，也有肯定的概率应用前面两种。

第一步的申请实现之后，咱们让多组配置同时在线上运行，然而运行完后怎么拿到后果呢？

简略的办法就是客户记录咱们的trace_id，GRTN有一个trace_id的理念，这个ID对应客户端的这一次播放，任何两次播放的ID都不一样。

另一种办法是客户端把一个session ID带在它的申请参数外面，这样一个客户端就在GRTN有一个session ID跟trace_id对应，这次播放用的什么conf ，咱们也可能给它记录到。同时这次播放，依据session ID，咱们就能够从客户端的埋点查到它的QOE后果。

GRTN 赛马零碎

接下来对它做关联，播放器在GRTN上实现播放之后，播放器这边开始埋日志，埋的外围日志就包含首帧耗时、百秒渲染卡顿，也包含任何一个播放端的播放时长。

在业务方记下来的日志中，会晓得session id对应的这一次播放播了多久，它的各项指标怎么。在GRTN就晓得发的trace_id是哪个，而后针对这一次播放，缓冲深度配了多少，以及丢包率目前统计下来是什么状况。

这两个数据（服务端日志和客户端日志）把客户的日志收上来，抛送给咱们之后，这边就把session ID和trace_id在GRTN的数据分析体系外面做一个综合，就失去了一个后果：任何一次播放它对应的服务端的网络状况是什么，它对应的客户端的首帧耗时、百秒渲染卡顿、播放时长是什么。GRTN就通过这两种数据综合把客户端的数据和服务端的一个行为做到了关联。

关联做到之后，下一步就做赛马零碎。

在任何一次配置的时候，就像当初阿里云给客户做调优的时候，咱们会当时与客户沟通调优。

例如说在这样一次配置中，以客户线上的业务为例，conf_1是一个高风险的性能，conf_2是对现有性能比方BBR的参数的调优，conf_3启用的可能是GCC。把配置发到节点，客户在进行播放之后，针对上两步把他的客户端和服务端的数据拿到之后，采集到GRTN这边，数据上传来之后，再对AB的后果做一个综合的剖析。

这个时候在研发人员的眼里就曾经明确的晓得下发的各组配置它的成果到底如何，区别是什么。研发调优人员就可能晓得怎么去做进一步的调优，同时反馈哪一组配置能够被淘汰，再基于好的配置对它进行进一步的调优。所以这也就是赛马零碎的价值——可能基于客户端的数据和服务端的数据进行综合的继续的迭代。

如图是赛马零碎，它作为一个整体，有GRTN的节点网，服务客户端上报数据和GRTN的日志零碎买通，做到相互配合。

GRTN QOE 优化案例

这是GRTN的一个优化样例，也就是赛马零碎的评分。

过后咱们做试验有4组，normal就是平时日常运行常量的配置，radical就是一组十分激进的配置，reference就是用来跟radical进行比照的参照。如图做了一个六维的展现，也依照咱们的想法对它进行了综合打分。

更具体的后果是上表，方才提到的conf_id配上来之后，运行完之后，接下来失去成功率、秒开这样的一些数据。这就是GRTN目前展现进去的赛马零碎可能看到的数据。

成功率、秒开，都属于QOS的领域，最初的均匀播放时长，是属于QOE的领域。

咱们测试下来失去的radical这一组的数据是最好的，它在播放时长上可能有1秒钟左右的劣势，积攒了24小时的数据，大略几十万的量级，咱们认为这个量级的播放是能够用于撑持AB的数据。GRTN最开始在手淘场景做这个零碎，手淘的业务量比拟大的，所以咱们从最开始通过手淘的线上的全副量级去运行。当初是间接能够通过内部客户的数据去运行，做成赛马零碎，将阿里云可编程的能力，客户端的数据采集，包含赛马，做成闭环。

当初优化的办法，想要优化某种策略，需发一组配置上来。例如发一组配置，运行一个晚顶峰，到第二天就能拿到数据后果，这样的过程实际上对迭代的劣势是十分大。

例如往年3月份，咱们给某个客户在调优播放时长的时候，通过剖析客户端的一些行为，包含通过测试对数据进行剖析，发现客户的音视频同步可能有点问题。怎么去解决这个问题呢？

咱们认为通过服务端的发帧策略的调整可能帮忙客户端更好地实现音视频同步。咱们用可编程把这个策略做好收回去，在第二天这个成果十分好。咱们发现发下去之后，这组配置的观众播放时长升高了，这就是QOE的优化。

在这个根底上就实现了第一轮的迭代，咱们认为这个路线是对的。接下来就是在这条路线上，怎么把参数进一步的调优。

以上整顿自LVS2022《从阿里云寰球实时传输网络GRTN登程，浅谈QOE优化实际》演讲全文。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。