共计 5862 个字符，预计需要花费 15 分钟才能阅读完成。
直播已深刻每家每户，以淘宝的直播为例，在粉丝与主播的连麦互动中如何实现无感合屏或切屏？阿里云 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 优化实际》演讲全文。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。
