在上周落幕帷幕的多媒體領域技術盛會——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從安全的角度來考慮, 不會采取這種方式, 是以從一開始就認定在短延時直播這個場景下，我們會使用固定端口的方式來提供服務。下圖是最終的方案，流媒體伺服器會開幾個端口分别支援不同播放形式的通路，允許使用者的端進行的靈活控制。
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備援計算等都會額外增加計算量，在多程序模式下可能還會遇到記憶體資源的過多消耗。