PrismCDN 網絡的架構解析，以及低延遲、低成本的奧祕

5 月 1九、20 日，行業精英齊聚的 WebRTCon 2018 在上海舉辦。又拍雲 PrismCDN 項目負責人凌建發在大會作了《又拍雲低延時的 WebP2P 直播實踐》的精彩分享。

分享介紹了 WebP2P 行業將從 FlashP2P 逐步進入 H5P2P，並分享了又拍雲 PrismCDN 網絡如何突破傳統 P2P 網絡高延遲、低分享率的難題。

因分享內容較多，特將演講整理爲兩部分：

• 取代 FlashP2P，H5P2P 將成爲 WebP2P 主流：介紹幾類 P2P 的架構、原理、優劣勢，介紹傳統樹狀、網狀兩種 P2P 結構的不足。
• PrismCDN 網絡的架構解析，以及低延遲、低成本的奧祕：介紹又拍雲 PrismCDN 的結構、優點，分析又拍雲 PrismCDN 達成好體驗、低成本、易使用的奧祕。

 

本文是第二部分《PrismCDN 網絡的架構解析，以及低延遲、低成本的奧祕》

 

又拍雲作 PrismCDN 這個產品，主要有三個要求：

第一，把體驗作好；

第二，下降成本；

第三，要易使用。

咱們先來看一下又拍雲 PrismCDN 所取得的成績，一項項分析 PrismCDN 在好體驗、低成本、易使用三方面是否達標。

PrismCDN 一開始作 SDK P2P，在體驗好、低成本上作得比較到位，但在「易使用」上不夠優秀。因此咱們研發了 WebP2P 功能。

△ 又拍雲 PrismCDN WebP2P

易使用：無插件、免 SDK、易回滾

SDK 要嵌入到客戶的 App 裏面去，客戶會擔憂三個問題：

• SDK 的穩定性；
• SDK 升級的時候，客戶須要從新發布新的App版本；
• SDK 部署以後，難回滾。

又拍雲 PrismCDN 團隊設計 WebP2P 的時候，集中解決了「易使用」這個難題。

WebP2P 沒有插件，也沒有 SDK，只是 JS 而已；發生異常只需切一下老版本就好，不須要像 App 那樣從新發佈一個新版本，客戶的開發成本降低，風險也下降了。

體驗好：流暢度高、延時低、秒開

咱們把 P2P 直播的體驗分爲「流暢度」「延時低」「秒開」幾個指標。

• 流暢度：儘可能不要卡頓，把卡頓率降下來，咱們作到了 99.9%；。
• 延時低：延時在 3 秒水平，和 CDN 直播的延時是相同的。秀場直播或者遊戲直播，有必定的互動，延時必定控制在幾秒以內，用戶才能夠接受。
• 秒開：首屏秒開，用戶一點進去的時候，直播畫面就能啓動起來；固然首屏時間和 P2P 沒什麼關係。

低成本：

又拍雲 PrismCDN 90%的流量來自於 P2P 霧節點，只須要 CDN 邊緣節點補充 10% 的流量。霧節點的成本大大低於 CDN 邊緣節點的成本，P2P 分享率高，就意味着總體成本降低，對客戶來講很是划算。

PrismCDN 架構解析

後面我會分析咱們是如何作到這三點的。在這以前，先了解一下又拍雲 PrismCDN 的架構。

△ 又拍雲 PrismCDN 架構示意圖

三角形裏是 CDN 服務器。熟悉 CDN 的人都知道它有三層的架構：中心節點、區域節點、邊緣結點。

咱們在作 PrismCDN 這張 P2P-CDN 網絡時，引入了「霧節點」。霧節點包括 OTT 機頂盒、路由器、APP 等，運行 WebRTC 的網頁也是能夠充當霧節點。咱們會把數據從 CDN 邊緣節點再次下沉，下沉到霧節點上。最後經過霧節點向客戶提供數據。

這個架構把 CDN 網絡的三層模型變成了四層模型。第四層就是佈置在用戶邊上的霧節點，在離用戶最近的邊緣計算資源裏面。

第五排是最終用戶端。示意圖裏把用戶端要拆分爲 WebRTC、Flash、App 幾個模塊，本質上是同一個。

放大 CDN 帶寬的霧節點

咱們重點看一下「霧節點」是怎麼回事。CDN 網絡的邊緣節點，統一當作一個 CDN 服務器。CDN 服務器會推送 1/20 的數據流到霧節點上。霧節點會和十幾、二十個播放端相連，直接把這 1/20 數據流轉發到各個播放端。

△ 又拍雲 PrismCDN 「霧節點」運行示意圖

咱們能夠計算一下。假設 CDN 推送 2M 的直播流，到了霧節點這邊就是 100K 的數據，假設霧節點轉發到 10 個播放端，這 10 個播放端就獲得了 1M 的數據。這 1M 數據對於播放端來說都是有效數據，即 CDN 的 100K 寬帶，經過一個霧節點使播放端獲得了 1M 的帶寬，這起到了放大 CDN 帶寬的做用，至關於把 CDN 帶寬放大了 10倍。

哪些設備能成爲霧節點呢？以路由器舉個例子。路由器只要集成一個 PrismCDN 霧節點的模塊，在這個模塊實現 WebRTC 須要的協議，好比 ICE、STUN 用於穿透的協議、DataChannel、DTLS、SCTP 等 P2P 鏈接的協議。有了這些協議就能夠實現霧節點之間以及霧節點與 Web、 APP 之間的通信。

同理，在播放的 App 也能夠成爲霧節點，只要它支持 WebRTC 協議而且保持在線。App 能夠根據客戶的需求來配置是否做霧節點。若是說客戶須要提供轉發，咱們就能夠把這個模塊運行起來。

播放 Web 也能夠做霧節點。這個比較好理解，本質上是兩個 Web 之間傳數據。同理，咱們也能夠經過根據客戶的需求，配置 Web 要不要做霧節點轉發數據。

PrismCDN 網絡運做介紹

經過 PrismCDN 網絡實現 P2P 直播，具體講起來仍是有點複雜的，咱們一步步來介紹。

第一步，先是直播源把一個 RTMP 流推到 CDN 網絡的中心節點上。CDN 中心節點對這個源進行作切塊，好比 20K 大小的 Block，因而直播流就變成了一個個 Block 的序列。在 CDN 網絡裏先把 Block 序列逐層發送到邊緣節點上。

在 CDN 邊緣節點到霧節點之間，就不是傳輸一個 Block 了，而是傳輸 Block 裏面的 1/20。咱們經過一些算法從 Block 裏面抽取 1/20 的數據推送到霧節點上面。霧節點再把 1/20 的數據轉發給和它相連的若干個播放節點。

一個霧節點會鏈接不少個播放節點，一個播放節點也會和不少個霧節點相連，並從這些霧節點處收數據。播放節點從每一個霧節點獲取的數據，就是CDN邊緣節點推送到霧節點的 Block 的 1/20 子數據流。

這就是 PrismCDN 網絡 P2P 部分的工做邏輯。

若是說 P2P 某些節點是丟包了，或者是掉線了，那麼播放節點能夠直接鏈接 CDN 邊緣節點，把丟失或者須要補充的數據給拉回來。最終播放節點可以把來自霧節點和 CDN 邊緣節點的數據數據組合還原出來原始的流，而後再經過轉封裝成 MP4 或者 FLV 等格式以後，餵給相應的播放器。

低延遲的奧祕：扁平化模型

傳統 P2P 最大的問題就是延時很高，不論樹型的直播方案，仍是 Peer五、Streamroot 等網狀型直播方案，延時都很是高。

PrismCDN 網絡是怎麼作到低延時的呢？這和咱們的扁平化的模型有關。

CDN 服務器幾乎同時把一個數據流的 1/20 子流推到不少霧節點，霧節點同時把數據推到了播放節點。整個過程當中，數據路徑很是短，它只是經過霧節點同時中轉一下。

經過扁平化的方案，PrismCDN 把延時控制在了 3 秒之內，和傳統 CDN 差很少，這個延時水平可以知足遊戲直播、秀場直播、體育直播等多個直播場景。相比之下，傳統 P2P 直播的延時有半分鐘甚至 1 分鐘之多。

△ PrismCDN 低延遲的奧祕：扁平化模型

高流暢的奧祕：霧節點智能選擇、冗餘連接

再來看看 PrismCDN 網絡在高流暢方面是怎麼作的。

△ PrismCDN 高流暢的奧祕：CDN 邊緣節點補數據

從上面的介紹，咱們知道一個播放節點的大部分數據是來自於霧節點。徹底依賴霧節點，會出現數據缺失。趕上數據丟失，PrismCDN 會經過數據通道從 CDN 邊緣節點拉取數據。這個模型就是 P2SP。

要作到流暢的話，要分兩大塊去考慮的：一塊是資源；另外一方面是技術，包括調度算法、回源算法等內容。

好比說在數據通道里面，咱們就會有各類方式作嘗試、作測試。又拍雲 PrismCDN 團隊在線上、在生產環境裏面去作對比測試，發現用 UDP 來傳數據要比 TCP 效果好不少，流暢度上面大概要高 5%。

在 WebP2P 裏面，有兩種補數據的方式：一種是要 WebSocket 去補數據，另一種是用 WebRTC DataChannel 去補數據。咱們在這兩種方案裏面進行 AB Testing。

資源不足的話，技術作得再好都沒用。比如 CDN 網絡，須要備充足的資源以後才能提供很好的服務。咱們依賴於又拍雲 CDN 網絡在全國各地的服務器、CDN 節點資源，同時霧節點的資源也部署了 100 多萬個。

霧節點智能選擇

PrismCDN 有超百萬規模的霧節點，霧節點的選擇是很是重要的。

咱們在霧節點、播放節點方面有幾個心得：

• 智能選擇霧節點
• 霧節點、播放節點就近原則
• 霧節點、播放節點相同 ISP 原則
• 冗餘連接，大數據分析霧節點質量

霧節點和播放節點，儘可能匹配相同 ISP、相同區域進行對接。假設某個霧節點是使用上海電信的，咱們儘可能給他匹配上海電信的播放節點。由於跨地區、跨運營商的傳輸質量不太好。跨運營商的通訊質量不大好，尤爲是對 UDP 協議的支持質量。爲了不運營商之間的數據傳輸出現錯誤，PrismCDN 自寫了一層去校驗數據包是否正確。

咱們還能夠對霧節點的質量進行統計分析，作更好的匹配。

冗餘連接

看完霧節點選擇的優化，咱們再看看鏈接的狀況。又拍雲 PrismCDM 的鏈接原則，歸納一下就是：啓用冗餘 P2P 鏈接，根據節點質量調整冗餘度，減小 CDN 回源量。

每一個霧節點傳輸一個 Block 的 1/20 數據，按理說一個播放節點鏈接 20 個霧節點就能夠了。實際上一個播放節點一般會多鏈接 1 到 2 個霧節點。由於霧節點畢竟是 P2P 節點，穩定性沒有像 CDN 節點那麼高，有時候會退出、會掉線、會丟包，必須給播放節點準備一些冗餘鏈接。好比說播放節點鏈接了 21 個霧節點，某一個霧節點中斷或者丟包了，不要緊，播放節點已經收到 20 份數據了，仍是可以組合、還原出原始數據。

同時能夠根據實時的傳輸狀況來調整播放節點的連接冗餘度。若是傳輸都是穩定的，一個播放節點連 21 個霧節點就能夠了。若是傳輸的抖動比較大，或者霧節點不太穩定，冗餘連接數就放大一點。最終目的是播放節點須要的數據都能從霧節點收到，不須要啓動 CDN 回源，不須要去 CDN 邊緣節點拉取補充數據，這樣流暢度就變得很是高。

CDN 的成本要高於 P2P，所以用冗餘連接的方式減小 CDN 回源，除了保障流暢度，還能夠下降成本。

低成本的奧祕：P2P 分享率高

最後看又拍雲 PrismCDN 低成本的一些狀況。

經過 PrismCDN，播放帶寬由兩部分組成：一部分是 CDN 帶寬，一部分是 P2P 帶寬。咱們的原則就是，提升 P2P 霧節點的分享率：加大 P2P 帶寬的比例，儘量減小 CDN 帶寬佔比。

在傳統 P2P 網絡裏，數據在播放節點之間互傳，播放器會下載數據後分享一部分給別人。也就是說只有在播放的時候，節點才能給別人傳輸數據。

如今的家庭帶寬都是上下不對稱的，下行若是有 20M，上行通常只有 2 到 4M 左右。大體計算一下，若是是一個碼率 3M 的直播流，有 1000 個併發觀看，累加起來的播放帶寬要達到 3G。那麼這時候這 1000 個播放終端供應的帶寬上限是 2G，即便每一個人所有供應數據，鏈接很是高效率的話，也存在 1G 的差額。這 1G 的數據，就須要 CDN 邊緣節點去補。

相比於傳統的 P2P 來作的話，PrismCDN 引入了純粹提供數據但不須要播放的設備，好比路由器、機頂盒、光貓等設備。這樣就填補了上面所說的 1G 的差額。

剛纔也提到了，冗餘連接不只可以保證流暢度，也能夠提供低成本的優點。儘可能從霧節點多傳一點數據，減小經過 CDN 邊緣節點拉取數據的機率。畢竟霧節點的成本比 CDN 低的多。霧節點的流量增多，CDN 邊緣節點流量減小，整張 PrismCDN 網絡的成本就會降下來。