更快的網(wǎng)絡與TCP慢啟動機制

還在糾結到哪里能找到“最好最快的”網(wǎng)絡提供商？最近我聽取并比較了十多個不同的方案之后，有人提醒了我一個簡單的事實：業(yè)界采用的主要指標（帶寬）實際上極具誤導性。其實對于大部分網(wǎng)站瀏覽的應用來說，超過幾兆的網(wǎng)絡連接對于性能只有很小的提升。

罪魁禍首之一就是“TCP慢啟動”，對，這是個功能，不是缺陷。要理解其中的原因，我們必須到TCP棧里面一探究竟，這樣我們也能學到一些建立更快速網(wǎng)絡服務的有趣的小技巧。

TCP慢啟動

TCP協(xié)議提供了許多內(nèi)置的功能，其中我們感興趣的兩個是擁塞控制和擁塞避免。TCP慢啟動是TCP層內(nèi)部實現(xiàn)擁塞控制的一種機制。

慢啟動和其它一些算法聯(lián)合使用，避免發(fā)送過多的數(shù)據(jù)以至網(wǎng)絡無力傳輸，也就是防止網(wǎng)絡擁塞。

－ wikipedia

表面上的流程很簡單：客戶端發(fā)送一個SYN包，它告知本端的最大緩存大小（rwnd － 接收窗口），發(fā)送端回傳幾個包作為應答（cwnd-擁塞窗口），之后，每次它收到來自客戶端的ACK包，它就把發(fā)送包（傳輸中并未收到確認的）的數(shù)量加倍。

這個過程也被稱作TCP連接的“指數(shù)增長”階段。OSI學院有一個很好的動畫演示這個過程：（滾動到底點擊播放）。那么，這和我們有什么關系呢？不管你的帶寬有多大，每一個TCP連接都要經(jīng)歷這個過程，這也就是說，通常情況下，實際用到的帶寬受制于發(fā)送端和接收端的緩存大小的設置。

HTTP和TCP慢啟動

或者，稍微換個說法，一個10M的帶寬平均上只用了16％的容量。老天！這說明，如果我們要提高網(wǎng)速，我們應該著眼于降低客戶端和服務器之間的往返時延，而不一定要一味地花錢提高帶寬。當然，當你在緩沖一個大文件的時候高帶寬很有用，或者跑個速度測試也能唬唬人。問題是，基于HTTP的交互傾向于應用短暫、突發(fā)的連接 － 在這樣的情況下，我們常常無法占用信道的全部容量！Google做一個研究表明，當帶寬從5M升高到10M，頁面加載時間只提高了讓人失望的5％。

CWND的故事

如果TCP慢啟動很慢的話，我們不能讓它快一點么？其實，直到最近，Linux TCP棧本身把擁塞窗口（cwnd）的初始值硬編碼為3到4個包，這也就是4kb的大小（一個包大約1360字節(jié)）。還有個頻繁發(fā)生的問題，HTTP有每獲取一個資源要建立一個連接的毛病。這些加在一塊，你的性能就受到了嚴重限制。

在內(nèi)核2.6.33版本里，經(jīng)過了長期討論和提交很多的IETF修改建議之后，cwnd的初始值被設為10個包。這本身就是一個很大的進步。但是有個問題，猜猜現(xiàn)在大部分服務器跑的是什么版本的內(nèi)核？沒錯，也許現(xiàn)在是時候更新你的服務器了。給你個實用的小提示，如果你考慮你的網(wǎng)絡服務開始使用SPDY，那么如果不在最近的幾個內(nèi)核上面跑，你實際上不會得到任何的性能提升！TCP棧的一個小小的改動在全局能產(chǎn)生巨大的變化。

那么我該怎么辦？

TCP慢啟動是一個功能，不是缺陷，而且它的確包含有趣而重大的意義。作為開發(fā)者，我們經(jīng)常會忽視客戶端到服務器的往返時延，但是如果如果我們真有志于建立更快的網(wǎng)站，現(xiàn)在該去研究一下這些選擇了：在和網(wǎng)絡服務通信的時候重用TCP連接，建立支持HTTP keep-alive和流水線的網(wǎng)絡應用，重視端到端的時延。噢，還有，別在高于10兆的寬帶上浪費錢了，可能你根本就不需要。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]