Darren Ng

除了巨大的流量壓力和激增的網(wǎng)民數(shù)量，智能手機、平板電腦和筆記本等設(shè)備種類逐漸豐富；傳統(tǒng)的瀏覽器和新興的移動應(yīng)用程序等各式瀏覽工具不斷涌現(xiàn)；音頻、視頻、游戲、圖片等不同內(nèi)容形式層出不窮；移動蜂窩數(shù)據(jù)網(wǎng)絡(luò)、固網(wǎng)、WiFi 等“最后一公里”的網(wǎng)絡(luò)技術(shù)發(fā)展并普及，整體網(wǎng)絡(luò)環(huán)境變得極其復(fù)雜。但無論網(wǎng)絡(luò)環(huán)境如何，普通終端用戶只想快速地獲取高清且流暢的內(nèi)容。

這看似簡單的需求背后，互聯(lián)網(wǎng)內(nèi)容提供商還要面對首幀時間、卡頓率、碼率、時延、下載時長、多項任務(wù)同時進(jìn)行時的優(yōu)先級等針對不同交付內(nèi)容的性能參數(shù)。要想在這樣共享的環(huán)境中使每個終端用戶都能夠擁有一個高效率、高質(zhì)量的體驗，網(wǎng)絡(luò)協(xié)議層面的優(yōu)化必不可少。

擁塞控制，“治堵”關(guān)鍵

網(wǎng)絡(luò)環(huán)境好比市政交通。只有少量行人時，道路永遠(yuǎn)暢通無阻。當(dāng)越來越多的機動車、非機動車涌上街頭，堵車現(xiàn)象隨之而來，于是就需要能有效應(yīng)對不同狀況的交通規(guī)則來緩解交通壓力。網(wǎng)絡(luò)亦是如此，流量太大、“路況”太復(fù)雜勢必會“堵”得水泄不通，而這個“堵”字用行話來講就是“擁塞”，用來“治堵”的網(wǎng)絡(luò)“交通規(guī)則”即是TCP（傳輸控制協(xié)議）擁塞控制算法。

目前，主流的TCP 擁塞控制算法主要被劃分為兩大類：一是以Cubic、Reno 為代表的基于丟包的算法，二是包括FastTCP 和BBR 在內(nèi)的基于RTT（往返時間）/時延的算法。盡管不同TCP 擁塞控制算法的具體運行機制有所差異，但都是通過對需要發(fā)送的數(shù)據(jù)量、擁塞窗口（cwnd）數(shù)值及接受窗口（rwnd）可接受的數(shù)據(jù)量三項參數(shù)進(jìn)行衡量，以達(dá)到避免網(wǎng)絡(luò)擁塞的目的。更進(jìn)一步講，采用TCP 擁塞控制算法所能實現(xiàn)的理想效果是，通過算法猜測網(wǎng)絡(luò)瓶頸在哪里，在達(dá)到瓶頸值之前盡可能多地發(fā)送數(shù)據(jù)，同時盡可能接近瓶頸上限而又不超過，而非發(fā)生擁塞后再做出反應(yīng)。

然而，面對市面上的諸多選擇，是否有一種TCP 擁塞控制算法能夠適用于所有的場景呢？

以一敵百，難以實現(xiàn)

問題的答案自然是否定的，而且Akamai 對網(wǎng)絡(luò)環(huán)境狀況的監(jiān)測結(jié)果也印證了這一點。Akamai 在全球部署了分布最廣泛且高度分散的內(nèi)容交付網(wǎng)絡(luò)（CDN），具備較高的對整體網(wǎng)絡(luò)的可見性，Akamai 在自身平臺上部署了多種TCP 擁塞控制算法，包括FastTCP、BBR、QDK、Cubic、Reno 等。以Akamai在亞太地區(qū)某區(qū)域不同網(wǎng)絡(luò)環(huán)境下的有效發(fā)包效率為例：

亞太地區(qū)某區(qū)域移動蜂窩網(wǎng)絡(luò)的數(shù)據(jù)顯示，當(dāng)交付內(nèi)容的大小在1M 至3M之間時，平均有效發(fā)包效率最高的TCP 擁塞控制算法 為QDK（18240.6kbps），比最低的FastTCP 快約4.4Mbps，差異高達(dá)驚人的33%。使用FastTCP 時，有超過半數(shù)情況有效發(fā)包效率 在11940.0kbps 以 上；而使用Reno 時，半數(shù)以上的情況有效發(fā)包率可達(dá)到16048.0kbps，遠(yuǎn)高于墊底的FastTCP。

而亞太地區(qū)相同區(qū)域固網(wǎng)的數(shù)據(jù)則呈現(xiàn)出另一番景象。BBR 的平均有效發(fā)包效率僅為20229.1kbps，是效率最低的TCP 擁塞控制算法，而在移動蜂窩網(wǎng)絡(luò)環(huán)境中不太“靈光”的FastTCP 反而以22694.9kbps 的平均有效發(fā)包效率，一躍成為了固網(wǎng)環(huán)境里的“優(yōu)等生”。同時，對超過一半情況有效發(fā)包效率可以達(dá)到的數(shù)值進(jìn)行比較，F(xiàn)astTCP 依然以18618.4kbps保持領(lǐng)先。

不難發(fā)現(xiàn)，每一種TCP 擁塞控制算法都有最適合它的特定網(wǎng)絡(luò)環(huán)境，沒有一勞永逸的方法可以解決繁雜且龐大的網(wǎng)絡(luò)中的所有問題。因此，如果固化地選用一種TCP擁塞控制算法，必然會出現(xiàn)一部分終端用戶難以快速獲得高清、流暢內(nèi)容的情況；但終端用戶又是挑剔的，對極致體驗的追求不分時間、地點、內(nèi)容和設(shè)備。面對如此難上加難的處境，互聯(lián)網(wǎng)內(nèi)容提供商自然不能束手就擒。

以動制動，應(yīng)勢而變

既然網(wǎng)絡(luò)環(huán)境中的擁塞狀況時刻處于動態(tài)的變化之中，試想如果能夠根據(jù)實際的網(wǎng)絡(luò)條件，自動選擇出最適合的TCP 擁塞控制算法，及時對癥下藥，難題也就可以迎刃而解。那么，這樣動態(tài)的優(yōu)化過程又該如何實現(xiàn)呢？

首先，依托一張能夠交付大規(guī)模流量的內(nèi)容交付網(wǎng)絡(luò)，從中收集涵蓋數(shù)據(jù)類型、網(wǎng)絡(luò)類型、用戶地理位置、網(wǎng)絡(luò)時延、使用時間段等20 個維度的海量數(shù)據(jù)，作為分析網(wǎng)絡(luò)環(huán)境狀況的原始素材。而要利用這些數(shù)據(jù)完成對網(wǎng)絡(luò)流量和擁塞情況的分析，并識別出其中的細(xì)微差別和特點，依靠人工手段顯然不現(xiàn)實，因此需要機器學(xué)習(xí)來助一臂之力。最后，根據(jù)機器學(xué)習(xí)的分析結(jié)果，自動地從所部屬的多種TCP 擁塞控制算法中，選擇出最適合當(dāng)前終端用戶所處網(wǎng)絡(luò)環(huán)境的一種，從而使應(yīng)勢而變的動態(tài)選擇成為現(xiàn)實。

當(dāng)前，Akamai 正在穩(wěn)步推進(jìn)以分析框架、機器學(xué)習(xí)、TCP 擁塞控制算法工具庫為主要構(gòu)成的動態(tài)協(xié)議優(yōu)化解決方案。憑借這套解決方案，Akamai 期待不僅能夠?qū)崿F(xiàn)對網(wǎng)絡(luò)使用體驗的優(yōu)化，更能夠營造一個相對公平的網(wǎng)絡(luò)使用環(huán)境。未來，Akamai 仍將是互聯(lián)網(wǎng)內(nèi)容提供商在網(wǎng)絡(luò)“治堵”道路上并肩同行、值得信賴的伙伴。