基於應用理解的協議棧最佳化

阿里雲影片雲發表於2023-03-09

作者:餘兵

移動網際網路時代,不同的應用追求的產品體驗差異性很大。

應用商店和圖片等下載型別業務追求速度、越快越好,短影片關注起播、拖拽響應速度和觀看過程卡不卡,直播追求畫質清晰、高位元速率和直播過程流暢;而遊戲則是追求低延時,網路穩定、不掉線。

如何保障不同型別應用的差異化產品體驗是移動網際網路時代的一個巨大的難題。

01 傳統協議棧技術與不足

協議棧是底層通訊技術,處在 OSI 模型的第四層,協議棧最佳化技術旨透過克服協議缺陷和改良協議機制,提升內容分發效率,改善產品體驗。

傳統的協議棧最佳化思路是以“快”破萬法,追求速度的極致,從速度視角去解所有應用的產品體驗問題,這對於下載類似的業務適用,但對於直播、點播和遊戲等業務確是不適用的,會出現產品體驗不好的現象。

點播和直播關注卡不卡、流暢與否,最核心的技術是保障播放器快取不空,持續不斷的有資料播放,和傳輸速度快慢並無直接關係;遊戲信令關注低延時,對頻寬需求量很小,但對丟包和網路抖動及其敏感,對於丟包感知、丟包恢復技術要求極高。

顯然,速度的解法,並不能滿足移動網際網路下所有應用產品體驗需求,協議棧最佳化技術需迭代要升級。其中最重要、最核心的技術是協議棧理解應用,理解應用的傳輸特徵、理解應用關鍵體驗指標、理解關鍵體驗指標背後的效能瓶頸,及其造成效能瓶頸的影響因素個各個影響因素貢獻的權重比例。

除了理解應用外,協議棧最佳化技術還需要擴充套件與延伸協議棧對應用傳輸過程的感知能力,感知結果與應用傳輸特徵匹配,再定製差異化的擁塞控制和丟包恢復演算法。

02 理解應用的協議棧技術

基於應用理解的協議棧,首先要理解不同應用的傳輸特徵、關鍵體驗指標、關鍵體驗指標背後的效能瓶頸,及其造成效能瓶頸的影響因素和個各個影響因素貢獻的權重比例;其次是對應用總結、分類,分成不同的業務類別,最後再針對不同的業務分類性的設計不同的演算法策略。方案的核心思想是用不同的演算法解決不同應用場景的產品體驗最佳化。

應用分類和解法

阿里 CDN 最近四年,一直在協議棧技術智慧化道路上探索,基於應用理解的協議棧技術是協議棧智慧化的技術基礎。針對阿里雲 CDN 平臺 130T 的業務規模做應用分類,分類規則依據兩個維度:應用傳輸特徵(不同的應用在業務特徵的差異性會反饋到傳輸行為上)、應用關鍵體驗指標(關注速度、卡頓率、低延時等不同的體驗指標),最終將所有應用分成四類業務:信令業務、下載業務、點播業務、直播業務。

l 信令業務

信令場景的傳輸特徵是互動式、低延時、資訊量少,比如遊戲對戰類、網站訪問類、釘釘、微信等 IM 通訊工具文字和語音通話類業務。關鍵的應用體驗指標是低延時、網路穩定、不抖動、不閃斷,所以信令業務的產品體驗最佳化解法是弱擁塞控制,強丟包恢復。最核心的最佳化要領總結為“快傳傳補”,“快傳”是指快速的將資料包文傳送到網路中,“快補”則是在擁塞檢測、丟包恢復技術上及時、實時,只有如此才能達到低延時的應用體驗需求。

協議棧技術本質上是一種攻防技術,貪心的擁塞控制是進攻,負責“免疫”的丟包恢復是防禦,進攻與防禦並存,順風時進攻,逆風時防禦,信令場景最佳化要領“快傳快補”正是如此。協議棧的最佳化策略必須攻防兼備,設計進攻策略時,同樣需要設計輔助的防禦策略,一個優秀的擁塞控制演算法,必定配套了一個優秀的丟包恢復演算法,只有這樣才能將協議棧技術演化到極致。

l 下載業務

下載場景特徵為資料量大、追求下載速度,需要的頻寬量大,期望壓著可用頻寬跑,充分利用鏈路可用頻寬,典型的應用有應用商店的 APP 下載,大檔案下載、高畫質圖片下週、手機作業系統升級包下載等。下載應用關鍵的體驗指標是下載速度、下載耗時,所以下載業務的最佳化要領是“擁塞控制、細水長流”,持續不斷的做好頻寬估計,持續不斷最大化利用鏈路探測頻寬,才能保障下載類業務的產品體驗,短視的突破、取巧難將效能做到極致。

l 點播業務

點播場景特徵為靜態的影片檔案流(快取在 CDN 邊緣節點)、不關注下載速度,關注影片播放卡不卡,影片起播和拖拽響應速度,比如行業手淘、快手、抖音、小紅書、優酷和螞蟻支付寶第三 tab 頁等平臺上提供的短影片點播業務。關鍵體驗度量指標是卡頓率,卡頓是播放器的行為,保障播放器快取不空,持續不斷的有資料播放是點播場景最佳化的關鍵難題。

l 直播業務

直播場景特徵為實時流、頻寬需求量不大但有突發(和影片編碼技術有關)、對網路丟包敏感、不關注下載速度,關注播放過程流暢與否,比如行業的手淘、快手、抖音、虎牙、鬥魚等平臺上提供的直播業務。直播業務的關鍵體驗是播放流暢、不卡頓,與點播業務的最佳化要領相似,區別是直播為實時流,阿里 CDN 的最佳化思路是弱擁塞控制,強丟包恢復。

基於應用理解分類,阿里雲 CDN 設計了一個協議棧演算法容器,包含四大主演算法,分別覆蓋信令業務、下載業務、點播業務和直播業務,每個主演算法包含三個子演算法,提供了低中高三個不同等級的分級服務,最終滿足各種應用的產品體驗改善需要。

協議棧演算法容器

區別於原始 Linx 核心的演算法模式——將不同思想、服務不同場景的演算法設計為獨立演算法,阿里 CDN 結合應用中心式、統一管控需求,也為了能讓演算法和應用更加靈活匹配,我們使用了一種新模式,設計了一個演算法底座,底座上生長了 5 個主演算法,主演算法提供低中高三種不同級別的分級服務,最終形成了演算法容器。

演算法容器的構建邏輯如下:

首先,通用能力抽象、底座化,抽象擁塞控制和丟包恢復技術作為演算法容器的底座。擁塞控制和丟包恢復是協議棧最核心的兩大技術,近乎 95%的協議棧最佳化工作都集中在此。擁塞控制類別人的心臟,透過頻寬估計和頻寬使用,控制整個協議棧的啟停;丟包恢復則類似人的免疫系統,當網路出現擁塞或出現丟包時負責免疫修復。

其次,通用能力靈活、彈性化,不用的場景分類對擁塞控制和丟包恢復依賴有差別。比如直播對於擁塞控制的依賴比較弱,直播為實時流,需要頻寬量相對固定,貪心式的擁塞控制算對直播產品體驗最佳化效果弱,但是對於丟包恢復的能力要求很高;下載業務對於擁塞控制的能力要求極高,需要擁塞控制演算法盡力而為,丟包恢復技術要求一般;再如信令業務,對頻寬的需求趨於無,但是對丟包恢復的能力要求極高。擁塞控制和丟包恢復通能力靈活、彈性後,場景分類演算法可以按照自己的需求選擇能力等級。

再次,場景分類主演算法設計,主演算法設計包含兩部分關鍵類容:第一是基於應用場景特徵的理解決策使用通用能力等級(擁塞控制和丟包恢復能力),第二部分是基於場景傳輸特徵和效能瓶頸,迭代專用策略。

最後,演算法服務分級的能力(阿里雲 CDN 設計了低、中、高三檔能力,演化為三個子演算法),不同應用對於產品體驗的要求有差異、對質量的敏感度也有差異,利用這種差異構建服務分級的能力,可以實現產品體驗和成本雙贏。比如 CDN 系統內部的日誌回傳對實時性要求不高,可以給予最低檔的最佳化服務;比如點播、直播、遊戲等業務對產品體驗要求非常高,可以給予最高的的產品體驗最佳化;又比如 CDN 內部管控類服務對質量的敏感適中,給予中間檔位的傳輸服務。

阿里CDN演算法容器圖
阿里CDN演算法容器圖

能力產品化交付

技術能力交付的方式有很多,演算法容器遵循了產品化模式交付標準,有如下功能或特性:

域名維度演算法配置,支援不同域名配置不同演算法:

l 支援域名維度國家、省份、運營商、節點、時間組合維度的演算法配置,可以靈活的組合使用演算法

l 域名策略 web 化配置、點滑鼠實現域名演算法配置

l 域名策略 web 化管理,提供網頁式域名演算法管理能力

l 域名演算法分鐘級生效,配置動作觸發下發邏輯,分鐘後生效

l 演算法策略到核心態,系統標準化 API,接入閘道器改造簡單、輕量

03 未來展望與規劃

移動網際網路時代需要的是基於產品體驗的協議棧最佳化技術,基於資料傳輸的最佳化技術只是資料包文的搬運工,是缺少靈魂的、行屍走肉的,無法理解應用傳輸特徵和產品體驗需求,難以滿足存量和爆炸式增長的 APP 應用需求。

基於資料的傳輸和基於產品體驗傳輸,中間差了一個協議棧智慧化技術。正如文章中提到觀點,基於應用理解的協議棧最佳化是協議棧智慧化的基礎技術,應用理解的協議棧最佳化技術是我們在智慧化道路上邁出的第一步,但不是最後一步,我們仍在路上。

我們的目標是讓協議棧最佳化技術理解應用、給協議棧技術植入智慧化基因、用智慧化的思路設計產品體驗的傳輸技術,最終解決移動網際網路下各種應用的產品體驗最佳化問題。

注:文中的出現的協議棧關鍵詞,如果沒有加限定詞,特指 TCP 協議棧。

相關文章