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

流量控制

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

Flow Control

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

慢啟動(dòng)

雖然流量控制可以避免發(fā)送方過載接收方，但是卻無法避免過載網(wǎng)絡(luò)，這是因?yàn)榻邮沾翱凇竢wnd」只反映了服務(wù)器個(gè)體的情況，卻無法反映網(wǎng)絡(luò)整體的情況。

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

Slow Start

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

Congestion Avoidance

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

擁塞避免

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

…

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

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

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

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

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

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

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

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

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

shell> sysctl -a | grep tcp_moderate_rcvbuf 

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

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

Buffer / 2^tcp_adv_win_scale 

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

BDP / (1 – 1 / 2^tcp_adv_win_scale) 

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

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

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

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

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

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

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

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

先讓我們看一下「cwnd」初始值比較?。ǖ扔?MSS）的時(shí)候會(huì)發(fā)生什么：

Small Window

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

Big Window

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

推薦：大拿 mnot 寫了一個(gè)名叫 htracr 的工具，可以用來測(cè)試相關(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」的大小并不一定有效，這是因?yàn)榍懊嫖覀冋f過網(wǎng)絡(luò)中實(shí)際傳輸?shù)奈唇?jīng)確認(rèn)的數(shù)據(jù)大小取決于「rwnd」和「cwnd」中的小值，所以一旦接收方的「rwnd」比較小的話，會(huì)阻礙「cwnd」的發(fā)揮。

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

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

Test Initcwnd

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

需要額外說明的是，單純數(shù)包可能并不準(zhǔn)確，因?yàn)榫W(wǎng)卡可能會(huì)對(duì)包做點(diǎn)手腳，具體說明信息請(qǐng)參考：Segmentation and Checksum Offloading: Turning Off with ethtool。

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

…

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