基于P2P的互聯(lián)網(wǎng)內(nèi)容加速
大多數(shù)時(shí)候，定義問(wèn)題比找到答案更難，也更有價(jià)值。這個(gè)世界需要困難的、明確界定的問(wèn)題。
互聯(lián)網(wǎng)所固有的問(wèn)題是什么？可能是“內(nèi)容交付”問(wèn)題的不同方面，例如，客戶端的內(nèi)容加速，高質(zhì)量的視頻交付等到。事實(shí)上，一個(gè)更好的互聯(lián)網(wǎng)概念已經(jīng)走進(jìn)了大眾的視野，即使用 P2P 協(xié)議在互聯(lián)網(wǎng)上以完全分布式的方式發(fā)布內(nèi)容。如果可以做到這一點(diǎn)，就可以建立一個(gè)完全去中心化的互聯(lián)網(wǎng)。特別地，IPFS正在尋找定義分發(fā)和定義“ Web”的全新方法。
這樣的互聯(lián)網(wǎng)理念確實(shí)有意義，但它將如何構(gòu)建呢？
P2P的固有問(wèn)題
在《面向互聯(lián)網(wǎng)應(yīng)用的網(wǎng)絡(luò)優(yōu)化》一文中談到了內(nèi)容分發(fā)的四種體系結(jié)構(gòu): 集中式托管、大型數(shù)據(jù)中心的CDN、高度分布式CDN 和 P2P 網(wǎng)絡(luò)。其中指出：P2P 可以被認(rèn)為是將分布式架構(gòu)推向了邏輯極限，理論上提供了近乎無(wú)限的可伸縮性。此外，在目前的網(wǎng)絡(luò)定價(jià)結(jié)構(gòu)下，P2P 提供了很有吸引力的經(jīng)濟(jì)性。
盡管 P2P 設(shè)計(jì)在理論上是可伸縮性最好的，但仍然存在一些實(shí)際問(wèn)題，特別是吞吐量、可用性和容量。
吞吐量
最常見的問(wèn)題是邊緣設(shè)備的上行鏈路容量有限，最主要的原因是 P2P 網(wǎng)絡(luò)的總下載容量由于其總上行容量而受到限制。不幸的是，對(duì)于普通用戶的寬帶連接，上行速度往往比下行速度低得多。一個(gè)上傳速率低于這些下行速率四分之一P2P網(wǎng)絡(luò)是否足夠了呢？
有研究表明，一旦客戶端的可用帶寬達(dá)到5mbps，那么對(duì)最終用戶頁(yè)面負(fù)載的影響可以忽略不計(jì)。
可用性
應(yīng)用P2P的下一個(gè)主要障礙是對(duì)等節(jié)點(diǎn)的可用性。換句話說(shuō)，是否有足夠的參與者，他們是否在線并且有足夠的時(shí)間提供價(jià)值？如今，邊緣設(shè)備的數(shù)量確實(shí)增加了，但是增加的夠多了嗎？
許多人有多種設(shè)備，這是一個(gè)巨大的邊緣設(shè)備池。走向數(shù)萬(wàn)億的設(shè)備。有足夠多的在線設(shè)備可能是安全的，但是普通用戶在線的時(shí)間足夠長(zhǎng)嗎？什么是“足夠長(zhǎng)的時(shí)間”？
赤道約40,000公里。根據(jù)經(jīng)驗(yàn)數(shù)據(jù)，光通過(guò)光纖傳輸1公里需要4.9微秒。這意味著數(shù)據(jù)可以在1/5秒(196毫秒)內(nèi)繞地球一周。如果認(rèn)為互聯(lián)網(wǎng)的運(yùn)行速度至少比這慢兩倍。這2倍的減速意味著環(huán)繞地球大約需要400毫秒。不幸的是，這個(gè)時(shí)間需要再加倍，以便考慮到全球傳輸路由，即便如此，數(shù)據(jù)可能也可以大約在大約800毫秒內(nèi)傳遍全世界。真正的問(wèn)題是，全球用戶的平均瀏覽時(shí)間是多少？有人統(tǒng)計(jì)的結(jié)果是是3分36秒，或216,000毫秒。
無(wú)論哪種情況，如果節(jié)點(diǎn)在線時(shí)間足夠下載一個(gè)網(wǎng)頁(yè)，那么數(shù)據(jù)就有足夠的時(shí)間環(huán)繞地球數(shù)百次，當(dāng)然足夠與地球上任何地方的同行聯(lián)系。
容量
如果有足夠多的用戶在線時(shí)間足夠長(zhǎng)，并且他們有一個(gè)可接受的出口吞吐量(上傳帶寬) ，剩下的問(wèn)題就是是否有足夠的空閑容量(磁盤空間)來(lái)提供一個(gè)正常運(yùn)行的網(wǎng)絡(luò)。如果請(qǐng)求的內(nèi)容遵循 Zipf 分布，就可以估算P2P網(wǎng)絡(luò)單元的大小，進(jìn)而達(dá)到一個(gè)給定的緩存命中率。
互聯(lián)網(wǎng)資源加載的P2P支持
如果已經(jīng)更好地定義了問(wèn)題，并建立了一個(gè)方案的理論可行性，接下來(lái)便是關(guān)注技術(shù)實(shí)現(xiàn)了。IPFS 之類的實(shí)現(xiàn)關(guān)注于分發(fā)整個(gè)內(nèi)容庫(kù)，允許用戶完全擺脫 Web 服務(wù)器和 DNS 的限制。這是一個(gè)了不起的大規(guī)模改變，但代價(jià)是需要用戶修改他們?cè)L問(wèn)內(nèi)容的方式。
由于 P2P 設(shè)計(jì)依賴于總的網(wǎng)絡(luò)規(guī)模，這種模型在達(dá)到臨界質(zhì)量之前很難發(fā)展。如果提高現(xiàn)有 web 內(nèi)容的透明交付，而不需要對(duì)用戶體驗(yàn)進(jìn)行任何更改，就意味著確保該技術(shù)遵守以下三個(gè)限制:
對(duì)于用戶來(lái)說(shuō)，解決方案應(yīng)該是透明的
對(duì)于開發(fā)人員，解決方案應(yīng)該要求零基礎(chǔ)設(shè)施更改
對(duì)于操作，解決方案應(yīng)該是自我管理的
對(duì)所有內(nèi)容完全支持P2P是困難的，特別是允許執(zhí)行具有業(yè)務(wù)邏輯的 JavaScript腳本。然而，如果關(guān)注流量的比重，會(huì)發(fā)現(xiàn)靜態(tài)組件(圖片/視頻/字體/CSS)大約占網(wǎng)站數(shù)據(jù)的80%左右，部分支持P2P或許是可行的。
支持P2P 的協(xié)議棧選擇
為了支持 P2P 內(nèi)容分發(fā)，需要開發(fā)一個(gè)覆蓋網(wǎng)絡(luò)，允許 P2P 連接在現(xiàn)有互聯(lián)網(wǎng)基礎(chǔ)設(shè)施中運(yùn)行。幸運(yùn)的是，這樣的堆棧是可用的，那就是WebRTC。WebRTC 是一個(gè)瀏覽器內(nèi)的網(wǎng)絡(luò)協(xié)議棧，支持點(diǎn)對(duì)點(diǎn)通信，主要應(yīng)用于語(yǔ)音和視頻應(yīng)用程序，以促進(jìn)點(diǎn)對(duì)點(diǎn)視頻和音頻會(huì)議。
與依賴 TCP 傳輸?shù)?HTTP 不同，WebRTC 依賴于一個(gè)更古老的協(xié)議——SCTP ，并將其封裝在UDP中。這允許更低的延遲傳輸，消除了數(shù)據(jù)包隊(duì)列頭部阻塞，并且，作為一個(gè)獨(dú)立的網(wǎng)絡(luò)堆棧，允許 WebRTC 使用比單獨(dú)使用 HTTP 顯著更多的帶寬。
SCTP 有點(diǎn)像OSI傳輸層的第三個(gè)輪子，我們經(jīng)常忘記它的存在，但它有一些非常強(qiáng)大的功能， 提供了可靠的、面向消息的傳輸。除了 SCTP，WebRTC 還利用了兩個(gè)附加的主要協(xié)議: 安全數(shù)據(jù)傳輸層加密協(xié)議(DTLS)和交互式連接建立協(xié)議(ICE) ，以支持網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)環(huán)境，例如防火墻穿越?？梢哉f(shuō)， WebRTC 擁有實(shí)現(xiàn)真正的點(diǎn)對(duì)點(diǎn)網(wǎng)絡(luò)所需的所有管道。
P2P 的瀏覽器支持
目前，主流的瀏覽器如Chrome、 Firefox、 Edge 以及現(xiàn)在的 Safari 都支持 WebRTC。對(duì)于http請(qǐng)求的攔截，可以通過(guò)service worker實(shí)現(xiàn)。service worker是大多數(shù)瀏覽器中的新特性，它允許在瀏覽器中運(yùn)行后臺(tái)進(jìn)程。與可用作線程代理的 Web worker 類似，service worker 對(duì)于如何與DOM交互和交換數(shù)據(jù)也有一些限制。然而，service worker有一個(gè)最初為支持離線頁(yè)面加載而開發(fā)的強(qiáng)大特性: Fetch API。Fetch API 允許service worker攔截請(qǐng)求和響應(yīng)調(diào)用，類似于 HTTP 代理。
通過(guò)service worker，現(xiàn)在可以截獲傳統(tǒng)的 HTTP 請(qǐng)求，并將這些請(qǐng)求加到 P2P 網(wǎng)絡(luò)中。利用瀏覽器本地的存儲(chǔ)模型，可以存儲(chǔ)和分發(fā) P2P加速的內(nèi)容。雖然瀏覽器中存在多種不同的存儲(chǔ)選項(xiàng)，但 IndexedDB是service worker和 DOM 中唯一可用的存儲(chǔ) API，WebRTC 代碼可以在其中執(zhí)行。
可能的優(yōu)化
有了P2P的內(nèi)容交付模型和一個(gè)可用的網(wǎng)絡(luò)協(xié)議棧，就應(yīng)該可以實(shí)現(xiàn)特定的高效傳輸和訪問(wèn)瀏覽器內(nèi)存儲(chǔ)介質(zhì)。
一個(gè)簡(jiǎn)單的優(yōu)化可能是優(yōu)先選擇駐留在同一網(wǎng)絡(luò)中的對(duì)等節(jié)點(diǎn)，或許可以通過(guò)每個(gè)對(duì)等點(diǎn)的自治系統(tǒng)來(lái)標(biāo)識(shí)，這樣的優(yōu)化可以將平均延遲減少兩倍。
另一個(gè)優(yōu)化是選擇將哪些資源復(fù)制到對(duì)等節(jié)點(diǎn)。例如，如果一個(gè)用戶當(dāng)前正在瀏覽一個(gè)網(wǎng)站的登陸頁(yè)面，本上可以預(yù)測(cè)下一個(gè)頁(yè)面的所有圖像，有效地完全消除延遲。
一句話小結(jié)
現(xiàn)在的世界比以往任何時(shí)候都更加緊密聯(lián)系在一起，隨著便攜設(shè)備的計(jì)算能力增強(qiáng)和物聯(lián)網(wǎng)的到來(lái)，下一代網(wǎng)絡(luò)可能會(huì)以P2P的模式發(fā)布么？
【關(guān)聯(lián)閱讀】