hi，大家好，又是新的一周，周末在朋友圈讀到一篇網(wǎng)絡(luò)優(yōu)化的文章，感覺文章比較接地氣，有實(shí)驗(yàn)測(cè)試，有數(shù)據(jù)分析，想分享給大家，讓我們?cè)俅渭訌?qiáng)對(duì)TCP以及網(wǎng)絡(luò)優(yōu)化的理解。

作者簡(jiǎn)介

費(fèi)良宏，AWS Principal Developer Advocate。在過去的20多年一直從事軟件架構(gòu)、程序開發(fā)以及技術(shù)推廣等領(lǐng)域的工作。他經(jīng)常在各類技術(shù)會(huì)議上發(fā)表演講進(jìn)行分享，他還是多個(gè)技術(shù)社區(qū)的熱心參與者。他擅長Web領(lǐng)域應(yīng)用、移動(dòng)應(yīng)用以及機(jī)器學(xué)習(xí)等的開發(fā)，也從事過多個(gè)大型軟件項(xiàng)目的設(shè)計(jì)、開發(fā)與項(xiàng)目管理。目前他專注與云計(jì)算以及互聯(lián)網(wǎng)等技術(shù)領(lǐng)域，致力于幫助中國的 開發(fā)者構(gòu)建基于云計(jì)算的新一代的互聯(lián)網(wǎng)應(yīng)用。可以通過這個(gè)郵箱與我聯(lián)系lianghon@amazon.com。

文章最初發(fā)表在：

https://aws.amazon.com/cn/blogs/china/talking-about-network-optimization-from-the-flow-control-algorithm/

授權(quán)后，發(fā)表在公眾號(hào)：極客重生

前言

誕生于1974年的TCP協(xié)議（Transmission Control Protocol，傳輸控制協(xié)議）絕對(duì)算得上是最古老的網(wǎng)絡(luò)協(xié)議之一，很可能是當(dāng)今互聯(lián)網(wǎng)上使用最多的網(wǎng)絡(luò)協(xié)議。我們每個(gè)人每天不經(jīng)意間就會(huì)發(fā)送和接收幾十萬甚至超過一百萬以上的TCP數(shù)據(jù)包用來收看視頻、玩游戲或者進(jìn)行網(wǎng)絡(luò)社交。

再進(jìn)一步，也許你還了解目前互聯(lián)網(wǎng)上最流行的兩種傳輸協(xié)議UDP和TCP。UDP概括起來是一個(gè)“發(fā)送后不管”的協(xié)議。它是無狀態(tài)的，沒有擁塞控制或可靠的傳輸支持，這也導(dǎo)致了網(wǎng)絡(luò)運(yùn)營商會(huì)針對(duì)UDP協(xié)議的限流。我們經(jīng)常看到UDP被用于DNS（域名系統(tǒng)）和NTP（網(wǎng)絡(luò)時(shí)間協(xié)議）等。與之相對(duì)，TCP則像是UDP互補(bǔ)的孿生兄弟，提供了可靠的傳輸和流量控制，因此TCP協(xié)議也變得相當(dāng)復(fù)雜。

人們通常認(rèn)為TCP和UDP的主要區(qū)別就是TCP給我們提供了可靠的數(shù)據(jù)包傳輸。當(dāng)然這是TCP最重要的功能之一，但TCP協(xié)議還為我們提供了流量控制。流量控制關(guān)乎網(wǎng)絡(luò)使用的公平性，這對(duì)互聯(lián)網(wǎng)的有效運(yùn)行是至關(guān)重要的。TCP使用多種擁塞控制策略來避免擁塞。具體來講，TCP會(huì)為每條連接維護(hù)一個(gè)“擁塞窗口”來限制可能在端對(duì)端間傳輸?shù)奈创_認(rèn)分組的總數(shù)量。并且，TCP在一個(gè)連接初始化或超時(shí)后使用一種“慢啟動(dòng)”機(jī)制來增加擁塞窗口的大小。所謂的“慢啟動(dòng)”，指的是初始值雖然比較低，但其增長極快：當(dāng)每個(gè)分段得到確認(rèn)時(shí)，擁塞窗口會(huì)增加一個(gè)MSS（Maximum segment size），使得在每次往返時(shí)間（Round-trip time，RTT）內(nèi)擁塞窗口能高效地雙倍增長。設(shè)想一下，如果沒有這種形式的流量控制，互聯(lián)網(wǎng)注定會(huì)在海量的數(shù)據(jù)傳輸之下不堪使用。

許多年來，不同的流量控制算法已經(jīng)在各種TCP堆棧中實(shí)現(xiàn)和使用。你可能聽說過TCP上的一些術(shù)語，例如Cubic、Tahoe、Vegas、Reno、Westwood，以及最近流行的BBR等。這些都是TCP中使用的不同擁塞控制算法。這些算法的作用是決定發(fā)送方應(yīng)該以多快的速度發(fā)送數(shù)據(jù)，并同時(shí)適應(yīng)網(wǎng)絡(luò)的變化。如果沒有這些算法，我們的互聯(lián)網(wǎng)一定會(huì)被數(shù)據(jù)填滿并且崩潰。

在Linux 下檢查當(dāng)前可用的擁塞算法可以使用如下命令：

sysctl net.ipv4.tcp_available_congestion_control

在我的這臺(tái)機(jī)器上就得到了如下的結(jié)果 ：

net.ipv4.tcp_available_congestion_control = reno cubic bbr bbr2 hybla highspeed htcp veno westwood vegas

如果想了解當(dāng)前使用了哪一種擁塞算法可以使用以下命令：

sysctl net.ipv4.tcp_congestion_control

得到的結(jié)果如下。可以看出當(dāng)前使用的是Cubic算法

net.ipv4.tcp_congestion_control = cubic

這里提到的Cubic 是一種較為溫和的擁塞算法，它使用三次函數(shù)作為其擁塞窗口的算法，并且使用函數(shù)拐點(diǎn)作為擁塞窗口的設(shè)置值。Linux內(nèi)核在2.6.19后使用該算法作為默認(rèn)TCP擁塞算法。我們今天所使用的絕大多數(shù)Linux 分發(fā)版本，例如Ubuntu、Amazon Linux 等均將Cubic作為缺省的 TCP流量控制的擁塞算法。

?

BBR 算法

TCP的BBR（Bottleneck Bandwidth and Round-trip propagation time，BBR）是谷歌在2016年開發(fā)的一種新型的TCP 擁塞控制算法。在此以前，互聯(lián)網(wǎng)主要使用基于丟包的擁塞控制策略，只依靠丟失數(shù)據(jù)包的跡象作為減緩發(fā)送速率的信號(hào)。這樣做的的效果還是不錯(cuò)的，但隨著全球化互聯(lián)網(wǎng)的迅速普及，我們所使用的網(wǎng)絡(luò)已經(jīng)發(fā)生了巨大的變化。我們擁有了越來越大的帶寬，而現(xiàn)在的互聯(lián)網(wǎng)質(zhì)量也越來越好。于是我們觀察到了一些新的問題，比如影響延遲的緩沖區(qū)膨脹的問題。BBR嘗試通過使用全新的擁塞控制來解決這個(gè)問題，它使用基于延遲而不是丟包作為決定發(fā)送速率的主要因素。下圖是一個(gè)原理的演示：

https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster

?

為什么BBR會(huì)更好？

盡管我省略了很多細(xì)節(jié)，但還免不了是涉及相對(duì)復(fù)雜的概念。但需要了解的是，使用BBR，可以獲得顯著的網(wǎng)絡(luò)吞吐量的提升和延遲的降低。吞吐量的改善在遠(yuǎn)距離路徑上尤為明顯，比如跨太平洋的文件或者大數(shù)據(jù)的傳輸，尤其是在有輕微丟包的網(wǎng)絡(luò)條件下。延遲的改善主要體現(xiàn)在最后一公里的路徑上，而這一路徑經(jīng)常受到緩沖膨脹（Bufferbloat）的影響。所謂“緩沖膨脹”指的網(wǎng)絡(luò)設(shè)備或者系統(tǒng)不必要地設(shè)計(jì)了過大的緩沖區(qū)。當(dāng)網(wǎng)絡(luò)鏈路擁塞時(shí)，就會(huì)發(fā)生緩沖膨脹，從而導(dǎo)致數(shù)據(jù)包在這些超大緩沖區(qū)中長時(shí)間排隊(duì)。在先進(jìn)先出隊(duì)列系統(tǒng)中，過大的緩沖區(qū)會(huì)導(dǎo)致更長的隊(duì)列和更高的延遲，并且不會(huì)提高網(wǎng)絡(luò)吞吐量。由于BBR并不會(huì)試圖填滿緩沖區(qū)，所以在避免緩沖區(qū)膨脹方面往往會(huì)有更好的表現(xiàn)。

?

看一看BBR的表現(xiàn)

BBR從4.9版本開始就已經(jīng)出現(xiàn)在Linux內(nèi)核之中，可以通過一個(gè)簡(jiǎn)單的sysctl命令來啟用。在我的測(cè)試中，我使用兩臺(tái)EC2 實(shí)例作為測(cè)試的硬件，安裝的操作系統(tǒng)為Ubuntu 20.04。為了滿足測(cè)試的要求，我將Linux 核心替換為我定制的5.8版本的核心。這兩臺(tái)實(shí)例運(yùn)行在同一個(gè)區(qū)域的同一個(gè)可用區(qū)之下。實(shí)例的類型是c5.2xlarge，網(wǎng)卡為Amazon ENA，實(shí)例的網(wǎng)絡(luò)最大帶寬為10Gbps。

第一個(gè)測(cè)試是簡(jiǎn)單的帶寬測(cè)試，看看我們可以從兩臺(tái)實(shí)例之間的單個(gè)TCP流量中得到什么。使用iperf3的測(cè)試顯示了兩臺(tái)實(shí)例之間的帶寬為4.98 Gbits/秒。這足以運(yùn)行我們的實(shí)驗(yàn)。

延遲對(duì)TCP吞吐量的影響

在現(xiàn)實(shí)的使用中，我所用到的服務(wù)器可能分布在世界的各個(gè)地區(qū)，所以我主要關(guān)心的是服務(wù)器之間的網(wǎng)絡(luò)性能，當(dāng)然網(wǎng)絡(luò)間的延遲是在所難免的。在這個(gè)測(cè)試中，我們將使用Linux流量控制工具(tc) 在兩臺(tái)實(shí)例之間引入100ms的往返時(shí)間。這大致相當(dāng)于從美國俄勒岡的us-west-2 訪問位于日本東京的github.com服務(wù)器(52.192.72.89)之間的延遲。

現(xiàn)在我們來看一下正常情況下兩臺(tái)實(shí)例的網(wǎng)絡(luò)延遲

接下來，可以像下面這樣在兩臺(tái)服務(wù)器的收發(fā)每個(gè)方向增加50ms的延遲。

sudo tc qdisc replace dev eth0 root netem latency 50ms

（注：取消上述的設(shè)置可以使用這個(gè)命令?sudo tc qdisc del dev eth0 root?）

如果我們用ping命令做一個(gè)檢測(cè)，現(xiàn)在可以看到100ms的往返時(shí)間

好了，該輪到我們的第一個(gè)測(cè)試了，我先用Cubic擁塞算法開始，因?yàn)檫@是目前最常用的TCP擁塞控制算法。

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic

iperf3的測(cè)試顯示平均傳輸速度為611 Mbits/秒。這是延遲對(duì)TCP吞吐量影響的第一條線索。與我們的初始測(cè)試（4.98Gbits/秒）相比，唯一發(fā)生變化的是引入了100ms的往返延遲。現(xiàn)在我們將擁塞控制算法設(shè)置為bbr，再進(jìn)行一次測(cè)試。

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

結(jié)果與上一次很相似，約為 609 Mbits/秒，這比使用Cubic的結(jié)果略低。到目前為止，我們還沒有看到真正的變化。

?

丟包對(duì)吞吐量的影響

我們要重復(fù)上面同樣的測(cè)試，但要增加少量的丟包。通過下面的命令，我只在服務(wù)器（發(fā)送方）端引入1.5%的丟包量。

sudo tc qdisc replace dev eth0 root netem loss 1.5% latency 50ms

在使用Cubic算法的第一次測(cè)試中，顯示出吞吐量的急劇下降；吞吐量下降到了10.5 Mbs/秒。這個(gè)下降的幅度大約是99.7%，導(dǎo)致這個(gè)鏈路的帶寬基本上無法滿足數(shù)據(jù)傳輸?shù)男枰恕?/p>

如果我們用BBR重復(fù)完全相同的測(cè)試，我們會(huì)看到比Cubic有顯著的改善。使用BBR后，吞吐量下降到333Mbits/秒，下降了45%。

上面的測(cè)試顯示了丟包和延遲對(duì)TCP吞吐量的巨大影響。在一個(gè)高延遲的路徑上，僅僅是少量的數(shù)據(jù)包丟失（1.5%）就會(huì)產(chǎn)生了巨大的影響。在這些較長的路徑上使用除BBR以外的任何其他技術(shù)，當(dāng)出現(xiàn)哪怕是少量的丟包時(shí)，都會(huì)造成很大的問題。也只有BBR在任何超過1.5%的丟包損失時(shí)都能保持一個(gè)不錯(cuò)的吞吐量數(shù)字。

Andree Toonk 在他的博客中驗(yàn)證了了使用不同擁塞控制算法、延遲和丟包參數(shù)所做的各種TCP吞吐量測(cè)試的全套測(cè)試，證明了在一定的丟包率（1.5%、3%）的情況下BBR的出色表現(xiàn)。結(jié)果如下圖：

網(wǎng)絡(luò)吞吐量 – 各種擁塞控制算法的測(cè)試結(jié)果

注意：一個(gè)TCP會(huì)話使用的擁塞控制算法只與局部有關(guān)。所以，兩個(gè)TCP系統(tǒng)可以在TCP會(huì)話的兩邊使用不同的擁塞控制算法。換句話說：服務(wù)器(發(fā)送方)，可以在本地啟用BBR，而客戶端不需要知道BBR，也不需要啟用BBR。

?

TCP ss (socket statistics) 工具

當(dāng)我們?cè)谔剿髡{(diào)整TCP性能的時(shí)候，一定不要忘記使用socket statistics,也就是ss命令。例如下圖所示，ss這個(gè)工具可以顯示大量的套接字信息，包括使用的TCP流控算法，每個(gè)TCP會(huì)話的往返時(shí)間以及計(jì)算出的帶寬和兩個(gè)對(duì)等體之間的實(shí)際傳輸速率等，可以很好的用于網(wǎng)絡(luò)監(jiān)測(cè)和優(yōu)化。

?

何時(shí)使用BBR

網(wǎng)絡(luò)在沒有丟包的情況下，Cubic和BBR對(duì)于這些較長時(shí)延的鏈路都有很好的表現(xiàn)。而在中度丟包的情況下，BBR的表現(xiàn)就非常突出了。為什么這一點(diǎn)很重要呢？或者換一個(gè)說法，為什么要針對(duì)丟包情況而進(jìn)行優(yōu)化？對(duì)于這個(gè)問題，讓我們考慮一下這樣的場(chǎng)景：我們?cè)诓煌牡胤椒胖糜蟹?wù)器，需要在系統(tǒng)或者服務(wù)器之間有源源不斷的數(shù)據(jù)傳輸。例如日志文件、數(shù)據(jù)庫同步、業(yè)務(wù)數(shù)據(jù)的異地備份等等。而在復(fù)雜的網(wǎng)絡(luò)環(huán)境下，會(huì)因?yàn)楦鞣N原因而出現(xiàn)丟包的情況。在這種場(chǎng)景下，BBR將會(huì)大放異彩，幫助您維護(hù)更好的網(wǎng)絡(luò)數(shù)據(jù)傳輸。

顯而易見，BBR對(duì)所謂的“長肥網(wǎng)絡(luò)”（帶寬延遲積大、丟包率高的網(wǎng)絡(luò)）非常有效，在CDN和視頻應(yīng)用等場(chǎng)景下也被證明有很好的表現(xiàn)。事實(shí)上，Youtube、Spotify和Dropbox大規(guī)模應(yīng)用BBR已經(jīng)有了很多的積累。這主要是因?yàn)锽BR會(huì)積極地提升到最佳發(fā)送速率，使你的視頻流加載或者文件下載速度更快。這是Dropbox 在2017年的一篇技術(shù)博客，非常值得我們學(xué)習(xí)。

Optimizing web servers for high throughput and low latency

?

BBR的缺點(diǎn)

看這個(gè)標(biāo)題很覺得奇怪吧。明明只要執(zhí)行一個(gè)sysctl命令，你就能獲得更好的吞吐量，網(wǎng)絡(luò)用戶就會(huì)獲得更好的體驗(yàn)，有什么理由不這樣做呢？好吧，BBR自出世以來已經(jīng)收到了一些批評(píng)，首先，因?yàn)樗鼉A向于搶占Cubic算法的帶寬，在網(wǎng)絡(luò)公平性上明顯存在不足；其次BBR的機(jī)制會(huì)導(dǎo)致高重傳率；第三點(diǎn)是在Wi-Fi環(huán)境下用戶的網(wǎng)速明顯變慢。綜合來看，BBR與Cubic 相比只能說互有優(yōu)劣，各有其擅長的領(lǐng)域。

BBRv2 點(diǎn)展望

針對(duì)BBR 的問題，BBRv2的目標(biāo)就是解決第一版中存在的一些主要缺點(diǎn)，其改進(jìn)包括了還使用聚合/運(yùn)行中的參數(shù)增強(qiáng)了網(wǎng)絡(luò)建模，并增加了對(duì)ECN(顯式擁塞通知)的支持等。為便于理解，我們可以通過這樣一張表來了解這幾個(gè)擁塞算法的異同。

注：ECN是指網(wǎng)絡(luò)瓶頸通知發(fā)送方在用盡緩沖區(qū)并開始“丟尾”數(shù)據(jù)包之前放慢速度的一種方式

現(xiàn)在我們了解了BBRv2，我們?cè)賹⒅暗膶?shí)驗(yàn)重復(fù)一次，看一看BBRv2的具體表現(xiàn)。

我們先將擁塞算法設(shè)定為BBRv2

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr2

接下來，使用iperf3 進(jìn)行測(cè)速，結(jié)果如下：

對(duì)比BBRv2、BBRv1的這兩個(gè)實(shí)驗(yàn)，我們能明顯的觀察到BBRv2 較之BBR速度明顯變“慢”了。但這可以說是一件好事，因?yàn)檫@或許是BBRv2廣泛應(yīng)用的前提。

隨著BBRv2的出現(xiàn)，Dropbox 已經(jīng)在其Dropbox Edge Network上進(jìn)行了試用。在這篇博客中深入討論了BBRv2的實(shí)踐，值得一讀。

Evaluating BBRv2 on the Dropbox Edge Network

這篇文章的結(jié)論對(duì)于BBRv2有很高的評(píng)價(jià)，特摘錄出來：

"在我們的測(cè)試中，BBRv2顯示了以下特性:

對(duì)于網(wǎng)速較低的用戶來說，帶寬可以與CUBIC媲美。

對(duì)于網(wǎng)速較高的用戶來說，帶寬可以與BBRv1媲美。

丟包率比BBRv1低4倍；但仍然比CUBIC高2倍。

傳輸中的數(shù)據(jù)比BBRv1低3倍；但略低于CUBIC。

RTTs較BBRv1低；但仍然比CUBIC高。

與BBRv1相比，RTT具有更高的公平性。

總的來說，BBRv2在BBRv1基礎(chǔ)上有了很大的改進(jìn)，而且在需要更高帶寬的情況下，它更接近于成為Reno/CUBIC的完全替代品。添加實(shí)驗(yàn)性的ECN支持，我們甚至可以看到他可以成為Datacenter TCP (DCTCP)的完全替代者."

BBR具體實(shí)現(xiàn)分析：來自Google的TCP BBR擁塞控制算法深度解析

最后

自2019年算法被提出， BBR2 已有了3個(gè)年頭，但仍處于Alpha/Preview Release。各大主流的Linux 分發(fā)版本中并沒有集成進(jìn)來。有意了解這個(gè)項(xiàng)目不妨通過GitHub 的這個(gè)地址來關(guān)注一下:

https://github.com/google/bbr

但是如果想嘗鮮卻有點(diǎn)麻煩，只能通過編譯Linux Kernel 來得到tcp_bbr.ko 這個(gè)內(nèi)核模塊。另一種選擇是不妨體驗(yàn)一下我剛剛完成的一個(gè)基于Ubuntu 20.04 的Linux kernel，其中就包括了這個(gè)BBRv2。

- END -

---

看完一鍵三連在看，轉(zhuǎn)發(fā)，點(diǎn)贊

是對(duì)文章最大的贊賞，極客重生感謝你

推薦閱讀

圖解Linux 內(nèi)核TCP/IP 協(xié)議棧實(shí)現(xiàn)|Linux網(wǎng)絡(luò)硬核系列

TCP/IP協(xié)議精華指南pdf發(fā)布

來自Google的TCP BBR擁塞控制算法深度解析

總結(jié)

以上是生活随笔為你收集整理的从流量控制算法谈网络优化-TCP核心原理理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。