摘要
在2021年的網際網路時代，越來越多的網絡直播節目相繼湧現。浏覽器是使用者最易接觸的管道之一，聚集了大量觀看直播的使用者。當使用者們同時觀看直播内容時，伺服器承受的負載随着使用者量的增加而增大，會導緻播放的卡頓，延遲等使用者體驗的下降；而且高昂的伺服器帶寬成本也不容忽視。
那麼是否存在一套解決方案，在保證使用者體驗與服務品質的前提下，又可以有效的降低伺服器的負載與帶寬呢？那就是接下來要介紹的Web P2P技術了。
一、Web P2P的前世今生
2010年，Adobe在Flash Player 10.0推出了實時流媒體RTMFP，使用RTMFP在Flash Player之間進行P2P成為可能。在随後的幾年内，該協定在網絡上如雨後春筍般的被廣泛部署，但是從2020年末開始，各家的浏覽器都已經徹底不支援Flash了。我們又應該如何在Web裡面使用P2P呢？
誕生于2011年的WebRTC技術，在Google、Microsoft、Apple、Mozilla等大廠的支援下，成為了H5的标準，并且Chrome、Edge、Safari、Firefox等主流浏覽器也都支援WebRTC。是以就可以通過WebRTC來實作P2P了。
下文把基于WebRTC實作的HTML5 P2P簡稱為H5 P2P。
二、WebRTC簡介
WebRTC的總體架構如下圖所示，如果是浏覽器開發者，通常需要關注并實作WebRTC C++ API，而我們的目标是基于浏覽器實作P2P，是以隻需要關注Web API即可。
整體的H5 P2P都是基于RTCPeerConnection和RTCDataChannel來實作的，隻是實作資料層面的P2P，不包含音視訊通信的内容。
三、總體架構
1. H5 P2P用戶端
主要包含通信子產品、傳輸子產品、節點管理、排程子產品、存儲子產品和統計子產品：
通信子產品：主要負責和服務端（上圖中的Index、CPS、Tracker）進行信令的通信
傳輸子產品：包含HTTPClient和基于RTCDataChannel實作的RTCClient（上傳&下載下傳）
節點管理：不同使用者間P2P主被動連接配接、斷開、淘汰、資源資訊同步
排程子產品：根據buffer水位、分片資訊、節點品質和規模進行CDN/P2P排程
存儲子產品：負責媒體資料的存儲、排序、以及淘汰
統計子產品：包含系統運作的埋點的實作
2. H5 P2P服務端
主要包含Index、CPS、Tracker和Stun服務：
Index：索引服務，提供其他服務位址。
CPS：資源屬性服務，将直播流的URL轉換為RID。
Tracker：資源追蹤服務，主要存儲使用者和資源之間的索引關系。
MQTT：信令服務，轉發使用者間建立P2P連接配接的offer/answer/candidate SDP協定。
Stun：采用coturn部署，主要使用者節點之間建立對等連接配接的UDP穿透。
四、階段流程
下圖簡略的展示了整體方案的各個階段、流程：
Step 1：網頁打開，首先向Index服務請求其他服務的位址，儲存于記憶體中
Step 2：用戶端收到直播請求，向CPS發送請求将URL轉換為資源ID(RID)，相同内容相同清晰度的直播流的資源ID(RID)是相同的，表明可以互相分享資料
Step 3：用戶端首先會啟動HTTPClient進行資料下載下傳，優先保證秒播。同時做以下2件事
a. 用戶端向Tracker服務發送Address協定，擷取其他正在觀看該直播的使用者位址，待後續建立連接配接，分享資料
b. 用戶端向Tracker服務發送Publish協定，将自己的資訊告知Tracker，使得别人可以即使搜尋到自己，進行資料分享
Step 4：向從Tracker擷取的其他使用者建立連接配接，彼此交換資訊，資料分享
五、連接配接建立
假設在Peer1和Peer2之間傳輸資料，那麼在傳輸之前，首先需要建立連接配接。在WebRTC中，浏覽器間通過ICE架構建立對等連接配接，主要包含Stun、TURN，下面分别簡單介紹一下：
1. ICE
ICE（Interactive Connectivity Establishment）提供的是一種P2P連接配接架構，統一各種NAT穿透技術（STUN，TURN）。基于offer/answer/candidate模式，通過多次位址交換，然後進行連通性測試，穿透使用者網絡間各類防火牆。ICE主要包含STUN、TURN等協定。
2. STUN
STUN（Simple Traversal of UDP Through NAT）允許位于NAT裝置後的用戶端找到自己的公網IP/Port位址，以及查詢出自己的NAT裝置類型，通過這些資訊使得兩個同時位于NAT後的2個裝置之間建立UDP通信，具體的STUN流程可以參考RFC5389，不在此贅述。
3. TURN
通俗的說，TURN（Traversal Using Relays around NAT）就是中繼/轉發，并不是所有的裝置之間都可以依靠STUN來建立連接配接的，那麼當兩個裝置之間無法依靠STUN建立連接配接時，就會啟用TURN來進行資料中轉。
由于我們的目标是節約帶寬，如果采用TURN轉發的話，并不能減少伺服器的帶寬消耗，另外一個原因是，在整個建立連接配接的過程中，有别于傳統的視訊通話隻能1對1，這裡的傳輸模式是1對多傳輸，是以并不要求每個連接配接都可靠，是以在H5 P2P項目我們僅僅通過STUN來實作連接配接的建立。
六、資料下載下傳
1. 資源編碼
Web P2P網絡直播方案也可以同時支援任意多路直播同時進行，必須保證各路直播流之間的獨立性，是以，我們提供一種統一的資源編碼方式，用來辨別唯一的一路直播流。這裡主要借用直播流中的StreamId，通過計算MD5，生成固定長度的資源ID（RID），不僅保證了内容相同，清晰度不同，RID也不同；也保證了相同的内容，由于斷流切換源位址，導緻URL變化，保證資源ID(RID)相同。
2. 下載下傳排程
在整個直播過程中，由于可播放緩存的資料是非常小的，通常不超過10秒？是以如何實時的根據目前的網絡狀态、網絡環境，作出使用CDN，又或是使用P2P的決策呢？這裡，我們的最佳實踐主要如下：
a. 為了保障使用者的觀看體驗，當緩沖區的可播資料低于某個門檻值（例如5秒），就切換CDN下載下傳
b. 當發現某一片未來的資料，周圍的人都沒有的時候，即使可供播放的buffer還有很多，不滿足a政策的描述，這個時候，為了盡快的分發資料，也應該及時切換至CDN，出現這種情況時，往往表示這個節點以及他連接配接的節點都處于整個直播資料分發的頂層，為了防止出現 “一人下載下傳多人圍觀” 的場景，本着更快的下載下傳導緻更早的上傳理念，不僅僅要求該節點自身盡快CDN下載下傳，同時也保證周圍使用者某個比例（例如15%）也盡快采用CDN下載下傳，進而使得整體資料的分發效率提升。
3. P2P任務配置設定
a. 任務編号
對于每一個資料塊都有一個自然數編号（sn），對于這個資料塊，我們按照固定長度（預設16KB）的大小進行切分，簡稱chunk_index，那麼（Rid, sn, chunk_index）就可以唯一确定一個資料片了。
b.配置設定請求
配置設定過程類似于撲克中的發牌機制，唯一的要求是對方這個節點擁有這個資料塊，并且品質越好的節點，越多越配置設定靠近播放點的、重要的資料。下圖簡明扼要的展示了3個相同品質節點配置設定2個資料塊（9個資料片）的過程。
4. 記憶體控制
對于Web P2P來說，所有的媒體資料都緩存在記憶體中，但是，也并不是會緩存完整的資料。對于直播來說，所有使用者的觀看點都是非常接近的，是以，記憶體始終緩存播放點前後的固定大小的資料。因為隻有這部分資料分享使用率才是最高的。
如上圖所示，有顔色的資料塊都是目前在記憶體緩存中的資料，其中紅色資料塊表示目前的播放點，黃色資料塊表示過去已經播放過的内容，綠色資料塊表示未來還未播放的内容，可以看到當播放點從100移動至101時，97号資料塊就被淘汰了，同時103号資料塊作為最新的資料被下載下傳下來并緩存到記憶體中。
七、工程實踐
1. Goggle FlatBuffers
不管是伺服器通信還是點對點的P2P傳輸均采用了FlatBuffers。FlatBuffers具有跨平台、記憶體和效率速度高，擴充靈活等優勢，被我們全平台統一采用，大幅降低了通信成本。
2. 多浏覽器相容
線上支援WebRTC的浏覽器不僅種類繁多，而且同一個産品的不同版本之間也可能千差萬别。為了解決這一痛點，最終采用了WebRTC adapter.js來解決這一挑戰。
3. 記憶體池
盡管Node.js自帶垃圾回收機制，以及記憶體管理政策，但是GC和記憶體配置設定也是需要成本的，況且Web端是單線程環境，任何性能的提升都會減少時間上的損耗，進而可以處理更大吞吐的網絡層傳輸以及業務邏輯。是以在記憶體配置設定上我們采用了記憶體池政策，基本實作了100%的記憶體重複使用。
八、技術結果
下圖展示某次大型直播的帶寬分時統計，顯示在19:25到21:00階段内的真實資料，随着人數的湧入和離去，Web P2P全程帶來可觀的帶寬收益。最終評估Web P2P，在不影響使用者使用體驗的前提下，不僅可以有效降低伺服器的負載壓力，并且能夠降低可觀比例的帶寬成本。
九、思考總結
目前，該技術已經大規模應用在各網絡直播中，良好的解決了服務品質與帶寬成本的平衡。但是，我們也發現在超大規模的直播下，存在了一些提升的空間，主要如下：
(1) coturn與MQTT的服務性能不高，會制約直播的服務品質。
(2) 接入邊緣網絡，打造多元化網絡，緩解CDN負載，并且可以進一步降低CDN的帶寬成本。