[直播CDN原理][解決延時][連麥問題]

 

• 直播的通常流程；

• CDN的技術原理及架構；

• CDN直播的技術難點和應對方案；

• 基於SD-RTN的，針對低延遲、強互動場景的直播技術。

 

直播的流程

 

正如上圖所示，整個直播流程分爲如下幾個關鍵步驟：

 

• 主播客戶端，將本地採集的視頻推送到CDN；

• CDN對視頻流進行緩存以及轉發；

• 觀衆客戶端，拉取CDN中緩存視頻流進行播放；

 

能夠看到CDN在這裏起到了關鍵的做用，2016也是一個CDN崛起的年代，網宿、快網、七牛、高升、藍汛、觀止雲、騰訊雲、百度雲、阿里雲等CDN紛紛表示對直播進行了支持，直播也逐漸成爲了CDN的標配。

那麼接下來了解一下CDN的技術原理。

CDN技術原理

CDN的全稱爲Content Delivery Network，即內容分發網絡，是一個策略性部署的總體系統，主要用來解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均勻等致使用戶訪問網站速度慢的問題。

 

CDN的技術原理見上圖，具體實現是經過在現有的網絡中，增長一層新的網絡架構，將網站的內容發佈到離用戶最近的網絡節點上，這樣用戶能夠就近獲取所需的內容，解決以前網絡擁塞、訪問延遲高的問題，提升用戶體驗。

對於直播來講，則將Web服務器換做主播客戶端，以下圖所示。

 

因爲視頻佔用帶寬較大，與普通的Web服務差異較大，這樣CDN的優點更能體現出來：網絡擁塞減小，訪問延遲下降，帶寬獲得良好的控制等等。

另外，CDN直播中經常使用的流媒體協議包括RTMP、HLS、HTTP FLV等。

 

• RTMP（Real Time Messaging Protocol）是基於TCP的，由Adobe公司爲Flash播放器和服務器之間音頻、視頻傳輸開發的開放協議。

• HLS（HTTP Live Streaming）是基於HTTP的，是Apple公司開放的音視頻傳輸協議。

• HTTP FLV則是將RTMP封裝在HTTP協議之上的，能夠更好的穿透防火牆等。

 

 

CDN的經常使用架構

CDN架構設計比較複雜，而且不一樣的CDN廠商，對其架構進行不斷的優化，因此架構也不能統一而論。這裏只是對一些基本的架構進行簡單的剖析。

CDN主要包含源站、緩存服務器、智能DNS、客戶端等幾個主要組成部分。

源站是指發佈內容的原始站點。添加、刪除和更改網站的文件，都是在源站上進行的；另外緩存服務器所抓取的對象也所有來自於源站。對於直播來講，源站爲主播客戶端。

緩存服務器是直接提供給用戶訪問的站點資源，由一臺或數臺服務器組成；當用戶發起訪問時，他的訪問請求被智能DNS定位到離他較近的緩存服務器。若是用戶所請求的內容恰好在緩存裏面，則直接把內容返還給用戶；若是訪問所需的內容沒有被緩存，則緩存服務器向鄰近的緩存服務器或直接向源站抓取內容，而後再返還給用戶。

智能DNS是整個CDN技術的核心，它主要根據用戶的來源，以及當前緩存服務器的負載狀況等，將其訪問請求指向離用戶比較近且負載較小的緩存服務器。經過智能DNS解析，讓用戶訪問同服務商下、負載較小的服務器，能夠消除網絡訪問慢的問題，達到加速做用。

客戶端即發起訪問的普通用戶。對於直播來講，就是觀衆客戶端。

對於直播來講，CDN總體架構以下圖：

 

主要流程爲：

 

1. 主播開始進行直播，向智能DNS發送解析請求；

2. 智能DNS返回最優CDN節點IP地址；

3. 主播端採集音視頻數據，發送給CDN節點，CDN節點進行緩存等處理；

4. 觀衆端要觀看此主播的視頻，向智能DNS發送解析請求；

5. 智能DNS返回最優CDN節點IP地址；

6. 觀衆端向CDN節點請求音視頻數據；

7. CDN節點同步其餘節點的音視頻數據；

8. CDN節點將音視頻數據發送給觀衆端；

 

說了這麼多CDN的技術和原理，不知道您看累了沒，那麼CDN直播是否萬事大吉了呢？接下來分析一下CDN的難點和解決方案。

CDN難點：播放延時

一提到直播，你們確定會想到播放延時的問題，那爲何會播放延時了？咱們從如下幾個方面分析：

1. 網絡延時

網絡延時這裏指的是從主播端採集，到觀衆端播放，之間的時間差。這裏不考慮主播段採集對視頻進行編碼的時間，以及觀衆端觀看對視頻進行解碼的時間，僅考慮網絡傳輸中的延時。例如說下圖中的網絡延時：

 

假設在該鏈路上有緩存，時間爲Tmax_cache ，那麼從主播到觀衆的延時Tdelay爲：

另外，數據傳輸過程當中還涉及到邏輯上的交互，例如包的重傳以及確認，以及緩存上的一些邏輯等，會在這個基礎上又增長不少。

那麼來簡單估算一下大概的網絡延時。衆所周知，光在真空中的速度約爲300,000km/s，而在其餘介質中光速會大大下降，因此在普通光纖中，工程上通常認爲傳輸速度是200,000km/s。從現實上來講，能夠參考以下：

路線 距離（km） 往返時延（ms）

北京到上海 1,200 12

北京到紐約 11,000 110

赤道周長 40,000 400

因此說，在節點較少、網絡狀況較好的狀況下，那麼網絡延時對應也是最小，加上必定的緩存，能夠控制延時在1s~2s左右。可是節點多、網絡差的狀況下，網絡延時會對應增大，經驗來講延時能夠達到15s以上。

2. 網絡抖動

 

 

如上圖所示，主播端t3和t5發出的包，分別在t3'和t5'到達，可是中間延時增大，即發生了網絡抖動。這樣形成觀衆端觀看視頻的延時會不斷增大。

3. 網絡丟包

CDN直播中用到的RTMP、HLS、HTTP FLV等協議都是在TCP的基礎之上。TCP一個很重要的特性是可靠性，即不會發生數據丟失的問題。爲了保證可靠性，TCP在傳輸過程當中有3次握手，見下圖。首先客戶端會向服務端發送鏈接請求，服務端贊成後，客戶端會確認此次鏈接。這就是3次握手。接着，客戶端就開始發送數據，每次發送一批數據，獲得服務端的「收到」確認後，繼續發送下一批。TCP爲了保證傳到，會有自動重傳機制。若是傳輸中發生了丟包，沒有收到對端發出的「收到」信號，那麼就會自動重傳丟失的包，一直到超時。

 

因爲互聯網的網絡情況是變化的，以及主播端的網絡情況是沒法控制的。因此當網絡中丟包率開始升高時，重傳會致使延時會不斷增大，甚至致使不斷嘗試重連等狀況，這樣不能有效的緩存，嚴重狀況下會致使觀衆端視頻沒法觀看。

解決方案

 

CDN與SD-RTN對比狀況以下：

 

• 基本原理不一樣。CDN是存儲轉發結構，設計目的是在各個邊緣節點緩存待分發內容，結構上從源站到觀衆是傘狀多級緩存放大方式。SD-RTN本質上一個實時傳輸網絡，用戶的數據在網絡單元內部和傳輸線路上都以實時交換方式傳送，UDP實現的傳輸協議，不會由於前一個包的丟失或延遲致使下後續包的延遲送達，而丟包能夠用對延遲更友好的方式修復或補償出來，從而可以保證最低延遲。

• 底層協議不一樣。SD-RTN採用了專爲實時傳輸設計的UDP協議，避免了採用TCP的延時不可控缺點。可以大大縮短交互延時，延時可從CDN方案的數秒，下降到數百毫秒。

• 內容分發機制不一樣。SD-RTN是基於自定義路由，選擇最優傳輸路徑，直接將內容端到端傳輸，數據在網絡單元中從不緩存，從而最大可能的下降延遲，同時內容安全性也更好。CDN是將內容緩存於緩存服務器中，再將內容就近下發，因此CDN更適合作內容分發，一對多的場景。

• 使用場景不一樣。SD-RTN適用於要求極低時延的實時互動場景，例如網絡電話、視頻會議、有主播與觀衆交互需求的互動直播等。CDN適用於對時延要求不高的場景，例如對延時要求不高、相似電視的單點直播、網站加速等。

 

SD-RTN的優點以下：

 

• 時延大大縮短。直播延時可從基於TCP的方案的數秒，下降到數百毫秒。這一延遲範圍，屬於實時通訊或準實時通訊延遲的範疇。在這一級別上，主播和觀衆能夠基本重如今現場活動中的交互體驗，從而大大釋放了內容製做者的潛力，也爲業務運營者創造新業務形式打開了無限的空間和可能。

• 抗丟包能力強。通常來講，SD-RTN中能夠針對用戶網絡使用更多的策略模型和技術，這樣在30%丟包時，依然可以進行正常直播。而基於TCP的直播方案在丟包2%時就明顯卡頓，達到30%常常已斷開鏈接，沒法進行直播。

 

CDN難點：連麥

直播中，主播若是要與用戶交互，常見有兩種方式：

 

• 第一種方式：文字，這種比較常見，實現也比較簡單，這裏再也不進行分析；

• 第二種方式：連麥，這樣主播能夠面對面與觀衆進行交互，增長了互動性；

 

因爲連麥方式比較複雜，這裏進行詳細分析。

1. 多路RTMP流實現

前面提到，RTMP是目前主播中最經常使用的協議，使用RTMP協議，能夠實現最簡單的一種連麥方式，以下圖。

 

當有連麥者時，則主播端和連麥者端，都分別推一路RTMP流到CDN，CDN再將這兩路RTMP流發送給觀衆端，觀衆端將兩路RTMP流合成爲一個畫面。這種方式的優勢是實現簡單，但缺點比較多：

 

• 主播與連麥者若是要進行交互，則考慮到上面分析的延時問題，在這裏延時須要至少加大一倍，這樣對於實時交互來講，徹底沒法接受；

• 主播與連麥者交互時，聲音會產生干擾，造成迴音；

• 觀衆端要接收兩條視頻流，帶寬、流量消耗過大，而且兩路視頻流解碼播放，耗費CPU等資源也很是多；

 

這樣看來，這種方式弊大於利，基本不可取。

2. 主播端與連麥者P2P

第二種方式，是主播端與連麥者之間使用P2P方式進行交互，而後主播端將本身和連麥者的視頻進行合併，再推到CDN上，CDN再發送給觀衆端，以下圖：

 

這種方式的優勢有兩個，一是主播和連麥者之間使用P2P，網絡質量較好，延遲較小，保證了二者之間交互不會有很是大的延時；二是能夠解決聲音的干擾問題，消除回聲。缺點是：

 

• P2P在某些網絡下沒法穿透，有些觀衆根本沒法與主播端進行交互；

• 主播端須要上傳兩路視頻：一路P2P與連麥者進行交互，一路使用RTMP推到CDN。還要下載一路視頻：連麥者P2P發送過來的交互數據。因此主播端要求帶寬須要較高，網絡較差時沒法進行主播；

• 主播端要進行多路視頻的編碼、解碼，要求主播端設備配置比較高，較差的設備也沒法進行主播；

• 只能支持一個連麥者，不能支持多個連麥者；

• 因爲主播端和連麥者通過CDN合併成一路，所以，不能實現主播端和連麥者視頻大小窗口切換。

 

綜合來講，P2P方式在必定程度上能夠解決連麥的問題。

3. 服務器端合圖

另一種方式，是主播和連麥者都將視頻推送到CDN中，而後CDN內部對這幾路視頻進行合圖，再將其發送給觀衆端。以下圖：

 

這種方式的優缺點以下：

優勢

 

• 主播和連麥者各路視頻都使用RTMP推送到CDN，能夠保證延時較小；

• 因爲CDN進行視頻合圖和發送，因此主播不須要很高的帶寬；

• 因爲CDN進行視頻合圖，因此主播的設備不須要配置很是高；

• 沒有聲音干擾問題；

• 能夠支持多個連麥者連麥；

 

缺點

 

• CDN須要進行視頻的合圖，須要額外開發工做，而且邏輯比較複雜；

• CDN須要進行視頻的合圖，須要消耗較高服務器資源；

• CDN合圖後的佈局難控制；

• 據目前所知，尚未CDN支持這種方案；

 

解決方案

具體SD-RTN的架構能夠參考下圖：

 

 

 

轉載自：http://www.javashuo.com/article/p-cdxhqdug-kc.html