摘要：在各種音視頻應(yīng)用充斥著市場的時候，毫無疑問，流媒體領(lǐng)域?qū)浅＿m合區(qū)塊鏈技術(shù)進(jìn)行場景落地。不可否認(rèn)，流媒體領(lǐng)域在眾多區(qū)塊鏈技術(shù)應(yīng)用場景中潛力巨大，將結(jié)合自身豐富的經(jīng)驗和前沿的區(qū)塊鏈技術(shù)為大家?guī)砀玫囊曨l觀看體驗。

在各種音視頻應(yīng)用充斥著市場的時候，毫無疑問，流媒體領(lǐng)域?qū)浅＿m合區(qū)塊鏈技術(shù)進(jìn)行場景落地。在上一篇文章中，我們主要討論了 PPIO 的 PCDN 架構(gòu)，接下來將介紹 PPIO 的中 P2SP 的下載邏輯和 IaaS 層的流量計數(shù)。

上圖為 PPIO 的 CDN 和 P2SP 的傳輸架構(gòu)圖。這里將會重點講解 PPIO 中 P2SP 的下載邏輯，它主要分三個部分，Buffer 管理，下載狀態(tài)機，和下載算法。接下來會對這三部分一一解釋。

Buffer 管理

Buffer 管理，即理解為本地設(shè)備管理著資源情況，從而決定需要下載的 Piece 的優(yōu)先級。Buffer 管理也是和實際應(yīng)用場景是相關(guān)的，對于流媒體來說，存在一個視頻播放位置，播放位置附近的內(nèi)容就是緊急內(nèi)容，該內(nèi)容則會被優(yōu)先下載。

#1 普通文件下載的 Buffer 管理邏輯

文件下載的 Buffer 管理相對簡單，因為沒有具體的播放位置，即內(nèi)容在緊急程度上沒有區(qū)別。下載算法將采用稀缺優(yōu)先的邏輯，優(yōu)先下載網(wǎng)絡(luò)中稀缺的 Piece。Piece 越稀缺，其下載的優(yōu)先級也就越高。如下圖：

在示意圖中，我們假設(shè)所有 Peer 都是一樣的，而因為 CDN 節(jié)點的存在，實際情況則會復(fù)雜得多。CDN 可以被認(rèn)為比較優(yōu)質(zhì)的，但是它不適合請求分散的碎片數(shù)據(jù)，更適合下載一段連續(xù)的數(shù)據(jù)。之所以將稀缺性作為普通文件的 Buffer 管理的指標(biāo)，是為了增加 P2P 網(wǎng)絡(luò)的資源健康度，并且讓數(shù)據(jù)盡快在 P2P 網(wǎng)絡(luò)中傳播。

#2 流媒體的 Buffer 管理邏輯

和普通文件下載不同的是，流媒體下載存在具體播放位置，為了保證視頻的觀看體驗，越接近播放位置的數(shù)據(jù)將會優(yōu)先進(jìn)行下載。

設(shè)計 PPIO 的時候，我們根據(jù)視頻播放位置，在流媒體下載的過程中，將其分為多個區(qū)間，越靠近播放位置的區(qū)間，下載優(yōu)先級越高。

已過區(qū)間：視頻播放位置之前的數(shù)據(jù)，無需進(jìn)行下載。

緊急區(qū)間：需要立即播放的數(shù)據(jù)，在此區(qū)間的數(shù)據(jù)將采用極端下載策略，旨在以最快的速度獲取數(shù)據(jù)。Piece 越靠近播放位置，下載優(yōu)先級越高。這種策略更加依賴于 CDN 和超級節(jié)點，盡管有重復(fù)下載的風(fēng)險，該區(qū)間將同時進(jìn)行 P2P 下載，即在第一時間從多個 Peer 下載數(shù)據(jù)。

正常下載區(qū)間：稍后進(jìn)行播放的數(shù)據(jù)。雖然此區(qū)間的數(shù)據(jù)也會很快被使用到，但是緊急程度不如緊急區(qū)間，因此這部分?jǐn)?shù)據(jù)，也是越靠近播放位置的 Piece，下載優(yōu)先級越高。但是此區(qū)間的策略不要過多依賴于 CDN 節(jié)點，并且在 P2P 下載的時候，盡量避免重復(fù)下載。

長遠(yuǎn)區(qū)間：播放時間遲于正常下載區(qū)間的數(shù)據(jù)，這部分采用類似于普通文件下載的稀缺性優(yōu)先下載的邏輯。此區(qū)間的數(shù)據(jù)下載盡量不要依賴于 CDN 節(jié)點。

狀態(tài)機是什么？它是一種根據(jù) Buffer 狀態(tài)來進(jìn)行下載數(shù)據(jù)的方式。下載數(shù)據(jù)的方式有2種: P2S，即從 CDN 中下載數(shù)據(jù)；P2P，即從其他多個 Peer 中下載數(shù)據(jù)。那么這兩種方式是如何切換的呢？這就是下載狀態(tài)機要解決的問題。

#1 普通文件下載的狀態(tài)機設(shè)計

普通文件下載的狀態(tài)機隨時評估 CDN 和 P2P 的下載質(zhì)量和資源情況，在三個下載狀態(tài)中相互切換，直到把文件完整地進(jìn)行下載。

#2 流媒體點播的狀態(tài)機設(shè)計

流媒體狀態(tài)機和普通文件下載狀態(tài)機雖然類似，但是在其之上稍作改進(jìn)，在判定 P2P 資源不足以支撐流暢播放的時候，直接放棄 P2P 的下載方式，不再嘗試幾種狀態(tài)的切換，避免造成不必要的開銷。

下載算法，就是將不同的待下載 Piece 分配到多個不同的 Peer 上的算法。這個算法在普通文件下載和流媒體下載的時候是不一樣的。

#1 普通文件下載

PPIO 的調(diào)度算法大致如下:

為了數(shù)據(jù)傳輸更加高效，下載節(jié)點與每個擁有資源的 Peer 建立起多個連接。這里的連接，不限于 TCP 協(xié)議，也有 UDP 協(xié)議實現(xiàn)的會話邏輯。PPIO 同時兼容多種協(xié)議，在不同的網(wǎng)絡(luò)環(huán)境下切換不同的協(xié)議，以應(yīng)對網(wǎng)絡(luò)的異構(gòu)性；

對于每個 Peer，根據(jù)歷史的數(shù)據(jù)傳輸情況，我們都進(jìn)行速度預(yù)測。如果沒有歷史記錄，則使用一個根據(jù)歷史經(jīng)驗得到的默認(rèn)值，缺省經(jīng)驗值；

根據(jù) Buffer 管理的情況，確認(rèn)所有下載 Piece 的優(yōu)先級，然后隨機通過連接向其他 Peer 發(fā)起 Piece 數(shù)據(jù)請求，對方接受請求后，立即發(fā)送 Pieces 數(shù)據(jù)；

任何一個連接只要收到一個 Piece，立即更新該連接的速度預(yù)測，并根據(jù) Buffer 管理的情況請求下一個沒有被下載的 Piece，直到下載完成；

如果 Piece 數(shù)據(jù)請求長時間沒有得到回應(yīng)，則會向其他 Peer 請求數(shù)據(jù)。對該長時間沒有回復(fù)的 Peer 做懲罰，這個懲罰可能會減少該 Peer 連接數(shù)，從而降低該 Peer 下載權(quán)重。

根據(jù)以往設(shè)計高速 P2P 網(wǎng)絡(luò)的經(jīng)驗，PPIO 采用對每個 Peer 進(jìn)行多虛擬連接下載，這個虛擬連接是支持多種協(xié)議之間切換的，其底層協(xié)議，會先嘗試 UDP，如果 UDP 不通再嘗試 TCP，極大的提高了傳輸效率。為什么要這樣做呢？那是因為 TCP 協(xié)議是多年以前根據(jù)互聯(lián)網(wǎng)早期的狀態(tài)設(shè)計的，其本身有弱點，即擁塞控制算法上采用了主動退讓的邏輯，這會造成的傳輸?shù)牡托剩⒉煌耆m合今天實際網(wǎng)絡(luò)的傳輸。

#2 流媒體下載

PPIO 為流媒體下載提供了一套優(yōu)化的 P2P 傳輸系統(tǒng)。為了保證觀看體驗，下載數(shù)據(jù)必須實時，并且能夠應(yīng)對 P2P 網(wǎng)絡(luò)的不穩(wěn)定性。為此，我們采用了數(shù)據(jù)驅(qū)動的 P2P 下載技術(shù)，并基于這個理念后做了很大的改進(jìn)和優(yōu)化，設(shè)計了一套基于預(yù)分配方式的 P2P 多點調(diào)度系統(tǒng)。實現(xiàn)最大化的下載速率，并將由于重復(fù)傳輸和請求所產(chǎn)生的開銷降至最低。PPIO 流媒體調(diào)度算法的設(shè)計如下：

和文件下載器一樣，給每個 Peer 建立多個連接，同時記錄每個虛擬連接的歷史下載速度；

對將要下載的 Piece，根據(jù) Piece 的緊急程度（細(xì)節(jié)見前面的 Buffer 管理）排序做預(yù)分配至每個連接上，并預(yù)測每個 Piece 的到達(dá)時間，從整體來看，以越緊急越優(yōu)先為原則。

針對未完成下載的 Piece，定時重做預(yù)分配，以適應(yīng)每個連接傳輸速度的變化；

當(dāng)每個連接每收到一個 Piece，則更新該通道的速度, 然后從該通道的預(yù)分配隊列中找到下一個 Piece，并發(fā)起請求；

對于非常緊急的 Piece（需要立即播放），允許同時向多個 Peer 請求數(shù)據(jù)；

PPIO 的 P2P 傳輸網(wǎng)絡(luò)是完全動態(tài)的，可以持續(xù)保持高效狀態(tài)。

你可能覺得目前為止我們所提及的都是傳統(tǒng)的 P2SP 的技術(shù)，這和 PPIO 的區(qū)塊鏈有關(guān)系嗎？別急，下面就來解釋一下，前面所介紹的內(nèi)容，都是圍繞著 PPIO 的 PaaS 層和 AS 層（Application Services層）所展開的。PCDN 的整個 P2SP 下載引擎都在 PaaS 層，流媒體格式和協(xié)議的支持，以及數(shù)據(jù)拆分，數(shù)據(jù)拼裝都在 AS 層。而整個去中心化存儲和區(qū)塊鏈的基礎(chǔ)設(shè)施都在 IaaS 層。

流量計數(shù)和IaaS層

PPIO 的設(shè)計理念不同于傳統(tǒng)的 P2P 傳輸項目，傳統(tǒng) P2P 項目倡導(dǎo)的是“人人為我，我為人人”的共享網(wǎng)絡(luò)，下載在傳輸上是“免費”的，上傳是無償?shù)?。?PPIO 建立了激勵網(wǎng)絡(luò)機制，用戶下載資源需要付費的，資源上傳者進(jìn)行一定的收費，即下載方要支付 Token 給上傳方。

在 PPIO 的 IaaS 層，為了保證 P2P 網(wǎng)絡(luò)的效率，不需要每個 Peer 都處理 Token 的支付和接收。因此 PPIO 設(shè)計了 Owner 機制。Owner 不是一個 P2P 傳輸角色，而是一個支付和結(jié)算角色。在 PCDN 架構(gòu)中，每個 Peer 都需要指定一個 Owner。這個 Peer 產(chǎn)生的花費由他的 Owner 來承擔(dān)，而同樣該 Peer 賺取的收入也有他的 Owner 來接收。

如果在需求端，可以將其理解為 CPool（代理支付網(wǎng)關(guān)，見文章《為什么 PPIO 要設(shè)計支付代理節(jié)點》），如果在供給端，也可以簡單理解其為“礦池”。對于 PCDN 業(yè)務(wù)來說，使用帶寬的花費一般是由內(nèi)容發(fā)布者來承擔(dān)。

作為 User 的 Peer 要從一個作為 Miner 的 Peer 中下載數(shù)據(jù)，以下就是最簡單的流程：

Owner 先將足夠的預(yù)支付款打到智能合約。

User 從 Owner1 處申請一個 Check（類似于支票），Check 中含有這個智能合約的地址。以及最大消費額度，CheckID，過期時間等。

Owner 審閱這個 Check 請求是否符合要求，若符合則將 Check 返還給 User；若不符合，比如申請的 Token 過多，則可以拒絕。

User 向 Miner 請求數(shù)據(jù)（通過 P2P 數(shù)據(jù)傳輸協(xié)議）且順利收到數(shù)據(jù)。

User 會將 Check 擴展成 Voucher（類似于憑據(jù)），并發(fā)給 Miner，這個過程（步驟4和5）是多次的，Voucher 涉及的金額會越來越大。

當(dāng)下載完成或異常終止時，就會提交該 Voucher 到 Miner 的 Owner，即 Owner2。

Owner2 收到該 Voucher，會向該區(qū)塊鏈智能合約發(fā)起提款。

如果 Voucher 正確且未超時，那么就能提款成功。

對 PCDN 業(yè)務(wù)的開發(fā)者來說，既可自己部署 CPool（即 Owner），也可以接入其他第三方 CPool（即 Owner）。另外，如果下載方和上傳方的 Owner 是同一個，那情況就會變得更加簡單，交易不用上鏈，在 Owner 的內(nèi)部進(jìn)行即能解決，Owner 的金錢數(shù)量不會變動。就這樣，PPIO 將 P2P 傳輸和區(qū)塊鏈計費進(jìn)行了有效的結(jié)合。

當(dāng)然，這只是一個 PPIO 中 IaaS 層計費中的一個最簡單的流程，實際情況會復(fù)雜得多。之后會有更多的文章來深度解析 PPIO 的 PCDN 相關(guān)的智能合約。

不可否認(rèn)，流媒體領(lǐng)域在眾多區(qū)塊鏈技術(shù)應(yīng)用場景中潛力巨大，PPIO 將結(jié)合自身豐富的 P2P 經(jīng)驗和前沿的區(qū)塊鏈技術(shù)為大家?guī)砀玫囊曨l觀看體驗。體量雖小，能量巨大，好戲正要上演，還不趕緊加入社群一起探討吧！