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

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

為什么 PPIO 要做音視頻

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

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

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

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

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

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

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

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

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

在 PPIO 的架構(gòu)中，流媒體音視頻的 API 是在 Application Services 層，因?yàn)樗膱?chǎng)景非常貼近于應(yīng)用，但 PCDN 的基礎(chǔ)在 PaaS 層，下面將重點(diǎn)說(shuō)明 PPIO 在流媒體視頻上的設(shè)計(jì)尤其是流媒體視頻數(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)是在整個(gè) CDN 的架構(gòu)中最接近用戶的節(jié)點(diǎn)。CDN 架構(gòu)的設(shè)計(jì)初衷是將數(shù)據(jù)存儲(chǔ)在中心，但中心數(shù)據(jù)并不是離每個(gè)用戶都是最近的，所以 CDN 架構(gòu)在很多邊緣城域網(wǎng)上都部署了 CDN 節(jié)點(diǎn)，這些節(jié)點(diǎn)用于數(shù)據(jù)的緩存，當(dāng)用戶請(qǐng)求使用數(shù)據(jù)的時(shí)候，就可以快速直接地給出數(shù)據(jù)，從而保證了良好的用戶體驗(yàn)。下圖為 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ǎng)的總產(chǎn)值達(dá)到200億美元，市場(chǎng)規(guī)模巨大。

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

分片和媒體

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

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

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

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

首先定義一下名詞。

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

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

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

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

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

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

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

#1. 普通文件的分片

如上圖所示，

一個(gè)文件劃分的 FS 等長(zhǎng)，那么最后一個(gè) FS 可能偏小。

每個(gè) FS 劃分的 FSP 等長(zhǎng)，那么最后一個(gè) FSP 可能更小。

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

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

#2. 點(diǎn)播

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

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

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

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

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

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

這里以 HTTP+FLV 為例。

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

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

#3. 直播

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

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

#3.1 HTTP 分段流直播

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

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

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

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

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

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

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

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

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

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

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

CDN 節(jié)點(diǎn)是在整個(gè) 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 并不相同，我們?cè)谶M(jìn)行 P2SP 協(xié)同傳輸?shù)臅r(shí)候要把不同的資源 ID 映射起來(lái)。Mapping 節(jié)點(diǎn)作用就在于此，其職責(zé)就是把這兩種不同的 ID 進(jìn)行映射，并提供查詢功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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