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

流量控制

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

Flow Control

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

慢啟動

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

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

Slow Start

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

Congestion Avoidance

說明：網(wǎng)絡(luò)中實際傳輸?shù)奈唇?jīng)確認的數(shù)據(jù)大小取決于「rwnd」和「cwnd」中的小值。

擁塞避免

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

…

如何調(diào)整「rwnd」到一個合理值

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

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

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

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

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

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

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

通過如下方式可以確認緩沖大小自動調(diào)優(yōu)機制的狀態(tài)（0：關(guān)閉、1：開啟）：

shell> sysctl -a | grep tcp_moderate_rcvbuf 

如果緩沖大小自動調(diào)優(yōu)機制是關(guān)閉狀態(tài)，那么就把緩沖的缺省值設(shè)置為BDP；如果緩沖大小自動調(diào)優(yōu)機制是開啟狀態(tài)，那么就把緩沖的最大值設(shè)置為BDP。

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

Buffer / 2^tcp_adv_win_scale 

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

BDP / (1 – 1 / 2^tcp_adv_win_scale) 

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

如何調(diào)整「cwnd」到一個合理值

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

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

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

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

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

舉例：假設(shè)網(wǎng)頁20KB，MSS大小1460B，如此說來整個網(wǎng)頁就是15MSS。

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

Small Window

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

Big Window

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

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

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

shell> ip route | while read p; do 
ip route change $p initcwnd 10; 
done 

需要提醒的是片面的提升發(fā)送端「cwnd」的大小并不一定有效，這是因為前面我們說過網(wǎng)絡(luò)中實際傳輸?shù)奈唇?jīng)確認的數(shù)據(jù)大小取決于「rwnd」和「cwnd」中的小值，所以一旦接收方的「rwnd」比較小的話，會阻礙「cwnd」的發(fā)揮。

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

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

Test Initcwnd

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

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

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

…

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