摘要： 在上週落幕帷幕的多媒體領域技術盛會——LiveVideoStackCon音視頻技術大會上，阿里雲的高級技術專家李剛進行了《下一代低延時的直播CDN》技術分享。主講人李剛，多年關注在CDN這個領域，早期主要研究和cache服務器緩存以及流媒體相關的技術, 專注CDN文件分發、圖片與大文件下載等業務。
在上週落幕帷幕的多媒體領域技術盛會——LiveVideoStackCon音視頻技術大會上，阿里雲的高級技術專家李剛進行了《下一代低延時的直播CDN》技術分享。主講人李剛，多年關注在CDN這個領域，早期主要研究和cache服務器緩存以及流媒體相關的技術, 專注CDN文件分發、圖片與大文件下載等業務。從2015年開始負責全面構建阿里雲CDN直播系統，對流式長連接的分發有很深刻的理解。今天主要分享內容是阿里雲自研低延時直播系統在構建時，遇到的一些技術難點與實踐。
分享從當下直播技術回顧、低延時直播技術思考、低延時直播技術實現、展望四個部分展開，本文爲演講原文，希望對直播CDN相關從業者有一定的幫助。
一、直播場景回顧
下圖列舉了當下存在的一些常見的直播場景。
秀場直播是國內最早出現的直播形式，在各個直播平臺上是比較常見的。
遊戲直播，像鬥魚、虎牙、戰旗等直播平臺都是比較典型的遊戲直播平臺，遊戲直播對碼率要求比較高，觀看人數也多，所以它也是流量貢獻最大的直播形式。
移動直播是最近一兩年比較火的直播形式，比較明顯的特點就是推流和播放比較容易, 通過手機APP就可以進行直播，所以手機直播一般也是推流數最多的直播形式。
活動賽事直播，像今年夏天的世界盃，這類直播一般對交互要求不高，所以一般都是HLS播放形式，延遲相對其他都會多一些。
答題直播是今年年初左右出現的新型直播形式，每場直播的時間不長，突發流量比較高。
這些直播場景，在國內主要用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從安全的角度來考慮, 不會採取這種方式, 所以從一開始就認定在短延時直播這個場景下，我們會使用固定端口的方式來提供服務。下圖是最終的方案，流媒體服務器會開幾個端口分別支持不同播放形式的訪問，允許用戶的端進行的靈活控制。
- 秒開問題
這裏講一下播放秒開的問題, 如果採用標準的WebRTC方式，那麼需要經過下圖這樣幾個環節。![阿里雲李剛：下一代低延時的直播CDN]()
這樣下來對於直播秒開的體驗來說就會很差，所以在實現低延時直播方案時針對這個問題需要進行優化處理, 去掉一些不必要的環節。
CDN服務器本身是有公網IP和端口的, 播放端沒有獨立的公網IP和端口，如果是像WebRTC這麼實現的話, 服務器把數據直接傳給播放端，那麼必然涉及到打洞探測的問題，所以如果想要達到秒開效果的話，就不能使用WebRTC的這種方式, 需要讓播放端先給服務器發送請求, 讓自己所在的NAT網關建立起映射之後，服務器再把數據吐給客戶端時就OK了。
上圖就是最終的時序圖，使用的是比較簡單的應答模式。沒有了TCP的三次握手環節，所以秒開效果一定比FLV、RTMP更好。同時，客戶端直接發起播放請求，請求包長度儘量控制在一個UDP包內，不要出現一個請求兩個包的情況。
國內直播平臺大部分還是使用h264和AAC，所以我們也是首先支持這兩種格式，其他音視頻格式像HEVC等也是我們後續要支持的格式。
3.RTP報文
PT字段是載荷類型，sequence number是包序列號，發送端切片的時候，寫好序列號，接收端依據這個序列號進行數據的還原。而且在重傳發生的時候，還依靠這個序列號進行NACK的反饋。時間戳對流媒體傳輸非常重要，播放器依賴它進行解碼和同步。×××C用來識別不同的身份，同一個IP和端口被NAT重新分配的時候, ×××C識別出這是一個不同的連接。
前面講過使用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冗餘計算等都會額外增加計算量，在多進程模式下可能還會遇到內存資源的過多消耗。