NO IMAGE

原文連結:http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598371&idx=1&sn=b9e81fc19c36c0c2a29dc98e27a6b215&chksm=8be99531bc9e1c275c0452fcc5ce9317b9617ca038f867c0d2c0bcd5f3c8c5cb17ea3008b6c8&mpshare=1&scene=2&srcid=10247BAv0yJ4ksnxoTm82Gda&from=timeline&isappinstalled=0#wechat_redirect

到處都在談直播,直播技術目前越來越大眾化,但也面臨著更多的挑戰。本次分享主要介紹直播的一般流程,CDN的技術原理及架構,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,20012
北京到紐約11,000110
赤道周長40,000400

所以說,在節點較少、網路情況較好的情況下,那麼網路延時對應也是最小,加上一定的快取,可以控制延時在1s~2s左右。但是節點多、網路差的情況下,網路延時會對應增大,經驗來說延時可以達到15s以上。

2. 網路抖動

網路抖動,是指資料包的到達順序、間隔和發出時不一致。比如說,傳送100個資料包,每個包間隔1s發出。結果第27個包在傳輸過程中遇到網路擁塞,造成包27不是緊跟著26到達的,而是延遲到87後面才達。在直播中,這種抖動的效果實際上跟丟包是一樣的。因為你不能依照接收順序把內容播放出來,否則會造成失真。

網路抖動,會造成播放延時對應增大。如果網路中抖動較大,會造成播放卡頓等現象。

如上圖所示,主播端t3和t5發出的包,分別在t3’和t5’到達,但是中間延時增大,即發生了網路抖動。這樣造成觀眾端觀看視訊的延時會不斷增大。

3. 網路丟包

CDN直播中用到的RTMP、HLS、HTTP FLV等協議都是在TCP的基礎之上。TCP一個很重要的特性是可靠性,即不會發生資料丟失的問題。為了保證可靠性,TCP在傳輸過程中有3次握手,見下圖。首先客戶端會向服務端傳送連線請求,服務端同意後,客戶端會確認這次連線。這就是3次握手。接著,客戶端就開始傳送資料,每次傳送一批資料,得到服務端的“收到”確認後,繼續傳送下一批。TCP為了保證傳到,會有自動重傳機制。如果傳輸中發生了丟包,沒有收到對端發出的“收到”訊號,那麼就會自動重傳丟失的包,一直到超時。

由於網際網路的網路狀況是變化的,以及主播端的網路狀況是無法控制的。所以當網路中丟包率開始升高時,重傳會導致延時會不斷增大,甚至導致不斷嘗試重連等情況,這樣不能有效的快取,嚴重情況下會導致觀眾端視訊無法觀看。

解決方案

拋棄傳統的基於TCP協議的方案,從底層協議和佈網上開始,使用基於UDP協議的方案。SD-RTN(Software-Defined Real Time Net work),軟體定義實時傳輸網路,是一種新型的專為內容實時傳輸而設計,基於UDP協議的網路架構。SD-RTN通過在網際網路上不同地區的資料中心放置軟體組網單元,相互連線互相排程,在現有的公共網際網路基礎上構建一層新的虛擬網路。能夠實時根據各節點的連線、傳輸狀況、負載狀況、到使用者的距離和響應時間,自動分配最優最通暢的傳輸路徑,達到實時傳輸需要的質量保障級別。

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方案,由於其延遲較低,主播和觀眾可以通過音訊實時互動,而不會感到延遲過大而不自然。使用SD-RTN,可以很好的解決多路RTMP、P2P連麥、伺服器端合圖這幾種方案的弱勢,並且開發難度降低,合圖佈局等都可以很好的在客戶端上進行控制。

具體SD-RTN的架構可以參考下圖:

客戶端均通過UDP連線SD-RTN架構服務,通過SD-RTN的就近接入策略,讓使用者就近接入質量最好的資料節點,經過傳輸延遲和質量優化的最優路徑,自動避免網路擁塞和骨幹網路故障的影響,將資料傳送給其他客戶端。若有常規的長延遲旁路直播,則可以將主播與連麥者合成一路直播流,通過RTMP推到CDN,進行下發。連線這一路的觀眾,不能參與連麥互動,達到了最佳直播效果。