直播，已經成為了“剁手黨”們最喜聞樂見的一種購物形式。對直播體驗的極致追求，也是淘寶技術人們長期的努力方向。為了提升用戶購物體驗，讓直播更加絲滑，讓剁手更快一些，在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協議對接代碼示範，客戶自行升級網絡模塊，底層網絡對接更透明
1.在現有的直播業務新增一個RTS播流域名，一個推流兩種方式拉流。
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的服務側核心能力，希望能給做流媒體技術的同學帶來些許啟發。感謝大家的閱讀。
