作者| 阿里文娛高級技術專家 木暮
一、背景
2019 年，整個互聯網的絕大部分流量來自於視頻服務，優酷，每日承載了上億用戶的幾十 億的視頻觀看，每日消耗的互聯網流量高達 Pb 級別。在如此高併發高流量的項目中，如何在保 障用戶體驗的前提條件下，有效的提升服務器以及帶寬的利用效率，實現消峰填谷，降低服務 器和帶寬成本，成為我們技術人的工作重心。
二、痛點與挑戰
每天晚上，為了保障所有用戶的流暢高清的觀看體驗，至少需要幾十 Tb 的高峰期帶寬， 這會帶來哪些問題呢？
1. 服務器數量大
按照單臺服務器萬兆的輸出來保守估算，至少需要幾千臺服務器，還不包括交換機等設備， 無論網絡的搭建還是維護，成本非常高。
2. 帶寬成本高
商業帶寬成本非常昂貴，按照幾十 Tb 來進行帶寬採購，費用將是天文數字。
3. 資源利用效率低
白天使用的帶寬，可能只有晚高峰的十分之一，將造成巨大的資源浪費。
三、PCDN 核心設計
PCDN 是阿里自研的以 P2P 技術為基礎，通過挖掘、利用、整合邊緣網絡而構建的內容分發網絡。通過 PCDN 的服務，能獲得同等甚至高於 CDN 的內容分發質量，同時顯著降低分發 成本，尤其適用於視頻點播、直播、文件下載等業務場景。
接下來，我們分別來闡述一些系統核心模塊的設計思路與實現方案。
1. 三級分發體系
整個 PCDN 分發網絡，由雲+邊緣節點+端的三級網絡組成。PCDN 採用同一套跨平臺的代 碼研發，消除了在不同終端上的差異性。另外在二級邊緣節點和三級的端之間，協議可以互相通信。
雲：包含 CDN 節點、播控、Tracker、Stun、Push 等服務。
邊緣節點：包含類玩客雲、類優酷路由寶、合作節點、礦機、運營商 MEC 等邊緣節點。
端：包含 PC(Windows、Mac)、手機（iPhone，Android Phone）、平板(iPad，Android Pad)、
OTT 等日常使用設備。
2. 統一的資源編排
對於 PCDN 網絡中的任何一個資源，無論是單一的視頻、文件，還是一路直播流，又或者 是一個 HLS 的播放列表，制定一種統一的、超越文件格式的資源編排方式是高效分發的基礎。 在優酷，我們提出了主資源ID+子資源 ID 的方式來構建資源的編排。
1）主資源 ID
對於任何的一個視頻/文件/直播流來說，主要資源 ID 是一個唯一的類 guid 格式的字符串(例如EADCAB58E5664965A9C3201D72F816CF)。
2）子資源 ID
對於某個視頻/文件/直播流來說，按照我們預定的規則（大小切分或者時間切分），邏輯切分出來的每個傳輸段落，我們在主資源 ID 後面加上 0001、0002 來順序生成每個子資源 id(例如EADCAB58E5664965A9C3201D72F816CF0001)。子資源 ID 不僅可以獨立作為 PCDN 網絡中唯一標識進行索引，同時，在必要的時候，雲端也有能力可以通過主資源 ID 來感知每個子資源ID 對應內容之間的聯繫和分佈。
3. 運營商地域的節點調度
1）運營商隔離 當節點充足時，會完全隔離某個運營商，在該運營商內部進行地域優先調度；當節點不夠時，依然會跨越運營商，儘可能的去尋找全網中所有的網絡供源節點。
2）地域就近優先 地域優先的節點調度策略，不僅有效的提升了節點間的傳輸速度，降低了丟包，而且從宏觀來看，降低了骨幹網絡傳輸壓力和運營成本，也減少了因大量的跨運營商的流量而被封 P2P的流量，最終提升的整個 PCDN 網絡的數據分發效率。
服務端會根據接入節點的地域，優先分配內網/社區等鄰近節點，其次會選擇同一個城市、 同省份、同區域（華東/華北等）、最後是相同國家的節點。
4. 連接機制
由於互聯網的 Ipv4 地址緊缺，所以絕大多數設備會在路由器的背後，使用內網地址進行通 信。因此，為了實現較高的連接成功率，這裡我們按照標準的 STUN 協議實現了點對點的 NAT 穿透，這裡就不花較大的篇幅來闡述。但是由於視頻播放屬於多對一服務，即多個節點為一個 節點服務，因此，我們的思路重點放在了全局的連接成功率：
1）如端口受限型-對稱型、對稱型-對稱型連接的情況，在 Tracker 服務端分配的時候，刻 意避開理論上無法連接、以及需要花費很大成本才能連接的情況；
2）客戶端上報 ip 段到 ip 段的連接成功數據，後端大數據計算之後，排除掉成功率較低的ip 段連接；
3）實現 upnp；
4）對於判定可以直連的連接，tcp 和 udp 同時發起連接，哪個先連上用哪個。
5. 高效傳輸通道
PCDN 作為一個在線數據分發網絡，最重要的就是點對點之間的傳輸通道，傳輸性能的好 壞直接決定了網絡的效率的高低。作為整個網絡中最基礎最核心的鏈路傳輸，我們基於 UDP 協 議自研了可靠傳輸機制，並且作出了一些改進：
1）快速啟動
根據連接過程的協議包，判斷出 RTT 和兩包間隔，從而快速的確定初始的發送窗口。例如 兩包間隔在 50ms，那麼窗口的初始值可以設定為 20（1000ms/50ms），如果兩包間隔特別小隻 有 1ms 的話，也可以設定一個上限閾值。在後續的傳輸過程中，速度越快，窗口越大。
2）丟包預判+快速重傳
傳統的丟包重傳算法，會根據端到端的 RTT 來進行判斷，當某個包在超過平均 RTT 或者 最大 RTT+閾值時，可以認為丟包，這時候會啟用丟包重傳。
在丟包重傳的技術上，我們還做了一些丟包預判+快速重傳，發送端發送了 1,2,3,4,5 幾個包， 然後依次收到遠端的 ACK1，ACK3 和 ACK4，當收到 ACK3 時，知道 2 被跳過 1 次，收到 ACK4 時，知道 2 被跳過了 2 次，此時可以認為 2 號丟失，不用等超時，直接重傳 2 號包，大大改善 了丟包時的傳輸速度。
3）非延遲 ACK
TCP 為了充分利用帶寬，延遲發送 ACK，這樣超時計算會算出較大 RTT 時間，延長了丟 包時的判斷過程，也延遲了發送窗口的移動。由於 ACK 包體積較小，我們採用了立即發送 ACK， 快速發現丟包，快速促使傳輸窗口移動。
6. 自適應調度狀態機
在整個播放過程中，如何根據當前的播放狀態、網絡環境，作出使用一級 CDN，或者是二 級邊緣節點、又或者是三級端側下載的決策呢？這裡，我們的最佳實踐是依據可供播放的 buffer 水位來進行決策。
我們主要設定了 3 個區域，按照播放進度條上的當前播放位置的距離由近及遠依次為緊急 區、過渡區和安全區：
1) 緊急區（紅色區域）
當可供播放的 buffer 水位在這個區域時，網絡的任何抖動都有可能造成用戶的卡頓，因此 在這樣的情況下，我們的調度狀態機會使用一級 CDN 進行下載。
2) 過渡區（黃色區域）
當可供播放的 buffer 水位在這個區域時，網絡的抗抖動能力略微增強，這時調度狀態機會 傾向於同時使用二級邊緣節點和三級端側節點同時進行下載。
3) 安全區（綠色區域）
當可供播放的 buffer 水位過渡區時，抵抗網絡抖動的能力已經比較強，對數據的時效性要求可以適當放低，這時調度狀態機會完全使用三級端側節點下載，分流服務器帶寬。
7. 自適應的磁盤緩存算法
為了最高效的發揮出端側供源能力，就必須保證所有的分佈式的磁盤緩存的內容必需符合 流量的請求分佈，即熱門資源的副本數多，冷門資源的副本數少。我們定義了一個參數叫做稀 缺值，端側的資源的存儲、淘汰都會以稀缺值為依據，基本上可以大致的達到符合流量的請求分佈狀態。
當稀缺值<閾值時，請求數很多而副本數很小，這時會積極的去緩存文件，提高副本數； 當稀缺值>閾值時，副本數太多而請求數太少，這時就不在繼續存儲新的副本，同時會加速淘汰多餘的緩存副本。
8. 精準的預先推送
利用非高峰時間離線分析用戶行為等數據，並將分析預測後的結果推送至二級三級網絡， 我們主要根據新上線的熱度片源和基於用戶觀看行為進行預推：
1) 當日新上線熱片的預推
熱片的上線，往往會由於副本數小，請求量大而對PCDN 網絡衝造成衝擊，因此為了避免衝擊，會在當日新上線之前，進行預推，使副本數達到一個預估合理值。
2) 基於用戶觀看行為的預推
a) 某用戶觀看連續觀看某個節目，並且最後一次觀看到第 N 分鐘，則主動推送第 N 分鐘 之後的內容；
b) 某用戶觀看某個電視劇的 1-N 集，則主動推送第 N+1 集。
9. 基於業務模式的配置變更
由於 PCDN 的業務涉及到播放和下載等業務，因此在不同的業務模式下，配置的參數、計算的算法，都應該是要有差異的：
1) 下載模式
對於下載來說，追求極限速度，因此會放大丟包超時，容忍亂序收包，降低重複包，達到最大的峰值下載速度。
2) 播放模式
在 buffer 水位比較短缺時，為了避免卡頓，追求下載數據的連續性，因此在下載數據由於 空洞造成不連續的時候，會採用丟包預判+快速重傳，通過適當的增加重複率來換取數據的連續 性；當 buffer 水位充足的時候，這個時候其實又轉化為了下載模式，追求極限的峰值下載速度。
四、技術成果與商業化
1. 優酷側
大幅度降低服務器、帶寬成本，接入 PCDN 平均可以降低 80%以上的服務器帶寬成本，消 峰填谷效果明顯(見下圖，實際需要的服務器帶寬與真實消耗的服務器帶寬)。
2. 阿里雲側
將 PCDN 的能力對外部客戶進行輸出。用戶通過集成 PCDN SDK 接入該服務後，能獲得等 同或高於 CDN 的分發質量，同時顯著降低分發成本，詳細請參考阿里雲官網。
五、思考總結
PCDN 是一個綜合性強、龐大、複雜的系統，從業務來說，有點播，直播和文件下載，從架構看，服務器有網關、Tracker、Stun、推送、配置等服務，客戶端不僅僅需要考慮全面跨終 端，而且還有連接、傳輸（下載、上傳），存儲等模塊，從對開發人員的要求來說，PCDN 整套 系統也涵蓋了大多數互聯網從業者的技術棧，既有服務後端開發、也有客戶端的底層技術、還 涉及移動端跨平臺 SDK，音視頻多媒體技術，網絡技術等等，這件事情要做到極致，絕對不容易。
除了上述的這些剛需組件的開發，更多的是需要去考慮如果對分發數據的抽象、邏輯建模， 另外，整個系統的參數眾多，每個模塊都是牽一髮而動全身，如何去保證整體的最優也是需要在一步一步摸索中才能悟出一些經驗。
在實現細節上，並沒有標準的做法，參數也沒有絕對的好壞，在業界每家都需要根據自己 業務進行深度的考量和優化。評價優劣的指標維度眾多，從宏觀來說，通常以分享率和卡頓率 為參考，從微觀來說，就涉及連接成功率，單點平均速度，緩存分佈質量等等，而且每個指標， 也沒有固定的標準。不同的業務形態，評價標準不盡相同，例如分享率指標，在 A 模式下，可 能 80%都算低，但是在 B 模式下，50%都很高。在這一點上，還是需要我們的開發同學不斷去重構系統的每個鏈路，逐點提升。
未來隨著 4K、5G、Ipv6 的來臨，對 PCDN 來說，既是機會，也有挑戰。以視頻為載體的 網絡流量會越來越大是機會，對清晰度、傳輸速度等要求不斷提升是挑戰。我們也在積極的探 索基於運營商基站、大型購物中心、地鐵站、社區等更細粒度的流量調度服務，另外隨著智能 硬件也越來越多的走入了千家萬戶，邊緣節點正在逐步增多，如何更高效的去構建這樣一張更 高密度的邊緣計算網絡也是我們正在研究的方向，同時，我們也會繼續深挖新技術，在資源發 現、網絡構建、任務分發、數據傳輸等各個環節不斷去嘗試、創新、突破，提供更高質量的 PCDN 服務。