直播已深入每家每戶，以淘寶的直播為例，在粉絲與主播的連麥互動中如何實現無感合屏或切屏？阿里雲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最佳化實踐》演講全文。

「影片雲技術」你最值得關注的音影片技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音影片領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲影片雲產品技術交流群，和業內大咖一起探討音影片技術，獲取更多行業最新資訊。