高清視頻下如何節省帶寬？

一節省帶寬成本的技術挑戰

從實際業務場景出發，節省帶寬成本這個命題，在技術上面臨非常多的挑戰。

第一，優酷服務的終端類型多，移動端有 Android，IPhone，IPad；PC 端有 Window 和 MAC，還有 Web 端，OTT 端等等。不同終端有不同特性，在處理機制上就會不同。即使同一類終端，針對特殊機型也需要做專門適配。

第二，視頻業務的種類多。像直播業務，點播業務，緩存下載業務，短視頻業務，每種業務所關注的指標都不相同，比如點播會關注播放是否流暢；直播還關注時延；緩存下載主要關注下載的速度。

第三，應用場景的多樣化。即使同一業務，也有很多細分場景，處理策略也存在差異。比如直播和點播有智能檔，緩存下載有邊下邊播，點播有倍速播放。不同的網絡類型，在處理上也會有所區別。

第四，視頻多，長尾視頻更多。

優酷有海量的資源，而邊緣節點的存儲是有限的，並不能所有資源都存，需要從中找最熱的資源存儲。
視頻格式多，不同的清晰度，會導致供源節點被稀釋掉，導致供給不足。
顯著的長尾特徵，大部分視頻的單日的播放量少，也需要處理方案。

二技術策略：雲邊端內容分發網絡

雲邊端內容分發網絡，簡稱 PCDN，它是以 P2P 技術為基礎，通過挖掘海量的碎片化的閒置資源，構建高品質低成本的內容分發網絡系統。

PCDN 是一個三級網絡加速體系：

一級是雲，也就是 CDN。
二級是邊緣網絡，包括邊緣節點，路由設備，商業 WiFi 等。這些節點不會直接參與消費，主要是作為供源節點，為其它節點提供上行。
三級是終端設備，這些設備是流量的主要消費者，其中一小部分能力強的節點，也可以為其它設備供源。

當有設備播放視頻時，PCDN 網絡就可以提供視頻加速，保證視頻穩定流暢的播放；通過合理地切換從不同節點的下載，讓成本降到最低。

從 PCDN 系統架構可以看出，雲邊端內容分發網絡分為三級網絡，涵蓋十多類節點，每類節點的上行能力，帶寬成本，存儲能力都各不相同。下面我們從帶寬成本，上行能力，存儲大小，節點規模，資源定位這五方面，對比一二三級各類節點的能力和特徵，最後給每類節點做出定位。

一級節點的上傳能力強、服務穩定，但帶寬成本很高，所以用它來下載必要的，緊急的數據。

二級節點的上傳能力比一級稍差，但 24 小時在線，能提供較穩定的服務，在某些條件下，可用來代替一級使用。

三級節點的上傳能力弱，存儲又小，也不能保證穩定在線。優勢就是規模大，成本低。可以通過多點下載，就近下載，將成本大幅的降低。

所以，根據三種節點特徵，揚長避短，最大化的利用每一類節點的優勢。比如，三級節點存儲小，要最大化利用它的上行帶寬，緩存頭部非常熱的資源。二級節點存儲大，能夠穩定供源，可以存儲中熱和長尾的視頻。

三 PCDN 底層基石：P2P 的基本原理

雲邊端內容分發網絡，底層用到 P2P 網絡技術，這張圖是一個簡單點的 P2P 模型：

節點 A 和節點 B 都看了《冰糖燉雪梨》的第 12 集，節點 A 先看的，觀看後本地會存有一部分數據，當節點 B 在觀看的時候，可以直接從節點 A，通過點對點數據傳輸的方式下載數據，不需要所有數據都從 CDN 下載。

在整個數據的分享過程，可以拆分成資源緩存、節點分配、下載調度和數據分享四個關鍵環節。

1 資源存儲

第一個環節，資源存儲。在這個環節中做了三事情：

如何標識一個資源？
將各類資源歸一化，切成一個個固定大小的分片。
決定哪些資源該存，哪些資源不該存？

資源標識

要標識一個資源，大家首先會想到的是 URL，但 URL 太長，在交互過程中不方便，並且會增加傳輸帶寬的損耗；另外，URL 中的很多可變元素，比如時間戳，鑑權信息等干擾信息必須去掉，否則會導致同一個視頻生成不同的資源 ID，不能相互分享。

優酷有一套資源 ID 的生成算法，會根據 URL 關鍵特徵信息，生成全局唯一的資源 ID，且長度小於 URL 長度，便於交互。

資源分組

第一，優酷有海量的視頻資源，有的文件很大，一旦超出緩存上限，就無法在本地緩存整個資源，無法做 P2P 分享，所以說要做切分。

第二，不同的視頻格式，比如 HLS 格式，會先請求一個 TS 索引文件，再依次請求每一個 ts。不同的視頻格式如果單獨處理，邏輯複雜度，且維護成本非常高。所以我們會在下載入口將視頻資源做分組，歸一成固定大小的文件，統一下載內核，簡化邏輯，減少維護成本。

第三，有助於提高分享效率。前面講 P2P 原理，節點 A 無需等整個視頻看完，前面的數據就可以分享。如果以整個視頻為單位進行分享，必須等整個視頻數據下載完成，效率就會非常低。

第四，提高緩存利用率。一個基本常識，如果將視頻按時間切分，每個時間點的播放數並不相同。例如片頭片尾，觀看的人非常少；另外，細心的同學會留意到，在進度條上方有很多劇情提示，精彩劇情會被反覆觀看。特別在綜藝節目中，當某位明星出現時，觀看的次數會明顯增多。而對不精彩的劇情呢，很多人會拖拽視頻，跳過去播放。所以，在切片之後，我們可以對播放量多的視頻多存儲，對於播放量少的視頻少存儲，從而提高整體的資源利用率和 P2P 分享率。

資源存儲

消費端在每個分片下載時，都會從服務端請求這個分片對應的節點列表，服務端就可以根據這個分片被請求的次數，來推算出大致的播放量。並且服務端有所有資源的被訪問記錄，就可以判斷哪些分片是熱門的，哪些是冷門的。邊緣節點在和服務端交互時拿到這個信息，來決定哪些資源該存，哪些不該存。

2 節點分配

第二個環節，是節點分配。在這個環節中包括節點篩選，節點調度和智能分配。

節點篩選

第一個是根據 NAT 類型過濾。所謂的 NAT 就是地址映射，是為了解決 IPv4 地址短缺的問題而引入的。大部分家庭網絡終端設備都是在路由下面，實際分配的是一個內網 IP 地址，訪問外網會通過 NAT 映射出一個公網 IP 和端口，我們常見的 NAT 類型有四種：全錐形、地址受限型、端口受限型和對稱型。其中“對稱型和對稱型節點”之前、“對稱型和端口受限型節點”之間的連通性是非常差的。所以，我們會根據 NAT 類型，將無法連通的節點過濾掉，提供返回的有效節點比例。

第二個是節點質量過濾。在大規模的節點網絡中，節點能力參差不齊，如果優質節點和質量差的節點混合在一起，就會增加端側節點質量評估的成本。因此需要過濾掉質量差的節點，提高返回節點的整體質量。

節點調度

第一個是就近原則。在距離維度上將節點劃分成 5 個範圍，範圍從小到大，依次是：鄰近節點，本市，本省，本大區，全國。其中鄰近節點主要，指同一個社區，企業，校園等。從數據上看，距離越近，速度越快，延遲會更低。

第二個是能力匹配原則。打個比方，節點 A 的上行能力是節點 B 的兩倍，那麼在分配次數上，按 2:1 的比例分配節點，這樣就能將 A 和 B 節點的上行能力最大化的發揮出來。否則如果按 1:1 的比例分配，可能會出現，A 的上行跑不滿，而節點 B 的負載過高等問題。

智能分配

前面的篩選和調度，主要是針對供給側節點信息的。而動態分配主要是針對消費側的信息的，就是消費節點在請求節點的時候，會上報一些當前請求的信息，動態計算出需要返回的節點個數，以及不同節點的比例。

第一個是清晰度，清晰度越高，需要的節點個數越多。

第二個是 buffer 水位，當 buffer 水位較低時，多分配一些高質量的節點，提高下載速度；當 buffer 水位較高時，多分配一些低成本的節點，降低帶寬成本。

第三個是，不同的節點按一定的比例返回，保證每一種節點都能分配到，同時也給端側一些決策空間。

3 下載調度

第三個環節，是下載調度。在這個環節中包括調度策略，節點管理和任務分配。

調度策略

在左邊這個圖形中，下面這個是播放進度條。這個點所在的位置就是播放點，播放點左邊的數據，是已經播完的數據，是藍色的線，播放點右邊灰色的這段區間是本地有緩存數據的區間，再往右這段，是將要下載的數據區間，這個點也叫下載點。

在下載調度上，我們的基本原則是：體驗優先，兼顧成本。

根據播放點後面，buffer 水位的高低，可以劃分成幾個區間，紅色這個區間，是緊急區，說明當前的 buffer 數據比較少，如果不及時補充數據，可能會影響播放體驗，這個區間內主要是從 CDN 節點下載，快速填滿 buffer；中間這個區間是過渡區，buffer 數據沒有那麼緊急了，可以讓一部分數據從二三級下載，如果，buffer 水位降低，可以繼續用一級下，如果 buffer 水位升高，則可以用二三級接管下載。最右邊的區間是安全區，可以全都走二級和三級下載。當然，這裡面會有很多細節的策略，比如這兩條水位線，並不是固定不變的，而會根據歷史卡頓情況，當前網絡質量，P2P 節點數和下載速度等，實時決策，動態調整的。

節點管理

首先是節點獲取，這裡為了節省和服務端交互的損耗，在上一個分片沒下完的時候，可以提前獲取下一個分片的節點，並且提前建立好一部分連接，等當前分片開始下載的時候，就可以直接發送任務請求。在每個節點的下載過程中，會根據節點的首包時間，下載速度，任務完成數量和質量等信息，給節點打分。最後任務會逐步收斂到質量好的節點上，而質量差的節點，就會被逐步淘汰掉。

任務分配

這裡面我們遵循多勞多得的方式，給下載速度快，完成質量好的節點，優先分配任務和分配更多的任務。同時，會監測每個節點當前的下載速度，RTT，提前預判後面的數據，是否會超時，如果預判會超時，就會提前回收任務，再分配給其他節點，而不會死等改任務超時。

4 數據分享

第四個環節，是數據分享。數據分享的過程，其實就是兩個節點之間建立連接，發送任務請求，供給端收到後，如果本地有數據，就會返回實際數據。最後在消費端會統一對數據數據做校驗，判斷是否被篡改，確保數據的一致性，這麼一個過程。

節點連接
這裡面重點講一下節點之間的連接，這裡說的連接主要指節點間的建立一種連通性，互相發包，對方能收到。節點間的連接主要有三種方式，有直連，反連和打洞三種方式，直連主要是用在對端是公網節點，可直接訪問的，比如大部分邊緣節點都在公網上，終端設備可以通過直連的方式訪問；反連主要是用在，己方在公網，可以直接被訪問，對端在 NAT 後面，這時候可以向對方的 Relay 發一個反連請求，由對端的 Relay 轉發給這個節點，再由對端發起向自己的直連，這種在己方在公網上，或者是全錐地址類型的時候，可以用。最後是打洞，這種方式，常用在兩個節點都在 NAT 後面。

數據傳輸

節點連通之後，主要就是協議交互和數據傳輸，這裡我們也自研了一種可靠的 UDP 傳輸方式，同時優化了裡面的擁塞控制算法，增加快速啟動，丟包預判，快速重傳等機制，讓傳輸更加的高效。

數據校驗

數據校驗是為了保證數據的一致性。在 P2P 網絡中，如果有髒數據是非常致命的，因為它會一傳十，十傳百，快速擴散到整個網絡中，汙染整個網絡數據。針對此，我們也有一套非常完備的方案，從磁盤存儲，上傳鏈路，網絡傳輸，下載鏈路等各環節都增加了校驗機制。

常見的校驗方法主要有 MD5，CRC 等。MD5 的安全性高，但性能開銷大，Crc 的安全性較弱，但性能開銷少。我們也採用了 MD5+Crc 相結合的技術方案，對關鍵數據做 MD5 校驗，對非關鍵數據做 crc 校驗，即保證數據一致性，又能最大化降低性能損耗。

通常情況下，劇集的熱度越高，越節省成本。因為熱劇的播放量大，供源節點多，分享效果好。但是，新片源並不適用這個規律。因為資源緩存需要一個時間窗口，很多熱劇熱綜都會選擇在晚間整點發布，用戶也會在發佈的第一時間觀看，而新發布的片源在短時間內，並沒有那麼多供源節點。在這一時間窗口內，供需非常不平衡，P2P 分享率也比較低。

針對此，我們採用了智能預推和快速回源方案。所謂智能預推，是綜合前幾集的播放量，同類視頻播放量的變化曲線，以及地區，運營商，清晰度等維度的播放信息，計算出需要往哪些地區的邊緣節點，推送多少副本數，在新片上線前，提前推送下去。

所謂快速回源，主要是針對不容易預測的，短時間內訪問量突然增加的資源，通過回源到邊緣節點，讓邊緣節點快速下載整個視頻，對之後再觀看視頻的節點進行加速。

通過這兩個方法，熱門劇集上線時，就不用擔心沒有供源節點，或者供源節點不足，導致分享率低。

大型直播主要指大型活動、體育賽事直播，比如像雙11 貓晚、春晚，國慶閱兵直播、世界盃直播等。

直播和點播的場景差異較大，挑戰也比點播大，主要表現在幾個方面：

首先是低延時。為了減少直播時延，在直播場景中實時能拿到的數據量非常有限，並且大家的播放點都是接近的，可供分享的數據非常少，所以會導致整體的供源節點不足。
其次是 buffer 水位低。因為數據量有限，一般只能拿到 2-3 個 ts，時長只有幾秒到十幾秒，這對調度的要求非常高。前面提到的點播的緊急區水位，在幾十秒用來抗網絡抖動，但是直播不會有那麼多 buffer。所以如果調度策略不合理就很容易造成卡頓。但前面讓出的 buffer 水位過多，又會減少 P2P 分享。
第三是高動態。對於點播來說，只要這個設備已經緩存了該資源，那麼不需要用戶在線看這個視頻，也可以對外分享，和用戶行為無關。但是，直播場景並不是這樣的，在直播場景中一旦退出直播間，這路流的數據就斷了，就不能再為其它節點供源。而在直播過程中，進出直播間是很常見的。

為了提高直播整體的分享率效率，這裡我們重點引入了邊緣節點。一是將邊緣節點作為供給，邊緣節點的服務相對是比較穩定的；其次，是邊緣節點在數據內容的更新上，會和 CDN 保持高度同步，在大部分情況下用來代替一級。

四實戰經驗分享

對於大型複雜的網絡系統，需要學會從點線面體不同的視角去看系統，從大到小，層層深入，同時又能夠跳出系統，看到系統整體的內外部環境，上下游交互。總體上，需要去理解整體系統的業務模式和運作原理。在面上，需要去熟悉系統各個面的劃分和交互，比如 PCDN 裡面就包含了調度面，管控面，業務面，基礎服務等等。在線上，需要去拆解每個面上的基礎功能模塊，以及不同層級的劃分，比如業務面上，有上傳，下載，發佈等等。在點上，需要深入瞭解每個技術點，算法策略等等。

首先，面對一個複雜的網絡系統，第一步要做的就是拆解。將一個系統，拆分成幾個子系統，明確每個子系統的職能，輸入是什麼，輸出是什麼。當然，光拆解還不夠，要對每個子系統定義出指標，用來反應系統的優劣，並將所有的指標通過數據和報表展示出來。這樣就能看到整個系統的全貌，以及哪裡有瓶頸。

其次，技術一定要與業務深度融合，才能發揮最大價值。例如，前文提到的倍速播放，如果在下載調度決策時，不能準確獲取播放的倍速信息，就可能誤判，導致原來需要從 CDN 下載的時候，沒有去下載，造成卡頓。

最後，建模和快速迭代。在整個 PCDN 網絡系統中，有很多的場景和功能都可以抽象成日常生活中的模型，例如下載調度算就像一個蓄水池模型，節點調度其實是一個供需模型等等。當建立好模型後，還需要及時的反饋，這其中有很多方式，可以通過壓測，用大量樣本去訓練，還有分桶驗證等其他方式，通過這些方式去判斷模型的優劣，以及找到模型當中各參數的最優解。

福利來了 | 電子書下載《文娛音視頻核心技術》