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

那末，這些連麥技術方案，真的能連嗎？本文將常見的，不常見的直播技術方案進行了比較，各位同學自己甄別。

首先，基礎知識普及，技術上直播的流程是甚么？

1、直播的流程

正如上圖所示，全部直播流程分為以下幾個關鍵步驟：
1、主播客戶端，將本地收集的視頻推送到CDN；
2、CDN對視頻流進行緩存和轉發；
3、觀眾客戶端，拉取CDN中緩存視頻流進行播放；

可以看到CDN在這里起到了關鍵的作用，2016也是1個CDN突起的年代，網宿、快網、7牛、高升、藍汛、觀止云、騰訊云、百度云、阿里云等CDN紛紜表示對直播進行了支持，直播也逐步成了CDN的標配。

那末接下來了解1下CDN的技術原理。

2、CDN技術原理

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

CDN的技術原理見上圖，具體實現是通過在現有的網絡中，增加1層新的網絡架構，將網站的內容發布到離用戶最近的網絡節點上，這樣用戶可以就近獲得所需的內容，解決之前網絡堵塞、訪問延遲高的問題，提高用戶體驗。

對直播來講，則將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廠商，也在對其架構進行不斷的優化，所以架構不能統1而論。這里只是對1些基本的架構進行簡單的剖析。

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

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

緩存服務器：是直接提供給用戶訪問的站點資源，由1臺或數臺服務器組成；當用戶發起訪問時，他的訪問要求被智能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的技術原理后，我們在做直播選型時，還需要了解1個方案優缺點。接下來，我們來分析1下CDN的短板。

4.1 短板：播放延時

連麥直播的困難主要是播放延時！播放延時從何而來？

4.1.1 網絡延時

網絡延時這里指的是從主播端收集，到觀眾端播放，這之間的時間差。這里不斟酌主播段收集對視頻進行編碼的時間，和觀眾端觀看對視頻進行解碼的時間，僅斟酌網絡傳輸中的延時。例如說下圖中的網絡延時：

另外，數據傳輸進程中還觸及到邏輯上的交互，例如包的重傳和確認，和緩存上的1些邏輯等，會在這個基礎上又增加很多。

那末來簡單估算1下大概的網絡延時。盡人皆知，光在真空中的速度約為300,000km/s，而在其他介質中光 速會大大下降，所以在普通光纖中，工程上1般認為傳輸速度是200,000km/s。從現實上來講，可以參考以下：

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

4.1.2 網絡抖動

網絡抖動，是指數據包的到達順序、間隔和發出時不1致。比如說，發送100個數據包，每一個包間隔1s發出。結果第27個包在傳輸進程中遇到網絡堵塞，造成包27不是緊隨著26到達的，而是延遲到87后面才達。在直播中，這類抖動的效果實際上跟丟包是1樣的。由于你不能依照接收順序把內容播放出來，否則會造成失真。

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

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

4.1.3 網絡丟包

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

由于互聯網的網絡狀態是變化的，和主播真個網絡狀態是沒法控制的。所以當網絡中丟包率開始升高時，重傳會致使延時會不斷增大，乃至致使不斷嘗試重連等情況，這樣不能有效的緩存，嚴重情況下會致使觀眾端視頻沒法觀看。

4.2 短板：連麥

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

第1種方式：文字，這類比較常見，實現也比較簡單，這里不再進行分析；
第2種方式：連麥，這樣主播可以面對面與觀眾進行交互，增加了互動性；
由于連麥方式比較復雜，這里進行詳細分析。

4.2.1 多路RTMP流實現

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

當有連麥者時，則主播端和連麥者端，都分別推1路RTMP流到CDN，CDN再將這兩路RTMP流發送給觀眾端，觀眾端將兩路RTMP流合成為1個畫面。這類方式的優缺點以下：

• 優點
  
  • 實現簡單；
• 缺點
  
  • 主播與連麥者如果要進行交互，斟酌到上面分析的延時問題，在這里延時需要最少加大1倍。這樣對實時交互來講，完全沒法接受；
  • 主播與連麥者交互時，聲音會產生干擾，構成回音；
  • 觀眾端要接收兩條視頻流，帶寬、流量消耗過大，并且兩路視頻流解碼播放，耗費CPU等資源也非常多；
  • 這樣看來，這類方式弊大于利，基本不可取。

4.2.2 主播端與連麥者P2P

第2種方式，是主播端與連麥者之間使用P2P方式進行交互，然后主播端將自己和連麥者的視頻進行合并，再推到CDN上，CDN再發送給觀眾端，以下圖：

這類方式的優缺點以下：

• 優點
  
  • 主播和連麥者之間使用P2P，網絡質量較好，延遲較小，保證了二者之間交互不會有非常大的延時；
  • 解決聲音的干擾問題，消除回聲；
• 缺點
  
  • P2P在某些網絡下沒法穿透，有些觀眾根本沒法與主播端進行交互；
  • 主播端需要上傳兩路視頻：1路P2P與連麥者進行交互，1路使用RTMP推到CDN。還要下載1路視頻：連麥者P2P發送過來的交互數據。所以主播端要求帶寬需要較高，網絡較差時沒法進行主播
  • 主播端要進行多路視頻的編碼、解碼，要求主播端裝備配置比較高，較差的裝備也沒法進行主播；
  • 只能支持1個連麥者，不能支持多個連麥者；
  • 由于主播端和連麥者經過CDN合并成1路，因此，不能實現主播端和連麥者視頻大小窗口切換。

綜合來講，P2P方式在1定程度上可以解決連麥的問題。

4.2.3 服務器端合圖

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

這類方式的優缺點以下：

• 優點
  
  • 主播和連麥者各路視頻都使用RTMP推送到CDN，可以保證延時較小；
  • 由于CDN進行視頻合圖和發送，所以主播不需要很高的帶寬；
  • 由于CDN進行視頻合圖，所以主播的裝備不需要配置非常高；
  • 沒有聲音干擾問題；
  • 可以支持多個連麥者連麥；
• 缺點
  
  • CDN需要進行視頻的合圖，需要額外開發工作，并且邏輯比較復雜；
  • CDN需要進行視頻的合圖，需要消耗較高服務器資源；
  • CDN合圖后的布局難控制；
  • 據目前所知，還沒有CDN支持這類方案；

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

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

（1）甚么是SD-RTN

SD-RTN（Software-Defined Real Time Net work），軟件定義實時傳輸網絡，是1種新型的專為內容實時傳輸而設計的網絡架構。通過在互聯網上不同地區的數據中心放置軟件組網單元，相互連接相互調度，在現有的公共互聯網基礎上構建1層新的虛擬網絡。SD-RTN系統能夠實時根據各節點的連接和傳輸狀態、負載狀態和到用戶的距離和響應時間，自動分配最優、最通暢的傳輸路徑，到達實時傳輸需要的質量保障級別。

（2）SD-RTN與CDN有何不同

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

• 底層協議不同。SD-RTN采取了專為實時傳輸設計的UDP協議，避免了采取TCP的延時不可控缺點。能夠大大縮短交互延時，延時可從CDN方案的數秒，下降到數百毫秒。

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

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

（3）SD-RTN相較CDN，有何優點

1、時延大大縮短。

直播延時可從CDN方案的數秒，下降到數百毫秒。這1延遲范圍，屬于實時通訊或準實時通訊延遲的范疇。在這1級別上，主播和觀眾可以基本重現在現場活動中的交互體驗，從而大大釋放了內容制作者的潛力，也為業務運營者創造新業務情勢打開了無窮的空間和可能。

比如，在這1延遲下，主播和觀眾可以不光通過文字交互，也能夠通過音頻實時交互，而不會感到延遲過大而不自然。這類交互體驗，在手機上也更自然，比打字更符合人的自然習慣。業務運營方固然可以把這1功能當作比文字互動更高級別的特權能力，僅僅對付費或是1定級別、身份的用戶才可以直接和主播語音互動。業務運營者也能夠利用此類功能創造類似課堂，或小劇院的現場互動氛圍，讓主播可以聽得到觀眾的提問，或是掌聲、嘆息，乃至噓聲，實現自然的臺上臺下交互和有沉醉感的互動直播體驗。加上輔助功能，體驗上可以任意規定誰可以發聲，誰不可以，這中間的可能性是無窮的。

更重要的是，即使在1般的連麥直播場景，這樣的體驗也能夠幫助這類低延遲觀眾（我們稱為“近場觀眾”）在上麥互動的時候實現平滑體驗，不用每次切換就黑屏1次，好像節目中斷1樣。

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

所有這些，都要歸公于聲網SD-RTN的實時傳輸保障能力。UDP實現的傳輸協議，不會由于前1個包的丟失或延遲致使下后續包的延遲投遞，而丟包可以用對延遲更友好的方式修復或補償出來。不采取這個機制是沒法到達這樣的延遲保障效果的。

2、抗丟包能力強。

使用聲網的技術，30%丟包時，仍然能夠進行正常直播。而基于TCP的CDN直播方案在丟包2%時就明顯卡頓，到達30%常常已斷開連接。

（3）基于SD-RTN的直播架構與特性

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

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

若有常規的長延遲旁路直播需求，則可以將主播與連麥者合成1路直播流，通過RTMP推到CDN，進行下發。連接這1路的觀眾，不能參與連麥互動（稱為“遠場觀眾”）。

主要特點以下：

1、可以支持更多的主播交互，目前支持7人視頻交互，100人語音交互。
2、當有觀眾連麥時，其他觀眾端收到的多路視頻，觀眾端可以動態選擇布局；
3、聲網Agora.io會將直播視頻推送到CDN，其他觀眾（網頁端等）可以直接觀看；
4、當有觀眾連麥時，聲網Agora.io會將視頻合圖后推送到CDN，其他觀眾（網頁端等）可以觀看到連麥者與主播的互動；
5、在經過RTMP推流前的觀眾端，可以進行大小流切換，自主選擇視頻大小窗口的切換。

【本文作者】

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