摘要

在2021年的互聯(lián)網(wǎng)時代，越來越多的網(wǎng)絡(luò)直播節(jié)目相繼涌現(xiàn)。瀏覽器是用戶最易接觸的渠道之一，聚集了大量觀看直播的用戶。當(dāng)用戶們同時觀看直播內(nèi)容時，服務(wù)器承受的負(fù)載隨著用戶量的增加而增大，會導(dǎo)致播放的卡頓，延遲等用戶體驗的下降；而且高昂的服務(wù)器帶寬成本也不容忽視。

那么是否存在一套解決方案，在保證用戶體驗與服務(wù)質(zhì)量的前提下，又可以有效的降低服務(wù)器的負(fù)載與帶寬呢？那就是接下來要介紹的Web P2P技術(shù)了。

一、Web P2P的前世今生

2010年，Adobe在Flash Player 10.0推出了實時流媒體RTMFP，使用RTMFP在Flash Player之間進(jìn)行P2P成為可能。在隨后的幾年內(nèi)，該協(xié)議在網(wǎng)絡(luò)上如雨后春筍般的被廣泛部署，但是從2020年末開始，各家的瀏覽器都已經(jīng)徹底不支持Flash了。我們又應(yīng)該如何在Web里面使用P2P呢？

誕生于2011年的WebRTC技術(shù)，在Google、Microsoft、Apple、Mozilla等大廠的支持下，成為了H5的標(biāo)準(zhǔn)，并且Chrome、Edge、Safari、Firefox等主流瀏覽器也都支持WebRTC。所以就可以通過WebRTC來實現(xiàn)P2P了。

下文把基于WebRTC實現(xiàn)的HTML5 P2P簡稱為H5 P2P。

二、WebRTC簡介

WebRTC的總體架構(gòu)如下圖所示，如果是瀏覽器開發(fā)者，通常需要關(guān)注并實現(xiàn)WebRTC C++ API，而我們的目標(biāo)是基于瀏覽器實現(xiàn)P2P，所以只需要關(guān)注Web API即可。

整體的H5 P2P都是基于RTCPeerConnection和RTCDataChannel來實現(xiàn)的，只是實現(xiàn)數(shù)據(jù)層面的P2P，不包含音視頻通信的內(nèi)容。

三、總體架構(gòu)

1. H5 P2P客戶端

主要包含通信模塊、傳輸模塊、節(jié)點管理、調(diào)度模塊、存儲模塊和統(tǒng)計模塊：

通信模塊：主要負(fù)責(zé)和服務(wù)端（上圖中的Index、CPS、Tracker）進(jìn)行信令的通信

傳輸模塊：包含HTTPClient和基于RTCDataChannel實現(xiàn)的RTCClient（上傳&下載）

節(jié)點管理：不同用戶間P2P主被動連接、斷開、淘汰、資源信息同步

調(diào)度模塊：根據(jù)buffer水位、分片信息、節(jié)點質(zhì)量和規(guī)模進(jìn)行CDN/P2P調(diào)度

存儲模塊：負(fù)責(zé)媒體數(shù)據(jù)的存儲、排序、以及淘汰

統(tǒng)計模塊：包含系統(tǒng)運行的埋點的實現(xiàn)

2. H5 P2P服務(wù)端

主要包含Index、CPS、Tracker和Stun服務(wù)：

Index：索引服務(wù)，提供其他服務(wù)地址。

CPS：資源屬性服務(wù)，將直播流的URL轉(zhuǎn)換為RID。

Tracker：資源追蹤服務(wù)，主要存儲用戶和資源之間的索引關(guān)系。

MQTT：信令服務(wù)，轉(zhuǎn)發(fā)用戶間建立P2P連接的offer/answer/candidate SDP協(xié)議。

Stun：采用coturn部署，主要用戶節(jié)點之間建立對等連接的UDP穿透。

四、階段流程

下圖簡略的展示了整體方案的各個階段、流程：

Step 1：網(wǎng)頁打開，首先向Index服務(wù)請求其他服務(wù)的地址，保存于內(nèi)存中

Step 2：客戶端收到直播請求，向CPS發(fā)送請求將URL轉(zhuǎn)換為資源ID(RID)，相同內(nèi)容相同清晰度的直播流的資源ID(RID)是相同的，表明可以互相分享數(shù)據(jù)

Step 3：客戶端首先會啟動HTTPClient進(jìn)行數(shù)據(jù)下載，優(yōu)先保證秒播。同時做以下2件事

a. 客戶端向Tracker服務(wù)發(fā)送Address協(xié)議，獲取其他正在觀看該直播的用戶地址，待后續(xù)建立連接，分享數(shù)據(jù)

b. 客戶端向Tracker服務(wù)發(fā)送Publish協(xié)議，將自己的信息告知Tracker，使得別人可以即使搜索到自己，進(jìn)行數(shù)據(jù)分享

Step 4：向從Tracker獲取的其他用戶建立連接，彼此交換信息，數(shù)據(jù)分享

五、連接建立

假設(shè)在Peer1和Peer2之間傳輸數(shù)據(jù)，那么在傳輸之前，首先需要建立連接。在WebRTC中，瀏覽器間通過ICE框架建立對等連接，主要包含Stun、TURN，下面分別簡單介紹一下：

1. ICE

ICE（Interactive Connectivity Establishment）提供的是一種P2P連接框架，統(tǒng)一各種NAT穿透技術(shù)（STUN，TURN）。基于offer/answer/candidate模式，通過多次地址交換，然后進(jìn)行連通性測試，穿透用戶網(wǎng)絡(luò)間各類防火墻。ICE主要包含STUN、TURN等協(xié)議。

2. STUN

STUN（Simple Traversal of UDP Through NAT）允許位于NAT設(shè)備后的客戶端找到自己的公網(wǎng)IP/Port地址，以及查詢出自己的NAT設(shè)備類型，通過這些信息使得兩個同時位于NAT后的2個設(shè)備之間建立UDP通信，具體的STUN流程可以參考RFC5389，不在此贅述。

3. TURN

通俗的說，TURN（Traversal Using Relays around NAT）就是中繼/轉(zhuǎn)發(fā)，并不是所有的設(shè)備之間都可以依靠STUN來建立連接的，那么當(dāng)兩個設(shè)備之間無法依靠STUN建立連接時，就會啟用TURN來進(jìn)行數(shù)據(jù)中轉(zhuǎn)。

由于我們的目標(biāo)是節(jié)約帶寬，如果采用TURN轉(zhuǎn)發(fā)的話，并不能減少服務(wù)器的帶寬消耗，另外一個原因是，在整個建立連接的過程中，有別于傳統(tǒng)的視頻通話只能1對1，這里的傳輸模式是1對多傳輸，所以并不要求每個連接都可靠，因此在H5 P2P項目我們僅僅通過STUN來實現(xiàn)連接的建立。

六、數(shù)據(jù)下載

1. 資源編碼

Web P2P網(wǎng)絡(luò)直播方案也可以同時支持任意多路直播同時進(jìn)行，必須保證各路直播流之間的獨立性，因此，我們提供一種統(tǒng)一的資源編碼方式，用來標(biāo)識唯一的一路直播流。這里主要借用直播流中的StreamId，通過計算MD5，生成固定長度的資源ID（RID），不僅保證了內(nèi)容相同，清晰度不同，RID也不同；也保證了相同的內(nèi)容，由于斷流切換源地址，導(dǎo)致URL變化，保證資源ID(RID)相同。

2. 下載調(diào)度

在整個直播過程中，由于可播放緩存的數(shù)據(jù)是非常小的，通常不超過10秒？因此如何實時的根據(jù)當(dāng)前的網(wǎng)絡(luò)狀態(tài)、網(wǎng)絡(luò)環(huán)境，作出使用CDN，又或是使用P2P的決策呢？這里，我們的最佳實踐主要如下：

a. 為了保障用戶的觀看體驗，當(dāng)緩沖區(qū)的可播數(shù)據(jù)低于某個閾值（例如5秒），就切換CDN下載

b. 當(dāng)發(fā)現(xiàn)某一片未來的數(shù)據(jù)，周圍的人都沒有的時候，即使可供播放的buffer還有很多，不滿足a策略的描述，這個時候，為了盡快的分發(fā)數(shù)據(jù)，也應(yīng)該及時切換至CDN，出現(xiàn)這種情況時，往往表示這個節(jié)點以及他連接的節(jié)點都處于整個直播數(shù)據(jù)分發(fā)的頂層，為了防止出現(xiàn) “一人下載多人圍觀” 的場景，本著更快的下載導(dǎo)致更早的上傳理念，不僅僅要求該節(jié)點自身盡快CDN下載，同時也保證周圍用戶某個比例（例如15%）也盡快采用CDN下載，從而使得整體數(shù)據(jù)的分發(fā)效率提升。

3. P2P任務(wù)分配

a. 任務(wù)編號

對于每一個數(shù)據(jù)塊都有一個自然數(shù)編號（sn），對于這個數(shù)據(jù)塊，我們按照固定長度（默認(rèn)16KB）的大小進(jìn)行切分，簡稱chunk_index，那么（Rid, sn, chunk_index）就可以唯一確定一個數(shù)據(jù)片了。

b.分配請求

分配過程類似于撲克中的發(fā)牌機(jī)制，唯一的要求是對方這個節(jié)點擁有這個數(shù)據(jù)塊，并且質(zhì)量越好的節(jié)點，越多越分配靠近播放點的、重要的數(shù)據(jù)。下圖簡明扼要的展示了3個相同質(zhì)量節(jié)點分配2個數(shù)據(jù)塊（9個數(shù)據(jù)片）的過程。

4. 內(nèi)存控制

對于Web P2P來說，所有的媒體數(shù)據(jù)都緩存在內(nèi)存中，但是，也并不是會緩存完整的數(shù)據(jù)。對于直播來說，所有用戶的觀看點都是非常接近的，因此，內(nèi)存始終緩存播放點前后的固定大小的數(shù)據(jù)。因為只有這部分?jǐn)?shù)據(jù)分享利用率才是最高的。

如上圖所示，有顏色的數(shù)據(jù)塊都是當(dāng)前在內(nèi)存緩存中的數(shù)據(jù)，其中紅色數(shù)據(jù)塊表示當(dāng)前的播放點，黃色數(shù)據(jù)塊表示過去已經(jīng)播放過的內(nèi)容，綠色數(shù)據(jù)塊表示未來還未播放的內(nèi)容，可以看到當(dāng)播放點從100移動至101時，97號數(shù)據(jù)塊就被淘汰了，同時103號數(shù)據(jù)塊作為最新的數(shù)據(jù)被下載下來并緩存到內(nèi)存中。

七、工程實踐

1. Goggle FlatBuffers

不管是服務(wù)器通信還是點對點的P2P傳輸均采用了FlatBuffers。FlatBuffers具有跨平臺、內(nèi)存和效率速度高，擴(kuò)展靈活等優(yōu)勢，被我們?nèi)脚_統(tǒng)一采用，大幅降低了通信成本。

2. 多瀏覽器兼容

線上支持WebRTC的瀏覽器不僅種類繁多，而且同一個產(chǎn)品的不同版本之間也可能千差萬別。為了解決這一痛點，最終采用了WebRTC adapter.js來解決這一挑戰(zhàn)。

3. 內(nèi)存池

盡管Node.js自帶垃圾回收機(jī)制，以及內(nèi)存管理策略，但是GC和內(nèi)存分配也是需要成本的，況且Web端是單線程環(huán)境，任何性能的提升都會減少時間上的損耗，進(jìn)而可以處理更大吞吐的網(wǎng)絡(luò)層傳輸以及業(yè)務(wù)邏輯。所以在內(nèi)存分配上我們采用了內(nèi)存池策略，基本實現(xiàn)了100%的內(nèi)存重復(fù)使用。

八、技術(shù)結(jié)果

下圖展示某次大型直播的帶寬分時統(tǒng)計，顯示在19:25到21:00階段內(nèi)的真實數(shù)據(jù)，隨著人數(shù)的涌入和離去，Web P2P全程帶來可觀的帶寬收益。最終評估Web P2P，在不影響用戶使用體驗的前提下，不僅可以有效降低服務(wù)器的負(fù)載壓力，并且能夠降低可觀比例的帶寬成本。

九、思考總結(jié)

目前，該技術(shù)已經(jīng)大規(guī)模應(yīng)用在各網(wǎng)絡(luò)直播中，良好的解決了服務(wù)質(zhì)量與帶寬成本的平衡。但是，我們也發(fā)現(xiàn)在超大規(guī)模的直播下，存在了一些提升的空間，主要如下：

(1) coturn與MQTT的服務(wù)性能不高，會制約直播的服務(wù)質(zhì)量。

(2) 接入邊緣網(wǎng)絡(luò)，打造多元化網(wǎng)絡(luò)，緩解CDN負(fù)載，并且可以進(jìn)一步降低CDN的帶寬成本。

總結(jié)

以上是生活随笔為你收集整理的构建基于浏览器的Web P2P网络直播的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。