從直播CDN的原理說(shuō)起，談如何解決延時(shí)和連麥的老難題？

image

到處都在談直播，直播技術(shù)目前越來(lái)越大眾化，但也面臨著更多的挑戰(zhàn)。本次分享主要介紹直播的一般流程，CDN的技術(shù)原理及架構(gòu)，CDN直播技術(shù)的難點(diǎn)和對(duì)應(yīng)的解決方案。希望能夠給大家?guī)?lái)幫助，更希望能推動(dòng)實(shí)時(shí)直播技術(shù)的改進(jìn)和改革。下面是本文的要點(diǎn)：

• 直播的一般流程；
• CDN的技術(shù)原理及架構(gòu)；
• CDN直播的技術(shù)難點(diǎn)和應(yīng)對(duì)方案；
• 基于SD-RTN的，針對(duì)低延遲、強(qiáng)互動(dòng)場(chǎng)景的直播技術(shù)。

直播的流程

image

正如上圖所示，整個(gè)直播流程分為以下幾個(gè)關(guān)鍵步驟：

• 主播客戶(hù)端，將本地采集的視頻推送到CDN；
• CDN對(duì)視頻流進(jìn)行緩存以及轉(zhuǎn)發(fā)；
• 觀眾客戶(hù)端，拉取CDN中緩存視頻流進(jìn)行播放；

可以看到CDN在這里起到了關(guān)鍵的作用，2016也是一個(gè)CDN崛起的年代，網(wǎng)宿、快網(wǎng)、七牛、高升、藍(lán)汛、觀止云、騰訊云、百度云、阿里云等CDN紛紛表示對(duì)直播進(jìn)行了支持，直播也逐漸成為了CDN的標(biāo)配。

那么接下來(lái)了解一下CDN的技術(shù)原理。

CDN技術(shù)原理

CDN的全稱(chēng)為Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，是一個(gè)策略性部署的整體系統(tǒng)，主要用來(lái)解決由于網(wǎng)絡(luò)帶寬小、用戶(hù)訪(fǎng)問(wèn)量大、網(wǎng)點(diǎn)分布不均勻等導(dǎo)致用戶(hù)訪(fǎng)問(wèn)網(wǎng)站速度慢的問(wèn)題。

image

CDN的技術(shù)原理見(jiàn)上圖，具體實(shí)現(xiàn)是通過(guò)在現(xiàn)有的網(wǎng)絡(luò)中，增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到離用戶(hù)最近的網(wǎng)絡(luò)節(jié)點(diǎn)上，這樣用戶(hù)可以就近獲取所需的內(nèi)容，解決之前網(wǎng)絡(luò)擁塞、訪(fǎng)問(wèn)延遲高的問(wèn)題，提高用戶(hù)體驗(yàn)。

對(duì)于直播來(lái)說(shuō)，則將Web服務(wù)器換作主播客戶(hù)端，如下圖所示。

image

由于視頻占用帶寬較大，與普通的Web服務(wù)差別較大，這樣CDN的優(yōu)勢(shì)更能體現(xiàn)出來(lái)：網(wǎng)絡(luò)擁塞減少，訪(fǎng)問(wèn)延遲降低，帶寬得到良好的控制等等。

另外，CDN直播中常用的流媒體協(xié)議包括RTMP、HLS、HTTP FLV等。

• RTMP（Real Time Messaging Protocol）是基于TCP的，由Adobe公司為Flash播放器和服務(wù)器之間音頻、視頻傳輸開(kāi)發(fā)的開(kāi)放協(xié)議。
• HLS（HTTP Live Streaming）是基于HTTP的，是Apple公司開(kāi)放的音視頻傳輸協(xié)議。
• HTTP FLV則是將RTMP封裝在HTTP協(xié)議之上的，可以更好的穿透防火墻等。

CDN的常用架構(gòu)

CDN架構(gòu)設(shè)計(jì)比較復(fù)雜，并且不同的CDN廠商，對(duì)其架構(gòu)進(jìn)行不斷的優(yōu)化，所以架構(gòu)也不能統(tǒng)一而論。這里只是對(duì)一些基本的架構(gòu)進(jìn)行簡(jiǎn)單的剖析。

CDN主要包含源站、緩存服務(wù)器、智能DNS、客戶(hù)端等幾個(gè)主要組成部分。

源站是指發(fā)布內(nèi)容的原始站點(diǎn)。添加、刪除和更改網(wǎng)站的文件，都是在源站上進(jìn)行的；另外緩存服務(wù)器所抓取的對(duì)象也全部來(lái)自于源站。對(duì)于直播來(lái)說(shuō)，源站為主播客戶(hù)端。

緩存服務(wù)器
是直接提供給用戶(hù)訪(fǎng)問(wèn)的站點(diǎn)資源，由一臺(tái)或數(shù)臺(tái)服務(wù)器組成；當(dāng)用戶(hù)發(fā)起訪(fǎng)問(wèn)時(shí)，他的訪(fǎng)問(wèn)請(qǐng)求被智能DNS定位到離他較近的緩存服務(wù)器。如果用戶(hù)所請(qǐng)求的內(nèi)容剛好在緩存里面，則直接把內(nèi)容返還給用戶(hù)；如果訪(fǎng)問(wèn)所需的內(nèi)容沒(méi)有被緩存，則緩存服務(wù)器向鄰近的緩存服務(wù)器或直接向源站抓取內(nèi)容，然后再返還給用戶(hù)。

智能DNS是整個(gè)CDN技術(shù)的核心，它主要根據(jù)用戶(hù)的來(lái)源，以及當(dāng)前緩存服務(wù)器的負(fù)載情況等，將其訪(fǎng)問(wèn)請(qǐng)求指向離用戶(hù)比較近且負(fù)載較小的緩存服務(wù)器。通過(guò)智能DNS解析，讓用戶(hù)訪(fǎng)問(wèn)同服務(wù)商下、負(fù)載較小的服務(wù)器，可以消除網(wǎng)絡(luò)訪(fǎng)問(wèn)慢的問(wèn)題，達(dá)到加速作用。

客戶(hù)端即發(fā)起訪(fǎng)問(wèn)的普通用戶(hù)。對(duì)于直播來(lái)說(shuō)，就是觀眾客戶(hù)端。

對(duì)于直播來(lái)說(shuō)，CDN整體架構(gòu)如下圖：

image

主要流程為：

1. 主播開(kāi)始進(jìn)行直播，向智能DNS發(fā)送解析請(qǐng)求；
2. 能DNS返回最優(yōu)CDN節(jié)點(diǎn)IP地址；
3. 主播端采集音視頻數(shù)據(jù)，發(fā)送給CDN節(jié)點(diǎn)，CDN節(jié)點(diǎn)進(jìn)行緩存等處理；
4. 觀眾端要觀看此主播的視頻，向智能DNS發(fā)送解析請(qǐng)求；
5. 智能DNS返回最優(yōu)CDN節(jié)點(diǎn)IP地址；
6. 觀眾端向CDN節(jié)點(diǎn)請(qǐng)求音視頻數(shù)據(jù)；
7. CDN節(jié)點(diǎn)同步其他節(jié)點(diǎn)的音視頻數(shù)據(jù)；
8. CDN節(jié)點(diǎn)將音視頻數(shù)據(jù)發(fā)送給觀眾端；

說(shuō)了這么多CDN的技術(shù)和原理，不知道您看累了沒(méi)，那么CDN直播是否萬(wàn)事大吉了呢？接下來(lái)分析一下CDN的難點(diǎn)和解決方案。

CDN難點(diǎn)：播放延時(shí)

一提到直播，大家肯定會(huì)想到播放延時(shí)的問(wèn)題，那為什么會(huì)播放延時(shí)了？我們從以下幾個(gè)方面分析：

1. 網(wǎng)絡(luò)延時(shí)

網(wǎng)絡(luò)延時(shí)這里指的是從主播端采集，到觀眾端播放，之間的時(shí)間差。這里不考慮主播段采集對(duì)視頻進(jìn)行編碼的時(shí)間，以及觀眾端觀看對(duì)視頻進(jìn)行解碼的時(shí)間，僅考慮網(wǎng)絡(luò)傳輸中的延時(shí)。例如說(shuō)下圖中的網(wǎng)絡(luò)延時(shí)：

image

假設(shè)在該鏈路上有緩存，時(shí)間為T(mén)max_cache ，那么從主播到觀眾的延時(shí)Tdelay為：

image.png

另外，數(shù)據(jù)傳輸過(guò)程中還涉及到邏輯上的交互，例如包的重傳以及確認(rèn)，以及緩存上的一些邏輯等，會(huì)在這個(gè)基礎(chǔ)上又增加很多。

那么來(lái)簡(jiǎn)單估算一下大概的網(wǎng)絡(luò)延時(shí)。眾所周知，光在真空中的速度約為300,000km/s，而在其他介質(zhì)中光速會(huì)大大降低，所以在普通光纖中，工程上一般認(rèn)為傳輸速度是200,000km/s。從現(xiàn)實(shí)上來(lái)說(shuō)，可以參考如下：

| 路線(xiàn) | 距離（km） | 往返時(shí)延（ms） |
| 北京到上海 | 1,200 | 12 |
| 北京到紐約 | 11,000 | 110 |
| 赤道周長(zhǎng) | 40,000 | 400 |

所以說(shuō)，在節(jié)點(diǎn)較少、網(wǎng)絡(luò)情況較好的情況下，那么網(wǎng)絡(luò)延時(shí)對(duì)應(yīng)也是最小，加上一定的緩存，可以控制延時(shí)在1s~2s左右。但是節(jié)點(diǎn)多、網(wǎng)絡(luò)差的情況下，網(wǎng)絡(luò)延時(shí)會(huì)對(duì)應(yīng)增大，經(jīng)驗(yàn)來(lái)說(shuō)延時(shí)可以達(dá)到15s以上。

2. 網(wǎng)絡(luò)抖動(dòng)

網(wǎng)絡(luò)抖動(dòng)，是指數(shù)據(jù)包的到達(dá)順序、間隔和發(fā)出時(shí)不一致。比如說(shuō)，發(fā)送100個(gè)數(shù)據(jù)包，每個(gè)包間隔1s發(fā)出。結(jié)果第27個(gè)包在傳輸過(guò)程中遇到網(wǎng)絡(luò)擁塞，造成包27不是緊跟著26到達(dá)的，而是延遲到87后面才達(dá)。在直播中，這種抖動(dòng)的效果實(shí)際上跟丟包是一樣的。因?yàn)槟悴荒芤勒战邮枕樞虬褍?nèi)容播放出來(lái)，否則會(huì)造成失真。

網(wǎng)絡(luò)抖動(dòng)，會(huì)造成播放延時(shí)對(duì)應(yīng)增大。如果網(wǎng)絡(luò)中抖動(dòng)較大，會(huì)造成播放卡頓等現(xiàn)象。

image

如上圖所示，主播端t3和t5發(fā)出的包，分別在t3'和t5'到達(dá)，但是中間延時(shí)增大，即發(fā)生了網(wǎng)絡(luò)抖動(dòng)。這樣造成觀眾端觀看視頻的延時(shí)會(huì)不斷增大。

3. 網(wǎng)絡(luò)丟包

CDN直播中用到的RTMP、HLS、HTTP FLV等協(xié)議都是在TCP的基礎(chǔ)之上。TCP一個(gè)很重要的特性是可靠性，即不會(huì)發(fā)生數(shù)據(jù)丟失的問(wèn)題。為了保證可靠性，TCP在傳輸過(guò)程中有3次握手，見(jiàn)下圖。首先客戶(hù)端會(huì)向服務(wù)端發(fā)送連接請(qǐng)求，服務(wù)端同意后，客戶(hù)端會(huì)確認(rèn)這次連接。這就是3次握手。接著，客戶(hù)端就開(kāi)始發(fā)送數(shù)據(jù)，每次發(fā)送一批數(shù)據(jù)，得到服務(wù)端的“收到”確認(rèn)后，繼續(xù)發(fā)送下一批。TCP為了保證傳到，會(huì)有自動(dòng)重傳機(jī)制。如果傳輸中發(fā)生了丟包，沒(méi)有收到對(duì)端發(fā)出的“收到”信號(hào)，那么就會(huì)自動(dòng)重傳丟失的包，一直到超時(shí)。

image

由于互聯(lián)網(wǎng)的網(wǎng)絡(luò)狀況是變化的，以及主播端的網(wǎng)絡(luò)狀況是無(wú)法控制的。所以當(dāng)網(wǎng)絡(luò)中丟包率開(kāi)始升高時(shí)，重傳會(huì)導(dǎo)致延時(shí)會(huì)不斷增大，甚至導(dǎo)致不斷嘗試重連等情況，這樣不能有效的緩存，嚴(yán)重情況下會(huì)導(dǎo)致觀眾端視頻無(wú)法觀看。

解決方案

拋棄傳統(tǒng)的基于TCP協(xié)議的方案，從底層協(xié)議和布網(wǎng)上開(kāi)始，使用基于UDP協(xié)議的方案。SD-RTN（Software-Defined Real Time Net work），軟件定義實(shí)時(shí)傳輸網(wǎng)絡(luò)，是一種新型的專(zhuān)為內(nèi)容實(shí)時(shí)傳輸而設(shè)計(jì)，基于UDP協(xié)議的網(wǎng)絡(luò)架構(gòu)。SD-RTN通過(guò)在互聯(lián)網(wǎng)上不同地區(qū)的數(shù)據(jù)中心放置軟件組網(wǎng)單元，相互連接互相調(diào)度，在現(xiàn)有的公共互聯(lián)網(wǎng)基礎(chǔ)上構(gòu)建一層新的虛擬網(wǎng)絡(luò)。能夠?qū)崟r(shí)根據(jù)各節(jié)點(diǎn)的連接、傳輸狀況、負(fù)載狀況、到用戶(hù)的距離和響應(yīng)時(shí)間，自動(dòng)分配最優(yōu)最通暢的傳輸路徑，達(dá)到實(shí)時(shí)傳輸需要的質(zhì)量保障級(jí)別。

CDN與SD-RTN對(duì)比情況如下：

• 基本原理不同。CDN是存儲(chǔ)轉(zhuǎn)發(fā)結(jié)構(gòu)，設(shè)計(jì)目的是在各個(gè)邊緣節(jié)點(diǎn)緩存待分發(fā)內(nèi)容，結(jié)構(gòu)上從源站到觀眾是傘狀多級(jí)緩存放大方式。SD-RTN本質(zhì)上一個(gè)實(shí)時(shí)傳輸網(wǎng)絡(luò)，用戶(hù)的數(shù)據(jù)在網(wǎng)絡(luò)單元內(nèi)部和傳輸線(xiàn)路上都以實(shí)時(shí)交換方式傳送，UDP實(shí)現(xiàn)的傳輸協(xié)議，不會(huì)因?yàn)榍耙粋€(gè)包的丟失或延遲導(dǎo)致下后續(xù)包的延遲送達(dá)，而丟包可以用對(duì)延遲更友好的方式修復(fù)或補(bǔ)償出來(lái)，從而能夠保證最低延遲。
• 底層協(xié)議不同。SD-RTN采用了專(zhuān)為實(shí)時(shí)傳輸設(shè)計(jì)的UDP協(xié)議，避免了采用TCP的延時(shí)不可控缺點(diǎn)。能夠大大縮短交互延時(shí)，延時(shí)可從CDN方案的數(shù)秒，降低到數(shù)百毫秒。
• 內(nèi)容分發(fā)機(jī)制不同。SD-RTN是基于自定義路由，選擇最優(yōu)傳輸路徑，直接將內(nèi)容端到端傳輸，數(shù)據(jù)在網(wǎng)絡(luò)單元中從不緩存，從而最大可能的降低延遲，同時(shí)內(nèi)容安全性也更好。CDN是將內(nèi)容緩存于緩存服務(wù)器中，再將內(nèi)容就近下發(fā)，所以CDN更適合做內(nèi)容分發(fā)，一對(duì)多的場(chǎng)景。
• 使用場(chǎng)景不同。SD-RTN適用于要求極低時(shí)延的實(shí)時(shí)互動(dòng)場(chǎng)景，例如網(wǎng)絡(luò)電話(huà)、視頻會(huì)議、有主播與觀眾交互需求的互動(dòng)直播等。CDN適用于對(duì)時(shí)延要求不高的場(chǎng)景，例如對(duì)延時(shí)要求不高、類(lèi)似電視的單點(diǎn)直播、網(wǎng)站加速等。

SD-RTN的優(yōu)勢(shì)如下：

• 時(shí)延大大縮短。直播延時(shí)可從基于TCP的方案的數(shù)秒，降低到數(shù)百毫秒。這一延遲范圍，屬于實(shí)時(shí)通信或準(zhǔn)實(shí)時(shí)通信延遲的范疇。在這一級(jí)別上，主播和觀眾可以基本重現(xiàn)在現(xiàn)場(chǎng)活動(dòng)中的交互體驗(yàn)，從而大大釋放了內(nèi)容制作者的潛力，也為業(yè)務(wù)運(yùn)營(yíng)者創(chuàng)造新業(yè)務(wù)形式打開(kāi)了無(wú)限的空間和可能。
• 抗丟包能力強(qiáng)。一般來(lái)說(shuō)，SD-RTN中可以針對(duì)用戶(hù)網(wǎng)絡(luò)使用更多的策略模型和技術(shù)，這樣在30%丟包時(shí)，依然能夠進(jìn)行正常直播。而基于TCP的直播方案在丟包2%時(shí)就明顯卡頓，達(dá)到30%經(jīng)常已斷開(kāi)連接，無(wú)法進(jìn)行直播。

CDN難點(diǎn)：連麥

直播中，主播如果要與用戶(hù)交互，常見(jiàn)有兩種方式：

• 第一種方式：文字，這種比較常見(jiàn)，實(shí)現(xiàn)也比較簡(jiǎn)單，這里不再進(jìn)行分析；
• 第二種方式：連麥，這樣主播可以面對(duì)面與觀眾進(jìn)行交互，增加了互動(dòng)性；

由于連麥方式比較復(fù)雜，這里進(jìn)行詳細(xì)分析。

1. 多路RTMP流實(shí)現(xiàn)

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

image

當(dāng)有連麥者時(shí)，則主播端和連麥者端，都分別推一路RTMP流到CDN，CDN再將這兩路RTMP流發(fā)送給觀眾端，觀眾端將兩路RTMP流合成為一個(gè)畫(huà)面。這種方式的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，但缺點(diǎn)比較多：

• 主播與連麥者如果要進(jìn)行交互，則考慮到上面分析的延時(shí)問(wèn)題，在這里延時(shí)需要至少加大一倍，這樣對(duì)于實(shí)時(shí)交互來(lái)說(shuō)，完全無(wú)法接受；
• 主播與連麥者交互時(shí)，聲音會(huì)產(chǎn)生干擾，形成回音；
• 觀眾端要接收兩條視頻流，帶寬、流量消耗過(guò)大，并且兩路視頻流解碼播放，耗費(fèi)CPU等資源也非常多；

這樣看來(lái)，這種方式弊大于利，基本不可取。

2. 主播端與連麥者P2P

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

image

這種方式的優(yōu)點(diǎn)有兩個(gè)，一是主播和連麥者之間使用P2P，網(wǎng)絡(luò)質(zhì)量較好，延遲較小，保證了兩者之間交互不會(huì)有非常大的延時(shí)；二是可以解決聲音的干擾問(wèn)題，消除回聲。缺點(diǎn)是：

• P2P在某些網(wǎng)絡(luò)下無(wú)法穿透，有些觀眾根本無(wú)法與主播端進(jìn)行交互；
• 主播端需要上傳兩路視頻：一路P2P與連麥者進(jìn)行交互，一路使用RTMP推到CDN。還要下載一路視頻：連麥者P2P發(fā)送過(guò)來(lái)的交互數(shù)據(jù)。所以主播端要求帶寬需要較高，網(wǎng)絡(luò)較差時(shí)無(wú)法進(jìn)行主播；
• 主播端要進(jìn)行多路視頻的編碼、解碼，要求主播端設(shè)備配置比較高，較差的設(shè)備也無(wú)法進(jìn)行主播；
• 只能支持一個(gè)連麥者，不能支持多個(gè)連麥者；
• 由于主播端和連麥者經(jīng)過(guò)CDN合并成一路，因此，不能實(shí)現(xiàn)主播端和連麥者視頻大小窗口切換。

綜合來(lái)說(shuō)，P2P方式在一定程度上可以解決連麥的問(wèn)題。

3. 服務(wù)器端合圖

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

image

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

優(yōu)點(diǎn)

• 主播和連麥者各路視頻都使用RTMP推送到CDN，可以保證延時(shí)較??；
• 由于CDN進(jìn)行視頻合圖和發(fā)送，所以主播不需要很高的帶寬；
• 由于CDN進(jìn)行視頻合圖，所以主播的設(shè)備不需要配置非常高；
• 沒(méi)有聲音干擾問(wèn)題；
• 可以支持多個(gè)連麥者連麥；

缺點(diǎn)

• CDN需要進(jìn)行視頻的合圖，需要額外開(kāi)發(fā)工作，并且邏輯比較復(fù)雜；
• CDN需要進(jìn)行視頻的合圖，需要消耗較高服務(wù)器資源；
• CDN合圖后的布局難控制；
• 據(jù)目前所知，還沒(méi)有CDN支持這種方案；

解決方案

使用前文中提到的SD-RTN方案，由于其延遲較低，主播和觀眾可以通過(guò)音頻實(shí)時(shí)交互，而不會(huì)感到延遲過(guò)大而不自然。使用SD-RTN，可以很好的解決多路RTMP、P2P連麥、服務(wù)器端合圖這幾種方案的弱勢(shì)，并且開(kāi)發(fā)難度降低，合圖布局等都可以很好的在客戶(hù)端上進(jìn)行控制。

具體SD-RTN的架構(gòu)可以參考下圖：

image

客戶(hù)端均通過(guò)UDP連接SD-RTN架構(gòu)服務(wù)，通過(guò)SD-RTN的就近接入策略，讓使用者就近接入質(zhì)量最好的數(shù)據(jù)節(jié)點(diǎn)，經(jīng)過(guò)傳輸延遲和質(zhì)量?jī)?yōu)化的最優(yōu)路徑，自動(dòng)避免網(wǎng)絡(luò)擁塞和骨干網(wǎng)絡(luò)故障的影響，將數(shù)據(jù)發(fā)送給其他客戶(hù)端。若有常規(guī)的長(zhǎng)延遲旁路直播，則可以將主播與連麥者合成一路直播流，通過(guò)RTMP推到CDN，進(jìn)行下發(fā)。連接這一路的觀眾，不能參與連麥互動(dòng)，達(dá)到了最佳直播效果。

嘉賓介紹

單輝，資深實(shí)時(shí)云計(jì)算架構(gòu)師，負(fù)責(zé)多媒體后臺(tái)開(kāi)發(fā)。原2345.com實(shí)時(shí)云計(jì)算架構(gòu)師，主導(dǎo)輸入法自然語(yǔ)言處理、實(shí)時(shí)云計(jì)算方案搭建及開(kāi)發(fā)。曾任職華為、JEDAT，研究UMTS、LTE等數(shù)據(jù)源解析統(tǒng)計(jì)，參與電子設(shè)計(jì)自動(dòng)化產(chǎn)品等開(kāi)發(fā)。在實(shí)時(shí)云計(jì)算，數(shù)據(jù)處理方面有深厚的經(jīng)驗(yàn)積累。

image

聊聊架構(gòu).jpg

原文來(lái)自:聊聊架構(gòu)

標(biāo)簽／Tag

技術(shù)文章 業(yè)界新聞 業(yè)界資訊聚合新聞 聚合公告