1、P2P技術(shù)如何將直播帶寬降低75%?實時直播經(jīng)過去年的千播大戰(zhàn)后已經(jīng)成為互聯(lián)網(wǎng)應(yīng)用的標(biāo)配技術(shù)，但直播平臺的成本卻一 直居高不下，各個平臺除了挖主播、挖網(wǎng)紅以外，其背后高額的帶寬費用也是他們最大的 一塊成本。現(xiàn)階段直播技術(shù)在傳輸方面分為兩塊：CDN和連麥系統(tǒng)，CDN負(fù)責(zé)流媒體的分發(fā) 傳輸，連麥系統(tǒng)負(fù)責(zé)解決同時多個主播間互動的實時通信傳輸問題。我們始終認(rèn)為基于CD N+連麥系統(tǒng)的直播技術(shù)是一個高成本高消耗的技術(shù)，從各大直播平臺紛紛虧損就驗證了這 一點。除了帶寬成本，延遲問題也是現(xiàn)在直播技術(shù)一個硬傷。我們很早就意識到現(xiàn)在傳統(tǒng) 的直播技術(shù)是無法大規(guī)模進(jìn)行在線教育互動直播，所以學(xué)霸君從2016年下半年就

2、開始研發(fā) 基于UDP和P2P技術(shù)的互動直播技術(shù)架構(gòu)。整個系統(tǒng)的設(shè)計目標(biāo)是：.端到端延遲控制在秒級范圍之內(nèi)。.在不影響視頻質(zhì)量的情況下盡力節(jié)省分發(fā)帶寬。整個基于P2P技術(shù)的分發(fā)架構(gòu)在一個10W+直播平臺上進(jìn)行了 9個月的測試和調(diào)優(yōu)，初步達(dá) 成了設(shè)計目標(biāo)。那整個系統(tǒng)是怎么設(shè)計的？使用了那些技術(shù)來達(dá)成目標(biāo)的？那接下來重點 來說一說架構(gòu)設(shè)計和技術(shù)細(xì)節(jié)。.P2P分發(fā)網(wǎng)絡(luò)架構(gòu)整個傳輸分發(fā)網(wǎng)絡(luò)我們把連麥系統(tǒng)和分發(fā)系統(tǒng)合二為一，將分布式推流與邊緣節(jié)點分發(fā)作 為一套傳輸體系，通過服務(wù)之間的P2P通信和路由選擇來實現(xiàn)連麥的最小時延，架構(gòu)如下 圖：relaynodenodenOdenodenodenodesuper

3、Lnode superLnodleiuper node,relaynodenodenOdenodenodenodesuperLnode superLnodleiuper node,叵 UpePinode服W間p2P分發(fā) 推流BGP s e rve rEdge | server 圖1整個傳輸分發(fā)網(wǎng)絡(luò)分為三部分：推流部分、服務(wù)之間P2P和客戶節(jié)點P2P。這個傳輸網(wǎng)絡(luò) 有一個系統(tǒng)錨點：假定推流者speaker推到Edge server上是不會發(fā)生丟包和延遲的，Ed ge server會通過服務(wù)間P2P快速將收到的流數(shù)據(jù)分發(fā)到其他的Edge server,而且在這個 過程也不會發(fā)生延遲和丟包。為什么需

4、要這樣一個錨點？因為在客戶節(jié)點的P2P網(wǎng)絡(luò)需要 保證流暢性和最小延遲，也就是要求所有的Edge server在最短時間周期內(nèi)擁有的完整的 數(shù)據(jù)，至于為什么要這樣，后面我們在流補償環(huán)節(jié)重點介紹。我將通過整個流數(shù)據(jù)傳輸過程來解析具體的技術(shù)細(xì)節(jié)，但在這之前首先要解決的就是媒體 數(shù)據(jù)分片問題，所有的傳輸過程會基于分片(segment)來設(shè)計。媒體數(shù)據(jù)分片媒體數(shù)據(jù)分片是整個分發(fā)傳輸體系中最為基礎(chǔ)的部分，我們在設(shè)計分片時主要考慮的是時 延和消耗的問題，分片如果太大，傳輸?shù)臅r延就會越高，例如：HLS。如果分片太細(xì)，網(wǎng)絡(luò) 中回饋報文就會很多，對P2P網(wǎng)絡(luò)來說額外的消耗也是個問題。最后我們借鑒了 RTP和FL

5、V中的經(jīng)驗，采用按幀來做數(shù)據(jù)分片，這樣做有以下幾個好處：按幀分片延遲粒度小，可以在幀傳輸進(jìn)行延時優(yōu)化 實現(xiàn)簡單，與編解碼器編碼原則一致組合靈活，可以實現(xiàn)播放buffer無縫結(jié)合。每一個分片稱作為segment,用一個自增長的32位ID來表示唯一性，傳輸過程都是以這個 ID為標(biāo)示來確定數(shù)據(jù)的完整性。推流與連麥確定好了媒體分片就可以進(jìn)行推流了，我們把推流和分發(fā)的路徑合二為一，上麥者是將流 數(shù)據(jù)segment推送到離自己最近的Edge server上，而不是推送到專門的連麥系統(tǒng)上。我 們推流傳輸使用的是RUDP傳輸算法，這個RUDP是采用了類似BBR基于延遲和丟包來設(shè)計 的擁塞算法，并且對報文做了擁

6、塞丟棄，示意圖如下：rudp senderrudp receiver關(guān)于RUDP的細(xì)節(jié)可以參考我的另一篇文章UDP是怎么實現(xiàn)可靠的。至于為什么不采用 RTP或者RTMP/TCP來推流，RTP雖然是基于UDP的，但需要通過RTCP和NACK來保證可靠 性，需要設(shè)計擁塞算法，也需要對RTP進(jìn)行改造擴展，而且還受RTP協(xié)議本身的限制，所 以我們并沒有直接采用RTP。對于RTMP/TCP設(shè)計是很簡單，但在弱網(wǎng)環(huán)境延遲很大，而且 容易引起重連，所以在設(shè)計之初就否定了。2.3server 間的 P2P 因為整個傳輸分發(fā)網(wǎng)絡(luò)是分布式的，由多個edge server組成，而且其他的連麥者可能在 其他的edge

7、 server上。所以基于系統(tǒng)錨點，媒體數(shù)據(jù)分片到edge server上必須盡快的 分發(fā)到其他的edge server上。最早我們采用的是統(tǒng)一用BGP server來中轉(zhuǎn)，這樣的耗費 的BGP帶寬很多，而且BGP server 一旦異常，整個edge server之間的通信就中斷了。其 實大部分時間跨運營商之間的edge server之間延遲也沒有想象的那么大，這可以考慮使 用Edge server之間點對點通信來解決問題，所以我們設(shè)計了一個基于RUDP無窗口多路徑 的傳輸模型來進(jìn)行edge server之間的通信，如下圖：上圖的通信模型是一個多路徑并聯(lián)通信模型，我們在RUDP發(fā)送前添加了一

8、個路徑路由表， 這個路由表記錄了各個路徑的分發(fā)概率，RUDP每次向接收端發(fā)送包時會通過路由表中的概 率來選取路徑，那么確定路由表概率就是一個非常重要的事情。我們是通過RUDP實時的A CK反饋和路徑實時ping探測來得到網(wǎng)絡(luò)的狀態(tài)（丟包，延遲，抖動），再將網(wǎng)絡(luò)狀態(tài)參數(shù) 輸入到逼近函數(shù)來確定各條路由的概率，這里有條原則：如果edge server之間直連的延 遲和丟包足夠小的情況下，直連通信路由的概率將會接近100%，如果某一條路由出現(xiàn)周期 性斷開或者延遲超過200ms，它的概率會接近0。以下是整個路由概率評估的過程示意圖:.P2P網(wǎng)絡(luò)構(gòu)建過程媒體流數(shù)據(jù)通過edgeserver間的P2P多路徑傳

9、輸網(wǎng)絡(luò)到達(dá)各個edge server上，接下每個 edge server需要將流數(shù)據(jù)分片下發(fā)到各個客戶節(jié)點上，我們針對了上麥節(jié)點做了傳輸特 殊處理讓時延更小，過程和普通的RTC通信模型相似，這里就不贅述了。觀看節(jié)點上分發(fā) 采用的自組織P2P網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)分發(fā)的，既然是通過P2P下發(fā)的，那么就要在客戶節(jié)點群 構(gòu)建一個P2P網(wǎng)絡(luò)，這個網(wǎng)絡(luò)是怎么構(gòu)建的？具體分為三步：連接、評估、分層。連接客戶節(jié)點程序是運行在客戶機上的，大部分客戶節(jié)點都會在路由器或者NAT后面，他們之 間要相互建立連接，必須穿越彼此的NAT和防火墻。雖然現(xiàn)在穿越NAT的方法，例如：STU N、ICE等。但穿越連通率始終是一個問題，如果

10、穿越率太低，會讓很多優(yōu)質(zhì)的節(jié)點資源得 不到充分利用。在設(shè)計穿越方案時直連連通率放在第一位，我們通過修改STUN協(xié)議設(shè)計了 一種基于端口多次猜測和嘗試的穿越機制，先會通過類似STUN協(xié)議判斷NAT類型、NAT端 口變化規(guī)律、NAT是否有黑名單機制等信息，然后將這些信息存到轄區(qū)連接中的edge serv er中。當(dāng)有伙伴節(jié)點來與它穿越，會交換彼此的這些信息，不同的排列組合會有不同的穿 越策略，每一次穿越的過程和結(jié)果都會記錄到我們的后臺數(shù)據(jù)庫，我們會周期將這些數(shù)據(jù) 進(jìn)行分析并調(diào)整協(xié)商穿越策略。如下圖：stun protoC多次猾口君逑多謔者stun protoC多次猾口君逑多謔者圖5穿越完成后，節(jié)點

11、之間就會進(jìn)行連接握手和身份證書（關(guān)于為什么要證書后面細(xì)講），建 立通信聯(lián)系和鄰居關(guān)系。那么鄰居關(guān)系是怎么動態(tài)變化的呢？鄰居關(guān)系與評估鄰居問題 連接一旦完成，節(jié)點與節(jié)點之間就成為鄰居，彼此會進(jìn)行狀態(tài)交換和心跳，那么問題來了， 一個直播系統(tǒng)有成千上萬的節(jié)點參與，如果都兩兩相連的話光心跳通信就可以將客戶節(jié)點 的上傳帶寬占滿。我們基于這個原則設(shè)計了一個節(jié)點LRU淘汰鏈表，鏈表中保持40個聯(lián)系 的鄰居節(jié)點。但老的節(jié)點會退出，新的節(jié)點會加入，LRU會根據(jù)鄰居與自己的通信狀態(tài)來 進(jìn)行LRU新增和淘汰，原則如下：就近原則，內(nèi)網(wǎng)優(yōu)先，同城同一營商網(wǎng)絡(luò)次之。周期性評測延遲和媒體分片命中率，末位劣汰。當(dāng)LRU列表中

12、節(jié)點不足40個時會從備用節(jié)點列表中選取進(jìn)行新的節(jié)點進(jìn)行連接并加 入到LRU中。節(jié)點評估 每個客戶節(jié)點的計算能力、通信能力、網(wǎng)絡(luò)分區(qū)等都不一樣，這使得我們必須對每個節(jié)點 做一個評價，對一個節(jié)點的評價分為兩部分：鄰居節(jié)點對自己的評價和自己對自己的評估。 鄰居評價主要是： RTT丟包率請求命中率通過這三個參數(shù)會對每個鄰居計算出一個親和力分值score，這個值會用于后面的分發(fā)選 擇。評估自己主要是：CPU、內(nèi)存網(wǎng)絡(luò)類型/訐1/46/有線網(wǎng)絡(luò)上傳帶見節(jié)點會周期性計算這兩類參數(shù)，通過一個網(wǎng)絡(luò)QOS收斂函數(shù)來計算節(jié)點能力和對鄰居QOS 策略。節(jié)點分層節(jié)點評估最終的目的是讓有能力的節(jié)點成為超級節(jié)點(super

13、 node)來分擔(dān)edge server 的分發(fā)壓力。那么一個節(jié)點成為超級節(jié)點的條件是什么呢？有以下幾個條件：有足夠的上傳帶寬，4G和弱WIFI下不能成為超級節(jié)點有空閑的CPU和內(nèi)存，計算能力不夠的低端移動設(shè)備不能成為超級節(jié)點對鄰居通信友好，不是通信孤島得到edge server的任命，和edgeserver之間通信順暢。超級節(jié)點如果性能衰減了怎么辦？答案是會退化成普通節(jié)點，因為節(jié)點評估是周期性實時 進(jìn)行的，如果發(fā)現(xiàn)節(jié)點性能衰減，edge server會讓其退化。既然任命了超級節(jié)點，那么超級節(jié)點是怎么工作的？每一個超級節(jié)點在被任命時都會分配 到一個分組ID，edge server會根據(jù)自己轄區(qū)

14、超級節(jié)點數(shù)量進(jìn)行分組，每個分組有多個超 級節(jié)點組成，分組內(nèi)的超級節(jié)點群負(fù)擔(dān)自己分組的媒體分片分發(fā)。例如：有5個超級節(jié)點 分組，這時單位周期內(nèi)有120個segment，那么第一個分組負(fù)責(zé)1、6、11、16編號的s egment分發(fā)，以此類推第二組負(fù)責(zé)2、7、12、17。這樣做是防止單個超級節(jié)點失效造 成網(wǎng)絡(luò)，增強P2P分發(fā)的穩(wěn)定性。示意圖如下：.P2P流媒體分發(fā)過程 通過上面的P2P網(wǎng)絡(luò)構(gòu)建過程我們知道整個P2P網(wǎng)絡(luò)其實是一個分層有向圖分發(fā)網(wǎng)絡(luò)，那 么具體是怎么進(jìn)行流數(shù)據(jù)分發(fā)的呢？也分三步：先推(push)、后拉(pull)、再補償，下面 來仔細(xì)解釋是怎么實現(xiàn)的。4.1push 在介紹超級節(jié)點時

15、有提到會根據(jù)segment ID將數(shù)據(jù)推到對應(yīng)的超級節(jié)點分組群上，超級節(jié) 點收到這些segment后怎么要怎么處理呢？按照P2P設(shè)計的原理應(yīng)該將數(shù)據(jù)轉(zhuǎn)發(fā)到其他分 組的超級節(jié)點或者普通節(jié)點上，但是如果都這樣推有可能會造成網(wǎng)絡(luò)發(fā)送冗余而消耗過多 的帶寬。為了解決這個問題設(shè)計了一個預(yù)先訂閱機制，原理就是每個P2P客戶節(jié)點會根據(jù) 自己緩沖區(qū)最大的segment ID來進(jìn)行預(yù)訂，提前預(yù)訂10秒以后的媒體數(shù)據(jù)分片，預(yù)訂請 求是根據(jù)節(jié)點評估出來的親和力值score來做權(quán)衡隨機請求，收到這些請求的超級節(jié)點會 將預(yù)訂的分片請求信息保存下，等到edge server推送到這個分片到這個超級節(jié)點，它就 會無條件轉(zhuǎn)發(fā)

16、這些被預(yù)訂的報文給發(fā)起預(yù)訂的節(jié)點，如下圖所示：從edge server到所有節(jié)點路徑最多兩層，這樣做是為了控制鏈路延遲不同分組supernode之間會相互訂閱對應(yīng)分組的segment普通node只會向super node發(fā)起訂閱4.2pull數(shù)據(jù)segment通過預(yù)先點閱的方式進(jìn)行push推送到各個客戶節(jié)點，但網(wǎng)絡(luò)是會丟包，supe r node也有可能會中途退出，這樣就會造成最終的節(jié)點發(fā)生丟包，那丟包了我們怎么辦？ 我們設(shè)計一個向鄰居拉取缺失分片的機制，大致的流程如下：.節(jié)點周期性檢查丟失分片的信息和收到分片的信息，構(gòu)建一個gossip協(xié)議向鄰居交換 緩沖區(qū)信息.節(jié)點收到鄰居的gossip信

17、息，將對方擁有的分片信息記錄到本地.本地根據(jù)記錄鄰居的分片信息查找自己丟失的分片，通過鄰居親和力值score進(jìn)行權(quán) 衡隨機選取鄰居，并向選取的鄰居發(fā)起pull請求.收到鄰居拉取分片請求，將分片發(fā)往請求的節(jié)點。整個步驟會周期性嘗試多次拉取，示意圖如下：nodenodenode /yPull nodenodenode /yPull segment - 1puli= 5pull SGgntesit = 6oss s-egmejits. = 1? 57 6)圖8這里值得一說的是因為會周期性交換緩沖區(qū)的gossip信息，這意味著緩沖區(qū)的gossip 信息越小越好，我們設(shè)計了一個類似bloom filte

18、r來描述gossip信息，不僅可以減小go ssip報文的數(shù)據(jù)大小，而且比對速度也很快。補償因為P2P的客戶節(jié)點是不穩(wěn)定的，有可能某個segment通過拉取多次還是沒有收到，這 個segment又臨近播放位置，那么缺失這個segment的節(jié)點會直接向edge server請求補 償讓其盡快傳送這個分片，這樣做的目的是防止因為P2P通信造成丟包的卡頓。這也就是 說每個edge server需要擁有所有分片數(shù)據(jù)，也是系統(tǒng)錨點。流程入下圖：superget segment = 2 gat segment = 3loss segment superget segment = 2 gat segment

19、 = 3loss segment = 3這個流程大部分情況下沒有問題，但如果同一時刻大部分客戶節(jié)點都缺失某幾個segment 分片時，會有大量的補償請求到edge server上會造成網(wǎng)絡(luò)風(fēng)暴。我們在應(yīng)對這個問題設(shè) 計了個稀缺評估和拒絕服務(wù)的機制。這個機制當(dāng)單位時間內(nèi)太多個補償請求到達(dá)edge ser ver會拒絕自己能承受之外的請求，只重發(fā)承受范圍之內(nèi)的分片。而且這個過程還會對補 償請求做稀缺評估，如果某個分片大部分節(jié)點都沒有，它會主動將這個分片通過super no de群再推送一次。緩沖buffer與時延控制 通過上面的三個階段可以將所有數(shù)據(jù)segment分發(fā)到每個客戶節(jié)點上，但客戶節(jié)點需

20、要一個緩沖buffer來配合這個三個階段和本地的播放，buffer如果緩沖時間過長，會引起不必要的延遲，如果過短會造成卡頓和三個階段不完整。為此我們設(shè)計了一個三階段buffer動態(tài)緩沖區(qū),入下圖所示：evictplaygetpull3000msj1 0RTT)13 kRTT.10i過期區(qū)間補盆區(qū)間pull區(qū)間時間軸圖10來解釋下上圖的各個區(qū)間的意思：Push區(qū)間：因為分片是通過不同的supernode推送過來的，那么必然會造成一定的抖動， 所以在buffer最開始的頭上會有一個jitter緩沖階段，直到第一個鄰居節(jié)點gossip信息 中有這個分片push位置結(jié)束，這個階段一般100300ms。

21、Pull區(qū)間：分片時序進(jìn)入pull區(qū)間后，會周期性檢查丟失的分片，根據(jù)gossip掌握的鄰 居進(jìn)行權(quán)衡拉取，會進(jìn)行3次嘗試，每一次嘗試時間是本地節(jié)點與鄰居之間的RTT值。3 次失敗進(jìn)入補償區(qū)間。補償區(qū)間：分片時序進(jìn)入補償區(qū)間后，也會周期檢查丟失的分片，根據(jù)丟失的分片ID直接 向edge server請求拉取，嘗試4次，每次嘗試時間一個本地節(jié)點與edge server之間的 RTT。如果4失敗進(jìn)行waiting狀態(tài)，等待鄰居gossip或者edge server主動推送。過期區(qū)間：被播放后的分片會放到這個過期區(qū)間中而不是立即刪除掉，為什么呢？因為每 一個節(jié)點的播放時間點不同，有可能本地播放的分片

22、正是其他節(jié)點丟失的分片，有可能其 他節(jié)點會通過pull來拉取，所以我們會把播放后的分片放在過期區(qū)間3秒后再刪除。秒開問題上面分發(fā)的三個階段和buffer控制解決了流持續(xù)分發(fā)和播放延遲控制問題，但現(xiàn)階段所有 的直播技術(shù)必須要有秒開，其實P2P分發(fā)在解決秒開比單純的server CDN轉(zhuǎn)發(fā)來的更加簡 單。秒開就是用戶進(jìn)入直播間時瞬間能看到主播的視頻圖像，那秒開的宗旨是新進(jìn)入的客 戶節(jié)點要求服務(wù)端邊緣節(jié)點從視頻的上一個GOP關(guān)鍵幀開始發(fā)送數(shù)據(jù)，客戶節(jié)點再根據(jù)視 頻編碼器從這個GOP關(guān)鍵幀0等待加速播放即可。我們在P2P分發(fā)網(wǎng)絡(luò)中新進(jìn)入的節(jié)點 會收Edgeserver的上一個GOP關(guān)鍵幀分片ID,客戶

23、節(jié)點根據(jù)這個ID從各個鄰居中快速拉 取整個GOP分片數(shù)據(jù)，而不是單純的讓Edge server來發(fā)，秒開的速度平均縮短了 100毫 秒。.P2P內(nèi)容授權(quán)直播分發(fā)技術(shù)除了傳輸分發(fā)以外，還需要考慮內(nèi)容防盜和授權(quán)，P2P系統(tǒng)中更加需要考慮 系統(tǒng)安全性。我們引入了 CA證書和雙端協(xié)商加密方案來保證鏈路的合法性。大致的做法是 每個合法的節(jié)點單元（edge和所有的客戶節(jié)點）會向CA發(fā)起合法校驗，如果檢驗通過，C A會根據(jù)節(jié)點的ID、節(jié)點RSA公鑰、授權(quán)起始時間、授權(quán)終止時間等信息利用CA的RSA進(jìn) 行證書生成。每個拿到證書的節(jié)點單元需要和其他的節(jié)點進(jìn)行通信，會先交換證書，校驗對方證書的合法性，讓后利用證書中的RSA公鑰加密一