• 直播的一般流程；

• 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的架構可以參考下圖：

轉載自：https://blog.csdn.net/jiangbb8686/article/details/86505754

標籤：其他

上一篇：Chrome瀏覽器中的三種重繪模式

下一篇：今日新聞整理 2020-7-15