共计 5973 个字符，预计需要花费 15 分钟才能阅读完成。
直播已深刻每家每户，以淘宝的直播为例，在粉丝与主播的连麦互动中如何实现无感合屏或切屏？LiveVideoStackCon 2022 音视频技术大会上海站邀请到了阿里云 GRTN 核心网技术负责人肖凯，为咱们分享 GRTN 核心网的运作机制、使用方面以及 QOE 的网络模型在业务板块的实际优化。
大家好，欢送大家来到 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 的一个优化。
在这个根底上就实现了第一轮的迭代，咱们认为这个路线是对的。接下来就是在这条路线上，怎么把参数进一步的调优。在最开始对发帧的策略进行调整之后，咱们只是做了一个粗调，感觉大略能够补救客户端的某些缺点。实现了之后，接下来做进一步的不同的配置，不同的参数之间去做调优。
以上就是我的分享，谢谢大家。
更多边缘云产品动静欢送关注公众号【阿里云 Edge Plus】