淺談TCP優(yōu)化

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

　　流量控制

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

Flow Control

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

　　慢啟動(dòng)

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

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

Slow Start

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

Congestion Avoidance

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

　　擁塞避免

　　從慢啟動(dòng)的介紹中，我們能看到，發(fā)送方通過(guò)對(duì)「cwnd」大小的控制，能夠避免網(wǎng)絡(luò)過(guò)載，在此過(guò)程中，丟包與其說(shuō)是一個(gè)網(wǎng)絡(luò)問(wèn)題，倒不如說(shuō)是一種反饋機(jī)制，通過(guò)它我們可以感知到發(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)，通常保持缺省即可，這里就不一一說(shuō)明了，有興趣的讀者可以自行查閱。

　　…

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

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

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

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

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

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

shell> sysctl -a | grep memnet.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)。

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

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ī)制是開(kāi)啟狀態(tài)，那么就把緩沖的最大值設(shè)置為BDP。

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

Buffer / 2^tcp_adv_win_scale

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

BDP / (1 – 1 / 2^tcp_adv_win_scale)

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

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

　　一般來(lái)說(shuō)「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ì)。

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

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

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

Small Window

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

Big Window

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

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

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

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

　　需要提醒的是片面的提升發(fā)送端「cwnd」的大小并不一定有效，這是因?yàn)榍懊嫖覀冋f(shuō)過(guò)網(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

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

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

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

　　…

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

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)