遠程控制的體驗是否優秀與網絡有著很大的關系。想要觸達遠程控制體驗的上限,我們需要十分先進遠控算法技術,同時也需要網絡狀態足夠穩定;但現實中,很多需要使用遠程控制的場景并沒有特別穩定的網絡,甚至可以稱其為“弱網環境”,在這類場景下保證遠程控制體驗的“下限”也十分重要。
針對弱網環境下的諸多問題,“國民遠控向日葵”通過引入BBR擁塞控制算法讓服務器之間的連接更快,端與服務器的連接更穩定,進而提升向日葵在弱網環境下的連接穩定性和帶寬的利用率。
這里,我們就來介紹一下到底什么是BBR擁塞控制算法,這一算法是如何發展而來的,向日葵引入該算法后效果如何。
何為擁塞控制算法
想要理解擁塞控制算法,我們首先要對網絡為什么會出現丟包卡頓進行一個簡單的解釋。
互聯網上的兩點通信時,每經過一個路由設備叫一跳(hop)。每一跳都有不同的帶寬,兩點之間的可用帶寬是每一跳中的最小值,被稱為Bottleneck BW。因為是公共鏈路,它們擁擠、丟包和排隊難以避免,可用帶寬也時大時小,這便是網絡卡頓的根本原因之一。
但網絡通信有一個補救機制,即使排隊和路由抖動產生了丟包或者數據錯誤,4層的TCP協議也會處理,它會重傳并進行帶寬控制,以保證數據的完整性,這便是擁塞控制算法的核心。
早期的Cubic擁塞控制算法
1980年代的互聯網崩潰,促成了TCP擁塞控制的落地。經過十多年的發展,Cubic出現并延續至令,目前它仍然是互聯網主流的擁塞控制算法,它基于著名的“加性增,乘性減”(AIMD)控制律,將丟包作為網絡鏈路擁塞的指示。通過檢測丟包,發現并主動降低發送頻率,減少擁塞。這被稱為“基于丟包”的擁塞控制算法。同類算法有幾個,像更早前的Reno, BIC等。
由于只有當路由器的隊列滿了以后才會有丟包,因此,這類算法傾向于快速填滿瓶頸路由器的緩存,然后急劇降低發包(減少50%),當隊列空閑后又慢慢填滿,周而復始。
Cubic算法的正常運行對鏈路的丟包率有一定的要求,在丟包率較高的長肥管道環境下,其發送窗口會迅速收斂到很小。另一方面,當實際可用帶寬增大時,它總是會花固定的時間去探測然后慢慢增大,效率是相對低下的。
同時,Cubic在擁塞避免階段會逐漸加大發送窗口直至填滿瓶頸隊列,這種機制加速了擁塞的形成,造成了網絡延時的波動。因此,在鏈路瓶頸處保持最大帶寬和最小延時的狀態是擁塞控制的目標,但明顯Cubic在目前的互聯網環境中已經不能很好的勝任。
谷歌提出BBR擁塞控制算法
基于上述Cubic算法的短板,谷歌提出一種基于延時帶寬積的算法BBR (Bottleneck Bandwidth and RTT),使用了交替測試鏈路的最大帶寬與最小的RTT的方法,來尋找名為Kleinrock的最佳操作點,這個點,核心特征是報文開始排隊。如下圖所示,Cubic的擁塞控制點是排隊并且緩存已經滿了。
將最近10次往返中測得的最大帶寬視為Bmax,將過去10s中測得的最小RTT視為Tprop,然后根據這兩個值估算BDP。
BBDP = Bmax × Tprop
BBR分別通過窗口增益和起博增益來調整CWND和發送速率,進而控制其發送行為,將擁塞快速收斂到最佳控制點。
向日葵通過BBR算法,提升連接帶寬3倍以上
基于BBR算法的種種優勢,向日葵將其引入并應用在遠程控制技術中,據向日葵的實驗室數據顯示,在跨國的弱網環境中,未使用多路復用的單連接應用,BBR能提升約10倍的端與服務器間的可用帶寬(如:由120Kbps提升到>1Mbps)。同時,國內的服務器間互聯時,BBR能提升1倍以上的服務器間帶寬利用率(由40%到85%)。
在實際的使用中,在經過支持BBR的服務器中轉后,向日葵的連接帶寬提升了3倍以上,幀率提升了5倍以上,對于用戶體驗改善明顯。
在BBR算法的加持下,我們可以顯著的感受到向日葵遠程控制的“下限”有了很充足的保障,當遠程控制應用在很多弱網環境、如工業、戶外等場景下時,相信向日葵能夠發揮充分的技術優勢。
