處處都在說直播連麥技術,它們真的能連嗎?

直播火了。連麥直播在火的路上。緩存

那麼,這些連麥技術方案,真的能連嗎?本文將常見的,不常見的直播技術方案進行了比較,各位同窗本身甄別。安全

首先,基礎知識普及,技術上直播的流程是什麼?服務器

1、直播的流程

圖片描述

正如上圖所示,整個直播流程分爲如下幾個關鍵步驟:網絡

一、主播客戶端,將本地採集的視頻推送到CDN;
二、CDN對視頻流進行緩存以及轉發;
三、觀衆客戶端,拉取CDN中緩存視頻流進行播放;

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

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

2、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協議之上的,能夠更好的穿透防火牆等。

3、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節點將音視頻數據發送給觀衆端;

4、CDN的短板

大概瞭解了CDN的技術原理後,咱們在作直播選型時,還須要瞭解一個方案優缺點。接下來,咱們來分析一下CDN的短板。

4.1 短板:播放延時

連麥直播的難題主要是播放延時!播放延時從何而來?

4.1.1 網絡延時

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

圖片描述

假設每一個節點進行緩存的時間爲Tcache,那麼從主播到觀衆的延時Tdelay爲:

Tcache=Tdelay1+Tcache1+Tdelay2+Tcache2+Tdelay3+Tcache3+Tdelay4+Tcache4+Tdelay5

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

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

圖片描述

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

4.1.2 網絡抖動

網絡抖動,是指數據包的到達順序、間隔和發出時不一致。好比說,發送100個數據包,每一個包間隔1s發出。結果第27個包在傳輸過程當中遇到網絡擁塞,形成包27不是緊跟着26到達的,而是延遲到87後面才達。在直播中,這種抖動的效果實際上跟丟包是同樣的。由於你不能依照接收順序把內容播放出來,不然會形成失真。

網絡抖動,會形成播放延時對應增大。若是網絡中抖動較大,會形成播放卡頓等現象。

圖片描述

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

4.1.3 網絡丟包

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

圖片描述

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

4.2 短板:連麥

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

第一種方式:文字,這種比較常見,實現也比較簡單,這裏再也不進行分析;
第二種方式:連麥,這樣主播能夠面對面與觀衆進行交互,增長了互動性;
因爲連麥方式比較複雜,這裏進行詳細分析。

4.2.1 多路RTMP流實現

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

圖片描述

當有連麥者時,則主播端和連麥者端,都分別推一路RTMP流到CDN,CDN再將這兩路RTMP流發送給觀衆端,觀衆端將兩路RTMP流合成爲一個畫面。這種方式的優缺點以下:

  • 優勢

    • 實現簡單;

  • 缺點

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

    • 主播與連麥者交互時,聲音會產生干擾,造成迴音;
      觀衆端要接收兩條視頻流,帶寬、流量消耗過大,而且兩路視頻流解碼播放,耗費CPU等資源也很是多;

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

4.2.2 主播端與連麥者P2P

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

圖片描述

這種方式的優缺點以下:

  • 優勢

    • 主播和連麥者之間使用P2P,網絡質量較好,延遲較小,保證了二者之間交互不會有很是大的延時;
      解決聲音的干擾問題,消除回聲;

  • 缺點

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

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

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

    • 只能支持一個連麥者,不能支持多個連麥者;

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

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

4.2.3 服務器端合圖

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

圖片描述

這種方式的優缺點以下:

  • 優勢

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

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

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

    • 沒有聲音干擾問題;

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

  • 缺點

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

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

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

    • 據目前所知,尚未CDN支持這種方案;

5、基於SD-RTN的解決方案

聲網Agora.io,在開發互動直播解決方案時,拋棄傳統的基於TCP協議的CDN方案,從底層協議和佈網上開始,建立了基於UDP協議的SD-RTN方案。

(一)什麼是SD-RTN

SD-RTN(Software-Defined Real Time Net work),軟件定義實時傳輸網絡,是一種新型的專爲內容實時傳輸而設計的網絡架構。經過在互聯網上不一樣地區的數據中心放置軟件組網單元,相互鏈接互相調度,在現有的公共互聯網基礎上構建一層新的虛擬網絡。SD-RTN系統可以實時根據各節點的鏈接和傳輸情況、負載情況以及到用戶的距離和響應時間,自動分配最優、最通暢的傳輸路徑,達到實時傳輸須要的質量保障級別。

(二)SD-RTN與CDN有何不一樣

  • 基本原理不一樣。CDN是存儲轉發結構,設計目的是在各個邊緣節點緩存待分發內容,結構上從源站到觀衆是傘狀多級緩存放大方式。SD-RTN本質上一個實時傳輸網絡,用戶的數據在網絡單元內部和傳輸線路上都以實時交換方式傳送,從而可以保證最低延遲。

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

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

  • 使用場景不一樣。SD-RTN適用於要求極低時延的實時互動場景,例如網絡電話、視頻會議、有主播與觀衆交互需求的互動直播等。CDN適用於對時延要求不高的場景,例如對延時要求不高、相似電視的單點直播、網站加速等。若硬要將CDN改造用於互動直播,那麼其結構上對下降延遲的不適應性,始終會成爲質量改進需求的瓶頸。

(三)SD-RTN相較CDN,有何優勢

一、時延大大縮短。

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

好比,在這一延遲下,主播和觀衆能夠不光經過文字交互,也能夠經過音頻實時交互,而不會感到延遲過大而不天然。這種交互體驗,在手機上也更天然,比打字更符合人的天然習慣。業務運營方固然能夠把這一功能看成比文字互動更高級別的特權能力,僅僅對於付費或是必定級別、身份的用戶才能夠直接和主播語音互動。業務運營者也能夠利用此類功能創造相似課堂,或小劇場的現場互動氛圍,讓主播能夠聽獲得觀衆的發問,或是掌聲、嘆息,甚至噓聲,實現天然的臺上臺下交互和有沉浸感的互動直播體驗。加上輔助功能,體驗上能夠任意規定誰能夠發聲,誰不能夠,這中間的可能性是無限的。

更重要的是,即使在通常的連麥直播場景,這樣的體驗也能夠幫助這類低延遲觀衆(咱們稱爲「近場觀衆」)在上麥互動的時候實現平滑體驗,不用每次切換就黑屏一次,好像節目中斷同樣。

對於近場觀衆,即使是在網絡較差的時候,基本上可以保證延遲不超過1秒,極少數觀衆延遲不超過2秒。相對於CDN,即使在網絡質量無問題時,也有3秒以上延遲。實測網絡丟包僅僅10%,就可讓延遲拉大到10秒。這樣的丟包率,在手機的無線信號下但是常常出現的。

全部這些,都要歸公於聲網SD-RTN的實時傳輸保障能力。UDP實現的傳輸協議,不會由於前一個包的丟失或延遲致使下後續包的延遲送達,而丟包能夠用對延遲更友好的方式修復或補償出來。不採用這個機制是沒法達到這樣的延遲保障效果的。

二、抗丟包能力強。

使用聲網的技術,30%丟包時,依然可以進行正常直播。而基於TCP的CDN直播方案在丟包2%時就明顯卡頓,達到30%常常已斷開鏈接。

(三)基於SD-RTN 的直播架構與特性

下圖是聲網Agora.io互動直播的架構圖

圖片描述

客戶端均經過UDP鏈接SD-RTN(Agora Global Network),經過SD-RTN的就近接入策略,讓使用者就近接入質量最好的數據節點,經過Agora Global Network的軟件定義優化路由,通過傳輸延遲和質量優化的最優路徑,自動避免網絡擁塞,並規避骨幹網絡故障的影響。

如有常規的長延遲旁路直播需求,則能夠將主播與連麥者合成一路直播流,經過RTMP推到CDN,進行下發。鏈接這一路的觀衆,不能參與連麥互動(稱爲「遠場觀衆」)。

主要特色以下:

一、能夠支持更多的主播交互,目前支持7人視頻交互,100人語音交互。
二、當有觀衆連麥時,其餘觀衆端收到的多路視頻,觀衆端能夠動態選擇佈局;
三、聲網Agora.io會將直播視頻推送到CDN,其餘觀衆(網頁端等)能夠直接觀看;
四、當有觀衆連麥時,聲網Agora.io會將視頻合圖後推送到CDN,其餘觀衆(網頁端等)能夠觀看到連麥者與主播的互動;
五、在通過RTMP推流前的觀衆端,能夠進行大小流切換,自主選擇視頻大小窗口的切換。

【本文做者】

單輝 聲網Agora.io 高級開發工程師

RTC2016火熱報名中!

若是你看這篇講直播的文章還不過癮,那麼能夠來到RTC 大會現場,參加直播技術分論壇,聽Top5直播平臺的大拿們「華山論劍」。

188元基礎票,限時免費中,能夠參加「直播技術分論壇」。

詳情查看大會官網,http://rtcexpo.org

相關文章
相關標籤/搜索