淺談TCP優化
很多人常常對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; do
ip 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 連接分塊下載比單連接下載快，大家有貨的話也請告訴我。