內(nèi)容來(lái)源：本文由IT大咖說(shuō)（WeChat_ID：itdakashuo）轉(zhuǎn)載自LiveVideoStack微信公眾號(hào)（ID：?livevideostack），好文請(qǐng)多支持！感謝您的閱讀~

閱讀字?jǐn)?shù)：8699?| 15分鐘閱讀

摘要

眾所周知運(yùn)維成本是直播網(wǎng)站最大的成本組成，運(yùn)維成本則主要體現(xiàn)在帶寬，而伴隨主播與用戶對(duì)視頻清晰度以及連麥的需求不斷提升，直播帶寬也在與日俱增。本文整理自學(xué)霸君音視頻技術(shù)負(fù)責(zé)人袁榮喜在LiveVideoStackCon 2017上的分享，通過(guò)實(shí)踐案例講解了如何使用P2P技術(shù)將帶寬和延遲降低到傳統(tǒng)技術(shù)的1/3，并詳細(xì)介紹了P2P分發(fā)算法的架構(gòu)設(shè)計(jì)和技術(shù)實(shí)現(xiàn)細(xì)節(jié)。

大家好，我是來(lái)自學(xué)霸君的袁榮喜，我演講的主題是《P2P技術(shù)是如何拯救一家直播網(wǎng)站的》，眾所周知直播網(wǎng)站最大的成本就是運(yùn)維成本，當(dāng)然還會(huì)有一部分主播的成本，而運(yùn)維成本的主要表現(xiàn)就在于帶寬，從目前統(tǒng)計(jì)來(lái)看，一個(gè)直播網(wǎng)站的成本大概有30%來(lái)源于帶寬。

一個(gè)直播網(wǎng)站的窘境

我的一個(gè)朋友是做直播平臺(tái)的，每天大概有10萬(wàn)人觀看，在經(jīng)歷了2016年的千播大戰(zhàn)之后，他們升級(jí)了觀看體驗(yàn)——主要是提高了分辨率和清晰度，但成本也因此提高到了原本的5倍，也就是假如原本是20G，現(xiàn)在每天要付出100G的帶寬流量，這對(duì)于一個(gè)普通的平臺(tái)來(lái)說(shuō)成本是致命的。

基本情況

那么我們先來(lái)看下這家平臺(tái)的具體情況：

它是南方三線城市的直播平臺(tái)，PC占有率大概有70%，移動(dòng)端占有率在30%左右，碼流也從320x240，20K升級(jí)到640x480，大概每秒的單路碼流在800kbps左右，也就是100KB/S的樣子 。因?yàn)樗蚘Y類似，都屬于聊天室形式的，也就說(shuō)每一個(gè)觀看端都會(huì)有上麥的需求，也因此必須要解決延遲的問(wèn)題，如果延遲太大，在上麥的過(guò)程中和下麥的過(guò)程中有可能會(huì)產(chǎn)生信息不對(duì)等，由此丟失一部分信息，因此對(duì)于觀看端延遲要求在兩秒以內(nèi)，而麥與麥之間的延遲要控制在500毫秒，這就對(duì)延遲有非常高的要求。

成本

前面提到平臺(tái)觀看人數(shù)能達(dá)到10萬(wàn)以上，它每天在邊緣節(jié)點(diǎn)上就需要用83G來(lái)扛住邊緣節(jié)點(diǎn)的分發(fā)，由于系統(tǒng)是分布式的，因此在邊緣節(jié)點(diǎn)與邊緣節(jié)點(diǎn)之間也需要做分發(fā)，這部分又會(huì)需要2G的BGP帶寬流量，這個(gè)帶寬很大。因此它需大概100臺(tái)物理機(jī)來(lái)抗，對(duì)于私有云搭建的成本我并不是很了解，如果按照公有云來(lái)計(jì)算的話，每個(gè)月大概要支付百萬(wàn)以上的成本，這對(duì)于一個(gè)三線城市的小公司來(lái)說(shuō)壓力是巨大的，況且還有比較沉重的業(yè)務(wù)和寥寥無(wú)幾的融資渠道。

存活的希望

那么平臺(tái)想要繼續(xù)存活，就需要將帶寬成本降到現(xiàn)在的1/3，也就是只用30G就能解決問(wèn)題。將產(chǎn)品遷移到CDN上是一個(gè)解決方法，畢竟各大云廠商目前的優(yōu)惠力度還是比較大的，但他們?cè)谇捌诓捎肅DN做測(cè)試時(shí)發(fā)現(xiàn)會(huì)有兩個(gè)問(wèn)題：首先是延遲問(wèn)題，在很多分享中也有提到CDN的延遲至少是3-5秒，有時(shí)候更大，尤其是在大規(guī)模直播下；而第二個(gè)問(wèn)題則是每個(gè)觀看端都會(huì)有上麥的需求，但連麥服務(wù)是需要額外付費(fèi)的，綜合計(jì)算使用CDN也無(wú)法降低成本，甚至還有增加。

那么我們考慮是否可以通過(guò)調(diào)整編解碼來(lái)實(shí)現(xiàn)，大家都知道H.265從編碼效果上來(lái)說(shuō)可以減掉一半的成本，我們也在小規(guī)模內(nèi)嘗試了替換，不過(guò)發(fā)現(xiàn)存在CPU消耗的問(wèn)題，因?yàn)橛^看端的設(shè)備比較多樣，既有移動(dòng)端、也有PC端，并且設(shè)備的性能參差不齊，在較差的機(jī)器上會(huì)頻繁出現(xiàn)卡頓，根據(jù)統(tǒng)計(jì)大致有50%的用戶無(wú)法接受這個(gè)方案。

那么既然是傳輸產(chǎn)生的高成本，是否可以對(duì)傳輸方式做優(yōu)化——P2P技術(shù)，它早期源于音頻分享和文件分享，并且是下一代CDN的主流技術(shù)。在做這樣一個(gè)系統(tǒng)之前首先需要調(diào)研目前用戶端上傳的最大帶寬，我們發(fā)現(xiàn)有50%以上用戶的上傳帶寬在1.6mbs以上，平均來(lái)看大概可以做到640KB/S 碼率的上傳程度。前期調(diào)查后，我們確立了系統(tǒng)設(shè)計(jì)的三個(gè)目標(biāo)：降成本、控延遲和保質(zhì)量，也就是在保證用戶體驗(yàn)下將成本降低1/3，在后期的小規(guī)模測(cè)試和大規(guī)模替換中的效果還是比較滿意的。

流媒體P2P分發(fā)系統(tǒng)

網(wǎng)絡(luò)架構(gòu)

接下來(lái)我們重點(diǎn)講解這個(gè)分發(fā)系統(tǒng)的具體細(xì)節(jié)，首先上圖是系統(tǒng)的架構(gòu)圖，大致分為四層：最上層是BGP——用來(lái)協(xié)調(diào)邊緣節(jié)點(diǎn)與邊緣節(jié)點(diǎn)之間的分發(fā)；第二層是邊緣節(jié)點(diǎn)，它主要是用來(lái)分發(fā)媒體數(shù)據(jù)到觀看端；第三層我們?cè)诳蛻舳藢用嫔献隽艘粚映?jí)節(jié)點(diǎn)，用來(lái)分?jǐn)偞蟛糠诌吘壒?jié)點(diǎn)的分發(fā)壓力，這一層的主要目的就是為了節(jié)省帶寬；第四層是普通節(jié)點(diǎn)，這主要是由于有些端可能是4G或者一些比較差的WiFi，它們可能沒(méi)有上傳的能力。那么在旁邊還有一個(gè)小紅圈，它表示推流的過(guò)程，因?yàn)闃I(yè)務(wù)中對(duì)上麥、連麥有需求，我們沒(méi)有用連麥系統(tǒng)，而是采用了一種推流加連麥的方式來(lái)做，使用的是可靠UDP，也就是RUDP技術(shù)。

三部分網(wǎng)絡(luò)

整個(gè)網(wǎng)絡(luò)分為三部分：一個(gè)是推流部分，就是我們要保證流是要推到邊緣節(jié)點(diǎn)上；第二是邊緣節(jié)點(diǎn)與邊緣節(jié)點(diǎn)要做一個(gè)可靠、快速的分發(fā)，讓所有數(shù)據(jù)盡量快到達(dá)Edge server，這樣保證延遲比較小；第三部分是P2P，當(dāng)數(shù)據(jù)到達(dá)Edge server上，我們要快速通過(guò)P2P網(wǎng)絡(luò)分發(fā)到各個(gè)觀看端進(jìn)行播放。在這個(gè)系統(tǒng)中有個(gè)錨點(diǎn)，就是所有Edge sever都應(yīng)該盡快拿到所有的視頻數(shù)據(jù)和音頻數(shù)據(jù)。

在具體介紹這三部分網(wǎng)絡(luò)實(shí)現(xiàn)方式之前，我們先來(lái)看下流媒體中最重要的一部分——分發(fā)切片，也就說(shuō)數(shù)據(jù)如何打包才能符合我們的要求和場(chǎng)景。最早我們采用HLS的方式，也就是一秒打一個(gè)分片，不過(guò)它會(huì)引來(lái)延遲的問(wèn)題，從實(shí)際的測(cè)試中我們發(fā)現(xiàn)會(huì)有大于一秒的延遲，但如果分片太小了就又會(huì)引入其他問(wèn)題。經(jīng)過(guò)測(cè)試，我們最終采用一幀為一個(gè)分片，這樣可以帶來(lái)三個(gè)好處：首先是粒度小，每一幀大概在幾十毫秒，這樣我們可以盡量去優(yōu)化這個(gè)延遲；第二點(diǎn)就是實(shí)現(xiàn)簡(jiǎn)單，因?yàn)槊恳粋€(gè)編解碼都是基于幀的編解碼，這樣天然的就是一個(gè)分片模式；第三點(diǎn)是組織比較靈活，可以與播放buffer無(wú)縫接合。

推流

接下來(lái)我們具體講解這三個(gè)網(wǎng)絡(luò)是如何實(shí)現(xiàn)的。首先是推流，推流一般來(lái)說(shuō)會(huì)用到RTMP或者說(shuō)TCP的方式，但它會(huì)帶來(lái)兩個(gè)問(wèn)題：在網(wǎng)絡(luò)不好的情況下，因?yàn)槊總€(gè)端都需要上傳和上麥的操作，這樣會(huì)引來(lái)延遲問(wèn)題，我們測(cè)試發(fā)現(xiàn)TCP最大的延遲有可能達(dá)到1.2秒，這是不可接受的；第二個(gè)就是在弱網(wǎng)環(huán)境下大量傳輸數(shù)據(jù)，它會(huì)產(chǎn)生TCP連接頻繁的斷開(kāi)，這就會(huì)造成數(shù)據(jù)推不上去或者間斷性的推上去，從而導(dǎo)致觀看節(jié)點(diǎn)頻繁卡頓。

UDP可以很好的解決延遲和連接的問(wèn)題，但由于它的不可靠，會(huì)產(chǎn)生丟包問(wèn)題，因此我們借助了WebRTC的GCC 原理，在UDP之上設(shè)計(jì)了一層可靠，保證數(shù)據(jù)可以盡快、盡好的傳到Edge server上。上圖是它的原理，它通過(guò)一系列并發(fā)的發(fā)包，最后再通過(guò)確認(rèn)機(jī)制來(lái)回饋要重傳的包或者說(shuō)什么時(shí)候重傳包。

單路徑RUDP

數(shù)據(jù)到了Edge server上之后就要把數(shù)據(jù)快速的傳輸?shù)狡渌鸈dge server，我們最初的設(shè)計(jì)和CDN一樣——通過(guò)BGP server單線的中轉(zhuǎn)，也就是Edge server將數(shù)據(jù)傳到BGP server，再由BGP server傳輸?shù)狡渌鸈dge server上，這種做法最大的好處在于實(shí)現(xiàn)簡(jiǎn)單，并且鏈路查找問(wèn)題比較明確。但同時(shí)它也存在兩個(gè)問(wèn)題：首先就是成本比較高，因?yàn)锽GP的成本是整個(gè)Edge server邊緣節(jié)點(diǎn)帶寬成本 的10倍；第二點(diǎn)因?yàn)樗墙⒃谒接性粕?，而私有云每個(gè)機(jī)房都有防火墻，而當(dāng)網(wǎng)站頻繁受到攻擊時(shí)就有可能變換防火墻策略，這樣就有可能導(dǎo)致某條鏈路不通或者到BGP不通，由此就會(huì)影響Edge server無(wú)法接收數(shù)據(jù)包，從而導(dǎo)致觀看節(jié)點(diǎn)卡頓。

多路徑RUDP

由此我們?cè)赗UDP之上設(shè)計(jì)了一個(gè)多鏈路的傳輸（如上圖）：首先Edge server之間是直連的，同時(shí)有多個(gè)BGP server來(lái)做relay ，中間是無(wú)狀態(tài)的，也就是即使某一條鏈路出現(xiàn)問(wèn)題，其他幾條鏈路還在并行傳數(shù)據(jù)，這樣就能保證盡量的可靠和可用。其次為了節(jié)省成本這里還有一個(gè)設(shè)計(jì)原則，Edge server之間盡量保證直連，不走BGP或者少量走BGP，這樣就可以節(jié)省一大部分BGP流量，根據(jù)統(tǒng)計(jì)可以節(jié)省80%的成本。

P2P網(wǎng)絡(luò)構(gòu)建

P2P連接

對(duì)于連接，穿越是一個(gè)非常頭疼的問(wèn)題，而我們?cè)谧畛醯陌姹疽彩腔贜AT的方式來(lái)做的，但同時(shí)引來(lái)一個(gè)問(wèn)題——穿越里只有60%，也就是說(shuō)有可能在某個(gè)防火墻或者NAT后面的節(jié)點(diǎn)擁有很好的上傳資源，卻沒(méi)有得到利用。因此我們通過(guò)STUN協(xié)議做了一個(gè)多端口的猜測(cè)機(jī)制，通過(guò)這個(gè)機(jī)制可以將整個(gè)穿越率優(yōu)化到80%。但依舊有一部分無(wú)法穿透，這是由于有些廠商會(huì)設(shè)置黑名單機(jī)制導(dǎo)致無(wú)法穿越，因此我們?cè)O(shè)計(jì)了云端協(xié)調(diào)穿越時(shí)機(jī)的機(jī)制，從而將穿越率優(yōu)化到大概90%，也基本達(dá)到我們的預(yù)期。

完成節(jié)點(diǎn)之間穿越，就可以做P2P通訊了。首先要建立心跳關(guān)系和心跳的狀態(tài)交換，不過(guò)雖然從原則上來(lái)講，一個(gè)節(jié)點(diǎn)跟所有的節(jié)點(diǎn)或者跟大部分節(jié)點(diǎn)能通訊是好的，但從實(shí)際效果來(lái)看并非如此，因?yàn)橹辈r(shí)有可能是一千個(gè)節(jié)點(diǎn)甚至更多節(jié)點(diǎn)，而一個(gè)節(jié)點(diǎn)不可能于這么多節(jié)點(diǎn) 頻繁的做心跳或者信息交換，否則本身的帶寬就會(huì)被這種探測(cè)包消耗掉，因此我們一般最多會(huì)選擇40個(gè)節(jié)點(diǎn)，而這40個(gè)節(jié)點(diǎn)也并非是固定不變的，它會(huì)有優(yōu)勝劣汰的機(jī)制，當(dāng)有節(jié)點(diǎn)被淘汰時(shí)我們就會(huì)從沒(méi)有穿越的節(jié)點(diǎn)中繼續(xù)穿越，然后達(dá)到一個(gè)平衡，如此就會(huì)形成一種群居效應(yīng)——好的節(jié)點(diǎn)會(huì)盡量聚集在一起。

節(jié)點(diǎn)評(píng)估

在確定了鄰居和通訊狀態(tài)以及探測(cè)機(jī)制后，我們就要對(duì)整個(gè)通訊做評(píng)估。評(píng)估分為兩部分：一個(gè)是評(píng)價(jià)鄰居，主要通過(guò)丟包率、RTT、通信命中率以及流媒體傳輸?shù)姆€(wěn)定性計(jì)算出一個(gè)親和度分值；第二就是評(píng)估自己，主要通過(guò)CPU、帶寬復(fù)用、網(wǎng)絡(luò)類型等計(jì)算出一個(gè)load（負(fù)載）值，通過(guò)它我們就能知道本地節(jié)點(diǎn)跟其他節(jié)點(diǎn)大概處于什么位置，我們就能進(jìn)行網(wǎng)絡(luò)策略調(diào)節(jié)、通訊的QOS、節(jié)點(diǎn)區(qū)分以及網(wǎng)絡(luò)收斂。我們?cè)缙诘木W(wǎng)絡(luò)收斂是通過(guò)對(duì)照表的方式實(shí)現(xiàn)的——也就是經(jīng)驗(yàn)值，但在網(wǎng)絡(luò)高度動(dòng)態(tài)時(shí)，會(huì)出現(xiàn)網(wǎng)絡(luò)波動(dòng)以及與鄰居之間的通訊失效，因此我們采用一個(gè)簡(jiǎn)單的神經(jīng)網(wǎng)絡(luò)和一個(gè)收斂函數(shù)f(x) 來(lái)做參數(shù)的調(diào)整決策。

節(jié)點(diǎn)分層

完成節(jié)點(diǎn)評(píng)估后，我們需要根據(jù)評(píng)估結(jié)果做節(jié)點(diǎn)區(qū)分，也就是要解決超級(jí)節(jié)點(diǎn)和普通節(jié)點(diǎn)的問(wèn)題。超級(jí)節(jié)點(diǎn)最重要的作用就是分?jǐn)侲dge server的分發(fā)壓力，同時(shí)還可能承擔(dān)一部分網(wǎng)絡(luò)節(jié)點(diǎn)管理工作。超級(jí)節(jié)點(diǎn)的產(chǎn)生方式有兩種：一種是自我推薦，這種方式它需要得到Edge server的許可；第二種是Edge server自身的分發(fā)壓力過(guò)于繁重，就會(huì)從質(zhì)量比較好的普通節(jié)點(diǎn)中挑選一些比較穩(wěn)定的成為超級(jí)節(jié)點(diǎn)。由于網(wǎng)絡(luò)是動(dòng)態(tài)的，有可能會(huì)出現(xiàn)衰減、分割、斷開(kāi)的情況，因此超級(jí)節(jié)點(diǎn)并非是永久的，當(dāng)超級(jí)節(jié)點(diǎn)的網(wǎng)絡(luò)出現(xiàn)衰減，評(píng)估函數(shù)f(x) 會(huì)作出反應(yīng)降級(jí)為普通節(jié)點(diǎn)，這其實(shí)是一個(gè)高度動(dòng)態(tài)的循環(huán)過(guò)程 。

P2P分發(fā)媒體數(shù)據(jù)

成功構(gòu)建網(wǎng)絡(luò)之后就是如何做數(shù)據(jù)分發(fā)，我們將它分為三步：先推、后拉、再補(bǔ)償，我們下面逐一做詳細(xì)介紹。

三階段——推

我們假定已經(jīng)選舉好一個(gè)超級(jí)節(jié)點(diǎn)，那么邊緣節(jié)點(diǎn)就會(huì)按照上圖向下推送媒體數(shù)據(jù)到超級(jí)節(jié)點(diǎn)，超級(jí)節(jié)點(diǎn)再向下推給其他節(jié)點(diǎn)或超級(jí)節(jié)點(diǎn)，這個(gè)推送本身是樹(shù)型結(jié)構(gòu)，而P2P是圖形結(jié)構(gòu)，因此我們引入了預(yù)先訂閱的機(jī)制。舉例說(shuō)明，假設(shè)某個(gè)節(jié)點(diǎn)播放到媒體包的第十秒，它就要開(kāi)始訂閱第二十秒到三十秒的包。那么訂閱是如何完成的呢？超級(jí)節(jié)點(diǎn)在確定自己身份時(shí)會(huì)確定一個(gè)區(qū)域值，那么普通節(jié)點(diǎn)就會(huì)向所在區(qū)域的超級(jí)節(jié)點(diǎn)訂閱（有可能會(huì)向多個(gè)超級(jí)節(jié)點(diǎn)訂閱），對(duì)前面的例子而言，節(jié)點(diǎn)有可能會(huì)向超級(jí)節(jié)點(diǎn)A訂閱一三五七九秒的包，向B訂閱二四六八十秒的包。而超級(jí)節(jié)點(diǎn)也會(huì)做預(yù)先訂閱，比如對(duì)于超級(jí)節(jié)點(diǎn)A而言，如果它自身負(fù)責(zé)一三五七九秒的包，那么直接向Edge server訂閱；相反則需要向負(fù)責(zé)對(duì)應(yīng)分片 的超級(jí)節(jié)點(diǎn)做訂閱。

有了這樣的訂閱關(guān)系，Edge server和超級(jí)節(jié)點(diǎn)就會(huì)根據(jù)訂閱的記憶信息向下推送。而這個(gè)推送路徑一般最多達(dá)到兩層，因?yàn)槿龑拥耐負(fù)涮L(zhǎng)，會(huì)引來(lái)延遲，同時(shí)路徑過(guò)長(zhǎng)，一旦某一個(gè)節(jié)點(diǎn)退出，受影響的節(jié)點(diǎn)太多。

三階段——拉

我們前面提到整個(gè)協(xié)議是建立在UDP之上的，而在推送過(guò)程中UDP有可能會(huì)出現(xiàn)丟包，這時(shí)我們就需要向鄰居拉取，那么如何拉取？首先我們通過(guò)gossip協(xié)議確定拉取的目標(biāo)：也就是在單位時(shí)間內(nèi)定時(shí)發(fā)送本地緩沖區(qū)有哪些包，把這些包通過(guò)gossip協(xié)議交換出去，鄰居節(jié)點(diǎn)之間就會(huì)知道其他節(jié)點(diǎn)包的信息，假如出現(xiàn)丟包的情況，就可以通過(guò)gossip信息找到需要去拉取的節(jié)點(diǎn)，而拉取節(jié)點(diǎn)的選擇是通過(guò)前面提到的親和度分值盡量選取近的、通訊友好的節(jié)點(diǎn)，而這個(gè)拉取過(guò)程有可能會(huì)是多次的，如果出現(xiàn)拉取失敗，則會(huì)在一個(gè)RTT周期 之后向其他節(jié)點(diǎn)拉取，它是一個(gè)循環(huán)的隨機(jī)過(guò)程。

三階段——補(bǔ)償

通過(guò)上述的手段我們就可以盡力把包拉取到本地，也可以減少對(duì)Edge server的依賴，但我們無(wú)法排除這樣一種可能性，就是我的周圍鄰居都沒(méi)有這個(gè)包，那么此時(shí)我們就只能向Edge server拉取，我們?cè)谇懊嬗刑岬藉^點(diǎn)的概念，Edge server應(yīng)該具有大部分或者全部的流媒體信息。

向Edge sever發(fā)起補(bǔ)償?shù)臈l件一般有兩種：第一種是在整個(gè)P2P網(wǎng)絡(luò)中稀缺的包；第二種是迫切需要播放的包。但這里面還存在一個(gè)風(fēng)險(xiǎn)，也就是頻繁的發(fā)起補(bǔ)償請(qǐng)求其實(shí)對(duì)Edge server是非常大的沖擊，尤其是大量存在稀缺塊的時(shí)候 ，因此我們需要限制Edge server單位時(shí)間內(nèi)的補(bǔ)償請(qǐng)求，但由于有了這種限制可能會(huì)導(dǎo)致某些節(jié)點(diǎn)補(bǔ)償失敗，這時(shí)它就會(huì)通過(guò)前面拉取的過(guò)程，通過(guò)gossip協(xié)議做查找拉取 ，而不是所有的都向Edge server拉取，這也是為了防止Edge server瞬間被補(bǔ)償請(qǐng)求打死掉。

三階段播放buffer

當(dāng)所有數(shù)據(jù)全部到了本地，本地會(huì)有一個(gè)播放緩沖區(qū)，包 括WebRTC都會(huì)有JitterBuffer這樣的播放緩沖，我們也設(shè)計(jì)了一個(gè)Buffer，它與前面講到的三階段一一對(duì)應(yīng)。

第一個(gè)是推區(qū)間，也就是負(fù)責(zé)推流區(qū)域的緩沖，相當(dāng)于一個(gè)Push的JitterBuffer，這里設(shè)置的400ms緩沖主要是為了防止過(guò)度拉取，因?yàn)橥扑偷牧魇遣灰?guī)則的，UDP會(huì)出現(xiàn)抖動(dòng)、丟包、延遲，同時(shí)P2P多路徑傳輸之間本身的問(wèn)題會(huì)引來(lái)抖動(dòng)，這個(gè)buffer就是為了防止太快進(jìn)行拉取用的 。第二個(gè)是拉區(qū)間，在這個(gè)區(qū)間我們一般會(huì)向鄰居拉取三次，這之間的緩沖也就是與鄰居之間的3個(gè)RTT來(lái)回。如果三次沒(méi)拉到，就會(huì)進(jìn)入補(bǔ)償區(qū)，補(bǔ)償區(qū)就會(huì)向服務(wù)器拉取4次，如果沒(méi)有拉取到數(shù)據(jù)則會(huì)返回拉區(qū)間。

經(jīng)過(guò)這樣的循環(huán)過(guò)程最終包被播放，對(duì)于已經(jīng)播放的包是否要?jiǎng)h除呢？我們知道P2P是對(duì)等系統(tǒng)，可能別人缺少你已經(jīng)播放的包，向你拉取，但你播放結(jié)束后就直接刪除了，這就導(dǎo)致沒(méi)有命中，這種現(xiàn)象肯定不是我們希望看到的，因此我們將已經(jīng)播放的分片放到緩沖區(qū)中保留3秒，盡量使得拉取請(qǐng)求命中。以上就是整個(gè)分發(fā)過(guò)程。?

最終效果

下圖是Edge server的對(duì)比數(shù)據(jù)，我們?cè)贓dge server上做了一個(gè)開(kāi)關(guān)——將它等分為開(kāi)啟P2P分發(fā)和不開(kāi)啟P2P分發(fā)，對(duì)同一個(gè)Edge sever以一天為單位收集數(shù)據(jù)：每5分鐘采集一次當(dāng)時(shí)每秒出去的帶寬，圖中紅色的線表示沒(méi)有開(kāi)啟P2P，也就是完全使用Edge server來(lái)中轉(zhuǎn)，藍(lán)色的線表示開(kāi)啟P2P。圖中我們可以看到在高峰期，開(kāi)啟P2P從Edge server輸出的流量大概不到100mb/s ，而未開(kāi)啟P2P的則是達(dá)到了將近480mb/s ，也就是在 Edge server上可以節(jié)省到原來(lái)的1/4。

經(jīng)過(guò)算法的升級(jí)，我們最終實(shí)現(xiàn)了這樣的效果：邊緣節(jié)點(diǎn)帶寬大致降到24G；BGP由于采用了多鏈路保障和直鏈的方式，大概降到原來(lái)的1/3-1/4的比例；因?yàn)閹挼慕档?，?duì)物理服務(wù)器的依賴也就自然減少，目前服務(wù)器降到41臺(tái)左右。這里值得一提的是，通過(guò)測(cè)試我們所有的端延遲大概在1秒左右，最大延遲在2秒左右，連麥延遲在200~800毫秒之間 ，與原先的情況相比，在保留固有功能和連麥系統(tǒng)等服務(wù)沒(méi)受到影響的情況下，我們節(jié)省了大概1/3的帶寬，基本達(dá)到了我們最初的要求，同時(shí)我們也還在不斷優(yōu)化這個(gè)網(wǎng)絡(luò)模型，也歡迎感興趣的小伙伴與我探討。

以上是本次的分享，感謝大家。

編者：IT大咖說(shuō)，轉(zhuǎn)載請(qǐng)標(biāo)明版權(quán)和出處