取代 FlashP2P，H5P2P 將成爲 WebP2P 主流

WebRTC 能夠有不少種的應用，好比實時音視頻通訊，又拍雲 PrismCDN 團隊目前在作把 WebRTC 應用於內容分發 CDN。利用 WebRTC DataChannel 下的一些功能，能夠去創建 P2P 鏈接，有了這個能力以後，咱們就能夠在網頁上面實現 P2P 的功能，也就是 WebP2P 的 H5P2P 實現。

在 CDN 網絡基礎上，加入 P2P 的目的是減小 CDN 的流量，用 P2P 鏈接完成大部分的流量。這樣會帶來一個巨大的好處——CDN 的成本降低，價格優點就體現出來了；對客戶、對視頻應用來說，帶寬成本也很是顯著地降低。成本優點這一最大的好處，也是咱們作 PrismCDN 這張 P2P-CDN 網絡最大的動力。

我今天主要以 WebP2P 功能來切入這個話題。

什麼是 WebP2P 呢？它主要功能是在可以以 P2P 方式傳輸數據到網頁上來，目的是要下降 CDN 的成本。

FlashP2P 已行至末路

舉一個已經存在了八年的 WebP2P 的典型應用：FlashP2P，這是 Adobe 公司本身研發的內嵌在 Flash 播放器裏面的 P2P 功能。它採用的協議是私有的 RTMFP，如今用這個協議的公司也蠻多的。

咱們先看一下 Flash 的將來：Google 聲明在 2020 年底就徹底不支持 Flash；也是2020 年下半年，微軟的 IE 和 Edge 瀏覽器放棄支持 Flash。

蘋果的態度其實你們都很清楚，喬布斯一開始就很討厭 Flash 這個東西。Mozilla 也是同樣，2020 年結束對 Flash 的支持。Facebook 也在 2020 年底的時候中止支持 Flash 的視頻遊戲。最後，Adobe 本身也宣佈了在 2020 年底就徹底中止支持 Flash。

也就是說，在 2020 年底的時候，FlashP2P 這個產品也就基本上結束了。

那麼咱們如何在 Web 裏面使用 P2P 呢？誕生於 2011年的 WebRTC 技術，在 Google、Microsoft、Apple、Facebook、Mozilla 等幾家大公司的支持下成爲了 H5 的標準，而且 Chrome、Firefox、Safari、Edge 等幾大瀏覽器也都支持 WebRTC，咱們就能夠用 WebRTC 來實現 P2P 的功能了。

基於 SDK 的 P2P 不適合網頁端

在講 WebP2P 以前，咱們先講一下基於 SDK 的 P2P 功能。它的原理是這樣的， SDK 裏面有一個 P2P 下載器，它可以創建 P2P 鏈接；P2P 不能完成全部的數據傳輸，不夠的數據再從 CDN 服務器補充。最終拼成一個完整的數據流，這就是所謂的P2SP 技術。

咱們在 SDK 裏面作一些本地的轉封裝以後，而後經過 local(127.0.0.1) 的 HTTP Server 向播放器提供標準的 HTTP 請求，好比說 HLS 、HTTPFLV。在使用傳統 CDN 服務時，播放器發起一個 HTTP 請求或者 RTMP 請求到 CDN,如今使用 SDK P2P CDN 服務後，播放器直接到本地地址（127.0.0.1）拉取一個 HTTP 請求。播放器只須要改變一下請求的 URL 就能夠從傳統 CDN 切換到 SDKP2P CDN。

若是要在 Web 上應用 SDK P2P 技術，只有一個方式，就是把這個 SDK 作成一個插件安裝到瀏覽器裏面去，包括用 ActiveX、NPAPI 這些技術把 SDK 嵌到瀏覽器裏面去。

過去若干年的經驗已經告訴咱們，瀏覽器插件帶來的用戶體驗是很是差的，最後幾乎全部的視頻網站沒有使用。因此說用 SDK 的方式去作 WebP2P，這條路走不通的。

本質上來說 FlashP2P 也是一個 SDK P2P，只不過說 Flash 這個插件應用太普遍了，幾乎每一個瀏覽器都會裝它，沒有從新安裝插件的問題。

WebRTC + H5 帶來了 WebP2P

有了 WebRTC 以後，經過瀏覽器實現點對點鏈接的可能性就來了。咱們能夠經過WebRTC + H5 的組合實現 WebP2P。

對 WebP2P 的研究，國外已經持續了一些時間了，包括 BiTorrent 也衍生出一個WebP2P 項目——WebTorrent。Peer五、Streamroot 是兩家商業公司，分別拿了 250 萬美圓和 320 萬美圓的投資。

H5P2P 用 JavaScript 實現 P2P 引擎，包括下載器、轉封裝。經過 WebRTC 裏面的 DataChannel 功能創建 P2P 鏈接，從 P2P 霧節點拿數據；當 P2P 數據不足時，能夠經過 WebSocket 或者 DataChannel 去 CDN 補數據；將 P2P 數據與 CDN 數據組合後獲得完整的媒體數據；最後經過 MSE 轉封裝成 mp4 向 H5 播放器 (video標籤) 提供媒體數據流。

以上就是在 H5 框架裏面實現 P2P 數據層面的邏輯，P2P 裏面還會有一些信令、管理服務器，經過 WebSocket 就能夠創建好 Web 與服務器之間通訊通道。

Flash 完全退出還要兩年時間，在這段時間裏，經過以下框架也是能夠適配 Flash 播放器。

樹狀、網狀：P2P 的選型

咱們總結一下過去若干年的 P2P 直播，主要有這樣的一些特徵，要麼樹型結構，要麼網狀結構，要麼樹型和網狀融合起來。

• Tree：樹型
• Mesh：網狀
• Tree + Mesh：樹型 +網狀

樹狀結構是最傳統的 P2P 直播，把播放節點分紅不少個層次，呈現一棵直播樹的形態。直播流經過 RTMP 推送到 CDN 服務器上，而後數據一層層地往下推：數據先往第一層節點發，第一層節點收到了以後再發給第二層節點，第二層節點再發給第三層節點，以此類推，逐層往下發。

當播放人數變多，P2P 直播的節點層級也變得很大，最多時會有十幾層。這致使它的延時很是大,少則 30 秒，多則達到幾分鐘的延遲。這種延時水平，在目前的遊戲直播、秀場直播等直播應用場景裏面是沒法應用的。

另外一方面，P2P 節點很容易出現退出等不穩定狀況，好比用戶關閉設備、退出程序等。P2P 直播樹有一個節點掛掉，它下面的子樹下的全部節點都會受到影響。這也意味着 P2P 直播樹不穩定。

你們對傳統的 P2P 直播樹作一些改進。好比節點只是從多個上層節點拿數據，避免子樹的不穩定；節點不僅是從上層拿數據，同層之間也能夠拿數據，這就是在同層之中引入網狀的結構了。

FlashP2P 事實上就拋棄了樹的概念，直接用一個網狀的概念。數據流一到播放節點，直接就開始在節點之間互相傳輸。這個類型網狀 P2P 網絡。

用 WebRTC 來作 P2P 的 Peer5 採用的是網狀 P2P 網絡。Streamroot 的解決方案也是網狀結構。

高延遲：樹狀、網狀 P2P 的困擾

相比樹狀 P2P 網絡，網狀 P2P 網絡的優點是比較穩定，由於節點之間可以互傳數據。

樹狀和網狀 P2P 網絡有兩個共同特色，其中一個就是延時大，數據進來以後要通過好多中轉才能到最後的播放節點。

樹狀和網狀 P2P 網絡另外一個特色：分享率不高。爲何呢？家庭帶寬上行、下行不對等限制了 P2P 網絡的性能。下行若是有 20M，上行通常只有 2 到 4M 左右。在傳統P2P網絡裏，播放端下載到數據後分享一部分給別人, 也就是說只有在播放的時候才能給別人傳輸數據,即數據只在播放節點之間互傳。

咱們設想一下，總共有 1000 人在播放，直播流碼率是 2M 的話，要讓這個直播可以百分之百經過 P2P 網絡跑起來，則平均每一個播放端必須提供 2M 上行帶寬資源。在目前的接入網環境下，這是比較困難的。

再假如直播流碼率達到了 3M，有 1000 人併發觀看，而且平均每一個播放端能提供 2M 有上行帶寬。累加起來的播放帶寬有 3G，可是這 1000 個播放終端總供應帶寬上限是 2G，即便每一個播放端所有供應數據，並且鏈接質量很是高的話，也存在 1G 的差額。這 1G 的數據，就須要到 CDN 邊緣節點去補。

上行帶寬的不足是致使了傳統 P2P 網絡的分享率不高的一個緣由。

本文第二部分《PrismCDN 網絡的架構解析，以及低延遲、低成本的奧祕》，將在明天推送，感興趣的朋友能夠關注下~

推薦閱讀：

低延時的P2P HLS直播技術實踐