繼雲計算之後,霧計算再起 - 談談 P2P CDN

繼雲計算之後,霧計算再起 - 談談 P2P CDN

(Photo Credit: https://www.polarising.com/fog-computing/)

雲漂浮在天空之上,霧則更貼近地面,透過這種十分形象的名稱,霧計算(Fog Computing)將數據、(數據)處理和應用程式集中在網路邊緣的設備中,而不是幾乎全部保存在雲中。這意味著計算從距離用戶較遠的數據中心(雲)拉回到了你我身邊的設備(霧),也可以是頻寬你正使用的電腦。

霧計算,是雲計算的延伸概念,也被稱為邊緣計算(Edge Computing),此名詞由 Cisco 首創。

霧計算 = 去中心化的分散式計算

霧計算可以理解為新一代的分散式計算,使網際網路的計算模式從中心化遷移至去中心化。

霧計算延伸並擴大了雲計算的網路計算模式,將網路計算從網路中心擴展到了網路邊緣,從而更加廣泛地應用於各種服務。霧計算有幾個明顯特徵:低延時和位置感知,更為廣泛的地理分佈,適應移動應用。

註:霧計算是個新名詞卻不是個新概念,在過去這概念被人稱作:

  • P2P ad-hoc networking
  • Grid Computing
  • Mesh Computing

物聯網加速了霧計算的到來

Fog networking supports the Internet of Things (IoT) concept, in which most of the devices used by humans on a daily basis will be connected to each other.

物聯網的願景十分巨集偉:人們將會通過物聯網建立一個由無數高度智能、相互聯繫的物品組成的世界。 要想讓這願景成為現實,其關鍵就在於把握雲計算的「請求式可伸展性(on-demand scalability)」。

物聯網與移動網際網路高速發展,我們週邊的設備計算能力也越來越強,但是網路基礎設施卻進展緩慢。在數據量越來越大、節點數越來越密的今日,網路頻寬並沒有隨著越來越多的連網設備一樣快速成長,成了網際網路發展的瓶頸,按照這局勢發展下去的話,數據傳輸和資訊獲取的速度將會捉襟見肘。為了剋服這問題,人們把焦點移回了身邊的裝置,希望將計算分散在邊緣的物理節點,利用邊緣計算減輕中心伺服器的負擔,BGP 機房、ISP 骨幹網的壓力也得以緩解。

物聯網發展的最終結果就是將所有的電子設備,移動終端,家用電器,車輛等等一切都互聯起來,這些設備數量巨大,而且分佈廣泛,為霧計算提供了很大的發展機會。

區塊鏈將會使霧計算更普及

霧能夠彌補雲的不足,並和雲相互配合,協同工作。相對於傳統的模式,區塊鏈的礦工們就是支撐霧計算的節點,透過共識演算法以及經濟激勵實現,霧計算可以說是站在共用經濟的風口上,進而實現企業與個人用戶間多贏的局面。

霧計算的應用:P2P CDN

霧計算中,我們先從伺服器資源談起,如前面所述,為瞭解決頻寬資源有限的問題,我們需要避免不必要的頻寬浪費,傳統的網路請求方式就是浪費機房與骨幹網路頻寬資源的元兇。 P2P CDN 就是霧計算裡面的一個典型應用,我們希望用戶的請求可以不需要上雲端,因為中介伺服器與雙方的網路傳輸都是多餘的浪費。透過 P2P CDN,我們將數據緩存在邊緣節點上,當用戶端訪問資源的時候,可以直接從臨近的霧節點獲取,而不需要回到遠方的雲端上。

關鍵技術: WebRTC

WebRTC(Web Real-Time Communication)是 W3C 推薦的標準,實現了瀏覽器之間直接的即時通訊,不再需要伺服器中轉,現在絕大多數的瀏覽器均已支援。在最早 2012 年谷歌的 Chrome 瀏覽器正式原生支援 WebRTC 時,Web 開發者主要都還是利用 WebRTC 開發即時聊天的應用,後來有些嗅覺敏銳的開發者/公司(如:Peer5),開始利用 WebRTC 的數據通道(Data Channel)技術做 P2P 流媒體。

註:目前最為廣泛使用的解決方案是 WebTorrent

Data Channel

WebRTC 數據通道(Data Channel),相比 WebSocket 和 HTTP,支援流量大、延遲低的連接,具有穩定可靠等優點。

數據通道的介面和 WebSocket 一樣,透過 send 來發送數據;透過 ommessage 來接收數據;透過 dataChannelOptions 可以讓數據通道在 UDP 或者 TCP 的優勢之間進行切換,比如讓數據傳輸得更加穩定可靠,或者傳輸得更快。其中比較重要的參數:

  • ordered:設置數據的接受是否按照發送的順序。設為 true 時表現更像 TCP,反之更像UDP。
  • maxRetransmitTime:數據發送失敗時,重新發送的最大超時
  • maxRetransmits:數據發送失敗時,重新發送次數的最大值

主流的 P2P CDN 架構

1. Mesh-based Pull Systems

較常見的設計,像 BT 就是屬於這樣的系統。在這個系統中,每個節點必須向中心倉庫(Media Repository)分享他們的節點存放數據(Media Chunk)的資訊,讓其他節點知道它們想要訪問的數據存放位置。

Mesh 結構的優點是穩定可靠,因為不需要維護樹狀結構,維護的複雜度低,帶來的缺點就是對延時無法掌握明確的邊界時間,這種演算法是一種隨機抓取的策略,抓取回來的節點資訊未必是最佳的,回放的效果較差,首次播放的延時也會相對長,還有造成頻寬資源浪費的問題。

2. Tree-based Push Systems

接近傳統的 CDN 的樹狀結構,讓上行頻寬大的節點接近源節點。差別在於,在這個系統的設計中,Client-Server 是多層級的,也就是說 Client 節點同時可以是別的 Client 節點的 Server。這個設計帶來的好處就是頻寬利用率高且延時小,系統的延遲被控制在這個樹的高度。

不過要維護一個穩定的樹狀結構的難度非常高,一旦網路拓撲中的節點進入與離開頻繁,樹都需要重新調整,恢復的時間影響了傳輸的品質。此外,如果只維持一棵樹的網路拓撲,會因為樹狀結構的設計導致葉節點的上行頻寬沒有辦法被利用到。

程式碼範例

PearPlayer.js 是完全用JavaScript 寫的開源 HTML5 流媒體播放框架,實現了融合HTTP(包含HTTPS、HTTP2)、WebRTC 的多協議、多源、低延遲、高頻寬利用率的無外掛程式 Web 端流媒體加速能力。基於 H5 的 MSE 技術 (Media Source Extension) 將來自多個源節點的 Buffer 分塊喂給播放器,再加上精心設計的演算法來達到最優的調度策略及對各種異常情況的處理,Pear Player能在保證用戶流暢視頻體驗的前提下最大化P2P率。

說了這麼多不如直接看程式碼比較有感覺,這是 P2P CDN 的PearPlayer.js 播放器範例:
https://gist.github.com/hitripod/5acda92b2bb2e080fc45b9258c0b21de

回到主題,P2P CDN 的優勢是什麼?傳統 CDN 安在?

傳統的方式是 CDN 公司自己部署節點並大量採購頻寬,再"零售"給客戶。隨著 4K、直播、AR/VR 等等網際網路應用興起,CDN 的潛在市場更大,一些 CDN 業務的創業型公司嘗試以 P2P CDN 這種新的思路顛覆傳統 CDN 市場,例如:白山雲、又拍雲、雲熵科技、星域 CDN 等等公司。

那麼,P2P CDN 是未來嗎?傳統的 CDN 是否就此消失?

P2P CDN 的使用場景是受限的

手機並不適合做 P2P 分發。用戶很多使用場景都是在移動的,而不是在 Wi-Fi 或有線連接的環境,除此之外,手機上還有電量與流量的限制。只有固定式的裝置才合適。扣除手機平板等移動裝置後,P2P 的節點就沒有那麼多了。

即使是固定式的裝置(如:NAS、個人電腦、路由器、電視盒),受限於 ADSL,大部分上下行的頻寬是非對稱型的,下行特別快,上行會窄一點。在這個場景下雖然把上行頻寬用起來了,但是最終對社會的成本是比較高的。小區寬頻是另外一回事,全是光纖到戶的,如果把機器推到小區裡面做 P2P 效果會更好一點。

短視頻就目前來看,因為首次打開時間長,延時相對高,並不適合透過 P2P 分發。不過若是大容量的影片,可以做分片高並發,透過 P2P CDN 可以大幅降低對骨幹網的負擔,根據統計內容提供者的 100G 內容可能就佔用 30% 的網間頻寬(情境:社區中的所有人同時看了同樣的 4K 影視)。

透過區塊鏈解決計費與激勵等問題

在 P2P 中不能應用傳統的網路計費模型,網路中的節點並不是全數為自己所有,提供上行頻寬的裝置必須獲得經濟回報,否則失去經濟激勵的 P2P 的網路就會失去節點分佈夠廣、夠多、夠密的優勢。

也因為區塊鏈優雅地解決了過去的痛點:計費方式、經濟激勵、分散式計算、共享資源、固定裝置的問題。近期很火熱的 ICO 中,光在八月份就有三個團隊以 P2P CDN (共用限制網路頻寬)為題目發行代幣/貨幣:BlockCDN, OneCloud, 流量礦石。

總結

Our P2P CDN is not meant to be a general purpose CDN — i.e., one that serves every kind of web content. We are solely focused on the scalable and efficient distribution of video (both live and on-demand). We feel this is a good focus area given recent claims that video represents 80% of all Internet traffic.

CDN 的本質就是緩存,客戶的需求是在透明合理的價格中追求快速、穩定。P2P CDN 適合高畫質、長時間影音檔案的點播應用或是靜態檔案緩存,不適合追求首次打開時間快、省點、對時間敏感應用(如:直播),也不會是個通用的緩存方案。

即使網路上所有設備都共用了其閒置頻寬,CDN 的服務質量依舊受限於其本身的上行頻寬已經計算能力,如果單只靠終端用戶的閒置資源要取代傳統 CDN 是不可能的,雲霧計算的結合才是正解:透過 P2P 降低頻寬獲取成本,並利用 BGP 機房中的高配伺服器保障 CDN 的服務質量。

Reference: