P2P如何將視頻直播帶寬降低75%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23、節(jié)點(diǎn)根據(jù)這個(gè)ID從各個(gè)鄰居中快速拉 取整個(gè)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é)商加密方案來保證鏈路的合法性。大致的做法是 每個(gè)合法的節(jié)點(diǎn)單元（edge和所有的客戶節(jié)點(diǎn)）會(huì)向CA發(fā)起合法校驗(yàn)，如果檢驗(yàn)通過，C A會(huì)根據(jù)節(jié)點(diǎn)的ID、節(jié)點(diǎn)RSA公鑰、授權(quán)起始時(shí)間、授權(quán)終止時(shí)間等信息利用CA的RSA進(jìn) 行證書生成。每個(gè)拿到證書的節(jié)點(diǎn)單元需要和其他的節(jié)點(diǎn)進(jìn)行通信，會(huì)先交換證書，校驗(yàn)對(duì)方證書的合法性，讓后利用證書中的RSA公鑰加密一