直播，已經成為了“剁手黨”們最喜聞樂見的一種購物形式。對直播體驗的極緻追求，也是淘寶技術人們長期的努力方向。為了提升使用者購物體驗，讓直播更加絲滑，讓剁手更快一些，在2020雙十一期間，淘寶首次啟用了阿裡雲CDN的GRTN全球實時傳輸網絡。資料顯示，和傳統的HTTPFLV/RTMP方式相比，在啟用了GRTN後，直播端到端的延時降低了83%。那麼，GRTN到底是什麼？其背後究竟隐藏了哪些核心技術？
這篇文章會通過回顧網際網路直播技術的發展曆程，深度剖析直播延時的技術挑戰，并解讀阿裡雲全球實時傳輸網絡GRTN的設計思路、技術原理、特質與應用實踐，以及GRTN在擺脫傳統直播技術所面臨的内卷化（Involution）窘境所作出的嘗試。GRTN不單單是為網際網路直播而設計，諸如時音視訊RTC等流媒體技術的使用者，比如雲會議、雲遊戲、雲桌面等，在将業務遷移至GRTN後可以有什麼新玩法和創新機遇？本文将為您解答。
作者：子融，阿裡雲進階技術專家，負責阿裡雲視訊直播産品和流媒體實時加速平台研發
網際網路直播技術的進化趨勢
網際網路直播技術的發展大緻可以被分為了4個階段：分别是創新期、演進期、量産期和瓶頸期。
網際網路上的第1場比較有名的直播還要追溯到20多年前，那是20世紀的最後一年，維多利亞秘密（Victoria Secret）線上上直播了她們的時尚走秀，也就是大家今天比較熟知的維密秀，盡管畫面及其不清晰，但也吸引了數以百萬級的觀衆，充分展現了直播這個新物種巨大的吸引力，要知道今天全球著名的流媒體公司Netflix奈非當時還是在靠DVD租賃來維持生計。這段時期我們稱之為直播技術的創新期，它革命性的将觀衆的觀影體驗從離線檔案下載下傳和DVD租賃更新到了線上，但這個時期的直播體驗還是比較差的，展現在時延和卡頓上就是分鐘級的延時并且經常卡頓。
接下來，伴随着網際網路的基礎設施的演進，流媒體技術也得到了長足的發展，這其中典型的代表是流媒體技術演進出了一種對CDN非常友好的模式，即媒體流切片模式，媒體流被分割成2-10s不等的切片檔案，并通過CDN來進行分發，這種特性很好地适應了網際網路延時抖動，進而提供了一種相對流暢的觀影體驗，并且将時延從數分鐘壓縮到了數十秒。這一時期我們稱之為網際網路直播的演講期，這一時期的直播應用主要以電視台體育賽事為主。
時間來到2016年，随着移動網際網路迎來4G時代，美女主播、遊戲主播等應用的興起，互動直播開始爆發，各種直播App如雨後春筍般湧現，這一時期，網紅們已經可以通過自己的手機随時随地的開播，此時國内主流的協定有耳熟能詳的RTMP、HTTPFLV、HLS等，由于底層的傳輸仍然采用TCP，延時普遍在5-10s之間，但畫面已經比較清晰和流暢了。
時至今日，網際網路直播經曆了4年的高速期發展，使用者對體驗的要求越來越高，傳統的5-10s延時很難進行實時互動，比如時下很火的直播帶貨和線上教育業務，主播和觀衆、老師和學生的實時互動體驗還是有很大的改進空間的，另外随着5G時代的到來，新的場景，比如AR/VR沉浸式直播、4K全息投影遠端直播都要求更高帶寬和更低延時。但直播技術近幾年卻未能有本質性的突破，各家直播CDN廠商都投入了大量的精力在對現有基于TCP的RTMP/FLV直播體系的品質優化上，主要優化手段有精細化的排程、精準的覆寫、優質的資源、優化緩存命中率、TCP協定棧優化、直播業務行為分析等，品質優化系統做得越來越精緻，但在時延的提升上也就是在幾百ms左右，甚至就是在扣那幾十ms，卡頓的降低也都是在幾個百分點左右，對實際使用者體驗的提升已經是非常有限了，網際網路直播技術開始遇到了瓶頸，這種内卷化的發展其實是一定程度上制約了業務的發展。
網際網路直播延時分布和技術挑戰
那麼如何才能在延時上有所突破呢？ 要解決這個問題，首先需要剖析一下直播延時的整體分布，網際網路直播全鍊路可以分為7個步驟：分别是采集、編碼、發送、分發、接收、解碼和渲染。
其中采集+編碼，解碼+渲染總體延時比較固定，共100ms左右，變動比較大的部分是分發和接收，從數十毫秒到數秒不等，主要取決鍊路時延抖動、協定棧的優化情況，以及CDN資源的覆寫情況。
在傳統的架構裡，這個7個環節互相獨立，互不相幹，這樣做的好處是團隊分工比較明确，但問題就是優化手段很難做到跨界融合，導緻無法做到系統級優化。比如，編碼器如果可以考慮發送時的擁塞情況來實時調整碼率就可以一定程度上緩解擁塞，進而降低延時；再比如傳統的流媒體傳輸中媒體資料發送和底層的傳輸是互相獨立的，底層TCP傳輸的擁塞控制算法是個通用算法，不會考慮媒體的特性，這樣的一個分層結構是很難形成即時回報系統的，那麼為了保障流暢度，緩存區的大小設計會相對保守，進而犧牲了端到端的時延，如果傳輸層和應用層是一體化的，QoS控制針對媒體特性來專門設計，同時配合編碼側的碼率控制，就能通過組合拳的方式，大大地降低延時。
是以上述各個環節應該是環環相扣，做到全鍊路互相感覺才能将延時壓縮到極緻。
業界主流低延時直播方案對比
業界主流的5種流媒體協定和技術，其中包括WebRTC、QUIC、SRT、CMAF、LLHLS。 這裡的對比從下述8個次元來展開：
提出時間：WebRTC是最早被提出的，QUIC緊随其後，最晚的是去年Apple新釋出的LLHLS
完備度：這裡的完備度主要關注這項技術是否涉及我們前面提到的直播全鍊路中的各個環節，比如WebRTC我們認為是全覆寫的，它涉及了從采集、編解碼、傳輸和渲染的全部環節，是以嚴格來講WebRTC并不是一個協定，而是一個開放的實時流媒體通信架構；那我們再來看QUIC，它是一個正在被IETF标準化的新一代傳輸協定；SRT在2017年剛開源的時候的隻是一個視訊傳輸協定，但随着很多編碼器廠商的支援，也開始可以影響編碼側的碼率，進而保持相對穩定的時延。
底層傳輸協定和類型：WebRTC、QUIC、SRT都是基于UDP的而且都是流式的傳輸，而CMAF和LLHLS都是切片方式的，底層基于HTTP。
标準和終端支援：WebRTC已經是W3C标準，并且使用了大量的IETF RFC規範，目前幾乎所有的浏覽器以及手機作業系統都支援WebRTC；QUIC預計在今年年底會正式成為下一代HTTP标準即HTTP/3，目前Chrome已經支援。
場景和延時：WebRTC是為實時音視訊通信場景設計，端到端延時是在400ms以内，250ms左右； 而其它幾個協定要做到2s以内，都還需要很多的額外技術投入。
綜合各方面因素，阿裡雲的新一代傳輸網絡選擇了WebRTC技術，不僅延時低，而且支援單通道全雙工，可以做到真正意義上的低延時+互動。
GRTN的定位
為了能夠降低直播的端到端延時，阿裡雲CDN與視訊雲聯合手淘技術、達摩院XG實驗室在先後從直播、短延時直播拓展到RTC領域，并在 QoS和AAA方面發力，最終成功建構了GRTN（Global Realtime Transport Network）全球實時傳輸網。
GRTN的定位是基于中心雲和邊緣雲的異構節點，建構超低延時、全分布式下沉的通信級流媒體傳輸網絡。GRTN目前融合了網際網路直播和RTC等多種業務場景的音視訊流傳輸和交換。基于GRTN的短延時直播RTS可以支援标準H5 WebRTC推播，在千萬級并發情況下延時可以控制在1s以内；RTC端到端延時可以控制在250ms左右。
GRTN架構
下圖是一個傳統互動直播系統的典型架構，這個架構的特點是：
• 樹狀層級結構
• 上行推流主流協定：RTMP/WebRTC
• 下行播放的主流協定： HTTPFLV/ RTMP/HLS
• 直播分發和RTC推流系統分離
• 端到端延時~6s
傳統架構的主要缺點是：
• 成本高，主要是媒體資料經過的鍊路長、直播分發和RTC推流系統孤立
• 延時大，因為采用的基于TCP的RTMP/HTTP-FLV協定，而且媒體資料經過的鍊路長
• 擴充難，由于RTMP/HTTP-FLV協定在傳輸上不是全雙工的，是以業務形态是隻能支援單向直播，視訊互動需要借助旁路的連麥系統。
相比于傳統的直播架構，GRTN架構的技術特點是：
• 混合組網：樹狀層級結構+對等圖形網
• 能力下沉：協定邊緣解除安裝+内部傳輸協定歸一化
• 控制和資料分離：動态路徑規劃+全分布式SFU
架構更新所帶來的核心價值是：
• 降成本，GRTN是一個多業務融合的網絡，可以支援直播、RTC和視訊上雲等多種場景，業務複用率高，另外 GRTN内部鍊路更短，節點内的成本也更低。
• 提品質，GRTN内部組網支援采用動态選路的方式來建構的網狀結構，内部鍊路延時可以做到20ms左右，并且内部鍊路采用了私有協定來進行高效傳輸。另外用戶端的推流和分發都是基于WebRTC來建構的，QoS擁塞控制是專門針對流媒體特性來進行設計的，并且還在基于線上資料建設進行持續疊代和打磨。
• 易擴充，GRTN支援了WebRTC協定，可以在單個連接配接通道上進行全雙工的通信，進而可以很自由的進行釋出和訂閱媒體流，在業務的擴充性上帶來了更大的想象空間。
GRTN核心技術 – 對等組網和路徑動态規劃
傳統的直播架構是一種層級的樹狀結構，由于媒體流的鍊路相對比較固定，這種結構的在産品初期可以把研發資源更多的投入在媒體協定的處理上，對于快速建構産品能力是相對風險可控的。但随着業務的發展，這種架構的缺陷也會越發明顯，比如延時高、成本高，而且擴充性也比較差等，在一定程度上是阻礙業務發展的，比如延時很難突破到6s以下，視訊的互動隻能借助旁路連麥系統等。
為了根本上解決這一系列問題，并結合層級結構有助于系統運維和容量評估，而網狀結構有益于建構高品質和低成本的網絡的特性，GRTN采用了混合組網方式，即層級結構和對等圖形方式相結合的組網的方式。選路中心會周期性收集内部鍊路探測的結果，為了配合動态組網，流媒體大腦子產品需要對流資訊進行管理，同時還需要支援路徑切換、容量規劃以及在成本和品質之間做綜合的排程。
GRTN核心技術 – 多路徑傳輸
為了能夠提高GRTN内部鍊路傳輸的可靠性，以及考慮在成本和品質間的均衡，GRTN支援如下3種内部鍊路多路徑傳輸模式：競速模式、備選模式和智能模式，可以在高可靠，品質，成本等諸多因素控制下進行适配和自适應的切換。
GRTN核心技術 – 能力下沉
流媒體技術向來以協定多著稱，主要是因為業務的多樣性導緻，下面是流媒體行業的技術進化趨勢對比表：
上表中隻整理了相對比較通用的協定，可以看到流媒體協定紛繁複雜，在傳統的架構裡這些協定的處理在中心完成，邊緣主要做透傳分發，這樣的問題就是協定處理的鍊路太長，不僅成本高而且延時大，那麼很自然的一個想法就是将協定和媒體處理能力下沉到CDN的邊緣，中心隻是做管控，進而做到類似Service Mesh的設計思想，将控制與資料分離，因為這些協定的本質都是在傳輸音視訊的基本流ES（Elementary Stream，比如常見的H.264/H.265/AAC/OPUS/VP8/VP8/AV1等），不同的協定解決的是不同的封裝格式的傳輸問題，比如有TS（Transport Stream）、PS（Program Stream）、MP4、fMP4（fragment MP4）、FLV等，而不同的封裝格式本質上就是針對不同場景下如何封裝ES流的問題，是以在邊緣設計一種通用的針對不同ES流的傳輸協定和緩存系統是完全可行的。GRTN将協定處理能力下沉到了邊緣節點，目前可以支援RTMP、HTTP-FLV、WebRTC、GB28181等流式協定。
GRTN核心技術 – 雙向實時信令網
前面提到GRTN核心價值之一是高品質，高品質除了延時低以外，還需要考慮快速容災切換能力，以及提升首屏秒開率等核心名額。
在RTC場景下有一個比較常用的功能是用戶端網絡的Mobility，比如使用者在開會的過程中回家或是離開家的時候手機網絡需要在4G和wifi之間切換，另外考慮用戶端接入的CDN節點出現異常的時候，這兩種情況都會造成用戶端在和GRTN通信過程中切換接入節點，GRTN建構的雙向的實時信令網能夠做到切網消息的毫秒級傳遞，當有一個釋出端的媒體流發生網絡切換後，訂閱的用戶端對GRTN内部發生的切換行為是完全無感覺的。
GRTN核心技術 – 持續疊代的QoS
GRTN之是以能夠做到在直播延時由6s降低到1s以内，RTC通信延時做到250ms左右，除了圖形網的結構的改造以及協定下沉等技術外，最核心的還是有采用了有媒體特性感覺的QoS，這和TCP或QUIC這類通用QoS政策在本質上是不一樣。
WebRTC的QoS是一個針對流媒體特性的多元決策體系，涉及到的算法和政策參數非常多，為了友善業務層對底層QoS算法和參數的擇優，GRTN設計了一套可插拔的的QoS內建架構，結合GRTN資料化的品質評估體系，可以做到一次內建持續疊代，不同的算法和參數都可以利用GRTN的A/B品質評估體系進行線上評估，形成賽馬機制。
同時QoS和文章前面提到的動态路徑規劃也是有很多結合點的，QoS研究中的一個很重要課題就是需要區分出網絡的抖動和擁塞，如果是擁塞那就需要回報給上遊進行信源帶寬調配（比如降碼率，流切換等），但如果隻是短暫的抖動，就可以啟用相對激進的抗丢包政策，動态路徑規劃也面臨類似的問題，如果是隻是短暫的擁塞，可以保持目前鍊路并借助QoS的抗丢包政策來扛，但如果是鍊路擁塞了，則需要盡快切換鍊路。
GRTN核心技術 – 流媒體孿生
GRTN更新到網狀結構後也會面臨一些新的挑戰。衆所周知，在618和雙11等大促活動期間確定CDN資源的充足供應是至關重要的，在傳統的層級結構下可以通過業務命中率來分别對L1/L2/中心分别進行評估，而在網狀結構下内部鍊路是動态規劃出來的，也就意味着流量的分布也是動态的，這對于如何評估 CDN的整體容量提出了新的挑戰；再比如動态選路算法如何在品質和成本之間找到均衡點，以確定GRTN系統的低成本高品質？ 為了解決此類問題，GRTN借鑒數字孿生(Digital Twin
https://en.wikipedia.org/wiki/Digital_twin)的思想設計了一個流媒體孿生(Streamimg Media Digital Twin)系統，用于容量評估、算法訓練、事件複盤和模拟壓測等。
GRTN核心技術 – 可程式設計
流媒體技術的上層業務場景非常豐富，比如電商直播、視訊會議、線上教育、企業直播、新零售等，是以有很多定制化開發的需求。可程式設計化改造是GRTN在提升系統穩定性上的一次嘗試，目前GRTN的中心流媒體大腦，節點側的業務子產品，媒體資料發送子產品、媒體信令處理子產品等都已經進行了可程式設計化改造，大部分情況下都可以避免二進制的釋出。
阿裡雲超低延時直播産品RTS
為了更加友善客戶和行業擁抱GRTN，阿裡雲基于GRTN打造了超低延時直播服務RTS，其有四個技術特性：
一、秒級延時和卓越的抗弱網能力，在相同卡頓率下延時可以降低80%，相比于傳統的RTMP和FLV的5-10s延時，RTS的延時可以達到1s以内，并且還在基于線上的大資料，在自我學習和持續疊代中。
二、成熟穩定，RTS曆經2年多時間的潛心研發，并經曆了淘寶直播618大促的線上考驗，目前已經在淘寶直播上線。
三、開放标準，為了能夠友善自研播放器的客戶使用我們的RTS服務，阿裡雲的WebRTC接入的信令協定的完全開放的、透明的。
四、廣覆寫和高并發，RTS服務是建構在阿裡雲2800+邊緣節點之上，可以支援千萬級并發播放。
客戶接入RTS的兩種解決方案
一、對于使用雲廠商播放SDK的客戶，更新播放SDK後可根據業務靈活選擇網絡傳輸協定，打造更高成本效益組合。
1.在現有的直播業務新增一個RTS播流域名，一個推流兩種方式拉流。
2.主播端無需改造，僅更新播放SDK，播放端自動識别不同URL參數。
二、對于自研播放器的客戶，阿裡雲開放與标準WebRTC協定對接代碼示範，客戶自行更新網絡子產品，底層網絡對接更透明
2.主播端不用改造，僅更新播放器網絡子產品，拉取超低延時流播放。
關于低延時+互動體驗更新路徑的未來展望
在流媒體業務的使用者體驗更新上，GRTN今天所帶來的不僅僅是延時的降低，另外一個很重要的能力就是GRTN所提供的靈活的互動能力，GRTN讓直播和RTC的邊界模糊，讓連麥和會議的界限模糊。在GRTN的世界裡隻有媒體流的釋出和訂閱關系，
• 直播：1人釋出多人訂閱
• 1v1用戶端連麥+直播：3人釋出多人訂閱，這裡的第3個釋出是來自主播側的合屏流。
• 1v1服務側連麥+直播： 3人釋出多人訂閱，這裡的第3個釋出是來自于服務側的合流釋出，當合流釋出上來的時候，可以利用GRTN的切流能力做到在連麥切換的時候觀衆無感。
• 視訊會議：多人釋出多人訂閱，GRTN的切流能力可以用于會議中的視訊大小流（高清晰度和低清晰度）切換。
再配合GRTN基于成本和穩定性所提供的分級的時延能力50ms/250ms/800ms/6s/…，就可以勾兌出不同的場景和産品化能力。
線上教育體驗更新
在過去，線上教育比較典型的架構是旁路直播模式，即雲端有個基于WebRTC的RTC媒體中心，老師以及需要實時互動的學員會接入到WebRTC頻道中，然後由RTC媒體中心，轉推一路RTMP流到直播CDN，進行旁路直播，由于直播時延大且協定的不一緻性，在這種情況下觀看直播的學員如果要切入到RTC頻道中進行互動，體驗是比較差的，有時還會有黑屏中斷。
如果希望降低延時并完全解決黑屏問題，那就需要将雲端的WebRTC雙向通信頻道的能力也下沉到GRTN上，由GRTN來承載，将互動和分發進行融合，進而形成一體化的超低延時互動大頻道，通過業務層來控制WebRTC流的訂閱關系，直播和互動頻道間不再有明确的界限，可以靈活的根據業務情況按需在2種模式間進行切換，而且這種切換對學員和老師都是完全無感的，
電商直播體驗的更新
當下的直播帶貨整體架構和上面講的線上教育沒有本質差別，在架構更新路徑上也是可以采用上述同樣的思路。這裡值得一提的是在使用了GRTN後，業務方的技術團隊可以将精力更多的集中在做很多創新的事情上，比如在小主播的帶貨房間裡，以前的互動隻有文字或是1v1的連麥，接入到GRTN後，很容易就可以将這個單向帶貨介紹的房間改造成一個類似視訊會議的多人互動讨論房間，使用者互動體驗提升後是否也能像時延降低一樣帶來GMV的轉換呢？
本篇文章重點介紹的是GRTN的服務側核心能力，希望能給做流媒體技術的同學帶來些許啟發。感謝大家的閱讀。
阿裡雲CDN視訊雲雙11钜惠，點選直達分會場