直播已深入每家每户，以淘宝的直播为例，在粉丝与主播的连麦互动中如何实现无感合屏或切屏？LiveVideoStackCon 2022 音视频技术大会上海站邀请到了阿里云 GRTN 核心网技术负责人肖凯，为我们分享 GRTN 核心网的运作机制、运用方面以及 QOE 的网络模型在业务板块的实践优化。
文 / 肖凯
整理 / LiveVideoStack
大家好，欢迎大家来到 LiveVideoStackCon 2022 音视频技术大会上海站，我是来自阿里云的肖凯，现在负责阿里云的 GRTN 的传输引擎的开发以及组网架构。今天讲解主要分两个版块，一方面简单介绍一下 GRTN 的理念和提供的能力。另一块就是阿里云的 GRTN 在接待客户的过程中，是怎样去优化 QOE 的指标。
今天的分享主要分为几块：GRTN 简介、阿里云做 QoE 的优化经验、赛马系统、和阿里云的一些可编程的能力。
1、GRTN 简介
GRTN 实际上现在是一张全 SFU 的网络，我是从 15 年开始做直播这一块，伴随阿里云直播系统一路做到现在的通信级的传输分发网络。
现在的阿里云的 GRTN 基于覆盖全球的 2800 多个边缘节点，我们把这些节点和网络资源运用起来，做成了一张通信级的 SFU 的传输网络。
这些节点，包括解决跨洲的网络问题，都有专门的线路，整个系统都是从直播演进过来，过去很多的 CDN 直播网络一般都是树状的结构。但阿里云的 GRTN 是一张树状和网状结合的动态网络，目前阿里云 GRTN 支撑的屏到屏延迟是 100 毫秒左右，满足云游戏或者云渲染这样的场景。
GRTN 的能力很简单，它提供的是内容的传输和分发。任何一个用户使用 RTP 协议，把媒体推到阿里云 GRTN 的节点，它就可以在全球的任何地方就近地从 GRTN 把内容拉出去，GRTN 会解决动态组网、就近接入等问题。
2、GRTN 当前业务模式
GRTN 的当前的业务模式，目前很多客户接的都是阿里云的 RTS 1.0，即在阿里云官网能够看到的 RTS 业务。
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 支持多人会议，如图所示，这里有 4 个参会方，这里会讲解多人会议在 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 在 RTS  2.0 上的一个典型的场景。
3、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（最后会有一个数据的展示）。
4、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 结果。
5、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 的日志系统打通，做到相互配合。
6、GRTN QOE 优化案例
这是 GRTN 的一个优化样例，也就是赛马系统的评分。当时我们做实验有 4 组，normal 就是平时日常运行常量的配置，radical 就是一组非常激进的配置，reference 就是用来跟 radical 进行对比的参照。如图做了一个六维的展示，也按照我们的想法对它进行了综合打分。
更详细的结果是这个表，刚才提到的 conf_id 配下去之后，运行完之后，接下来得到成功率、秒开这样的一些数据。这就是 GRTN 目前展示出来的赛马系统能够看到的数据。
成功率、秒开、都属于 QOS 的范畴，最后的平均播放时长，是属于 QOE 的范畴。我们测试下来得到的 radical 这一组的数据是最好的，它在播放时长上可能有 1 秒钟左右的优势，积累了 24 小时的数据，大概几十万的量级，我们认为这个量级的播放是可以用于支撑 AB 的数据。GRTN 最开始在手淘场景做这个系统，手淘的业务量比较大的，所以我们从一开始拿手淘的线上的全部量级去运行。现在是直接可以拿外部客户的数据去运行，做成赛马系统，将阿里云可编程的能力，客户端的数据采集，包括赛马，做成一个闭环。
现在优化的方法，想要优化某种策略，就发一组配置下去。例如发一组配置，运行一个晚高峰，到了第二天就能拿到数据结果，这样的一个过程实际上对迭代的优势是非常大的。
例如今年 3 月份左右，我们给某个客户在调优播放时长的时候，通过分析客户端的一些行为，包括通过测试对数据进行分析，发现客户的音视频同步可能有点问题。怎么去解决这个问题呢？我们认为通过服务端的发帧策略的调整能够帮助客户端更好地实现音视频同步。我们用可编程把这个策略做好发出去，在第二天这个效果是非常好的。我们发现发下去之后，这组配置的观众播放时长升高了，这其实就是 QOE 的一个优化。
在这个基础上就完成了第一轮的迭代，我们认为这个路线是对的。接下来就是在这条路线上，怎么把参数进一步的调优。在最开始对发帧的策略进行调整之后，我们只是做了一个粗调，觉得大概可以弥补客户端的某些缺陷。实现了之后，接下来做进一步的不同的配置，不同的参数之间去做调优。