很多人常常對TCP優化有一種霧里看花的感覺，實際上只要理解了TCP的運行方式就能掀開它的神秘面紗。Ilya Grigorik?在「High Performance Browser Networking」中做了很多細致的描述，讓人讀起來醍醐灌頂，我大概總結了一下，以期更加通俗易懂。

?

流量控制

傳輸數據的時候，如果發送方傳輸的數據量超過了接收方的處理能力，那么接收方會出現丟包。為了避免出現此類問題，流量控制要求數據傳輸雙方在每次交互時聲明各自的接收窗口「rwnd」大小，用來表示自己最大能保存多少數據，這主要是針對接收方而言的，通俗點兒說就是讓發送方知道接收方能吃幾碗飯，如果窗口衰減到零，那么就說明吃飽了，必須消化消化，如果硬撐的話說不定會大小便失禁，那就是丟包了。

Flow Control

接收方和發送方的稱呼是相對的，如果站在用戶的角度看：當瀏覽網頁時，數據以下行為主，此時客戶端是接收方，服務端是發送方；當上傳文件時，數據以上行為主，此時客戶端是發送方，服務端是接收方。

慢啟動

雖然流量控制可以避免發送方過載接收方，但是卻無法避免過載網絡，這是因為接收窗口「rwnd」只反映了服務器個體的情況，卻無法反映網絡整體的情況。

為了避免過載網絡的問題，慢啟動引入了擁塞窗口「cwnd」的概念，用來表示發送方在得到接收方確認前，最大允許傳輸的未經確認的數據。「cwnd」同「rwnd」相比不同的是：它只是發送方的一個內部參數，無需通知給接收方，其初始值往往比較小，然后隨著數據包被接收方確認，窗口成倍擴大，有點類似于拳擊比賽，開始時不了解敵情，往往是次拳試探，慢慢心里有底了，開始逐漸加大重拳進攻的力度。

Slow Start

在慢啟動的過程中，隨著「cwnd」的增加，可能會出現網絡過載，其外在表現就是丟包，一旦出現此類問題，「cwnd」的大小會迅速衰減，以便網絡能夠緩過來。

Congestion Avoidance

說明：網絡中實際傳輸的未經確認的數據大小取決于「rwnd」和「cwnd」中的小值。

擁塞避免

從慢啟動的介紹中，我們能看到，發送方通過對「cwnd」大小的控制，能夠避免網絡過載，在此過程中，丟包與其說是一個網絡問題，倒不如說是一種反饋機制，通過它我們可以感知到發生了網絡擁塞，進而調整數據傳輸策略，實際上，這里還有一個慢啟動閾值「ssthresh」的概念，如果「cwnd」小于「ssthresh」，那么表示在慢啟動階段；如果「cwnd」大于「ssthresh」，那么表示在擁塞避免階段，此時「cwnd」不再像慢啟動階段那樣呈指數級整整，而是趨向于線性增長，以期避免網絡擁塞，此階段有多種算法實現，通常保持缺省即可，這里就不一一說明了，有興趣的讀者可以自行查閱。

…

如何調整「rwnd」到一個合理值

有很多人都遇到過網絡傳輸速度過慢的問題，比如說明明是百兆網絡，其最大傳輸數據的理論值怎么著也得有個十兆，但是實際情況卻相距甚遠，可能只有一兆。此類問題如果剔除奸商因素，多半是由于接收窗口「rwnd」設置不合理造成的。

實際上接收窗口「rwnd」的合理值取決于BDP的大小，也就是帶寬和延遲的乘積。假設帶寬是 100Mbps，延遲是 100ms，那么計算過程如下：

BDP = 100Mbps * 100ms = (100 / 8) * (100 / 1000) = 1.25MB

此問題下如果想最大限度提升吞度量，接收窗口「rwnd」的大小不應小于 1.25MB。說點引申的內容：TCP使用16位來記錄窗口大小，也就是說最大值是64KB，如果超過它，就需要使用tcp_window_scaling機制。參考：TCP Windows and Window Scaling。

Linux中通過配置內核參數里接收緩沖的大小，進而可以控制接收窗口的大小：

shell> sysctl -a | grep mem net.ipv4.tcp_rmem = <MIN> <DEFAULT> <MAX>

如果我們出于傳輸性能的考慮，設置了一個足夠大的緩沖，那么當大量請求同時到達時，內存會不會爆掉？通常不會，因為Linux本身有一個緩沖大小自動調優的機制，窗口的實際大小會自動在最小值和最大值之間浮動，以期找到性能和資源的平衡點。

通過如下方式可以確認緩沖大小自動調優機制的狀態（0：關閉、1：開啟）：

shell> sysctl -a | grep tcp_moderate_rcvbuf

如果緩沖大小自動調優機制是關閉狀態，那么就把緩沖的缺省值設置為BDP；如果緩沖大小自動調優機制是開啟狀態，那么就把緩沖的最大值設置為BDP。

實際上這里還有一個細節問題是：緩沖里除了保存著傳輸的數據本身，還要預留一部分空間用來保存TCP連接本身相關的信息，換句話說，并不是所有空間都會被用來保存數據，相應額外開銷的具體計算方法如下：

Buffer / 2^tcp_adv_win_scale

依照Linux內核版本的不同，net.ipv4.tcp_adv_win_scale?的值可能是 1 或者 2，如果為 1 的話，則表示二分之一的緩沖被用來做額外開銷，如果為 2 的話，則表示四分之一的緩沖被用來做額外開銷。按照這個邏輯，緩沖最終的合理值的具體計算方法如下：

BDP / (1 – 1 / 2^tcp_adv_win_scale)

此外，提醒一下延遲的測試方法，BDP中的延遲指的就是RTT，通常使用ping命令很容易就能得到它，但是如果 ICMP 被屏蔽，ping也就沒用了，此時可以試試?synack。

如何調整「cwnd」到一個合理值

一般來說「cwnd」的初始值取決于MSS的大小，計算方法如下：

min(4 * MSS, max(2 * MSS, 4380))

以太網標準的MSS大小通常是1460，所以「cwnd」的初始值是3MSS。

當我們瀏覽視頻或者下載軟件的時候，「cwnd」初始值的影響并不明顯，這是因為傳輸的數據量比較大，時間比較長，相比之下，即便慢啟動階段「cwnd」初始值比較小，也會在相對很短的時間內加速到滿窗口，基本上可以忽略不計。

不過當我們瀏覽網頁的時候，情況就不一樣了，這是因為傳輸的數據量比較小，時間比較短，相比之下，如果慢啟動階段「cwnd」初始值比較小，那么很可能還沒來得及加速到滿窗口，通訊就結束了。這就好比博爾特參加百米比賽，如果起跑慢的話，即便他的加速很快，也可能拿不到好成績，因為還沒等他完全跑起來，終點線已經到了。

舉例：假設網頁20KB，MSS大小1460B，如此說來整個網頁就是15MSS。

先讓我們看一下「cwnd」初始值比較小（等于4MSS）的時候會發生什么：

Small Window

再看一下「cwnd」初始值比較大（大于15MSS）的時候又會如何：

Big Window

明顯可見，除去TCP握手和服務端處理，原本需要三次RTT才能完成的數據傳輸，當我們加大「cwnd」初始值之后，僅用了一次RTT就完成了，效率提升非常大。

推薦：大拿?mnot?寫了一個名叫?htracr?的工具，可以用來測試相關的影響。

既然加大「cwnd」初始值這么好，那么到底應該設置多大為好呢？Google在這方面做了大量的研究，權衡了效率和穩定性之后，最終給出的建議是10MSS。如果你的Linux版本不太舊的話，那么可以通過如下方法來調整「cwnd」初始值：

shell> ip route | while read r; doip route change $r initcwnd 10;done

需要提醒的是片面的提升發送端「cwnd」的大小并不一定有效，這是因為前面我們說過網絡中實際傳輸的未經確認的數據大小取決于「rwnd」和「cwnd」中的小值，所以一旦接收方的「rwnd」比較小的話，會阻礙「cwnd」的發揮。

推薦：相關詳細的描述信息請參考：Tuning initcwnd for optimum performance。

有時候我們可能想檢查一下目標服務器的「cwnd」初始值設置，此時可以數包：

Test Initcwnd

通過握手階段確認RTT為168，開始傳輸后得到第一個數據包的時間是409，加上RTT后就是577，從409到577之間有兩個數據包，所以「cwnd」初始值是2MSS。

需要額外說明的是，單純數包可能并不準確，因為網卡可能會對包做點手腳，具體說明信息請參考：Segmentation and Checksum Offloading: Turning Off with ethtool。

補充：有人寫了一個名叫?initcwnd_check?的腳本，可以幫你檢查「cwnd」初始值。

…

實踐是檢驗真理的唯一標準，希望大家多動手，通過實驗來檢驗結果，推薦一篇不錯的文章：Impact of Bandwidth Delay Product on TCP Throughput，此外知乎上的討論也值得一看：為什么多 TCP 連接分塊下載比單連接下載快，大家有貨的話也請告訴我。

此條目由老王發表在Technical分類目錄，并貼了Linux、TCP標簽。將固定鏈接加入收藏夾。

總結

以上是生活随笔為你收集整理的浅谈TCP优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。