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

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

為什么 PPIO 要做音視頻

據2018年10月的《全球互聯網現象報告》，視頻應用使用所產生的流量占互聯網總流量的58%左右。正如報告中所指出，視頻應用在全球應用流量的份額出現了前所未有的增長。

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

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

PPIO 將陸續提供3套 API：

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

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

基于 Application Service 層的點播，直播以及更多 API 接口。

開發者可以選擇在任意一層進行開發，完成自己的 APP 或者 DAPP。

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

在 PPIO 的架構中，流媒體音視頻的 API 是在 Application Services 層，因為它的場景非常貼近于應用，但 PCDN 的基礎在 PaaS 層，下面將重點說明 PPIO 在流媒體視頻上的設計尤其是流媒體視頻數據分發的相關部分。

CDN 和 PCDN

CDN，全稱是 Content Delivery Network，即數據分發網絡，現代互聯網的核心基礎設施之一。CDN節點是在整個 CDN 的架構中最接近用戶的節點。CDN 架構的設計初衷是將數據存儲在中心，但中心數據并不是離每個用戶都是最近的，所以 CDN 架構在很多邊緣城域網上都部署了 CDN 節點，這些節點用于數據的緩存，當用戶請求使用數據的時候，就可以快速直接地給出數據，從而保證了良好的用戶體驗。下圖為 CDN 節點的架構圖。

至今，CDN 技術已經發展了很多年，從事 CDN 業務的公司不在少數，并且已經出現大規模的商業應用。2018年底，全球 CDN 市場的總產值達到200億美元，市場規模巨大。

PPIO 在設計 PCDN 的時候，并不是提出全新的數據分發方案，而是在現有 CDN 分發方案的基礎上，給予 P2P 傳輸的補充方案，使得數據分發服務既能夠兼容過去的方案，又能實現更廉價更高速。下圖為 PCDN 兼容現有 CDN 方案的設計圖。

分片和媒體

分片是 P2P 傳輸技術的基礎。對 P2P 系統來說，分片規則至關重要。那么，什么是分片？分片就是將一個文件或者一段流，按照某種統一的規則來進行切分和編號。被切分出來的每一個單元稱為 Piece，也就是 P2P 傳輸的單元。如果兩個 Piece 編號一樣，那么就認為他們是同一個 Piece。傳統的 P2P 協議里面，分片是以中心化的方式來完成的；例如 BitTorrent 是由做種的用戶（第一個用戶）來進行分片，后面的 P2P 網絡都按照第一個用戶的分片方式來進行。

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

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

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

首先定義一下名詞。

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

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

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

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

TSP：對 TS 進行分片后的每個 Piece。

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

VSP：對 Video Segment 進行分片后的每個 Piece。

#1. 普通文件的分片

如上圖所示，

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

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

一個 FS 對應一個 bitmap，bitmap 中的一個 bit 對應一個 FSP。

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

#2. 點播

這里重點考慮了 PPIO 架構針對兩種流媒體傳輸模式的分片。

#2.1 HTTP 分段流點播

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

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

這樣同樣支持拖動：當用戶拖動時，播放器指定 TS 索引，然后根據 TS 索引下載相關內容，相關 TS 下載完畢后，傳遞給播放器,? 完成播放。

#2.2 HTTP 連續流的點播

這里以 HTTP+FLV 為例。

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

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

#3. 直播

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

這里重點闡述一下 PPIO 架構針對兩種流媒體傳輸模式的分片的思考。

#3.1 HTTP 分段流直播

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

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

#3.2 HTTP 連續流直播

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

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

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

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

分片只是建立起了 P2SP 下載的秩序，高效的傳輸架構也是不容忽視的。介紹完分布式切片的方式，那么接下來就要討論一下如何用 P2SP 網絡進行高效的數據傳輸。

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

這是 PPIO 的 PCDN 全節點架構圖，在此，分別介紹一下里面的角色。

1. CDN 節點：

CDN 節點是在整個 CDN 的架構中最靠近用戶的節點；用戶可以直接從中獲取數據。CDN 節點發展多年，現在已經支持多種傳輸協議，包括 HTTP，HTTP/2，QUIC+HTTP/3 等。

#2. Mapping 節點：

CDN 中有資源唯一 ID，而 P2P 中也有唯一 ID，他們擁有的資源 ID 并不相同，我們在進行 P2SP 協同傳輸的時候要把不同的資源 ID 映射起來。Mapping 節點作用就在于此，其職責就是把這兩種不同的 ID 進行映射，并提供查詢功能。

Mapping 節點是個商業節點，開發者可以自己開發 Mapping 節點，用于自己應用的場景，因為只有開發者本人最清楚 CDN 中的資源唯一 ID 和 PPIO 中 P2P 的資源唯一 ID 是否一致。

如果開發者不自己開發 Mapping 節點，也可以對接公用的 Mapping 節點。公用 Mapping 節點建立的就是 CDN 中的 Url 和 PPIO 中 RID 之間的對應關系。

Mapping 節點是必須的嗎？不是，因為 Mapping 節點只是一種對應關系，如果這個對應關系對開發者來說可以用一套簡單算法直接離線實現，就不需要 Mapping 節點。

#3. Peer 節點：

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

#4. Tracker 節點

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

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

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

#5. SuperPeer 節點

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

SuperPeer 作為高質量節點，算法上會被優先照顧，回報和收益也會較高。

#6. Push 節點

Push 節點是用于做預熱調度的，簡單地說，就是把人為判斷的未來一定會變熱的內容強行塞到大量的 Peer 上。雖然 PPIO 有通過 Overlay 網絡自然發現變熱的機制，但是自然變熱往往比較慢，而通過 Push 節點調度變熱，能夠做到預先處理，當需要下載該文件的時候，網絡中已經有大量的 Peer 存儲了這個文件進行數據上傳，從而大大提升了用戶體驗。

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

想了解更多有關 PPIO 的信息，可以移步官網：pp.io