為了全面提升淘寶直播體驗和互動能力，淘系技術團隊聯合阿里云經歷三年時間打造了首個全鏈路RTC實時傳輸網。在時延、成本、抗弱網等指標均取得巨大提升。本次邀請到阿里巴巴淘系技術資深技術專家陳舉鋒老師（豐火），為我們介紹GRTN的技術演進路線及未來規劃。

文 / 陳舉鋒（豐火）

整理 / LiveVideoStack

我從2016年開始做淘寶直播，在2017年也做了很多分享。從2016年啟動到現在這幾年內淘寶直播還是有了很多技術沉淀，記得2017年當時最早說的是在直播上行上通過RTC優化直播鏈路，這個方案當時在業界還比較少被談到，因為當時大部分方案都是傳統的上行走RTMP，下行走FLV，沒記錯的話我們應該是較早在直播上引入RTC的技術，當時來看淘寶直播在技術上還是具備一定的前瞻性。技術一直在進步，說明從2016年到現在RTC技術在直播的應用越來越廣，研究也越來越深入。

從淘寶的經驗來看，引入RTC技術后對整個淘寶直播的體驗、核心的業務指標都帶來很大的幫助。GRTN是淘寶直播和阿里云團隊共建的RTC網絡，我會分享GRTN在淘系內容業務上的落地和規劃，也會介紹下GRTN的關鍵技術點。

#01?淘寶的業務數據

回顧淘寶直播以往的業務數據，2016年啟動淘寶直播，到2020年雙十一為止整個數據的增速非常驚人，這是一個從0到1的業務，剛啟動時既沒有業務基礎也缺少技術儲備，唯一有的是2016年淘寶直播在手淘首頁的“愛逛街”有一個很小的版塊，只有60萬DAU，但較好的點是在主播供給有一些沉淀。實際在逛逛的業務之前，淘系在一些小的內容賽道上如有好貨、必買清單上還是做了不少嘗試。愛逛街也是其中一個典型例子，當然后面遇到了很多困難，DAU跌得比較厲害，在首頁的位置也往下移。但在早期為淘系積累了一大批優質的內容生產者，達人、寫手，這些積累為淘寶直播在最早啟動時帶來了幫助。

回到2016年的啟動淘寶直播的時間點，早期對整個直播的業務模式定義很清楚，2016年市場并沒有電商直播的概念，所謂的“百播大戰”，其實大家提到的都是秀場、游戲、或是傳統的YY直播廠商將直播平臺移動化的產物，基本沒有提到電商或“賣貨”在直播場景中的模式。這里可以重點提一下，確實是淘寶直播定義了整個電商直播的標準——邊看邊買：主播講、用戶問問題、主播回答問題形成的購買鏈路，這其實是2016年淘寶直播的第一個版本上線后，這個核心的商業模式已經建立。后續我們做了很多工作，低時延、互動能力優化、在多媒體互動上大量的玩法，都是在模式邊緣性的擴充和升級，本質并沒有變，過去4年內的核心還是“邊看邊買”，并且非常好的將直播互動能力應用起來。在很長一段時間，整個淘寶直播的轉換率僅次于“手猜”，對大部分人逛淘寶都是具備極強的目的性，很少逛“猜你喜歡”，大部分還是打開手淘搜索欄直接搜索。互動+電商直播對整個購買鏈路的轉換率提升影響很大，這就是創新的力量。

整體數據基本是連年翻倍的增速，無論是直播間DAU、還是整個直播開播場次、成交規模在去年全年已經突破4000億。

覆蓋的內容形態上也發生了很多變化，早期典型場景是女裝類和美妝類，但最近幾年如珠寶、美食，包括村播各種形態都涌現出來，數據表現還不錯，除了內容的多樣化之外，成交規模上也有33個過億的直播間（雙11期間），整體呈現出非常健康的狀態，這也是我們過去在生態多樣性努力的成果。

在供給側，開播鏈路也做了大量的簡化。原來電商平臺上較為復雜的開店、上新、認證安全機制導致淘寶直播在很長一段時間在開播、入駐、發送商品的整個流程會相當復雜，所以從業務方面去年在開播鏈路上做了極簡：一鍵開播、一鍵入駐、一鍵上架，整個商家開播的場次、頻次得到大幅提升。技術上，去年雙11單個直播間同時在線人數突破200萬，這是真實連接的同時在線（淘寶直播間的口徑是嚴格意義上的真實在線，一定是長連接能夠維持在播放態），在200萬的真實在線中，單個直播間的播放時延在1.2s以內，更大的困難在于極低時延的同時要確保畫面和消息的同步，要保證畫面中上鏈接時，鏈接能夠同時彈出來，這是很關鍵的。而且因為“搶到就是賺到”，目前直播間內的購買模式已經變成了強實時的“秒殺模式”，意味著推送的寶貝鏈接一定要第一時間與畫面同步且最低時延推送給直播間的所有用戶，才能夠實現“看到就搶到”。這其實是規模所帶來的最大技術挑戰。

另外規模的上升如果沒有編解碼、碼率層面的優化，會帶來成本線性的增加。所以我們也做了基于H.265的全鏈路、包括H.266的預研。利用帶寬95峰值計費的特性通過削峰填谷的手段做一些智能的調度，以達到兩個目的：第一個是使峰值降下來。第二個是在峰值不變（總成本不變）的條件下，把日常碼率提上去。

我的主題也會圍繞以上幾個方面展開。

#02 玩法介紹

大家平常看直播間時，除了觀看之外，會給主播側提供一些營銷類能力包括抽獎、打賞、倒計時紅包。我會從業務角度重點介紹“情景互動”。

其實在我們做整個直播間的實時內容理解之前，直播間的內容分發鏈路是很困難的，因為直播間具有強實時性，可能存在兩個小時就結束了，意味著內容只有在兩個小時內分發價值最大。比如在主播賣貨結束后再進行分發，此時貨已經沒有了，分發的價值不大，只剩下簡單的內容介紹價值。

第二個點是在直播的過程中，如何最大鏈路將分發價值發揮出來。分發網絡的實時性是沒有問題的，這是阿里巴巴集團最大的優勢。困難是直播間內發生的事情無法預測，不像視頻、圖文，有大量已知的前置內容，在上線內容分發之前就有許多預處理可以將它做到結構化。但直播不一樣，也是剛才所說的結合圖像識別，語音信息甚至上下文信息將整個直播間內容做到結構化。最佳狀態是主播正在賣連衣裙，而我們希望用戶在主搜中搜索“連衣裙”時命中的就是主播此時介紹的連衣裙，現在也已經很接近這個狀態了。

#03?技術架構

介紹一下我們的技術架構。

首先從層次上看，最底層的基礎設施主要基于阿里云的多媒體體系，包括邊緣推流、中心轉碼、時移、錄制能力。第二點包括播放側的分發機制，這是阿里云的技術應用。直播的一個比較大的不同點在于，淘寶直播在阿里云的基礎之上建立自己的分法體系——RTC分發體系，這是有一個過程的，不是一步到位的，它們共同構成了淘寶直播底層基座。

直播開放平臺層核心分成三方面，一方面分為兩頭。一頭是生產側，包括編解碼體系、主播APP、前處理（美顏處理）、場景識別、端側推流能力、上線的處理包括流控。另一頭是觀看側，整個淘寶直播的房間應用了自研播放器，做了大量后置電路處理包括畫面增強、自研的H.265軟件解碼器，值得一提的是淘寶直播間大概率是唯一一家實現了全鏈路H.265覆蓋，意味著整個鏈路沒有轉碼（生產、推流、分發側、播放側）完全支持全鏈路H.265，而且覆蓋比例非常高。有同學疑惑軟解H.265在端側實現的難度，解決了這個問題也就解決了整個H.265在端側解碼的覆蓋，結合硬解鏈路做到極大的提升，也會節約很多轉碼成本。

在流媒體鏈路之上，分裝了整個直播間直播業務領域模型的概念，比如流狀態、互動能力、商品管理能力、彈幕、營銷型玩法。我們分裝了整體的一套API支撐核心業務。

直播底層最核心的兩個傳輸鏈路：一個是流媒體鏈路，另一個是消息點鏈路。消息點鏈路是整個評論消息和營銷型類玩法怎么和流媒體鏈路同時向下做分發、同步。這是我們核心的幾個技術點。

#04 技術演進

直播在過去幾年除了基礎性優化，最大的底層改造是從傳統基于CDN的中心化分發機制轉化為去中心化網絡上。我們先介紹一下原始網絡特點及問題。

首先在第一個階段（上方左圖），是迄今為止大部分直播廠商所用的最典型方案。大家基于CDN最傳統的中心分發網絡，主要以FLV文件為主。這樣的好處是一方面對整個CDN改造低，其二是無論是RTMP還是FLV，在兩端業務方面支持是最完備的。而且底層協議流控方面，都走TCP，不需要做太多優化改造，是最快從0到1直播業務構建體系，但這個模式存在的問題是什么？雖然這個模式很快，包括淘寶直播第一期也是這樣做的，但是整個鏈路一定會從L1到L2到中心節點，存在回源機制，這是不可避免的。因為這是靜態的結構，不存在任何動態感知能力，會帶來大量回源成本和時延問題。時延問題一方面與回源有關系，也與整個流控協議缺少更精細力度的控制有關系，RTMP和端側的FLV是典型的TCP底層協議，在業務上能優化的點有限，調調本地的Cache，L1緩存的GOP大小，手段有限，會帶來很多額外的成本。

我們在淘寶直播發現了這種體系下更為嚴重的一個點，淘寶直播的主播相對秀場、游戲等比較分散。秀場上熱門主播是比較集中的狀態，可能占了頭部整個流量的60%甚至80%，這樣它的中心化分發可以將成本攤平，而淘寶大部分主播在線處于平均水位線以下，和頭部差別很大，但這一部分用戶占了絕大多數。剛剛中心化機制主要解決熱點集中的問題，但在淘寶直播中，100萬的在線人數可能分布在上萬個直播間中，所以這個機制會進一步放大成本高的問題。

以上就是為什么會演化出淘寶會向GRTN去中心化方式走，這里有一個形成過程。

第一個階段起源于一個很簡單的問題，當時通過線上數據分析，絕大多數在播放側引發的卡頓大多是因為上行網絡的抖動，基本上在第一跳（主播的RTMP到L1節點之間的波動引發了大多數卡頓），但在當時情況下無法對鏈路重新做優化，很典型的設計機制是我們在與L1同級的節點中部署了淘寶直播自己的上升節點，與主播走的是私有的RTC協議，從RTC協議節點上直推到L1，中間走的是同一個地方，走專線或者GRTN，也就是最前面的一公里用私有協議走掉，這是第一步的RTC。

第二步先走的下行，就是主播的下行和下行的L1節點之間，把它改造成了RTC。改造后的效果比較好，但這里的效果更多的是解決卡頓問題。基于WebRTC的上行，整個RTMP上行改造之后對卡頓的優化非常明顯，卡頓降了接近1/3，尤其在弱網場景以及海外推流場景下表現非常突出。但是后面經過時延統計，兩頭編解碼大概在60ms，整個發送在不到100ms，播放側也類似，核心在整個分發鏈路時延占的最多。所以說兩頭問題解決的話可以解決卡頓問題，但并不能解決時延的問題，這就回到了如何真正做到全鏈路RTC。

這不是業務型決策，中間的整個分發機制一定要跟整個CDN的原來的技術貼近。因為原來的CDN分發機制并不是流媒體的分發網絡，它本質是文件的分發網絡。那么如何改造它，我們聯合了多個團隊，最終完成了GRTN全鏈路RTC的升級。這里帶來的優勢幾乎基本可以解決前面的問題，一方面它是完全去中心化不存在任何回源的邏輯，對一些區域非常接近的房室的話，利用整個動態路由的策略，完全可以不經過中心的浪費。

全鏈路的RTC帶來的好處是節點和節點之間的感知以及傳輸做到更細密度的控制，甚至是一些針對流媒體傳輸的特殊性。流媒體傳輸中有些包可以丟，策略上面可以做一些更細力度的控制，不一定是可靠到達；在提出多網融合之前，我們在整個直播、視頻會議、連麥場景等很多時候其實走的是獨立的通道，播放的時候可能走FLV，用戶之間連麥用RTC。

目前為止大部分在線教育廠商因為成本問題還是采用的這個策略，但是如果完成了整個RTC全鏈路網絡，任何一個節點都可以做上行或下行，同時下行直播鏈路和它成為雙向的通話場景本質上沒有任何區別，這意味著我們可以在同一個通道完成連麥和直播播放場景。當然視頻會議在整個外圍系統增加了MCU或SIP網關中其實也是類似，也就是說在直播、連麥、視頻會議和點對點通話做到了四網合一。今天來說這個方向得到了普遍意義的認可。

成本上面包括回源成本、鏈路過長的成本都會得到解決，全雙工和多網融合是一個概念，同時具備上行和下行的邏輯。

以上基本是網絡演進的一個過程。

#05 低延時直播

回到剛剛提到的直播間里主播上鏈接的機制，本質上包括幾個問題：

消息到達率：消息超過百萬級在線的話其實跟原來幾千幾萬在線分發所面對的困難完全不是一個技術體系。做法上除了對原來的Push模式大量的改造，包括分統機制、飽和機制，這里最大的技術改造是把消息做到分層，包括主播推送給用戶的消息，這個到達率及對業務的價值我們認為是最大的。這類采用Push消息，把原來的進出直播間、評論、擴散的消息更多在CDN靜態化。最終其實是把整個消息機制做成了推拉結合機制，把整個5s消息到達率做到高于三個9，大概是3s的三個9。

單純的消息穩定到達率及時效性，它如果不能和畫面的到達率結合起來，效果是不能發揮出來的（上鏈接之后，畫面要更短時間看到，同時搶寶貝的鏈接在主播側盡可能短的看到并且時延要縮短，這里一方面依賴消息鏈路的改造，一方面依賴整個GRTN低時延傳輸之外，兩者的同步方面主要是基于幀的染色，目前走的SEI，或者是特殊幀的附加信息保證兩者同步，關鍵在于同步的時間窗要盡可能小；上鏈接過大的話，極有可能是畫面到了，用戶通過提前畫面的截選把鏈接解出來），這也是需要關注的點。2018年，有一個場景是“點題成金”-沖關答題分獎金，即使這種技術在“點題成金”模式下會更為迫切，但畫面和題目一定要高度一致，這就是直播和消息的強同步。

依賴于整個RTC的全鏈路，時延基本可以做到小于1s，這是一個均值，在一些更為非盲情況下，時延可以做到更低。

#06?淘寶直播連麥

雙通道帶來的優勢是RTC通道可以同時承接直播推流與連麥，再借助于外圍系統的配套，視頻會議也可以承接（MCU），這也是我們正在做的方向，希望四個場景（直播、通話、視頻會議、連麥）各有一個真實的業務能夠承接起來，并具有一定的規模。

淘寶目前的端合流與云合流分別有一個演進階段，但最終走向了融和型。因為端合流會帶來成本上的優勢，但云合流在調度和擴展性更有優勢，所以兩種方向我們都做了支持。演進的路徑上基本也是從早期的RTMP支持連麥的時候，后面因為上行和下行RTMP的階段化，已經有了融和態，最后走了全鏈路RTC徹底解決了直播連麥通道上不統一的問題。

#07?GRTN動態路徑規劃

GRTN的動態路徑規劃中有幾個重點。

一個是動態路由規劃，這里核心是每一個節點對任一個節點的到達路徑都是可感知的，有很多衡量的指標，比如任何兩個節點之間的丟包率、時延、抖動、容量、成本都有動態預估。因為中間整個網絡會持續發送探測包把信息記錄下來，所以節點1方面它對自己可連接的節點到任意一個節點的路由都是有動態的策略表并記錄的。根據策略方式，有些質量最優，那在丟包、時延、抖動方面有權重的設計，保證它一定處于最低時延及最小卡頓率下傳輸；另一種成本最優，可能中間的鏈路比較長，走的節點成本消耗不同，有些走專線，有些走LTN，會產生成本的不同，這塊也會計算成本還是質量最優。

目前GRTN真正在線上跑的版本還是融合了各種策略，典型的一個例子如果是RTC通話連麥場景，它對時延也就是質量要求最高，卡頓要求最低，這就會選擇質量最優的策略。所以這塊也會根據不同場景做一些設計。

#08?參數自學習

在整個網絡上面，很多參數是此消彼長的（卡頓和時延），但這只是最終的表現。如果在細粒度，如編碼側、解碼側、端側的緩存設置上面，整個系統目前有超過400個參數，這些參數的最優解是什么，在收斂過程中很難確定也很難證實。

所以我們做了參數自學習的方式，前期有人工剪枝，之后利用線上大量的AP系統對400個參數的收斂做了非常快的設計。純粹通過參數優化方式帶來收益，在底層機制不變的條件下純粹的參數優化已經對卡頓和時延帶來明顯的優勢。

#09 游戲玩法

去年我們做了大量了基于玩法型的優化，包括營銷類優化（抽獎、發紅包）和社區互動型玩法或游戲類玩法，可以拉近主播和用戶之間的連接（如：抖音前段時間的潛水艇），既有樂趣也有內容的產出。但這個模式在之前沒有很好的應用在直播中，會遇到幾個問題：

首先，用到大量端側推理模型，在手淘無論是MN還是端側的網絡小樣本訓練都沒有完全跟上。今年基本可以做到和業界對齊。

其次，有很多探索靠單純端側的算力無法滿足。比如3D直播間、虛擬主播技術，對一些算力的訴求是綜合的單純放在端上是不現實的，如何用更好的方案一方面把端側和云端的算力一致化運用起來，去除差異。本質上來說，前處理的模式就識別或是畫面特效配合，在端側或云側處理對于用戶側和主播側是無感知的。舉個例子，比如人臉識別或是特效識別，我們既可以把這個模型放在主播側推優之前，完全用主播側APP或PC處理，也可以完全放在GRTN的某個節點處理完成后通過實時回顯鏈路放到主播側APP上。所以對主播來說，如果可以解決時延的問題，回顯來自本地還是云端是沒有任何區別的。解決如何充分靈活地調動云端算力，并結合GRTN實時回顯鏈路解決直播的流內互動玩法問題是我們的根本目的。

簡單介紹一下，上圖中的幾個玩法。第二個“打年獸”，主播通過人臉控制屏幕下方炮臺的左右移動，打上方小蜜蜂，通過人臉輸入控制道具。游戲基于兩種機制，人臉的識別、流的處理、渲染和最終合成完全是一個端上的版本，同時我們也做了云端的版本。

3D直播間，人員站在綠幕前，后面的場景是3D數字直播間，通過摳圖、合成方式做成。在3D場景下，完全放在端側不現實，沒有很好的算力，它和后面的3D場景完全不交互，但做到完全的3D化后，可以和場景中的元素交互，解決直播間里的遠程機樣的問題。

#10?多媒體處理中心

整個的設計模式上述介紹的差不多，最重要的的幾點是把前置的能力作為GRTN的算子掛接上去，還可以掛在端上調度的系統上。另外GRTN整個實時回顯模式也做到了云端一體化設計。

#11?智能控制

最后一部分的核心是針對目前帶寬的水位或是業務數據上的策略，對于整個線上碼率、根據更細粒度人群的投放，我們做整個成本和畫質的平衡，在雙11期間發揮了很好的作用，晚上可以做到分裝級降碼率，還會自動根據線上的變化提升整個畫質。

以上是分享的內容，謝謝！

詳情請掃描圖中二維碼或點擊閱讀原文了解大會更多信息。

總結

以上是生活随笔為你收集整理的GRTN赋能淘系内容业务的演进路线及未来规划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。