什么是TCP?
TCP始于1970年,作為協(xié)議套件的一部分, TCP / IP將數據格式化成數據包在網(wǎng)絡(luò )上進(jìn)行傳輸。IETF工作人員表示,超過(guò)90%的IP流量都通過(guò)TCP傳輸。
在過(guò)去的幾十年里,為加快TCP / IP的速度,很多人都在為T(mén)CP如何處理?yè)矶碌膯?wèn)題不斷努力。TCP通過(guò)監控傳輸中丟失的分組數量減慢在感知擁塞時(shí)發(fā)送流量的速度。由于網(wǎng)絡(luò )交換機和路由器的小緩沖區與互聯(lián)網(wǎng)連接的低帶寬很匹配,所以BBR的效果還是很不錯的。遺憾的是,“基于損失”擁塞控制在當今的環(huán)境中并不適用。
BBR優(yōu)勢
BBR以一定速度不斷評估多個(gè)路由的吞吐量和往返流量時(shí)間,得出遍歷網(wǎng)絡(luò )需要的時(shí)間。這樣一來(lái),BBR以網(wǎng)絡(luò )可處理的速度發(fā)送流量,比最初的TCP擁塞控制更有效果。
BBR還兼容由Google設計的替代傳輸協(xié)議——快速UDP互聯(lián)網(wǎng)連接(QUIC),并被IETF作為標準。
BBR并不是工程師們?yōu)榧铀賂CP所做出的第一個(gè)努力。北卡羅來(lái)納州立大學(xué)的研究人員表示,當今開(kāi)發(fā)TCP中使用的最流行的基于丟失的擁塞控制算法之一是二進(jìn)制增加擁塞控制(BIC),其次是CUBIC,還有另一種流行的擁塞控制算法叫做Reno。這些算法都是使用分組丟失來(lái)確定擁塞的,盡管開(kāi)發(fā)BBR的Google工程師Jacobson表示,在他看來(lái),BBR才是唯一一個(gè)通過(guò)實(shí)際估計流量速度來(lái)確定最佳傳輸速度的TCP算法。
BBR取得初步成功
Mirja Kuhlewind是蘇黎世網(wǎng)絡(luò )系統集團的高級研究員,也是IETF的運輸區域主管,負責TCP的維護和改進(jìn)工作。她表示,在傳輸與擁堵控制方面建立標準需要很長(cháng)的時(shí)間,在BIC和BBR的發(fā)展之前,通過(guò)數十次TCP技術(shù)改進(jìn),才僅有一個(gè)成為了標準,擁塞控制計劃的標準化不是一件易事。
Reno和CUBIC基于相同的原理工作,將丟失包作出的反應作為擁塞的標志,檢測到丟失時(shí)降低發(fā)送速率。而B(niǎo)BR利用的是分組定時(shí)信息來(lái)確定鏈路是否擁塞。
谷歌的一些客戶(hù)已經(jīng)意識到BBR的重要性,Wordpress在Google Cloud和Founder中托管了50萬(wàn)個(gè)站點(diǎn),谷歌的CTO Jason Cohen也表示BBR與其他基于丟失的擁塞控制相比提高了2700倍的吞吐量、延遲降低了25倍。
BBR原理簡(jiǎn)介
擁塞現象是指到達通信子網(wǎng)中某一部分的分組數量過(guò)多,使得該部分網(wǎng)絡(luò )來(lái)不及處理,以致引起這部分乃至整個(gè)網(wǎng)絡(luò )性能下降的現象,嚴重時(shí)甚至會(huì )導致網(wǎng)絡(luò )通信業(yè)務(wù)陷入停頓,即出現死鎖現象。這種現象跟公路網(wǎng)中經(jīng)常所見(jiàn)的交通擁擠一樣,當節假日公路網(wǎng)中車(chē)輛大量增加時(shí),各種走向的車(chē)流相互干擾,使每輛車(chē)到達目的地的時(shí)間都相對增加(即延遲增加),甚至有時(shí)在某段公路上車(chē)輛因堵塞而無(wú)法開(kāi)動(dòng)(即發(fā)生局部死鎖)。
擁塞控制就是針對此問(wèn)題的控制技術(shù)/解決方案,但也不能說(shuō)是解決,控制技術(shù)只能起到盡量避免/緩解擁塞的作用。TCP-BBR技術(shù)呢,用了一種溢水原理的思想,來(lái)預判丟包率,調配發(fā)包速率。
假設你有一支較細的U形管,下面還有一堆不可溶的填塞物,你從一邊開(kāi)始大量灌水,如果另一邊出水正常,你就可以繼續加大灌水量,達到最大帶寬。如果另一邊發(fā)現水時(shí)斷時(shí)有,就證明下面出現了隨機擁堵,這時(shí),你就要減小灌水量,等待水位落下。這時(shí)如果采用傳統繼續灌水時(shí),也就會(huì )造成水溢出(丟包現象的產(chǎn)生)。所以這是真正的按需發(fā)包。當然,這一切是建立在系統預估的情況下。