阿里云全球?qū)崟r(shí)傳輸網(wǎng)絡(luò)GRTN—QOE優(yōu)化實(shí)踐

GRTN的當(dāng)前的業(yè)務(wù)模式，目前很多客戶接的都是阿里云的RTS 1.0，即在阿里云官網(wǎng)能夠看到的RTS業(yè)務(wù)。

RTS 1.0是阿里云從18年左右開始研發(fā)的，它的核心理念是為了幫助客戶在有限改造的前提下，接入GRTN，把延遲降下去。傳統(tǒng)的直播FLV延遲大概在5秒， HLS更多，延遲達(dá)到20s 左右。RTS就是對推流側(cè)或者播放側(cè)進(jìn)行改造，最重要的還是播放側(cè)協(xié)議換成RTP，能夠做到延遲在1秒左右，這個(gè)技術(shù)在19年左右淘寶直播已經(jīng)全量落地。

RTS 1.0結(jié)束之后，阿里云就進(jìn)入到了RTS 2.0的時(shí)代。RTS 2.0里，我們對實(shí)時(shí)流媒體這個(gè)場景的預(yù)期是沒有RTC和直播的區(qū)分，可以讓所有的業(yè)務(wù)都建立在全鏈路RTP的協(xié)議上。全鏈路使用通信級的傳輸，是GRTN的技術(shù)理念。目前的RTS 2.0，它是具有通信級的服務(wù)能力的。

RTS 2.0的傳輸延遲在國內(nèi)基本是在100毫秒左右，即為節(jié)點(diǎn)的傳輸耗時(shí)，剩下的延遲就可以放在編碼側(cè)或者放在播放側(cè)，用來抗抖動。這樣的場景一般用在一對一的通視頻通信，或者多人會議，包括連麥直播一體化。

那在GRTN上怎么把一對一通信做出來呢？

阿里云GRTN的對外服務(wù)包括兩種模式，一種是阿里云的SDK，通過使用GRTN的私有協(xié)議，另一方面，阿里云也支持瀏覽器，GRTN的生態(tài)是完全開放。用戶可以使用瀏覽器，以標(biāo)準(zhǔn)的SDP信令交互的方式與GRTN的對接，把媒體推進(jìn)來，再通過GRTN選擇性地把媒體拉出去。兩個(gè)客戶端跟GRTN可以選擇通過單PC或者多PC的模式交換音頻、視頻或自定義的消息，通過GRTN實(shí)現(xiàn)通信級的傳輸，這就是一對一通信。

這個(gè)模型并不僅限于通信，還包括云渲染，云游戲的模型。

在一對一通信的基礎(chǔ)上，GRTN支持多人會議，如圖所示，這里有4個(gè)參會方，這里會講解多人會議在GRTN上需要怎樣的能力。

在參會人比較多的時(shí)候，通常而言選擇性的訂閱對端的視頻、音頻是一個(gè)很麻煩的問題，因?yàn)樯婕暗紸udio Ranking。很多業(yè)務(wù)方為了做這種多人會議，不得不把音頻放到一個(gè)專門的Ranking Server上去做。GRTN提供了大規(guī)模的Audio Ranking能力，也就是說任何一個(gè)端在GRTN上消費(fèi)音頻，都可以做到為它進(jìn)行Audio Ranking。這個(gè)人訂閱了什么，GRTN就在這個(gè)人訂閱的音頻中進(jìn)行Audio Ranking，不涉及Ranking server, 不增加延遲。

GRTN的另一個(gè)重要能力是切流。GRTN可以為任何觀眾實(shí)現(xiàn)他的媒體的替換，在云合流的連麥場景，這是一個(gè)很核心的能力，在一個(gè)瀏覽器上，觀眾通過GRTN在看一個(gè)人的畫面，然后通過切流的指令，就讓這個(gè)觀眾在完全無感的情況下實(shí)現(xiàn)畫面的切換。

這就是GRTN的切流能力，這個(gè)能力可以為GRTN上某一個(gè)主播的所有觀眾實(shí)現(xiàn)媒體畫面的實(shí)時(shí)切換，可以從a畫面切到b畫面，從a主播切到b主播，觀眾是完全無感的。

接下來我們看如何用切流能力實(shí)現(xiàn)云端連麥合流？在連麥這個(gè)場景上，如果是客戶端的連麥，那就是ab兩個(gè)主播進(jìn)行連麥，觀眾在看a主播的過程中他們一連麥，觀眾看的畫面就實(shí)時(shí)變成了a和b合屏的畫面。這種場景能夠簡單的實(shí)現(xiàn)，通過端合流，即a主播在端上直接把自己的畫面更改，觀眾看的內(nèi)容相應(yīng)進(jìn)行變化。但是存在一些場景端合流是無法做到的，例如端的性能不夠，這樣場景下就需要通過云合流。

如圖所示，一個(gè)主播流的畫面推送到GRTN之后，有一個(gè)觀眾在看主播的畫面，當(dāng)這個(gè)主播和別的粉絲發(fā)生了連麥，連麥之后有一個(gè)業(yè)務(wù)方的合屏服務(wù)器，合屏服務(wù)器會把兩個(gè)媒體合成一個(gè)。在這個(gè)時(shí)候就需要實(shí)現(xiàn)客戶端的畫面切換，而且全部都要切過去，這個(gè)時(shí)候我們提供的能力是切流指令，即前面所講的切流的能力。切流指令傳輸?shù)紾RTN之后，GRTN將主播所有觀眾的畫面無感地切換成合屏流的畫面。

這個(gè)能力目前是實(shí)現(xiàn)淘寶直播在GRTN上直播連麥完全一體化的基礎(chǔ)解決方案。

這是一個(gè)通用的方案，在后面隨著GRTN和后續(xù)RTS 2.0服務(wù)的對外輸出，這個(gè)能力會直接對外開放。

在這里和大家簡單介紹一下淘寶直播的情況，淘寶直播實(shí)際上已經(jīng)實(shí)現(xiàn)全量在通過GRTN進(jìn)行，任何一場直播里觀眾和主播之間的延遲基本上都在1秒以內(nèi)的。這個(gè)目前是GRTN在 RTS  2.0上的一個(gè)典型的場景。

QOE的一些優(yōu)化實(shí)際上就是基于阿里云的外部客戶的數(shù)據(jù)，為什么講QOE而不是QOS？因?yàn)槲覀冊诮哟蛻舻倪^程中發(fā)現(xiàn)，QOE通常都是客戶本身制定的一系列的指標(biāo)，比如說滲透率、觀播時(shí)長、業(yè)務(wù)轉(zhuǎn)換率，這些指標(biāo)不是把QOS某個(gè)指標(biāo)做好了，QOE就能變好。

例如GRTN在接客戶時(shí)，發(fā)現(xiàn)我們的首幀卡頓、百秒卡頓時(shí)長、延遲、畫質(zhì)全方位的領(lǐng)先，RTS的QOS一定是全方位的比FLV要好，也就不用說比HLS了。但在面對不同的客戶的時(shí)候，有的客戶他說他的QOE正了，有的客戶說他的QOE有問題，因?yàn)樵诳蛻魪膫鹘y(tǒng)的FLV過渡到RTS以及RTS 2.0之后，他們會因?yàn)榭蛻舳说倪m配沒有做好，或者說業(yè)務(wù)場景的磨合沒有做好，遇到了一些問題。例如 WebRTC來進(jìn)行通信，播放器的buffer的機(jī)制可以做得非常的激進(jìn)，但是當(dāng)在直播場景時(shí)，觀眾的體驗(yàn)可能比你的激進(jìn)的延遲控制更加重要，所以在直播場景下更多的是要去做一個(gè)平衡。

在這個(gè)過程中，我們發(fā)現(xiàn)有時(shí)候客戶把QOS全做正了，但是QOE卻還需要花很多的時(shí)間去處理，所以在把QOE做正的過程中，要用的什么方法？

這是在QOE里阿里云要持續(xù)投入的。想要做好QOE一定要有業(yè)務(wù)輸入，沒有業(yè)務(wù)的輸入，沒有業(yè)務(wù)的反饋，QOE肯定是做不正的，所以阿里云有一個(gè)持續(xù)的基于業(yè)務(wù)的數(shù)據(jù)驅(qū)動技術(shù)投入這個(gè)板塊。

這里最重要的一點(diǎn)就是客戶端的數(shù)據(jù)，在做QOE的過程中，我認(rèn)為服務(wù)端是沒有資格說QOE的，只有客戶端和業(yè)務(wù)才有資格說自己的QOE這么正。所以在這個(gè)過程中，GRTN的方法是先得到業(yè)務(wù)方的脫敏數(shù)據(jù)，然后去做QOE（最后會有一個(gè)數(shù)據(jù)的展示）。

GRTN優(yōu)化QOE的一個(gè)理念是，GRTN做到了無感的鏈路切換。

GRTN內(nèi)部是一個(gè)全SFU網(wǎng)絡(luò)，上游的網(wǎng)絡(luò)隨時(shí)切換，對觀眾來說是完全無感的。同時(shí)還有強(qiáng)實(shí)時(shí)的主備鏈路。在很多直播、通信場景下，會有重保的概念，或是強(qiáng)實(shí)時(shí)的雙路保障。如果節(jié)點(diǎn)之間出現(xiàn)問題，能夠立馬把它切到另外的節(jié)點(diǎn)鏈路上，這樣觀眾完全無感。

還有GRTN節(jié)點(diǎn)和客戶端之間的mobility的方案，例如某個(gè)節(jié)點(diǎn)可能網(wǎng)絡(luò)有問題，或者客戶端的網(wǎng)絡(luò)發(fā)生了WiFi到4G的切換，那么使用一個(gè)mobility的方案瞬間能夠切換節(jié)點(diǎn)，同時(shí)GRTN的下游消費(fèi)者完全不受影響。

GRTN另一個(gè)優(yōu)化QOE的方法，就是可編程策略。可編程實(shí)際上是我們近一年做出來的一個(gè)成果。傳統(tǒng)的QOS優(yōu)化能力，例如啟用BBR還是啟用GCC或者是別的擁塞控制算法，會發(fā)一堆的配置下去，配置里面全是開關(guān)。但是現(xiàn)在GRTN，可以在邊緣直接用可編程的策略執(zhí)行模塊，類似CDN有可編程的能力，包括邊緣腳本之類，GRTN也類似，但是做的比較徹底。現(xiàn)在的能力是可以在節(jié)點(diǎn)直接下發(fā)策略，運(yùn)行語言，可以直接對發(fā)幀和發(fā)包邏輯做控制，可以介入到重傳邏輯中，直接編程GRTN的對每一個(gè)客戶端的行為，即通過策略配置系統(tǒng)直接把代碼發(fā)下來。無需軟件發(fā)版升級，因?yàn)橄?800多個(gè)節(jié)點(diǎn)，是無法高頻升級軟件版本的，但是利用GRTN可編程能力可以實(shí)現(xiàn)一天幾個(gè)策略迭代，結(jié)合客戶端的數(shù)據(jù)，能夠?qū)崿F(xiàn)數(shù)據(jù)的打通。這樣發(fā)策略下來，客戶端拿到QOE的數(shù)據(jù)反饋給GRTN，GRTN的調(diào)優(yōu)人員就知道如何去進(jìn)一步的優(yōu)化。

如圖是GRTN的一個(gè)多場景的隨機(jī)配置，也是基于阿里云線上海量的業(yè)務(wù)數(shù)據(jù)來進(jìn)行的。例如阿里云線上的配置管理系統(tǒng)會把配置集下發(fā)，這是做AB的基礎(chǔ)能力。后面配置管理系統(tǒng)會將n組配置實(shí)時(shí)發(fā)到全網(wǎng)所有的邊緣節(jié)點(diǎn)，針對的是某一個(gè)域名。針對這個(gè)域名，同時(shí)給他發(fā)出三組配置下去進(jìn)行隨機(jī)，可能會配一定的權(quán)重。例如阿里云認(rèn)為conf_1 是個(gè)高風(fēng)險(xiǎn)的配置，一個(gè)高風(fēng)險(xiǎn)的新型的功能，發(fā)出去之后，把conf_1指配全網(wǎng)1%的業(yè)務(wù)量去做 AB。發(fā)到節(jié)點(diǎn)之后，當(dāng)任何一個(gè)消費(fèi)者來到GRTN消費(fèi)內(nèi)容時(shí)，將對它進(jìn)行一個(gè)隨機(jī)加權(quán)的選擇，它有一定的概率使用conf_1，也有一定的概率使用后面兩種。

第一步的請求完成之后，我們讓多組配置同時(shí)在線上運(yùn)行，但是運(yùn)行完后怎么拿到結(jié)果呢？

簡單的方法就是客戶記錄我們的trace_id，GRTN有一個(gè)trace_id的理念，這個(gè)ID對應(yīng)客戶端的這一次播放，任何兩次播放的ID都不一樣。

接下來對它做關(guān)聯(lián)，播放器在GRTN上完成播放之后，播放器這邊開始埋日志，他們埋的核心日志就包括首幀耗時(shí)、百秒渲染卡頓，也包括任何一個(gè)播放端的播放時(shí)長。在業(yè)務(wù)方記下來的日志中，它知道這個(gè)session id對應(yīng)的這一次播放播了多久，它的各項(xiàng)指標(biāo)怎樣。在GRTN就知道發(fā)的trace_id是哪個(gè)，然后針對這一次播放，緩沖深度配了多少，以及丟包率目前統(tǒng)計(jì)下來是什么情況。

這兩個(gè)數(shù)據(jù)（服務(wù)端日志和客戶端日志）把客戶的日志收上來，拋送給我們之后，這邊就把session ID和trace_id在GRTN的數(shù)據(jù)分析體系里面做一個(gè)綜合，就得到了一個(gè)結(jié)果：任何一次播放它對應(yīng)的服務(wù)端的網(wǎng)絡(luò)情況是什么，它對應(yīng)的客戶端的首幀耗時(shí)、百秒渲染卡頓、播放時(shí)長是什么。GRTN就通過這兩種數(shù)據(jù)綜合把客戶端的數(shù)據(jù)和服務(wù)端的一個(gè)行為做到了關(guān)聯(lián)。

關(guān)聯(lián)做到之后，下一步就做賽馬系統(tǒng)。在任何一次配置的時(shí)候，就像現(xiàn)在阿里云給客戶做調(diào)優(yōu)的時(shí)候，我們會事先跟客戶說一下要為你做調(diào)優(yōu)。

例如說在這樣一次配置中，以客戶線上的業(yè)務(wù)為例，conf_1是一個(gè)高風(fēng)險(xiǎn)的功能，conf_2是對現(xiàn)有功能比如BBR的參數(shù)的調(diào)優(yōu)，conf_3啟用的可能是GCC。把配置發(fā)到節(jié)點(diǎn)，客戶在進(jìn)行播放之后，針對上兩步把他的客戶端和服務(wù)端的數(shù)據(jù)拿到之后，采集到GRTN這邊，數(shù)據(jù)上傳來之后，再對AB的結(jié)果做一個(gè)綜合的分析。這個(gè)時(shí)候在研發(fā)人員的眼里就已經(jīng)明確的知道下發(fā)的各組配置它的效果到底如何，區(qū)別是什么。研發(fā)調(diào)優(yōu)人員就能夠知道怎么去做進(jìn)一步的調(diào)優(yōu)，同時(shí)反饋哪一組配置可以被淘汰，再基于好的配置對它進(jìn)行進(jìn)一步的調(diào)優(yōu)。所以這也就是賽馬系統(tǒng)的價(jià)值——能夠基于客戶端的數(shù)據(jù)和服務(wù)端的數(shù)據(jù)進(jìn)行綜合的持續(xù)的迭代。

如圖是賽馬系統(tǒng)，它作為一個(gè)整體，有GRTN的節(jié)點(diǎn)網(wǎng)，服務(wù)客戶端上報(bào)數(shù)據(jù)和GRTN的日志系統(tǒng)打通，做到相互配合。

這是GRTN的一個(gè)優(yōu)化樣例，也就是賽馬系統(tǒng)的評分。當(dāng)時(shí)我們做實(shí)驗(yàn)有4組，normal就是平時(shí)日常運(yùn)行常量的配置，radical就是一組非常激進(jìn)的配置，reference就是用來跟radical進(jìn)行對比的參照。如圖做了一個(gè)六維的展示，也按照我們的想法對它進(jìn)行了綜合打分。

更詳細(xì)的結(jié)果是這個(gè)表，剛才提到的conf_id配下去之后，運(yùn)行完之后，接下來得到成功率、秒開這樣的一些數(shù)據(jù)。這就是GRTN目前展示出來的賽馬系統(tǒng)能夠看到的數(shù)據(jù)。

成功率、秒開、都屬于QOS的范疇，最后的平均播放時(shí)長，是屬于QOE的范疇。我們測試下來得到的radical這一組的數(shù)據(jù)是最好的，它在播放時(shí)長上可能有1秒鐘左右的優(yōu)勢，積累了24小時(shí)的數(shù)據(jù)，大概幾十萬的量級，我們認(rèn)為這個(gè)量級的播放是可以用于支撐AB的數(shù)據(jù)。GRTN最開始在手淘場景做這個(gè)系統(tǒng)，手淘的業(yè)務(wù)量比較大的，所以我們從一開始拿手淘的線上的全部量級去運(yùn)行。現(xiàn)在是直接可以拿外部客戶的數(shù)據(jù)去運(yùn)行，做成賽馬系統(tǒng)，將阿里云可編程的能力，客戶端的數(shù)據(jù)采集，包括賽馬，做成一個(gè)閉環(huán)。

現(xiàn)在優(yōu)化的方法，想要優(yōu)化某種策略，就發(fā)一組配置下去。例如發(fā)一組配置，運(yùn)行一個(gè)晚高峰，到了第二天就能拿到數(shù)據(jù)結(jié)果，這樣的一個(gè)過程實(shí)際上對迭代的優(yōu)勢是非常大的。

例如今年3月份左右，我們給某個(gè)客戶在調(diào)優(yōu)播放時(shí)長的時(shí)候，通過分析客戶端的一些行為，包括通過測試對數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)客戶的音視頻同步可能有點(diǎn)問題。怎么去解決這個(gè)問題呢？我們認(rèn)為通過服務(wù)端的發(fā)幀策略的調(diào)整能夠幫助客戶端更好地實(shí)現(xiàn)音視頻同步。我們用可編程把這個(gè)策略做好發(fā)出去，在第二天這個(gè)效果是非常好的。我們發(fā)現(xiàn)發(fā)下去之后，這組配置的觀眾播放時(shí)長升高了，這其實(shí)就是QOE的一個(gè)優(yōu)化。

在這個(gè)基礎(chǔ)上就完成了第一輪的迭代，我們認(rèn)為這個(gè)路線是對的。接下來就是在這條路線上，怎么把參數(shù)進(jìn)一步的調(diào)優(yōu)。在最開始對發(fā)幀的策略進(jìn)行調(diào)整之后，我們只是做了一個(gè)粗調(diào)，覺得大概可以彌補(bǔ)客戶端的某些缺陷。實(shí)現(xiàn)了之后，接下來做進(jìn)一步的不同的配置，不同的參數(shù)之間去做調(diào)優(yōu)。

以上就是我的分享，謝謝大家。