首先篮洁，基礎知識普及涩维，技術上直播的流程是什么？

一袁波、直播的流程

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

1、主播客戶端篷牌，將本地采集的視頻推送到CDN睡蟋；

2、CDN對視頻流進行緩存以及轉發(fā)枷颊；

3薄湿、觀眾客戶端，拉取CDN中緩存視頻流進行播放偷卧；

可以看到CDN在這里起到了關鍵的作用豺瘤，2016也是一個CDN崛起的年代，網(wǎng)宿听诸、快網(wǎng)坐求、七牛、高升晌梨、藍汛桥嗤、觀止云须妻、騰訊云、百度云泛领、阿里云等CDN紛紛表示對直播進行了支持荒吏，直播也逐漸成為了CDN的標配。

那么接下來了解一下CDN的技術原理渊鞋。

二绰更、CDN技術原理

CDN的全稱為Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡锡宋，是一個策略性部署的整體系統(tǒng)儡湾，主要用來解決由于網(wǎng)絡帶寬小、用戶訪問量大执俩、網(wǎng)點分布不均勻等導致用戶訪問網(wǎng)站速度慢的問題徐钠。

CDN的技術原理見上圖，具體實現(xiàn)是通過在現(xiàn)有的網(wǎng)絡中役首，增加一層新的網(wǎng)絡架構尝丐，將網(wǎng)站的內(nèi)容發(fā)布到離用戶最近的網(wǎng)絡節(jié)點上，這樣用戶可以就近獲取所需的內(nèi)容衡奥，解決之前網(wǎng)絡擁塞爹袁、訪問延遲高的問題，提高用戶體驗杰赛。

對于直播來說，則將Web服務器換作主播客戶端矮台，如下圖所示乏屯。

由于視頻占用帶寬較大，與普通的Web服務差別較大瘦赫，這樣CDN的優(yōu)勢更能體現(xiàn)出來：網(wǎng)絡擁塞減少辰晕，訪問延遲降低，帶寬得到良好的控制等等确虱。

另外含友，CDN直播中常用的流媒體協(xié)議包括RTMP，HLS校辩，HTTP FLV等窘问。

RTMP（Real Time Messaging Protocol）是基于TCP的，由Adobe公司為Flash播放器和服務器之間音頻宜咒、視頻傳輸開發(fā)的開放協(xié)議惠赫。

HLS（HTTP Live Streaming）是基于HTTP的，是Apple公司開放的音視頻傳輸協(xié)議故黑。

HTTP FLV則是將RTMP封裝在HTTP協(xié)議之上的儿咱，可以更好的穿透防火墻等庭砍。

三、CDN的常用架構

CDN架構設計比較復雜混埠。不同的CDN廠商怠缸，也在對其架構進行不斷的優(yōu)化，所以架構不能統(tǒng)一而論钳宪。這里只是對一些基本的架構進行簡單的剖析揭北。

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

源站：是指發(fā)布內(nèi)容的原始站點侦高。添加嫉柴、刪除和更改網(wǎng)站的文件，都是在源站上進行的奉呛；另外緩存服務器所抓取的對象也全部來自于源站计螺。對于直播來說，源站為主播客戶端瞧壮。

緩存服務器：是直接提供給用戶訪問的站點資源登馒，由一臺或數(shù)臺服務器組成；當用戶發(fā)起訪問時咆槽，他的訪問請求被智能DNS定位到離他較近的緩存服務器陈轿。如果用戶所請求的內(nèi)容剛好在緩存里面，則直接把內(nèi)容返還給用戶秦忿；如果訪問所需的內(nèi)容沒有被緩存麦射，則緩存服務器向鄰近的緩存服務器或直接向源站抓取內(nèi)容，然后再返還給用戶灯谣。

智能DNS：是整個CDN技術的核心潜秋，它主要根據(jù)用戶的來源，以及當前緩存服務器的負載情況等胎许，將其訪問請求指向離用戶比較近且負載較小的緩存服務器峻呛。通過智能DNS解析，讓用戶訪問同服務商下辜窑、負載較小的服務器钩述，可以消除網(wǎng)絡訪問慢的問題，達到加速作用穆碎。

客戶端：即發(fā)起訪問的普通用戶切距。對于直播來說，就是觀眾客戶端惨远。

對于直播來說谜悟，CDN整體架構如下圖：

主要流程為：

主播開始進行直播话肖，向智能DNS發(fā)送解析請求；

智能DNS返回最優(yōu)CDN節(jié)點IP地址葡幸；

主播端采集音視頻數(shù)據(jù)最筒，發(fā)送給CDN節(jié)點，CDN節(jié)點進行緩存等處理；

觀眾端要觀看此主播的視頻，向智能DNS發(fā)送解析請求幔荒；

智能DNS返回最優(yōu)CDN節(jié)點IP地址；

觀眾端向CDN節(jié)點請求音視頻數(shù)據(jù)邢锯；

CDN節(jié)點同步其他節(jié)點的音視頻數(shù)據(jù)；

CDN節(jié)點將音視頻數(shù)據(jù)發(fā)送給觀眾端搀别；

四丹擎、CDN的短板

大概了解了CDN的技術原理后，我們在做直播選型時歇父，還需要了解一個方案優(yōu)缺點蒂培。接下來，我們來分析一下CDN的短板榜苫。

4.1 短板：播放延時

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

4.1.1 網(wǎng)絡延時

網(wǎng)絡延時這里指的是從主播端采集垂睬，到觀眾端播放媳荒，這之間的時間差。這里不考慮主播段采集對視頻進行編碼的時間驹饺，以及觀眾端觀看對視頻進行解碼的時間钳枕，僅考慮網(wǎng)絡傳輸中的延時。例如說下圖中的網(wǎng)絡延時：

另外逻淌，數(shù)據(jù)傳輸過程中還涉及到邏輯上的交互么伯，例如包的重傳以及確認疟暖，以及緩存上的一些邏輯等卡儒，會在這個基礎上又增加很多。

那么來簡單估算一下大概的網(wǎng)絡延時俐巴。眾所周知骨望，光在真空中的速度約為300,000km/s，而在其他介質(zhì)中光 速會大大降低欣舵，所以在普通光纖中擎鸠，工程上一般認為傳輸速度是200,000km/s。從現(xiàn)實上來說缘圈，可以參考如下：

所以說劣光，在節(jié)點較少袜蚕、網(wǎng)絡情況較好的情況下，那么網(wǎng)絡延時對應也是最小绢涡，加上一定的緩存牲剃，可以控制延時在1s~2s左右。但是節(jié)點多雄可、網(wǎng)絡差的情況下凿傅，網(wǎng)絡延時會對應增大，經(jīng)驗來說延時可以達到15s以上数苫。

4.1.2 網(wǎng)絡抖動

網(wǎng)絡抖動聪舒，是指數(shù)據(jù)包的到達順序、間隔和發(fā)出時不一致虐急。比如說箱残，發(fā)送100個數(shù)據(jù)包，每個包間隔1s發(fā)出戏仓。結果第27個包在傳輸過程中遇到網(wǎng)絡擁塞疚宇，造成包27不是緊跟著26到達的，而是延遲到87后面才達赏殃。在直播中敷待，這種抖動的效果實際上跟丟包是一樣的。因為你不能依照接收順序把內(nèi)容播放出來仁热，否則會造成失真榜揖。

網(wǎng)絡抖動，會造成播放延時對應增大抗蠢。如果網(wǎng)絡中抖動較大举哟，會造成播放卡頓等現(xiàn)象。

如上圖所示迅矛，主播端t3和t5發(fā)出的包妨猩，分別在t3’和t5’到達，但是中間延時增大秽褒，即發(fā)生了網(wǎng)絡抖動壶硅。這樣造成觀眾端觀看視頻的延時會不斷增大。

4.1.3 網(wǎng)絡丟包

CDN直播中用到的RTMP销斟、HLS庐椒、HTTP FLV等協(xié)議都是在TCP的基礎之上。TCP一個很重要的特性是可靠性蚂踊，即不會發(fā)生數(shù)據(jù)丟失的問題约谈。為了保證可靠性，TCP在傳輸過程中有3次握手，見下圖棱诱。首先客戶端會向服務端發(fā)送連接請求泼橘，服務端同意后，客戶端會確認這次連接迈勋。這就是3次握手侥加。接著，客戶端就開始發(fā)送數(shù)據(jù)粪躬，每次發(fā)送一批數(shù)據(jù)担败，得到服務端的“收到“確認后，繼續(xù)發(fā)送下一批镰官。TCP為了保證傳到提前，會有自動重傳機制。如果傳輸中發(fā)生了丟包泳唠，沒有收到對端發(fā)出的“收到”信號狈网，那么就會自動重傳丟失的包，一直到超時笨腥。

由于互聯(lián)網(wǎng)的網(wǎng)絡狀況是變化的拓哺，以及主播端的網(wǎng)絡狀況是無法控制的。所以當網(wǎng)絡中丟包率開始升高時脖母，重傳會導致延時會不斷增大士鸥，甚至導致不斷嘗試重連等情況，這樣不能有效的緩存谆级，嚴重情況下會導致觀眾端視頻無法觀看烤礁。

4.2 短板：連麥

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

第一種方式：文字脚仔，這種比較常見，實現(xiàn)也比較簡單舆绎，這里不再進行分析鲤脏；

第二種方式：連麥，這樣主播可以面對面與觀眾進行交互吕朵，增加了互動性猎醇；

由于連麥方式比較復雜，這里進行詳細分析边锁。

4.2.1 多路RTMP流實現(xiàn)

前面提到姑食，RTMP是目前主播中最常用的協(xié)議波岛，使用RTMP協(xié)議茅坛，可以實現(xiàn)最簡單的一種連麥方式，如下圖。

當有連麥者時贡蓖，則主播端和連麥者端曹鸠，都分別推一路RTMP流到CDN，CDN再將這兩路RTMP流發(fā)送給觀眾端斥铺，觀眾端將兩路RTMP流合成為一個畫面彻桃。這種方式的優(yōu)缺點如下：

優(yōu)點

缺點

主播與連麥者如果要進行交互，考慮到上面分析的延時問題晾蜘，在這里延時需要至少加大一倍邻眷。這樣對于實時交互來說，完全無法接受剔交；

主播與連麥者交互時肆饶，聲音會產(chǎn)生干擾，形成回音岖常；

觀眾端要接收兩條視頻流驯镊，帶寬、流量消耗過大竭鞍，并且兩路視頻流解碼播放板惑，耗費CPU等資源也非常多；

這樣看來偎快，這種方式弊大于利冯乘，基本不可取。

4.2.2 主播端與連麥者P2P

第二種方式晒夹，是主播端與連麥者之間使用P2P方式進行交互往湿，然后主播端將自己和連麥者的視頻進行合并，再推到CDN上惋戏，CDN再發(fā)送給觀眾端领追，如下圖：

這種方式的優(yōu)缺點如下：

優(yōu)點

主播和連麥者之間使用P2P，網(wǎng)絡質(zhì)量較好响逢，延遲較小绒窑，保證了兩者之間交互不會有非常大的延時；

解決聲音的干擾問題舔亭，消除回聲些膨；

缺點

P2P在某些網(wǎng)絡下無法穿透，有些觀眾根本無法與主播端進行交互钦铺；

主播端需要上傳兩路視頻：一路P2P與連麥者進行交互订雾，一路使用RTMP推到CDN。還要下載一路視頻：連麥者P2P發(fā)送過來的交互數(shù)據(jù)矛洞。所以主播端要求帶寬需要較高洼哎，網(wǎng)絡較差時無法進行主播

主播端要進行多路視頻的編碼烫映、解碼，要求主播端設備配置比較高噩峦，較差的設備也無法進行主播锭沟；

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

由于主播端和連麥者經(jīng)過CDN合并成一路族淮，因此，不能實現(xiàn)主播端和連麥者視頻大小窗口切換凭涂。

綜合來說祝辣，P2P方式在一定程度上可以解決連麥的問題。

4.2.3 服務器端合圖

另外一種方式切油，是主播和連麥者都將視頻推送到CDN中较幌，然后CDN內(nèi)部對這幾路視頻進行合圖，再將其發(fā)送給觀眾端白翻。如下圖：

這種方式的優(yōu)缺點如下：

優(yōu)點

主播和連麥者各路視頻都使用RTMP推送到CDN乍炉，可以保證延時較小滤馍；

由于CDN進行視頻合圖和發(fā)送岛琼，所以主播不需要很高的帶寬；

由于CDN進行視頻合圖巢株，所以主播的設備不需要配置非常高槐瑞；

沒有聲音干擾問題；

可以支持多個連麥者連麥阁苞；

缺點

CDN需要進行視頻的合圖困檩，需要額外開發(fā)工作，并且邏輯比較復雜那槽；

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

CDN合圖后的布局難控制骚灸；

據(jù)目前所知糟趾，還沒有CDN支持這種方案；

聲網(wǎng)Agora.io甚牲，在開發(fā)互動直播解決方案時义郑，拋棄傳統(tǒng)的基于TCP協(xié)議的CDN方案，從底層協(xié)議和布網(wǎng)上開始丈钙，創(chuàng)建了基于UDP協(xié)議的SD-RTN方案非驮。

（一）什么是SD-RTN

SD-RTN（Software-Defined Real Time Net work），軟件定義實時傳輸網(wǎng)絡雏赦，是一種新型的專為內(nèi)容實時傳輸而設計的網(wǎng)絡架構劫笙。通過在互聯(lián)網(wǎng)上不同地區(qū)的數(shù)據(jù)中心放置軟件組網(wǎng)單元芙扎，相互連接互相調(diào)度，在現(xiàn)有的公共互聯(lián)網(wǎng)基礎上構建一層新的虛擬網(wǎng)絡邀摆。SD-RTN系統(tǒng)能夠實時根據(jù)各節(jié)點的連接和傳輸狀況、負載狀況以及到用戶的距離和響應時間伍茄，自動分配最優(yōu)栋盹、最通暢的傳輸路徑，達到實時傳輸需要的質(zhì)量保障級別敷矫。

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

基本原理不同例获。CDN是存儲轉發(fā)結構，設計目的是在各個邊緣節(jié)點緩存待分發(fā)內(nèi)容曹仗，結構上從源站到觀眾是傘狀多級緩存放大方式榨汤。SD-RTN本質(zhì)上一個實時傳輸網(wǎng)絡，用戶的數(shù)據(jù)在網(wǎng)絡單元內(nèi)部和傳輸線路上都以實時交換方式傳送怎茫，從而能夠保證最低延遲收壕。

底層協(xié)議不同。SD-RTN采用了專為實時傳輸設計的UDP協(xié)議轨蛤，避免了采用TCP的延時不可控缺點蜜宪。能夠大大縮短交互延時，延時可從CDN方案的數(shù)秒祥山，降低到數(shù)百毫秒圃验。

內(nèi)容分發(fā)機制不同。SD-RTN是基于自定義路由缝呕，選擇最優(yōu)傳輸路徑澳窑，直接將內(nèi)容端到端傳輸，數(shù)據(jù)在網(wǎng)絡單元中從不緩存供常，從而最大可能的降低延遲摊聋，同時內(nèi)容安全性也更好。CDN是將內(nèi)容緩存于緩存服務器中栈暇，再將內(nèi)容就近下發(fā)栗精。

使用場景不同。SD-RTN適用于要求極低時延的實時互動場景瞻鹏，例如網(wǎng)絡電話悲立、視頻會議、有主播與觀眾交互需求的互動直播等新博。CDN適用于對時延要求不高的場景薪夕，例如對延時要求不高、類似電視的單點直播赫悄、網(wǎng)站加速等原献。若硬要將CDN改造用于互動直播馏慨，那么其結構上對降低延遲的不適應性，始終會成為質(zhì)量改進需求的瓶頸姑隅。

（三）SD-RTN相較CDN写隶，有何優(yōu)點

1、時延大大縮短讲仰。

直播延時可從CDN方案的數(shù)秒慕趴，降低到數(shù)百毫秒。這一延遲范圍鄙陡，屬于實時通信或準實時通信延遲的范疇冕房。在這一級別上，主播和觀眾可以基本重現(xiàn)在現(xiàn)場活動中的交互體驗趁矾，從而大大釋放了內(nèi)容制作者的潛力耙册，也為業(yè)務運營者創(chuàng)造新業(yè)務形式打開了無限的空間和可能。

比如毫捣，在這一延遲下详拙，主播和觀眾可以不光通過文字交互，也可以通過音頻實時交互蔓同，而不會感到延遲過大而不自然溪厘。這種交互體驗，在手機上也更自然牌柄，比打字更符合人的自然習慣畸悬。業(yè)務運營方當然可以把這一功能當作比文字互動更高級別的特權能力，僅僅對于付費或是一定級別珊佣、身份的用戶才可以直接和主播語音互動蹋宦。業(yè)務運營者也可以利用此類功能創(chuàng)造類似課堂，或小劇場的現(xiàn)場互動氛圍咒锻，讓主播可以聽得到觀眾的發(fā)問冷冗，或是掌聲、嘆息惑艇，甚至噓聲蒿辙，實現(xiàn)自然的臺上臺下交互和有沉浸感的互動直播體驗。加上輔助功能滨巴，體驗上可以任意規(guī)定誰可以發(fā)聲思灌，誰不可以，這中間的可能性是無限的恭取。

更重要的是泰偿，即便在一般的連麥直播場景，這樣的體驗也可以幫助這類低延遲觀眾（我們稱為“近場觀眾”）在上麥互動的時候實現(xiàn)平滑體驗蜈垮，不用每次切換就黑屏一次耗跛，好像節(jié)目中斷一樣裕照。

對于近場觀眾，即便是在網(wǎng)絡較差的時候调塌，基本上能夠保證延遲不超過1秒晋南，極少數(shù)觀眾延遲不超過2秒。相對于CDN羔砾，即便在網(wǎng)絡質(zhì)量無問題時负间，也有3秒以上延遲。實測網(wǎng)絡丟包僅僅10%蜒茄，就可以讓延遲拉大到10秒唉擂。這樣的丟包率餐屎，在手機的無線信號下可是經(jīng)常出現(xiàn)的檀葛。

所有這些，都要歸公于聲網(wǎng)SD-RTN的實時傳輸保障能力腹缩。UDP實現(xiàn)的傳輸協(xié)議屿聋，不會因為前一個包的丟失或延遲導致下后續(xù)包的延遲送達，而丟包可以用對延遲更友好的方式修復或補償出來藏鹊。不采用這個機制是無法達到這樣的延遲保障效果的润讥。

2、抗丟包能力強盘寡。

使用聲網(wǎng)的技術楚殿，30%丟包時，依然能夠進行正常直播竿痰。而基于TCP的CDN直播方案在丟包2%時就明顯卡頓脆粥，達到30%經(jīng)常已斷開連接。

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

下圖是聲網(wǎng)Agora.io互動直播的架構圖

客戶端均通過UDP連接SD-RTN（Agora Global Network）影涉，通過SD-RTN的就近接入策略变隔，讓使用者就近接入質(zhì)量最好的數(shù)據(jù)節(jié)點，通過Agora Global Network的軟件定義優(yōu)化路由蟹倾，經(jīng)過傳輸延遲和質(zhì)量優(yōu)化的最優(yōu)路徑匣缘，自動避免網(wǎng)絡擁塞，并規(guī)避骨干網(wǎng)絡故障的影響鲜棠。

若有常規(guī)的長延遲旁路直播需求肌厨，則可以將主播與連麥者合成一路直播流，通過RTMP推到CDN豁陆，進行下發(fā)夏哭。連接這一路的觀眾，不能參與連麥互動（稱為“遠場觀眾”）献联。

主要特點如下：

1竖配、可以支持更多的主播交互何址，目前支持7人視頻交互，100人語音交互进胯。

2用爪、當有觀眾連麥時，其他觀眾端收到的多路視頻胁镐，觀眾端可以動態(tài)選擇布局偎血；

3、聲網(wǎng)Agora.io會將直播視頻推送到CDN盯漂，其他觀眾（網(wǎng)頁端等）可以直接觀看颇玷；

4、當有觀眾連麥時就缆，聲網(wǎng)Agora.io會將視頻合圖后推送到CDN帖渠，其他觀眾（網(wǎng)頁端等）可以觀看到連麥者與主播的互動；

5竭宰、在經(jīng)過RTMP推流前的觀眾端空郊，可以進行大小流切換，自主選擇視頻大小窗口的切換切揭。