搜狐視訊P2P技術揭祕 - 分享率控制篇
搜狐視訊P2P技術揭祕 - 分享率控制篇
在《搜狐視訊P2P技術揭祕 - 架構篇》中指出播放器P2P客戶端的一個重要任務就是尋找一個兼顧流暢率和分享率的平衡點，本文將介紹搜狐視訊P2P客戶端使用的方法。
1 業務決定控制邏輯
一個完整的播放器APP至少有以下兩個基本功能：
- 播放；
- 下載。
實際上這兩個業務功能定義還不夠細，播放可以分為線上播放和離線播放，下載根據播放器邏輯又可以分為普通下載和預載入。
- 播放：
- 線上播放：直接播放來自網路的媒體檔案；
- 離線播放：播放已經下載到本地的媒體檔案；
- 下載
- 普通下載：使用者直接發起的下載請求；
- 預載入：預先載入當前播放分段的後續若干分段。
對不同的業務來說，流暢率和分享率的優先順序有所不同。
| 業務 | 分享率 | 流暢率 | 下載速度 |
|---|---|---|---|
| 線上播放 | 中 | 高 | 中 |
| 普通下載 | 中 | 低 | 高 |
| 預載入 | 高 | 低 | 低 |
流暢率又體現為上報給播放器的有序資料的速度穩定性，流暢率和分享率的衝突，往往就是使用P2P和CDN兩個通道的衝突。主要體現在：
- P2P的Peer質量參差不齊，使用UDP協議，有比較高的機率出現丟包、抖動、亂序，導致上報播放器的有序資料的速度不穩定，也就是流暢率不足；
- P2P的Peer數量可能不足，導致下載速度不夠，需要CDN的彌補，兩個通道的切換、同時使用的邏輯需要比較好的控制，否則可能導致流暢率不足。
在線上播放業務中，首開時間、流暢度直接影響使用者體驗，因此分享率的重要性降低，但是並不會太低，當緩衝的資料足夠後，應儘可能使用P2P。至於緩衝的資料來自CDN還是P2P，根據不同的前提有不同的策略，假設CDN的部署足夠好，那麼CDN下載是最優選擇，首開的前幾秒資料應該優先從CDN下載。但是也有例外，CDN的頻寬往往是比較昂貴的，一些小運營商可能會提供免費的CDN，但質量就無法保證，這個時候就需要權衡。移動P2P的一個可選策略是同時從CDN和P2P兩個通道下載前幾秒的資料，一旦資料緩衝完成，則根據CDN和P2P的當前質量對比，切換到合適的通道。
在普通下載業務中，下載速度和分享率優先順序比較高，資料的有序性並不重要。但是既然是下載速度優先，那麼最終主要使用P2P還是使用CDN決定於Peer的數量和質量，如果Peer不足，質量不佳，那麼速度不足的時候仍然要切換到CDN。
預載入業務對使用者來說是不可見的，可以在播放到當前分段末尾若干時間的時候開始，這個時候應該以P2P為主，速度和流暢率優先順序降低。
2 搜狐影音/搜狐視訊
搜狐影音(Windows)和搜狐視訊(移動端)都實現了基於P2P的線上播放和離線下載業務，但是搜狐影音P2P的分享率比搜狐視訊高，主要原因是：
- 搜狐影音在PC端，機器效能、網路環境整體更好；
- 搜狐影音開啟了P2P的預載入，預載入的分段基本都使用P2P下載；
- 搜狐影音開啟了P2P的本地快取，已經播放過的視訊被快取到本地，再次播放時將直接載入本地快取，而本次播放的資料被統計到P2P通道中。
除了以上差異，兩者的P2P實現沒有本質的區別，尤其是在分享率控制的演算法實現。
| 演算法思想：用有限狀態機來描述一次業務呼叫中P2P、CDN狀態的切換。一個狀態的輸入是當前P2P、CDN的各種引數，包括P2P下載速度、CDN下載速度、P2P Peer數、當前上報連續資料的速度、已經上報的資料量、檔案的位元速率等，通過一定的邏輯來計算下一個狀態是P2P還是CDN。在任務開始時，針對不同的業務建立不同的狀態機，例如，為線上播放業務建立緊急狀態機，為下載業務建立下載狀態機，為預載入業務建立預載入狀態機，根據狀態機的當前狀態來判斷下載任務應該分發給P2P Peer還是CDN。 |
|---|
2.1 狀態定義
typedef enum state {
0：初始狀態；
1：P2P狀態；
2：CDN狀態；
3：P2P+CDN組合狀態；
} state;
2.2 輸入事件
typedef struct event {
0：當前P2P速度；
1：當前CDN速度；
2：連續上報播放器的速度；
3：已經上報播放器的資料量；
4：已經上報播放器的資料比例；
5：已經上報播放器的時間；
6：視訊檔案的位元速率；
7：活躍種子數；
8：播放器已經快取的視訊時長；
9：播放準備時間(廣告時間)；
10：本狀態已經維持的時間；
……
} event;
2.3 狀態轉換
由於有4個狀態，因此有以下幾個狀態轉換動作：
- on_state_init(in event)，在初始狀態下執行；
- on_state_p2p(in event)，在P2P狀態下執行；
- on_state_cdn(in event)，在CDN狀態下執行；
- on_state_p2p_cdn(in event)，在P2P+CDN混合狀態下執行；
在這些狀態轉換動作中，根據狀態機型別、輸入事件引數、當前狀態來決定下一個狀態：
- 從初始狀態可能進入P2P狀態、CDN狀態或P2P+CDN 狀態；
- 從P2P狀態可能進入CDN或P2P+CDN狀態；
- 從CDN狀態可能進入P2P狀態或P2P+CDN狀態；
- 從P2P+CDN狀態可能進入P2P狀態或者CDN狀態。
2.4 轉換邏輯
不同狀態機的區別主要體現在初始狀態以及狀態轉換邏輯。
舉個例子，線上播放業務的緊急狀態機下，初始狀態可能是CDN，如果上報的資料量已經超過了播放器的緩衝若干秒，並且P2P打通的活躍Peer數超過一定的閾值，那麼會切換到P2P+CDN混合狀態，在混合狀態下，如果P2P的速度超過一定的閾值，就會切到純P2P狀態，否則如果P2P的速度不足，Peer質量也不佳，那麼會切換到純CDN狀態……
這些用到的所有閾值都是從Navigation服務獲取的，從資料層面得到了一定的靈活性。後來，我們發現轉換邏輯也可能需要動態調整，因此把狀態機的實現放到lua指令碼中，指令碼部署在服務端，這樣轉換邏輯的實現就更靈活。
狀態機指令碼的更新依賴於統計資料，P2P的每次請求都會上報一次請求中的各種資料，主要包括狀態切換的輸入、輸出，後臺分析指令碼將分析狀態切換的詳細資料並進行統計，根據統計的資料，可以分析出目前的狀態轉換邏輯的問題，形成一個反饋閉環。
3 Flash 播放器/H5 播放器
頁面的播放器主要負責線上播放業務，並沒有下載業務，因此P2P、CDN的切換邏輯比較簡單。
首開的幾秒資料從CDN下載，然後設定一個緩衝，播放過程中，當緩衝中的資料不足時主要由CDN來快速填充，緩衝時間外的資料則主要由P2P來下載。