文章目錄

• • 1、下載策略優化
  • • CDN選擇策略
    • 錯誤處理策略
    • 碼率選擇策略
  • 2、協議和架構優化
  • • HTTP2
    • TCP變種擁塞控制
    • QUIC
    • 架構

流媒體協議的選擇與分發體系架構的設計對優化起著關鍵作用。

HLS和DASH協議在點播和OTT直播服務中已逐漸占據主流，其思想主要是將視頻轉為不同碼率并切為較小的片段，將流媒體分發從服務器推送轉向客戶端以HTTP下載方式獲取，在此情境下，客戶端下載策略是技術優化的重點，主要集中的方面：

• 1、視頻鏈路的選擇和切換策略
• 2、視頻下載的預請求、并發策略和錯誤處理策略
• 3、視頻碼率的選擇和切換策略

1、下載策略優化

早先視頻服務的下載策略多由工程師憑經驗設置，基于IF…ELSE…構造邏輯，但隨著各家公司工程水平的提高，許多團隊開始使用較復雜的算法作為下載策略，以爭取QOS上出色的表現。

當前通用的做法是將策略組件化，且針對不同平臺和場景使用不同的算法，持續上線A/B測試并觀察數據表現，根據結果進行頻繁迭代。

CDN選擇策略

對于流量方面，常見的做法是將大部分流量由自有CDN提供，少部分流量由第三方CDN承擔，作為削平峰值的手段。小公司無自建CDN，往往使用幾家不同的CDN并將流量在其間調配，這樣做的好處是：

• 一則避免路徑鎖定；
• 二則保障流量安全；
• 三則可對服務質量有所比較，汰弱留強。

自建CDN的流量調配，其策略通常是在知曉用戶的地理位置和網絡狀況后，結合節點的位置和負載情況，按規劃問題求解。

在混合架構下，既然客戶端進行播放時有多個CDN可供選擇，與多CDN的情況下所依據的信息較少，大多數第三方CDN并不允許指定邊緣節點，視頻服務將動態監控不同情況用戶（可依據地理位置，網絡狀況等特征分類）在某CDN獲取服務的質量，并據此推斷特定用戶應由哪個CDN服務。

下圖是多CDN切換邏輯：

流量調配可以具備多種策略并能在不同策略件平滑地進行切換，如基于成本的策略、基于質量最優的策略、基于ISP的策略等，其中或許還需要更多約束條件，例如調配一定數量的請求，保證所有CDN均處于緩沖完備的狀態。

錯誤處理策略

在視頻播放期間發生某一碼率的下載失敗時，優先嘗試較低碼率下載或可解決問題，若所有碼率的片段均不能正常下載，可嘗試播放前方的片段。當源站的流媒體服務正常，但用戶在某一個CDN無法正確獲得服務時，轉向另一CDN提供的資源可以讓播放繼續。倘若遇到特殊情況，如下載速度非常緩慢，帶來多次緩沖，卻并未失敗，則需要跟蹤下載進度，并為何時放棄，切換下載目標或CDN的判定設定合理規則。

對于直播來說，錯誤處理的方式要更加細致。

若我們對丟失的視頻片段簡單跳過，將導致播放位置過于靠近Edge，從而帶來大量短促的緩沖。解決方法是：除了設置恰當的緩沖長度外，還可以使用特別的視頻片段（如無節目片段）卻帶丟失的片段。

碼率選擇策略

為追求更高的視頻質量、較低的緩沖次數和時長，給予用戶清晰流暢的觀看體驗，一個好的ABR（Adaptive Bitrate，即碼率自適應）算法非常重要。

ABR技術理論上可以構建在任何支持多碼率的流媒體協議之上。

下面是一個會話中碼率動態切換的示意圖：

ABR算法設計的出發點有基于帶寬估計、基于緩沖區長度、混合帶寬估計和緩沖區長度等方向，代表性算法包括：

• 移動平均線：移動平均線，即將段時間內的數值連成曲線，用來顯示歷史波動情況，當有多條不同區間的移動平均線，且平均線之間發生穿越時，可被視為超勢發牛變化的信號。
• 卡爾曼濾波：Kalman Filter即卡爾曼濾波，算法基于隱馬爾可夫模型，能從一系列不完全及包括噪聲的信息中估計動態系統的狀態，它根據各個指標在不同時間下的值考慮其聯合分布，再產生對未知量的估計，算法常用于航空航天技術的導航空制和機器人的運動規劃等領域，廣義的卡爾曼濾波算法包括擴展卡爾曼濾波和無損卡爾曼濾波等。
• CS2P：C2SP又稱Cross Session Stateful Predictor，是在iQiyi數據的基礎上提出的利用HMM模型進行預測的算法。
• BOLA：BOLA，是基于緩沖區長度估計使用Lyapunov優化的一種算法，在Github上有開源的參考實現。
• MPC：MPC，即Model Predictive Control,是種綜合帶寬估計和愛沖區長度的算法。

下面是Netflix的ABR算法

2、協議和架構優化

HTTP2

HTTP2已得到大部分CDN公司、瀏覽器、反向代理的支持，眾多視頻網站也在逐步推進中。HTTP2沒有改動HTTP的語義，但包含了大量新特性，如對HTTP頭進行數據壓縮、服務器端推送，請求Pipeline化、對數據傳輸采用多路復用等。

建立TCP連接的耗時常常達到數百毫秒，HTTP2將TCP連接分為若干個流，每個消息由若干最小的二進制幀組成，對新頁面加載的加速十分明顯。協議引入HPACK算法，令客戶端與服務器維護相同的靜態字典和可添加內容的動態字典，以哈夫曼編碼減小頭部大小。HTTP2引入的服務器端推送，允許服務器提供瀏覽器渲染頁面所需的資源，無須瀏覽器收到并解析頁面之后重行請求，同樣節約了加載時間。

TCP變種擁塞控制

TCP協議的擁塞算法常年為人詬病，當網絡存在丟包時，TCP連接速率將被大幅度調低，若丟包并非由持續存在的因素導致，實質導致了對帶寬的巨大浪費。

（TCP擁塞控制算法與路由器中的主動隊列管理(AQM)模型息息相關，路由器中簡單的隊尾丟棄方案存在多種問題，如果增加預測環節，使得緩存耗盡前有計劃地丟棄一部分分組，提早通知發送方降低速率，這就是AQM地核心思想。TCP的擁塞控制大致可以分為基于丟包反饋的協議，如Tahoe Reno、HSTCP、CUBIC等；基于路徑延遲反饋的協議，如Vegas、FAST TCP、Westwood等；基于顯式反饋的協議，如ECN、XCP等）

Serverspeeder（即銳速）是常用的TCP網絡加速軟件，可在Linux、Windows服務器上使用，不論網站，還是CDN節點，均可借此大幅提高網絡傳輸速度。另一個知名的優化方式是Google非官方提出的BBR算法，它在RTT（往返時延）增大的時候并非馬上降速，而是保持最近的最大速率進行發送，且在有空閑帶寬時加速搶占，但缺陷是減速收斂較慢，也并不適合深隊列的情形。

QUIC

使用QUIC協議而非TCP協議是近年來一些公司的嘗試，這是一個由Google倡導并正在標準化的，構建于UDP協議之上的傳輸層協議，并可能得到DASH協議的支持，其設計旨在：

1、減少握手數據包、

2、支持前向糾錯FEC（FEC即Forward Error Correction，前向錯誤更正，通過增加元余信息，在發生錯誤時，無須通知發送方重發即問進行錯誤恢復，用于流媒體傳輸時，可將N個音視頻包異或得到新包插入流中，代價是流的大小變為(N+1)/N倍。）

3、支持會話的快速重啟和并行下載等

最近被重命名為HTTP3。

QUIC協議在快速連接、弱網狀態下的下載速度、網絡類型切換時連接的保持等方面都頗有優勢

架構

對于點播和直播，在CDN的邊緣節點上予以緩存是提升包括啟動時間在內的傳輸性能的首要步驟。

對于CDN而言，根據熱點預測將視頻的初始片段（一個完整的GOP）預先緩存到和邊緣服務器僅為常規手段，視頻網站可以根據數據預測的結果將熱門節目的完整內容主動加入緩存。

此外，由于長視頻模式的服務通常版權節目數量不過百萬級，若條件允許，可于所有節點服務器中維持持久化的緩存，至少囊括冷門視頻在內所有節目的起始片段，以此提高用戶體驗，在存儲成本低廉的當下十分劃算。

在自建CDN的場景下，無疑可以從數據預測所有內容的訪問熱度以及根據用戶確認訪問的分布，按照預測結果進行預熱。由于每個視頻均存在不同碼率，此時將各碼率內容視為不同的文件預測可能得到更好的結果，理論上，可以將節目片段的觀看熱度、電影的宣發計劃等均納入考量。在規模較大的視頻服務商的體系中，約束條件可能還包括在不同的子集群的狀態是否健康，子集群和整體的流量是否平衡。

對OTT直播節目來說甚至不需要以上步驟，將頻道主動推送至邊緣節點，而非待用戶請求再自源站拉取，就可以改善首批用戶的體驗，并降低延時。

完整的播放請求中，資源獲取、鑒權等工作通常需要訪問源數據中心，對啟動時間等指標存在多重影響，在自建CDN場景中，許多服務均可被前移至邊緣節點予以加速，常見的如轉碼服務，在直播場景下節目流上傳的節點不需要設置為源站，而可以在任意邊緣節點接收、轉碼、再行分發，如果進行得當的設計，DRM許可、廣告投放等服務也并非不能部署在邊緣站進行加速。

在游戲、秀場直播場景下，當前仍由非HTTP協議占據主流，視頻傳輸以RTP或相似的協議為主，網絡層協議選擇UDP，由于UDP的非可靠性，此時對丟包可采用FEC或帶外重傳的方式。在傳輸過程中，由于大于MTU[插圖]的包將導致IP層分片傳輸，通常的策略是將音視頻幀按略小于MTU的大小切分成RTP包，有些公司認為路由器存在小包優先的策略，因而在擁塞嚴重的網絡環節下對切分上限設置在靠近MTU除以2的位置對傳輸較為有利。

與HLS或DASH播放時，對直播視頻片段來說，若無法下載，則嘗試其他碼率或下一片段相似，在RTP環境下，服務端應監控傳輸狀況，主動切換合適的碼率，丟棄超時的幀乃至整個GOP，播放器也應在緩沖區過長的情況下采用丟幀方法追趕進度。