“立足當下，著眼未來”，任何一位從業者都應該謹遵這樣的格言。阿里云通過總結這么多年的流媒體傳輸服務，分析痛點、提出措施、改進技術、認真思考，帶來了MediaUni這樣一個面向未來的流媒體傳輸網絡。LiveVideoStackCon2023上海站邀請到了黃海宇為我們介紹阿里云在MediaUni上的設計與實踐。

大家好，我是阿里云視頻云的黃海宇，今天分享主題是MediaUni——面向未來的流媒體傳輸網絡設計與實踐。

下面我將會從應用對流媒體傳輸網絡的要求、MediaUni定位與系統架構、MediaUni技術剖析、基于MediaUni的應用落地和流媒體傳輸網絡的未來5個方面展開介紹。

-01-

應對流媒體傳輸網絡的要求

如圖所示，不同場景延時從左往右依次升高。最右側，超過30秒的延時，通常被認為是一個可傳播的場景，例如視頻點播，行業內會通過一張CDN點播網，服務這樣的傳輸需求。

3~10秒的延時區間多見于直播，會使用如RTMP、HTTPFLV和HLS等協議，進行一些流式或小分片的傳輸，可滿足3~5秒的延時需求，通常適用于彈幕互動的場景。在行業內，通常使用CDN直播網絡進行這樣的傳輸服務。

最近興起的800毫秒到1秒左右的延時，通常可以滿足體育賽事直播中的傳輸延時需求，例如，在世界杯直播場景中，該延時的直播讓用戶不再會感受到進球時刻的明顯差異。另外，通過淘寶等電商場景的實踐發現，該延時級別的直播，相對于3~10秒的普通直播，可以有效提升GMV。

視頻會議、直播連麥、語音聊天的延時通常在250毫秒到400毫秒之間，行業內通常會采用如BGP帶寬或者三線帶寬，構建一張低延時的音視頻通訊網絡，來進行實時音視頻傳輸支持。

更低延時的場景，我們將其稱為可操控和可沉浸場景，延時在50~80毫秒，可操控的典型場景是平行駕駛，當自動駕駛出現問題時，可以通過遠程指令操控汽車、接管駕駛。而云游戲、云渲染則是典型的可沉浸場景。

從上面可以看到，延時的降低帶來了更多的業務場景和更多新的玩法。

以延時最低的云渲染場景為例，通過其頂層架構圖，可以發現，用戶產生一系列的操作指令，通過傳輸網絡傳輸到相關的業務服務器，再控制渲染服務器進行渲染，渲染后的數據會經過流媒體服務器，再通過流媒體傳輸網絡進行傳輸，最終達到用戶終端。

相比傳統的媒體傳輸，該架構有兩個特點：第一，視頻來自于渲染而非拍攝，會涉及到大量的計算環節；第二，傳輸網絡不僅要傳輸媒體，還要傳輸控制指令，需要保證控制指令的低延時和可靠的交付。

成本和質量是傳輸網絡繞不開的兩個話題。左圖展示了一個阿里云典型直播APP客戶的云上成本構成，70%左右來自于傳輸，這意味著在當下企業降本的大環境下，需要對傳輸提出更低成本的要求。右圖是另一個典型視頻APP的播放時長與卡頓率的關系數據，通過AB測試我們發現，隨著卡頓率的逐步降低，播放時長也會有明顯的提升。

綜合來看，應用對流媒體傳輸網絡的要求來自于四個方面：第一，延時的降低可以催生更多業務場景；第二，低成本，媒體傳輸是視頻應用成本的重要組成部分；第三，更高質量的視頻可以提升用戶的觀看時長；第四，多維度，除了媒體傳輸之外，還需要支持互動消息的傳輸、控制信令的傳輸，同時也要支持與計算的緊密相連。

-02-

MediaUni定位與系統架構

基于以上思考，阿里云設計并實現了MediaUni，其中Uni取自單詞unified，意為通過一張統一的網絡，服務各種業務場景。

MediaUni是阿里云全球實時傳輸網絡GRTN的升級，是基于廣泛的異構節點，構建的全分布式、超低延時、多業務支撐的多元融合流媒體傳輸網絡。

MediaUni的核心理念在于融合，這主要出于如下三方面的思考。

第一、業務混跑帶來的資源利用率提升。云廠商的基本商業邏輯是：云是彈性服務，大家可以按需付費，即買即用，那么，由于不同用戶使用的時間段是不同的，購買的固定資源則可分時服務到不同的廠商，使得云服務的資源利用率大于客戶自行購買的的資源利用率，從而降低成本。與普通的云計算不同，流媒體的一大特點是業務的聚集，例如，單一的互聯網娛樂直播，大部分都會發生在晚上8:00~11:00的晚高峰之間，而大部分的會議分布在白天上班時間，體育賽事則可能出現在任一時間段，如果我們僅僅支持其中一種業務，則無法達到資源復用的目的。

這背后的理論依據是概率論最基本的中心極限定理：大量獨立的隨機變量之和服從正態分布，隨機變量越多，他們的和將越聚集在平均值之和附近。對應到流媒體傳輸業務，每個客戶對資源的使用就是一個隨機變量，他們對資源的總需求就是服務商需要保障的資源總量。為了達到更高的復用率，我們需要盡可能擴大業務的規模與多樣性，從而達到綜合降本的目的。

第二、技術復用帶來的研發邊際成本降低。不管是音視頻點播的傳輸網絡，還是直播的傳輸網絡，還是實時音視頻通訊，都會涉及一些相同的技術，比如協議的優化、QoS優化、調度等，而在一張網上實現這些技術，可以帶來更好的技術復用，將單點技術做得更加深入，從而帶來更大的業務價值。

第三、云產品更加便捷與高效。從云廠商的角度來說，把各種傳輸能力進行融合，意味著用戶在使用產品時會更加便捷，比如通過一張網的融合，用戶在阿里云上可以通過一鍵升級，將自己的普通直播（3~5秒延遲）升級為低延時互動直播（400毫秒）。

圖為MediaUni的架構

可以看到，MediaUni構建在阿里云廣泛的異構資源上，包括3200+的邊緣計算節點，以及29個region，同時也包括超過180T的帶寬，涉及的計算資源類型包括CPU、GPU、ASIC。

這里有兩個很重要的系統，第一個是感知系統。感知系統需要具備三方面的感知能力：

①感知業務信息，在直播時有些應用信息是在真正發生之后才知道的，例如，某個直播流觀看人數突然增多，我們必須有能力實時感知到，從而提供一些差異化的服務；

②感知資源信息，包括基礎資源的水位、CPU與內存的狀態、帶寬的使用情況、以及網絡的延遲、丟包率等；

③感知服務質量，例如各種業務的卡頓率、視頻首幀的延時、推拉流成功率等。

第二個是決策系統，這些感知信息在收集以后，會推送給決策系統，并基于成本與質量的平衡，進行調度決策：包括接入的調度、路由的選擇、實時的逃逸策略以及算力的調度等等。

MediaUni的整體架構具有幾個明顯的特點：

一、可以支持多種協議。這些協議是在邊緣支持的，在邊緣節點進行一層卸載，卸載以后中心會采用統一的內部傳輸協議，這樣利于我們擴展業務場景，同時又不影響內部核心系統；

二、MediaUni支持混合組網。延時要求不高的場景，會采用樹狀組網，而對于音視頻通訊這樣延時要求高的場景，會采用對等組網的方式；

三、網絡之間的路由會基于源選擇動態路徑服務用戶；

四、全鏈路可編程。很多業務在同一張網上運行以后，可能會存在業務之間相互影響的問題，為了減少系統的變更，我們支持了全鏈路的可編程，讓大部分業務需求能夠通過可編程的方式實現；

五、算網結合。計算部署在網絡節點上，能夠提高資源利用率，同時也降低為了計算而傳輸數據帶來的成本與延遲；

六、異構網絡、計算資源支持。系統支持單線、多線、BGP多種網絡資源類型，也支持CPU、GPU、ASIC多種計算類型；

七、持續迭代的QoS。系統支持QoS算法的可插拔，并具備完善的AB測試能力，幫助QoS不斷迭代。

融合帶來諸多好處，但也會帶來額外的挑戰。首先是異構資源的適配和納管。其次是基于不可靠的資源提供可靠的服務，這是這張網絡最大的挑戰，通常的音視頻通訊網絡，采用更加優質的資源以達到更低的延遲及穩定性，對于統一的網絡，如何在更多的節點里面優選出節點，進行更好的服務則至關重要。

另外的挑戰來自于多業務混跑帶來快速迭代的需求，運行的業務越多，系統更新也會越來越快，如何滿足系統的快速迭代以及緩解隨之而來的穩定性沖擊，也是一個很大的挑戰。最后是標準化和智能化帶來的挑戰。

-03-

MediaUni技術剖析

下面簡要介紹MediaUni對不同場景的支持。

直播場景有幾個特點，一個是大規模會帶來高并發和成本敏感，另外一個是突發的直播事件。對此阿里云采取了以下措施：首先是混合組網。在3~10秒延遲的直播中采用樹狀組網，如果延遲需求達到400毫秒左右，將會采用對等組網。其次是熱流的秒級感知，當一個流突然從冷流變成熱流時，將迅速動態擴大服務資源。另外，目前行業內直播業務仍以基于TCP的協議為主，我們對協議棧進行了深度優化，以達到更好的服務質量。最后是質量與成本可運營，能夠根據業務的質量、成本偏好進行調節。

實時通訊場景有兩個特點，一個是低延時，一個是場景化。在低延時的實時通訊場景下，為了保障低延時，通常會采用各種QoS策略，但不同場景的QoS策略是千差萬別的。例如，視頻會議和普通的語音聊天傳輸，采用的QoS技術差別非常大，為此MediaUni采用動態組網、就近接入、可插拔QoS和秒級逃逸幾個技術來解決上述問題。

就近接入，意味著能夠快速感知用戶和節點之間的鏈路狀態，服務器可以很快做出一些QoS策略的調整。可插拔的QoS能夠幫助團隊應對各種不同場景化的QoS需求。阿里云的傳輸依靠大量邊緣節點，各個邊緣節點的可靠性不盡相同，所以需要對這些節點進行更快速的感知，預防故障的發生以及服務質量的下降。

云渲染場景伴隨超低延時和控制信令傳輸兩個特點。這里采用就近接入和就近異構計算兩種方式，選擇距離用戶最近的計算節點和傳輸節點進行接入，并采用異構的計算方式服務用戶。

數據傳輸場景，通常延時低、可靠性高，而且數據傳輸量相對較少。通過協議復用與擴展，支持數據的傳輸，同時采用多徑和FEC技術，提升數據傳輸可靠性，減少重傳。

針對不可靠資源的高質量是傳輸網絡面臨的巨大挑戰，也是關鍵技術。

傳輸網絡的不可靠主要來源于兩個方面，一是資源的不可靠：一方面邊緣節點的可用性不盡相同，另一方面大部分的傳輸都基于公網，而公網建立在IP之上，是一張盡力而為的網絡，經常會遇到網絡抖動，如何去對抗網絡質量的抖動也是一個很大的挑戰。

二是流媒體傳輸的業務特點，包括長鏈接和熱點突發。為了保障低延遲，流媒體的傳輸通常采用長鏈接方式，需在建立連接時就分配系統資源，但視頻的特點是音視頻碼率會動態波動，例如世界杯，開始時視頻的碼率可能只有一兆，但是進球時可能會波動到四兆、五兆甚至更高；另一方面，熱點事件突發時會對資源的需求迅速擴大，這都意味著用戶業務對資源有很大彈性的要求。

針對上述問題，我們進行了兩方面的優化。一方面是弱網對抗。從生產端到傳輸端，再到播放端，會有很多的優化策略，例如，在前處理時進行降噪、通過阿里云窄帶高清技術降低碼率、支持多流、SVC等；傳輸側相應的策略有動態路由、協議棧優化、FEC、多徑等；播放側會有jitterbuffer、neteq、后處理等方式。

另一方面的優化是感知與逃逸。因為構建在不可靠的資源上，所以非常需要實時感知資源的狀態以及業務的狀態，再通過智能的決策做秒級的逃逸。

在感知與逃逸的關鍵技術方面，以下分享一些細節。

我們設計了多維感知評分系統。通常的流媒體傳輸只感知服務節點的可用性，為了能夠支持多種業務，同時提供更好質量，我們引入了評分的概念，對每一個節點進行評分，同時也對節點之間的鏈路進行評分。 評分來自于三個方面：首先是節點的日志，包括資源的信息、資源的水位和軟件運行的狀態；其次是端邊探測系統，我們不能夠僅僅相信服務端的日志，因為可能存在服務質量或服務可用性問題，一些客戶沒有訪問到服務就失敗了，從而導致幸存者偏差，為此我們構建了幾十萬的端設備，用于不斷探測系統，探測的結果也是評分的重要依據；最后，是業務層的一些質量數據，比如卡頓率、首幀，以及拉流成功率這類核心的服務質量指標，也將作為評分的一大依據。

在多維感知系統得到這些評分之后，會輸出每個節點以及每條鏈路的評分，并根據評分結果，把相應的信息傳輸到智能決策系統。智能決策系統會依據業務類型、服務等級、資源的成本以及水位這三方面信息作出決策，包括節點的管控、用戶接入的調度、路由動態切換以及無損切換等。由于音視頻采用長鏈接，其可調度性較差，當發生故障或感知到質量下滑后，需要對原有的長鏈接進行遷移，其中包括處理任務的無損遷移和傳輸鏈路上鏈接的無損遷移。

這里面有三個難點，一是感知的速度，我們采用了兩種手段，一方面做業務分級，對系統資源利用率非常大的數據，會使用高優先級通道傳輸；另一方面進行節點上的計算，將很多計算，包括評分，放在節點上完成，這樣傳輸的數據會大幅減少，從而提升傳輸速度。第二個難點是如何實現無損切換，要保證音視頻的無感切換需要進行幀級別的續接，同時也要處理時間戳連續性、分布式系統調用異常等細節。第三個難點是如何做決策，因為擁有大量的信息，而不同的業務對質量的要求又不盡相同，如何進行智能決策，同時又滿足成本的需求，就存在著很大的挑戰。

經過技術上的迭代優化，阿里云成功實現在節點故障時的秒級切換，并保障了在質量惡化時的分鐘級逃逸。

另一個關鍵技術是協議棧的應用層聯動，這里主要針對TCP場景。

TCP場景一直都有一個優化手段叫做單邊加速，這是因為服務器的協議棧由自己控制，可以修改內核進行優化，但是客戶側的TCP協議棧由客戶端操作系統提供，不能進行修改，而最近幾年出現的Quic，可以在應用層進行擁塞控制以及協議棧優化，但由于TCP仍然是流媒體傳輸的主要協議，我們進行了深度的優化。傳統的單邊加速采用通用的加速方法，修改傳輸的擁塞控制策略，但傳輸層與應用層相互獨立，4層的TCP協議不能感知到7層的應用信息，同時7層也感知不到4層的網絡傳輸變化。產生這樣的問題，主要是因為4層在設計上是一個通用協議，不區分流媒體，也不區分文件。為此，我們將4層和7層的信息打通，實現4層和7層的聯動以及7層和4層的聯動。

右圖上面為流媒體傳輸引擎Tengine-Live，處于應用層，能夠獲得相應的業務信息、碼率信息，同時也會控制一些丟包的策略。在傳輸時可以通過4層的通道，把業務的偏好、帶寬的需求、碼率波動以及帶寬的大小，傳遞給操作系統，而操作系統則根據傳輸的不同階段采取不同的應對措施。

具體來說，操作系統可以根據應用層的信息選擇擁塞控制算法類型，如我們自研的類Cubic算法和類BBR算法，也可以進行子算法的選擇，同時，操作系統還可以根據應用層傳入的具體信息對算法進行微調，例如，可以根據碼率的大小選擇首窗窗口，可以根據播放的階段來均衡策略的激進性，也可以對算法的參數進行調節。

相應的傳輸信息也會通過4層到7層的通道，把底層擁塞控制里面的實時帶寬、網絡擁塞狀態、網絡RTT丟包率等信息傳遞給應用層，如果應用層發現底層網絡已經嚴重擁塞，則可以采取更激進的丟包策略。

該技術上線以后，實現了播放首幀降低12.1毫秒、卡頓率降低32.5毫秒、拉流成功率提升0.101%的顯著效果。

全鏈路可編程，是為了應對多鏈路混跑所帶來的挑戰，多業務混跑會使得需求爆炸性增長，需要一種盡量減少侵入的方式來滿足需求的快速迭代。

為此我們開發了全鏈路可編程系統，對流媒體傳輸和流媒體處理都進行了可編程擴展，把C代碼進行原子能力的抽象，抽象到相應Lua的API，通過調用這些API，可以組合出各種不同的業務能力，以滿足播放行為、時間戳、QoS算法迭代以及轉碼動態規則調整等需求。Lua代碼實現以后，會通過配置中心傳輸到流媒體的傳輸網絡和處理網絡，以滿足新功能或優化快速迭代的需求。

這里有幾點需要注意：高性能，對于傳輸節點來說，Lua的性能非常重要，因為傳輸節點的吞吐量非常大，我們大量使用 Lua FFI 而非 Lua Cfunction，減少 Lua 棧數據交互操作，同時也對其中的熱點進行性能優化；安全性，需要嚴格控制Lua的可操作范圍，避免對系統造成影響；此外，靈活性是我們采用可編程的目的，實現中也考慮了動態下發，支持灰度、AB 實驗、熱更新，可插拔等能力，以提高可編程的靈活性。

-04-

基于MediaUni的應用落地

在卡塔爾世界杯期間，我們支持了超低延時的直播，將端到端直播延時降低到一秒以內。此外，我們還帶來了更好的播放體驗，卡頓率顯著下降，從3.19%降低至2.13%。

在一些云渲染的場景，通過就近傳輸和就近處理，我們實現端到端延時降低到58毫秒。目前，這項技術已經應用在央博的云廟會，以及去年雙11淘寶未來城中。

云上藝考則綜合使用了多項能力。在遠程監考場景，當老師對一個學生感興趣時，可以單擊進入電視直播模式，達到400毫秒延時的直播。如果老師有問題需要和學生進行溝通，開啟連麥，也可以做到400毫秒之內的通信。同時，媒體處理服務可以對這些流進行實時的合流，形成一個老師面對多個學生的畫面。另外，基于數據傳輸的能力，應用層可以實現口播的功能，將數據通過網絡傳給學生，進行考場規則的宣讀與顯示。

-05-

流媒體傳輸網絡的未來

流媒體傳輸網絡的未來主要有4個方向，分別是更低延時、更智能、更開放和算網融合。

隨著AIGC的發展，越來越多的視頻內容，不再局限于拍攝產生，而可以通過AIGC來生成。當如此多內容通過AIGC的方式生產時，更低的延時毫無疑問會帶來更多的玩法。

無論是前面提到的調度系統，還是4層7層聯動的策略，都有很多的智能邏輯在里面。從更大的范圍講，傳輸系統內部存在大量參數與邏輯組合，這些組合目前是經驗性的，或者是通過AB測試選擇出來的，但對這些參數與組合的衡量結果是確定的，通過衡量視頻核心的播放參數，可以構成一個監督學習系統。如何根據反饋，調整網絡里面復雜的參數，更智能無疑是更好的解決辦法。

在視頻領域，兩個最重要的方向就是視頻的處理和視頻的傳輸。視頻處理已擁有很多國際標準，例如H.265、H.266、AV1。但在視頻傳輸上，標準并沒有這么被廣泛定義或者使用，例如，音視頻底層的RTP這樣的傳輸協議標準，只規定了非常基礎的包格式，而在大部分偏向應用的場景下，例如RTMP、HLS等標準都是由一些公司自己制定的，這些標準并沒有進行很好的統一，隨著AIGC的到來，整條視頻鏈路的分工更加細化，行業需要更多的標準幫助不同工具、服務的提供方進行數據交互。阿里云也在積極參與一些協議的標準化，促進協議更加開放。

最后一點是算網融合，正如剛才所說，AIGC的出現，會讓更多的視頻通過計算的方式產生，這個時候就需要更多地把計算能力融合到網絡能力中，通過算網融合，綜合調度，進一步降低整體的資源消耗，同時也帶給用戶更高質量的服務。