在上週落幕帷幕的多媒體領域技術盛會——LiveVideoStackCon音視訊技術大會上，阿里雲的高階技術專家李剛進行了《下一代低延時的直播CDN》技術分享。主講人李剛，多年關注在CDN這個領域，早期主要研究和cache伺服器快取以及流媒體相關的技術, 專注CDN檔案分發、圖片與大檔案下載等業務。從2015年開始負責全面構建阿里雲CDN直播系統，對流式長連線的分發有很深刻的理解。今天主要分享內容是阿里雲自研低延時直播系統在構建時，遇到的一些技術難點與實踐。

分享從當下直播技術回顧、低延時直播技術思考、低延時直播技術實現、展望四個部分展開，本文為演講原文，希望對直播CDN相關從業者有一定的幫助。

一、直播場景回顧

下圖列舉了當下存在的一些常見的直播場景。

1. 秀場直播是國內最早出現的直播形式，在各個直播平臺上是比較常見的。
2. 遊戲直播，像鬥魚、虎牙、戰旗等直播平臺都是比較典型的遊戲直播平臺，遊戲直播對位元速率要求比較高，觀看人數也多，所以它也是流量貢獻最大的直播形式。
3. 移動直播是最近一兩年比較火的直播形式，比較明顯的特點就是推流和播放比較容易, 通過手機APP就可以進行直播，所以手機直播一般也是推流數最多的直播形式。
4. 活動賽事直播，像今年夏天的世界盃，這類直播一般對互動要求不高，所以一般都是HLS播放形式，延遲相對其他都會多一些。
5. 答題直播是今年年初左右出現的新型直播形式，每場直播的時間不長，突發流量比較高。

這些直播場景，在國內主要用HTTP-FLV和RTMP這種傳輸形式，這兩種傳播形式一般延時在3-5秒，當然這也會受視訊本身GOP影響, 移動直播一般是1-2秒時間間隔，所以控制在3-5秒是比較容易的。但是遊戲直播關鍵幀延時一般在8-10秒，所以遊戲直播的延時更大一些。而活動賽事直播一般不會強調互動性，對流暢度比較高，所以會一般選用HLS，延時在10秒以上。

二、低延時直播需求

3~5秒延時對於多數常見的直播形式一般問題不大, 但是對於某些場景效果會很差。

對於連麥場景影響是最明顯的, 連麥超過1秒，對話可能就沒辦法維持下去了。現在一般直播平臺的連麥直播需求都會藉助第三方的連麥服務，然後再推給直播CDN廠商。

在答題直播場景下, 一般都要求在一段時間內使用者提交答案，如果有各別使用者延遲比較大，這樣對使用者是不公平的。雖然直播平臺仍然使用FLV的傳輸形式完成答題直播，但是基本都會採用SEI插幀等方法來解決時間同步問題, 需要平臺的端和直播CDN做一些配合來完成。

除了連麥、答題場景之外，像線上課堂、線上拍賣等場景因為涉及到實時性的互動，對延時的要求也比較高。

從對業務的支援層面來看, 僅僅有RTMP、FLV這種3~5秒延時以上的直播形式已經不夠了, 需要對更低延遲的直播業務進行支援。從技術的角度來看，國內常用的FLV、RTMP這種直播手段，本身是Adobe自己的標準, 而且很快會停止對flash的維護, 另一方面WebRTC技術的興起，Chrome、Safari等瀏覽器也都進行了支援，因此也需要對新的技術有一些調研和準備。

基於對於這些問題的思考, 阿里雲CDN也開展了對低延時直播技術的研發。

三、短延時直播VS實時音視訊通訊

簡單介紹下實時音視訊通訊和短延時直播的區別：

使用WebRTC主要用於解決實時音視訊通話的需求，必然對延遲要求非常嚴格, 一個會議室中參與的多方可以進行視訊通話, 每個參與者可以看到其他參與者，也能聽到其他參與者說話。每個參與者既有推流，又有播放，資料是雙向的。所以參與人數不會太多，一般不能超過20個。 短延時直播仍然是直播業務型別, 只是延時比較低, 短延時直播的業務模型相對簡單, 資料單向傳輸，一個主播推流，參與的播放者人數沒有限制，上百萬都可以。

四、技術選型的思考

在做短延時直播專案的時候，我們在技術選型上做了一些思考。

首先，是必須要相容已有直播業務和技術棧，因為阿里雲直播CDN系統已經有了很多客戶，短延時直播需要從現有直播的業務上慢慢衍生, 可以讓客戶在短延時和常規直播手段進行切換, 這也是處於業務穩定性的考慮。

第二，對於直播來講, 秒開是一個很重要的指標，我們後面詳細展開。當然卡頓也是重要的指標，因為WebRTC在移動端擁塞控制和重傳方面有一些處理，所以卡頓率方面不會比TCP差。

第三，對齊到WebRTC會是最終的結果, 畢竟使用者能夠使用H5就可以直接推流或者觀看直播, 更方便客戶的接入和使用。但由於完整的支援WebRTC要解決加解密、打洞、音訊格式等問題, 所以前期考慮只使用WebRTC中的一部分技術，完整支援WebRTC會是二期的工作。

五、TCP的可能性

已有的業務，無論是圖片、大小檔案、點播、直播，這些都是在TCP通訊基礎上實現的，所以短延時直播在開展的時候我們就思考了TCP的可能性。

我們對於短延時的目標定義為從端到端800毫秒以內，一場直播的延遲來自於推流端延遲、CDN產生的延遲、播放端延遲這三個方面，很多客戶會關注CDN產生的延遲，我們也對資料進行過統計，CDN從入到出所產生的總延時，全網平均不到100毫秒，晚高峰平均也不超過200毫秒。而從經驗角度來看，播放端的延遲會比較嚴重，主要是兩方面，一方面是開播時候卡前一個關鍵幀所帶來的延遲，另一方面如果CDN伺服器到播放端有抖動，累積的延遲會越來越多。

之前有一個彩票直播業務的客戶, 因為客戶擔心使用者懷疑刮獎的時效性, 所以對延時要求就非常苛刻, 客戶的端進行延遲優化, 延遲也可以做到1秒內。

所以，一開始我們有了這樣一個結論，網路正常的情況下，使用現有的RTMP、FLV進行分發，延遲也可以做到1秒以內。

但是現實情況是網路是不可能出現不丟包的情況。當網路抖動出現丟包的時候，TCP是ACK確認機制的，也就是傳送方傳送一包之後，一定要等過對方迴應，才會繼續發。如果說網路一旦出現丟包，就會在一個RTO之後重傳，RTO的值和RTT有關，並且RTO的最小值是200ms。如果想保證流暢性，你的播放端一定要至少能容忍200ms以上的抖動，但播放端的jitbuffer太多又無法滿足低延時的要求。

這裡對一下比WebRTC中RTP傳輸使用的NACK機制，NACK的丟包反饋更加及時，如果網路是偶然性抖動居多的時候, NACK機制效果更加好。這裡我們也做了一個統計，全網平均RTT小於15ms，如果CDN節點覆蓋足夠好的情況下，延遲理論上會很低。以1.5Mbps位元速率的音視訊流舉例，每秒鐘100個包，包和包之間就是10ms的間隔。如果當第二個丟包出現的時候，第三個包對方接收到了，就可以馬上知道第二個包是丟掉了，就可以立刻返回一個NACK，進行重傳。在這種極限情況下，重傳間隔就是25ms，相比之前TCP的200ms是一個質的提升，想滿足絕大部分播放延遲在800ms以內才有可能。

另外，使用TCP的話，無效傳輸沒法避免,。TCP是採用socket buffer進行通訊，資料也是從應用層先進入socket buffer再分發。對於RTMP或FLV的分發來說，假如某一幀的資料的一部分已經進入了socket緩衝區, 那麼也必須將這一幀剩餘的資料傳送出去, 如果剩餘的資料不發出去的話, 播放端會出現解析錯誤, 斷開連線, 這個體驗會很差。

而在網路在出現波動的時候, 有可能這socket buffer裡面的資料很久之後才能傳送到對方, 而在短延時直播的場景下, 這些socket buffer裡面和應用層太久的資料再發送給播放端已經沒有意義，也就是說會產生很多無效的傳輸。

六、自研短延時直播方案

基於這些考慮，我們最終採用了以下的方案。WebRTC是當下短延時流媒體的傳輸比較熱門的技術, 所以在實現短延時直播的同時會考慮使用WebRTC相關的一些技術。原有的RTMP, FLV, HLS這些使用TCP，新增阿里自研私有ARTP短延時方案，最終會支援WebRTC，ARTP和WebRTC使用UDP傳輸。

在研發之前，我們會對各項部署做一些思考。

1.埠問題

WebRTC的預設工作方式SFU伺服器會為每個參與者需要為其他每個參與者分配一個埠, 一定程度上來說是通過不同的埠來區分參與者。而CDN從安全的角度來考慮, 不會採取這種方式, 所以從一開始就認定在短延時直播這個場景下，我們會使用固定埠的方式來提供服務。下圖是最終的方案，流媒體伺服器會開幾個埠分別支援不同播放形式的訪問，允許使用者的端進行的靈活控制。

2. 秒開問題

這裡講一下播放秒開的問題, 如果採用標準的WebRTC方式，那麼需要經過下圖這樣幾個環節。

這樣下來對於直播秒開的體驗來說就會很差，所以在實現低延時直播方案時針對這個問題需要進行優化處理, 去掉一些不必要的環節。

CDN伺服器本身是有公網IP和埠的, 播放端沒有獨立的公網IP和埠，如果是像WebRTC這麼實現的話, 伺服器把資料直接傳給播放端，那麼必然涉及到打洞探測的問題，所以如果想要達到秒開效果的話，就不能使用WebRTC的這種方式, 需要讓播放端先給伺服器傳送請求, 讓自己所在的NAT閘道器建立起對映之後，伺服器再把資料吐給客戶端時就OK了。

上圖就是最終的時序圖，使用的是比較簡單的應答模式。沒有了TCP的三次握手環節，所以秒開效果一定比FLV、RTMP更好。同時，客戶端直接發起播放請求，請求包長度儘量控制在一個UDP包內，不要出現一個請求兩個包的情況。

國內直播平臺大部分還是使用h264和AAC，所以我們也是首先支援這兩種格式，其他音視訊格式像HEVC等也是我們後續要支援的格式。

3.RTP報文

PT欄位是載荷型別，sequence number是包序列號，傳送端切片的時候，寫好序列號，接收端依據這個序列號進行資料的還原。而且在重傳發生的時候，還依靠這個序列號進行NACK的反饋。時間戳對流媒體傳輸非常重要，播放器依賴它進行解碼和同步。SSRC用來識別不同的身份，同一個IP和埠被NAT重新分配的時候, SSRC識別出這是一個不同的連線。

前面講過使用TCP傳輸的時候，網路抖動出現堆積時，需要丟幀，但是一定是丟完整的幀，不能丟片段。那為什麼RTP場景下為什麼沒有這個問題？以H264為例，RTP在封裝的時候，如果NAL單元小於MTU，那麼我們認為一個RTP包可以完整封裝一個NAL單元的，如果出現丟幀，那麼我們認為缺少的是一個完整的NAL單元，對後面NAL單元解析是沒有問題的，不會出現資料錯亂。

如果一個NAL單元大於一個MTU的時候，假設一個NAL單元需要三個RTP包封裝，不管丟到哪一個還是全部丟掉，接收端都可以標識出這個NAL單元，不會影響其他NAL單元的解析。

4.平滑傳送機制

現在採用的混合擁塞演算法，基於丟包率和基於延遲進行位元速率控制。標準的做法是，當播放卡頓時，會讓傳送端降位元速率。

從兩個方面來看，當推流端上行出現抖動的時候，伺服器會反饋資料包，把位元速率自動降下來。當播放端出現下行抖動的時候，一種是輸出轉碼流，另一種是讓主播推兩路流上來，讓播放卡頓的使用者換到低位元速率。

5.播放端上的優化

第一階段是開播階段，獲得GOP資料的時候，如果端不做處理的話，一定會有一個延遲。所以在這個階段，播放端一定進行快進的操作，縮短延遲。第二階段是當網路出現抖動的時候，會慢慢放大buffer的長度，來一定程度上適應抖動，提高流暢度。第三階段，當網路恢復的時候，我們可以適當快進，減小buffer，把進度趕回來。也就是說這個buffer大小是動態變化的。

6.RTC內部打包機制

H264和AAC資料會在內部先進行切片，放到平滑傳送佇列再發送給對端，同時重傳包也會進入平滑傳送佇列, 並且會放到平滑傳送佇列的隊首位置。

7.FEC冗餘傳輸

FEC是靠冗餘傳輸，來提高容錯率。關鍵幀10%冗餘率, 非關鍵幀5%，根據丟包判斷出網路狀況，動態調整冗餘度。

8.UDP傳輸注意事項

UDP無連線，也就沒有TCP的連線斷開時的揮手確認連線關閉的機制。那麼對於主播來說，如果出現斷開，然後短時間再重推的話就會遇到問題，因為CDN會認為前一個推流連線還在，新的推流連線推的是同名流，會拒絕掉新的連線，主播也會反饋無法推流。對於播放來說，雖然沒有同名流問題，但是如果播放端不再觀看，CDN伺服器會仍然將資料傳送給指定的IP和埠，這就產生了很多無效的傳輸。最終會反映到流量和計費日誌上。所以採用RTCP報文的方式，對於播放和推流連線的斷開進行通知，節省資源消耗, 流搶佔等問題。

9.探活策略

除了對於正常關閉進行主動通知之外, 還需要對超時情況進行處理。即便是TCP傳輸的時候也有類似的問題，推流端傳送了FIN結束報文，但是伺服器未必收到，所以一定要有超時的機制來進行管理。我們採用資料及時反饋的機制，在下行播放端要求週期性的返回心跳，上行要求推流端在8或10秒內一定要有一些真實資料傳輸，否則我們就會斷開。

這幅時序圖更細緻的展開了一下實現的邏輯，播放端和伺服器。

Tengine是阿里開源的伺服器軟體, 阿里雲CDN的檔案、點播、直播功能都是在其基礎上進行開發，而在短延時直播功能的實現我們也是把開源的WebRTC的庫進行了一些改造。選擇Tengine來做主要原因也是因為對其非常的熟悉，而且在其基礎上也積累了很多配套的技術，包括配置下發管理、日誌收集、業務處理等。

最後，我們來看下實際的資料情況。 目前短延時直播功能是在一些地區進行了部署和驗證，還沒到全網鋪開的階段。 秒開資料比原來FLV訪問提升很大, UDP互動省去了三次握手環節。錯誤率和延遲都有了較大的提升。這裡目前只對比了下行，從已經灰度的一些節點來看，上行卡頓資料要優於原有RTMP的推流。

七、後續展望

完整的支援WebRTC一定是目標, 畢竟直接通過瀏覽器就可以完成推流和播放對於使用者的接入來說實在太方便, 對於CDN來講控制接入一定是一個必須做的事情。

對於CDN要做的另一個事情就是優化傳輸，其實無論對於檔案加速還是流媒體加速，傳輸永遠都是最重要的，CDN這個分發網路本身就是為了優化傳輸而存在。

從實踐來看，UDP傳輸比原來的TCP傳輸對資源消耗要多，而且重傳、封包、FEC冗餘計算等都會額外增加計算量，在多程序模式下可能還會遇到記憶體資源的過多消耗。

雲伺服器99元拼團購！拉新還可贏現金紅包！300萬等你瓜分！ 馬上一鍵開團贏紅包： http://click.aliyun.com/m/1000019899/

閱讀原文