1. 程式人生 > >搜狐視訊P2P技術揭祕 - 分享率控制篇

搜狐視訊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來下載。