摘要：的分片方式是和文件結(jié)構(gòu)或者流媒體協(xié)議相關(guān)的。需要注意的是，這里的普通文件不是流媒體視頻文件，不具備流媒體的特性。，也就是分段流媒體的原始分段。除了支持分段流和連續(xù)流以外，后面還計劃逐步支持其他媒體格式和協(xié)議。

工作日早晨8點(diǎn)的地鐵，Lisa 拿出手機(jī)打開 Tik Tok 來打發(fā)半小時的通勤時間；12點(diǎn)，吃完午飯的 Lisa 趁著午休時間忙里偷閑看看 YouTube 上有趣搞笑的視頻；晚上8點(diǎn)，忙碌了一天的她回到家之后躺在沙發(fā)上打開電視，在 Netflix 和 Hulu 上搜索著最新的電影準(zhǔn)備充實夜晚的生活?？吹竭@里，你是不是仿佛看見了自己的影子？確實，我們每天都花費(fèi)了大量的上網(wǎng)時間在音視頻應(yīng)用上，而對這一切我們也許毫無察覺。

為什么 PPIO 要做音視頻

據(jù)2018年10月的《全球互聯(lián)網(wǎng)現(xiàn)象報告》，視頻應(yīng)用使用所產(chǎn)生的流量占互聯(lián)網(wǎng)總流量的58%左右。正如報告中所指出，視頻應(yīng)用在全球應(yīng)用流量的份額出現(xiàn)了前所未有的增長。

PPIO 是為開發(fā)者打造的去中心化存儲與分發(fā)平臺，讓數(shù)據(jù)存儲更便宜、更高速、更隱私。官方網(wǎng)站是?pp.io?。

在設(shè)計 PPIO 的時候，我們就把音視頻這一方向視為重中之重，不僅要順利地支持主流音視頻傳輸協(xié)議，還要把服務(wù)質(zhì)量 QoS 做好。為了讓大家能更好的理解接下來介紹的 PPIO 流媒體音視頻的數(shù)據(jù)分發(fā)，我們先來回顧一下 PPIO 的商業(yè)化架構(gòu)。

PPIO 將陸續(xù)提供3套 API：

基于 IaaS 層的存儲空間和帶寬租用的 API。

基于 PaaS 的 POSS，PCDN，PRoute 的 API。

基于 Application Service 層的點(diǎn)播，直播以及更多 API 接口。

開發(fā)者可以選擇在任意一層進(jìn)行開發(fā)，完成自己的 APP 或者 DAPP。

如果把 PPIO 和 AWS 云計算服務(wù)做對比，其層次類比為：

在 PPIO 的架構(gòu)中，流媒體音視頻的 API 是在 Application Services 層，因為它的場景非常貼近于應(yīng)用，但 PCDN 的基礎(chǔ)在 PaaS 層，下面將重點(diǎn)說明 PPIO 在流媒體視頻上的設(shè)計尤其是流媒體視頻數(shù)據(jù)分發(fā)的相關(guān)部分。

CDN 和 PCDN

CDN，全稱是 Content Delivery Network，即數(shù)據(jù)分發(fā)網(wǎng)絡(luò)，現(xiàn)代互聯(lián)網(wǎng)的核心基礎(chǔ)設(shè)施之一。CDN節(jié)點(diǎn)是在整個 CDN 的架構(gòu)中最接近用戶的節(jié)點(diǎn)。CDN 架構(gòu)的設(shè)計初衷是將數(shù)據(jù)存儲在中心，但中心數(shù)據(jù)并不是離每個用戶都是最近的，所以 CDN 架構(gòu)在很多邊緣城域網(wǎng)上都部署了 CDN 節(jié)點(diǎn)，這些節(jié)點(diǎn)用于數(shù)據(jù)的緩存，當(dāng)用戶請求使用數(shù)據(jù)的時候，就可以快速直接地給出數(shù)據(jù)，從而保證了良好的用戶體驗。下圖為 CDN 節(jié)點(diǎn)的架構(gòu)圖。

至今，CDN 技術(shù)已經(jīng)發(fā)展了很多年，從事 CDN 業(yè)務(wù)的公司不在少數(shù)，并且已經(jīng)出現(xiàn)大規(guī)模的商業(yè)應(yīng)用。2018年底，全球 CDN 市場的總產(chǎn)值達(dá)到200億美元，市場規(guī)模巨大。

PPIO 在設(shè)計 PCDN 的時候，并不是提出全新的數(shù)據(jù)分發(fā)方案，而是在現(xiàn)有 CDN 分發(fā)方案的基礎(chǔ)上，給予 P2P 傳輸?shù)难a(bǔ)充方案，使得數(shù)據(jù)分發(fā)服務(wù)既能夠兼容過去的方案，又能實現(xiàn)更廉價更高速。下圖為 PCDN 兼容現(xiàn)有 CDN 方案的設(shè)計圖。

分片和媒體

分片是 P2P 傳輸技術(shù)的基礎(chǔ)。對 P2P 系統(tǒng)來說，分片規(guī)則至關(guān)重要。那么，什么是分片？分片就是將一個文件或者一段流，按照某種統(tǒng)一的規(guī)則來進(jìn)行切分和編號。被切分出來的每一個單元稱為 Piece，也就是 P2P 傳輸?shù)膯卧?。如果兩個 Piece 編號一樣，那么就認(rèn)為他們是同一個 Piece。傳統(tǒng)的 P2P 協(xié)議里面，分片是以中心化的方式來完成的；例如 BitTorrent 是由做種的用戶（第一個用戶）來進(jìn)行分片，后面的 P2P 網(wǎng)絡(luò)都按照第一個用戶的分片方式來進(jìn)行。

而 PCDN 的分片是不同的。PCDN 使用的是 P2SP 的技術(shù)，這里的 S 指的是 Server（服務(wù)器），也就是說 P2SP 的數(shù)據(jù)最原始來源不是節(jié)點(diǎn)，而是一個標(biāo)準(zhǔn)化輸出的 Server，可能是 HTTP 協(xié)議，也可能是 HTTP2，QUIC+HTTP/3 等其他協(xié)議。這樣的 Server 在 CDN 體系下是標(biāo)準(zhǔn)化的，它們不具有切片的能力。所以 PPIO 在設(shè)計 PCDN 時，由 Peer（P2P 的普通網(wǎng)絡(luò)節(jié)點(diǎn)）來分布式完成切片，所以這要求所有的節(jié)點(diǎn)，對于一個相同的資源里來說，必須按照相同的分片規(guī)則來進(jìn)行分片，從而確保 Peer1（節(jié)點(diǎn)1）和 Peer2（節(jié)點(diǎn)2）的分片是一致的。

PPIO 的分片方式是和文件結(jié)構(gòu)或者流媒體協(xié)議相關(guān)的。 這里先介紹一下 PPIO 對兩種主流的流媒體傳輸方式的兼容情況和具體方案，一個是分段流的方式，包括 HLS（Http Live Streaming）和 DASH 兩種方式；另一個是 HTTP 連續(xù)流的方式，比如 HTTP+FLV。此外，PPIO 將支持兩種視頻數(shù)據(jù)分發(fā)場景：直播和點(diǎn)播。

首先，說一下我們對普通文件的分片方式。需要注意的是，這里的普通文件不是流媒體視頻文件，不具備流媒體的特性。

首先定義一下名詞。

Segment：文件，點(diǎn)播流，直播流的大段單位，不確定是否固定長度。一個文件可以就是一個 Segment；但是一個直播流是由多個 Segment 組成；點(diǎn)播流看情況，可能是一個 Segment，也可能是由多個 Segment 組成。

Piece：P2SP 調(diào)度的最小單元，在 P2P 的 bitmap 會作為1個 bit 來表示。

SubPiece：最終 P2P 協(xié)議的傳輸單位，小于 UDP 的 MTU（一般為1350直接），PPIO 底層大量使用 UDP 協(xié)議。如果一個 UDP 報文大于 MTP，那么丟包率就會大大增加。

TS：Transport Stream，也就是分段流媒體的原始分段。這里以 HLS 為例，所以這里寫成TS。如果是 DASH 流，就對應(yīng) FMP4。

TSP：對 TS 進(jìn)行分片后的每個 Piece。

VS：Video Segment, 對于 HTTP 連續(xù)流點(diǎn)播，由固定大小切片；對于直播，根據(jù)I幀邊界和最小時長切分而得。

VSP：對 Video Segment 進(jìn)行分片后的每個 Piece。

#1. 普通文件的分片

如上圖所示，

一個文件劃分的 FS 等長，那么最后一個 FS 可能偏小。

每個 FS 劃分的 FSP 等長，那么最后一個 FSP 可能更小。

一個 FS 對應(yīng)一個 bitmap，bitmap 中的一個 bit 對應(yīng)一個 FSP。

如果是普通視頻文件，透明支持拖動，也支持邊下邊播。用戶如果拖動，播放器會指定 range，根據(jù) range 和固定大小計算出 FS 索引，請求相關(guān) FS 里面需要的 FSP。相關(guān) FSP 下載完畢后，再合并流，傳遞給播放器。

#2. 點(diǎn)播

這里重點(diǎn)考慮了 PPIO 架構(gòu)針對兩種流媒體傳輸模式的分片。

#2.1 HTTP 分段流點(diǎn)播

這里，以 HLS 為例，DASH 等其他分段流類似。

從視頻服務(wù)器上拿到 m3u8，得到里面的 TS 文件列表。一般來說，一個 HLS 點(diǎn)播流所劃分成的 TS 不一定等長。每個 TS 劃分的 TSP 等長，但最后一個 TSP 可能偏小。其中，一個 TS 對應(yīng)一個 bitmap，bitmap 中的一個 bit 對應(yīng)一個 TSP。

這樣同樣支持拖動：當(dāng)用戶拖動時，播放器指定 TS 索引，然后根據(jù) TS 索引下載相關(guān)內(nèi)容，相關(guān) TS 下載完畢后，傳遞給播放器,? 完成播放。

#2.2 HTTP 連續(xù)流的點(diǎn)播

這里以 HTTP+FLV 為例。

圖中的 Tag 指得是流媒體中原始的數(shù)據(jù)特征。其中，一個 FLV 點(diǎn)播流所劃分的 VS 等長，最后一個 VS 可能偏小；而每個 VS 劃分的 VSP 等長，最后一個 VSP 可能偏小。每個 VS 對應(yīng)一個 bitmap，bitmap 中的一個 bit 對應(yīng)一個 VSP。FLV 點(diǎn)播的切片方式和文件下載的方式一樣。

當(dāng)然，這樣也是支持邊下邊播和拖動的：當(dāng)用戶拖動的時候，播放器指定 range，根據(jù) range 和固定的 Segment 大小來計算出 VS 索引，請求相關(guān) VS。完成下載后，再合并流，傳遞給播放器。

#3. 直播

從切片角度來看，直播比起點(diǎn)播來說要復(fù)雜。因為直播既沒有開始，也沒有結(jié)束，每個用戶開始觀看直播的時候，下載的都是中間的數(shù)據(jù)。并且所有用戶的數(shù)據(jù)要按照同樣的分片規(guī)則來分片，這里不僅僅要分片，而且還要能夠同步。除此之外，一般直播還有回放功能。

這里重點(diǎn)闡述一下 PPIO 架構(gòu)針對兩種流媒體傳輸模式的分片的思考。

#3.1 HTTP 分段流直播

這里還是以 HLS 為例，DASH 等其他分段流類似。

HLS 的直播和 HLS 點(diǎn)播的切片方式一樣，假設(shè)當(dāng)前直播 m3u8 文件， 播放 TS1，TS2，TS3，TS4，TS5。按照基準(zhǔn)時延的設(shè)置，直播會從某一個 TS 開始播放，比如說從 TS1 播放，時延最長，因此從 P2P 網(wǎng)絡(luò)中拿到數(shù)據(jù)的機(jī)會就越多，從而 P2P 利用率就最高；但是如果從 TS5 播放，時延最短，因此從 P2P 網(wǎng)絡(luò)中拿到數(shù)據(jù)的機(jī)會就越少，從而 P2P 利用率就最低；如果從 TS3 播放，就是折中方案。

#3.2 HTTP 連續(xù)流直播

HTTP 連續(xù)流的直播，指的是一開始就沒有結(jié)束的流，這里還是以 HTTP+FLV 為例。

一個 FLV 直播流所劃分的 VS 不一定等長，VS 以關(guān)鍵幀為邊界開始，以一個時間單位為最小來進(jìn)行切片時間。切片算法要保證每個 VS 里面的每個幀的數(shù)據(jù)都是完整的，并且必須包含一個關(guān)鍵幀。

假設(shè)當(dāng)前直播播放 VS1，VS2，VS3，VS4，VS5，按照基準(zhǔn)時延的設(shè)置，如果從 VS1 播放，時延最長，從 P2P 拿數(shù)據(jù)的機(jī)會就越多，P2P 利用率最高；如果從 VS5 播放，時延最短，從 P2P 拿數(shù)據(jù)的機(jī)會就越少，P2P 利用率最低；因此從 VS3 播放便是折中方案。

PPIO 除了支持 HTTP 分段流和 HTTP 連續(xù)流以外，后面還計劃逐步支持其他媒體格式和協(xié)議。

分片只是建立起了 P2SP 下載的秩序，高效的傳輸架構(gòu)也是不容忽視的。介紹完分布式切片的方式，那么接下來就要討論一下如何用 P2SP 網(wǎng)絡(luò)進(jìn)行高效的數(shù)據(jù)傳輸。

P2SP 的傳輸是一種結(jié)合了 P2P 下載和從 Server 下載的下載方式。數(shù)據(jù)傳輸需要解決的問題就是在合適的時間挑選合適的方式進(jìn)行下載。

這是 PPIO 的 PCDN 全節(jié)點(diǎn)架構(gòu)圖，在此，分別介紹一下里面的角色。

1. CDN 節(jié)點(diǎn)：

CDN 節(jié)點(diǎn)是在整個 CDN 的架構(gòu)中最靠近用戶的節(jié)點(diǎn)；用戶可以直接從中獲取數(shù)據(jù)。CDN 節(jié)點(diǎn)發(fā)展多年，現(xiàn)在已經(jīng)支持多種傳輸協(xié)議，包括 HTTP，HTTP/2，QUIC+HTTP/3 等。

#2. Mapping 節(jié)點(diǎn)：

CDN 中有資源唯一 ID，而 P2P 中也有唯一 ID，他們擁有的資源 ID 并不相同，我們在進(jìn)行 P2SP 協(xié)同傳輸?shù)臅r候要把不同的資源 ID 映射起來。Mapping 節(jié)點(diǎn)作用就在于此，其職責(zé)就是把這兩種不同的 ID 進(jìn)行映射，并提供查詢功能。

Mapping 節(jié)點(diǎn)是個商業(yè)節(jié)點(diǎn)，開發(fā)者可以自己開發(fā) Mapping 節(jié)點(diǎn)，用于自己應(yīng)用的場景，因為只有開發(fā)者本人最清楚 CDN 中的資源唯一 ID 和 PPIO 中 P2P 的資源唯一 ID 是否一致。

如果開發(fā)者不自己開發(fā) Mapping 節(jié)點(diǎn)，也可以對接公用的 Mapping 節(jié)點(diǎn)。公用 Mapping 節(jié)點(diǎn)建立的就是 CDN 中的 Url 和 PPIO 中 RID 之間的對應(yīng)關(guān)系。

Mapping 節(jié)點(diǎn)是必須的嗎？不是，因為 Mapping 節(jié)點(diǎn)只是一種對應(yīng)關(guān)系，如果這個對應(yīng)關(guān)系對開發(fā)者來說可以用一套簡單算法直接離線實現(xiàn)，就不需要 Mapping 節(jié)點(diǎn)。

#3. Peer 節(jié)點(diǎn)：

Peer 就是 P2P 網(wǎng)絡(luò)中的節(jié)點(diǎn)，在 PPIO 的網(wǎng)絡(luò)中，Peer 即可能是存儲節(jié)點(diǎn)，也可能是用戶，也可能兩者都是（即上傳數(shù)據(jù)又下載數(shù)據(jù)的節(jié)點(diǎn)）。在 PPIO 的供給和需求以及區(qū)塊鏈設(shè)計中，一般會把存儲節(jié)點(diǎn)和用戶分角色來描述，但是在 P2P 網(wǎng)絡(luò)中，大部分功能和代碼都是一致的，所以在這都稱為 Peer 節(jié)點(diǎn)，他們在傳輸協(xié)議上也是對等的。

#4. Tracker 節(jié)點(diǎn)

PPIO 中 Tracker 節(jié)點(diǎn)的定位和 BitTorrent 中 Tracker 的定位是接近的。主要是用于管理 RID（資源 ID, 用于標(biāo)記一個文件或流）和 P2P 節(jié)點(diǎn)之間的關(guān)系。Tracker 上對每個 RID 都記錄了擁有該資源的 Peer 節(jié)點(diǎn)的關(guān)系。當(dāng)一個 Peer 要獲取一個資源的時候，首先從 Tracker 中查詢到首批 Peer，然后就可以從擁有該資源的這些 Peer 中下載數(shù)據(jù)了。后續(xù)可以從這些首批 Peer 中利用“泛洪”的機(jī)制查詢到更多的 Peer，最終在本地形成一個越來越大 Peer 庫，直到發(fā)現(xiàn)幾乎所有的 Peer。

看到這里，你一定會有這樣的疑問。Tracker 不就是網(wǎng)絡(luò)的“中心”嗎？只要這個“中心”出現(xiàn)問題，網(wǎng)絡(luò)不就出問題了嗎？那么 Tracker 是必須存在的嗎？當(dāng)然不是，因為 Tracker 只是對初始節(jié)點(diǎn)的發(fā)現(xiàn)，而在 PPIO 中還有一套發(fā)現(xiàn)初始 Peer 節(jié)點(diǎn)的機(jī)制，那就是 DHT，即分布式哈希表。PPIO 是使用 KAD 算法來實現(xiàn) DHT 的。不過使用 DHT 方式去發(fā)現(xiàn)初始節(jié)點(diǎn)的效率比較低，沒有通過 Tracker 來得快速和高效。

開發(fā)者在基于 PPIO 進(jìn)行應(yīng)用開發(fā)的時候，可以根據(jù)自己的要求來選擇 Tracker 方式還是 DHT 方式。如果追求效率和 QoS，Tracker 方式更好；如果追求完全地去中心化，就可以只使用 DHT 方式。

#5. SuperPeer 節(jié)點(diǎn)

在 PPIO 的分發(fā)網(wǎng)絡(luò)中，還有一種特殊的 Peer 節(jié)點(diǎn)，我們稱為 SuperPeer。SuperPeer 是我們根據(jù)各方面的技術(shù)條件利用算法自動選擇出來的。SuperPeer 的篩選條件會有很多，網(wǎng)絡(luò)情況，存儲情況，長時間在線情況，抵押情況，以及歷史違約情況等都會考慮。當(dāng)各方面的技術(shù)條件都達(dá)到要求的時候，就能自動升級為 SuperPeer。

SuperPeer 作為高質(zhì)量節(jié)點(diǎn)，算法上會被優(yōu)先照顧，回報和收益也會較高。

#6. Push 節(jié)點(diǎn)

Push 節(jié)點(diǎn)是用于做預(yù)熱調(diào)度的，簡單地說，就是把人為判斷的未來一定會變熱的內(nèi)容強(qiáng)行塞到大量的 Peer 上。雖然 PPIO 有通過 Overlay 網(wǎng)絡(luò)自然發(fā)現(xiàn)變熱的機(jī)制，但是自然變熱往往比較慢，而通過 Push 節(jié)點(diǎn)調(diào)度變熱，能夠做到預(yù)先處理，當(dāng)需要下載該文件的時候，網(wǎng)絡(luò)中已經(jīng)有大量的 Peer 存儲了這個文件進(jìn)行數(shù)據(jù)上傳，從而大大提升了用戶體驗。

當(dāng)然，PPIO 的流媒體設(shè)計并不是三言兩語就能說清楚的，這篇文章主要講解了 PPIO 的 PCDN 架構(gòu)，更多內(nèi)容會在下一篇文章中為大家慢慢道來，關(guān)注 PPIO 公眾號，不要錯過最新的精彩內(nèi)容！

想了解更多有關(guān) PPIO 的信息，可以移步官網(wǎng)：pp.io