[[421315]]

大多數時候，定義問題比找到答案更難，也更有價值。這個世界需要困難的、明確界定的問題。

互聯網所固有的問題是什么?可能是“內容交付”問題的不同方面，例如，客戶端的內容加速，高質量的視頻交付等到。事實上，一個更好的互聯網概念已經走進了大眾的視野，即使用 P2P 協議在互聯網上以完全分布式的方式發布內容。如果可以做到這一點，就可以建立一個完全去中心化的互聯網。特別地，IPFS正在尋找定義分發和定義“ Web”的全新方法。

這樣的互聯網理念確實有意義，但它將如何構建呢?

P2P的固有問題

在《面向互聯網應用的網絡優化》一文中談到了內容分發的四種體系結構: 集中式托管、大型數據中心的CDN、高度分布式CDN 和 P2P 網絡。其中指出：P2P 可以被認為是將分布式架構推向了邏輯極限，理論上提供了近乎無限的可伸縮性。此外，在目前的網絡定價結構下，P2P 提供了很有吸引力的經濟性。

盡管 P2P 設計在理論上是可伸縮性最好的，但仍然存在一些實際問題，特別是吞吐量、可用性和容量。

吞吐量

最常見的問題是邊緣設備的上行鏈路容量有限，最主要的原因是 P2P 網絡的總下載容量由于其總上行容量而受到限制。不幸的是，對于普通用戶的寬帶連接，上行速度往往比下行速度低得多。一個上傳速率低于這些下行速率四分之一P2P網絡是否足夠了呢?

有研究表明，一旦客戶端的可用帶寬達到5mbps，那么對最終用戶頁面負載的影響可以忽略不計。

可用性

應用P2P的下一個主要障礙是對等節點的可用性。換句話說，是否有足夠的參與者，他們是否在線并且有足夠的時間提供價值?如今，邊緣設備的數量確實增加了，但是增加的夠多了嗎?

許多人有多種設備，這是一個巨大的邊緣設備池。走向數萬億的設備。有足夠多的在線設備可能是安全的，但是普通用戶在線的時間足夠長嗎?什么是“足夠長的時間”?

赤道約40,000公里。根據經驗數據，光通過光纖傳輸1公里需要4.9微秒。這意味著數據可以在1/5秒(196毫秒)內繞地球一周。如果認為互聯網的運行速度至少比這慢兩倍。這2倍的減速意味著環繞地球大約需要400毫秒。不幸的是，這個時間需要再加倍，以便考慮到全球傳輸路由，即便如此，數據可能也可以大約在大約800毫秒內傳遍全世界。真正的問題是，全球用戶的平均瀏覽時間是多少?有人統計的結果是是3分36秒，或216,000毫秒。

無論哪種情況，如果節點在線時間足夠下載一個網頁，那么數據就有足夠的時間環繞地球數百次，當然足夠與地球上任何地方的同行聯系。

容量

如果有足夠多的用戶在線時間足夠長，并且他們有一個可接受的出口吞吐量(上傳帶寬) ，剩下的問題就是是否有足夠的空閑容量(磁盤空間)來提供一個正常運行的網絡。如果請求的內容遵循 Zipf 分布，就可以估算P2P網絡單元的大小，進而達到一個給定的緩存命中率。

互聯網資源加載的P2P支持

如果已經更好地定義了問題，并建立了一個方案的理論可行性，接下來便是關注技術實現了。IPFS 之類的實現關注于分發整個內容庫，允許用戶完全擺脫 Web 服務器和 DNS 的限制。這是一個了不起的大規模改變，但代價是需要用戶修改他們訪問內容的方式。

由于 P2P 設計依賴于總的網絡規模，這種模型在達到臨界質量之前很難發展。如果提高現有 web 內容的透明交付，而不需要對用戶體驗進行任何更改，就意味著確保該技術遵守以下三個限制:

• 對于用戶來說，解決方案應該是透明的
• 對于開發人員，解決方案應該要求零基礎設施更改
• 對于操作，解決方案應該是自我管理的

對所有內容完全支持P2P是困難的，特別是允許執行具有業務邏輯的 JavaScript腳本。然而，如果關注流量的比重，會發現靜態組件(圖片/視頻/字體/CSS)大約占網站數據的80%左右，部分支持P2P或許是可行的。

支持P2P 的協議棧選擇

為了支持 P2P 內容分發，需要開發一個覆蓋網絡，允許 P2P 連接在現有互聯網基礎設施中運行。幸運的是，這樣的堆棧是可用的，那就是WebRTC。WebRTC 是一個瀏覽器內的網絡協議棧，支持點對點通信，主要應用于語音和視頻應用程序，以促進點對點視頻和音頻會議。

與依賴 TCP 傳輸的 HTTP 不同，WebRTC 依賴于一個更古老的協議——SCTP ，并將其封裝在UDP中。這允許更低的延遲傳輸，消除了數據包隊列頭部阻塞，并且，作為一個獨立的網絡堆棧，允許 WebRTC 使用比單獨使用 HTTP 顯著更多的帶寬。

SCTP 有點像OSI傳輸層的第三個輪子，我們經常忘記它的存在，但它有一些非常強大的功能， 提供了可靠的、面向消息的傳輸。除了 SCTP，WebRTC 還利用了兩個附加的主要協議: 安全數據傳輸層加密協議(DTLS)和交互式連接建立協議(ICE) ，以支持網絡地址轉換(NAT)環境，例如防火墻穿越。可以說， WebRTC 擁有實現真正的點對點網絡所需的所有管道。

P2P 的瀏覽器支持

目前，主流的瀏覽器如Chrome、 Firefox、 Edge 以及現在的 Safari 都支持 WebRTC。對于http請求的攔截，可以通過service worker實現。service worker是大多數瀏覽器中的新特性，它允許在瀏覽器中運行后臺進程。與可用作線程代理的 Web worker 類似，service worker 對于如何與DOM交互和交換數據也有一些限制。然而，service worker有一個最初為支持離線頁面加載而開發的強大特性: Fetch API。Fetch API 允許service worker攔截請求和響應調用，類似于 HTTP 代理。

通過service worker，現在可以截獲傳統的 HTTP 請求，并將這些請求加到 P2P 網絡中。利用瀏覽器本地的存儲模型，可以存儲和分發 P2P加速的內容。雖然瀏覽器中存在多種不同的存儲選項，但 IndexedDB是service worker和 DOM 中唯一可用的存儲 API，WebRTC 代碼可以在其中執行。

可能的優化

有了P2P的內容交付模型和一個可用的網絡協議棧，就應該可以實現特定的高效傳輸和訪問瀏覽器內存儲介質。

一個簡單的優化可能是優先選擇駐留在同一網絡中的對等節點，或許可以通過每個對等點的自治系統來標識，這樣的優化可以將平均延遲減少兩倍。

另一個優化是選擇將哪些資源復制到對等節點。例如，如果一個用戶當前正在瀏覽一個網站的登陸頁面，本上可以預測下一個頁面的所有圖像，有效地完全消除延遲。

一句話小結

現在的世界比以往任何時候都更加緊密聯系在一起，隨著便攜設備的計算能力增強和物聯網的到來，下一代網絡可能會以P2P的模式發布么?