爲什麼專一於流媒體領域？PPIO 技術揭祕

工做日早晨8點的地鐵，Lisa 拿出手機打開 Tik Tok 來打發半小時的通勤時間；12點，吃完午餐的 Lisa 趁着午休時間忙裏偷閒看看 YouTube 上有趣搞笑的視頻；晚上8點，忙碌了一天的她回到家以後躺在沙發上打開電視，在 Netflix 和 Hulu 上搜索着最新的電影準備充實夜晚的生活。看到這裏，你是否是彷彿看見了本身的影子？確實，咱們天天都花費了大量的上網時間在音視頻應用上，而對這一切咱們也許毫無察覺。

爲何 PPIO 要作音視頻

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

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

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

PPIO 將陸續提供3套 API：

1. 基於 IaaS 層的存儲空間和帶寬租用的 API。
2. 基於 PaaS 的 POSS，PCDN，PRoute 的 API。
3. 基於 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