罪魁禍首之一就是“TCP慢啟動”，對，這是個功能，不是缺陷。要理解其中的原因，我們必須到TCP棧里面一探究竟，這樣我們也能學(xué)到一些建立更快速網(wǎng)絡(luò)服務(wù)的有趣的小技巧。
TCP慢啟動
TCP協(xié)議提供了許多內(nèi)置的功能，其中我們感興趣的兩個是擁塞控制和擁塞避免。TCP慢啟動是TCP層內(nèi)部實現(xiàn)擁塞控制的一種機制。
慢啟動和其它一些算法聯(lián)合使用，避免發(fā)送過多的數(shù)據(jù)以至網(wǎng)絡(luò)無力傳輸，也就是防止網(wǎng)絡(luò)擁塞。
- wikipedia
表面上的流程很簡單：客戶端發(fā)送一個SYN包，它告知本端的最大緩存大小(rwnd - 接收窗口)，發(fā)送端回傳幾個包作為應(yīng)答(cwnd-擁塞窗口)，之后，每次它收到來自客戶端的ACK包，它就把發(fā)送包(傳輸中并未收到確認的)的數(shù)量加倍。
這個過程也被稱作TCP連接的“指數(shù)增長”階段。OSI學(xué)院有一個很好的動畫演示這個過程：(滾動到底點擊播放)。那么，這和我們有什么關(guān)系呢？不管你的帶寬有多大，每一個TCP連接都要經(jīng)歷這個過程，這也就是說，通常情況下，實際用到的帶寬受制于發(fā)送端和接收端的緩存大小的設(shè)置。
HTTP和TCP慢啟動
或者，稍微換個說法，一個10M的帶寬平均上只用了16%的容量。老天!這說明，如果我們要提高網(wǎng)速，我們應(yīng)該著眼于降低客戶端和服務(wù)器之間的往返時延，而不一定要一味地花錢提高帶寬。當然，當你在緩沖一個大文件的時候高帶寬很有用，或者跑個速度測試也能唬唬人。問題是，基于HTTP的交互傾向于應(yīng)用短暫、突發(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的初始值被設(shè)為10個包。這本身就是一個很大的進步。但是有個問題，猜猜現(xiàn)在大部分服務(wù)器跑的是什么版本的內(nèi)核？沒錯，也許現(xiàn)在是時候更新你的服務(wù)器了。給你個實用的小提示，如果你考慮你的網(wǎng)絡(luò)服務(wù)開始使用SPDY，那么如果不在最近的幾個內(nèi)核上面跑，你實際上不會得到任何的性能提升!TCP棧的一個小小的改動在全局能產(chǎn)生巨大的變化。
那么我該怎么辦？
TCP慢啟動是一個功能，不是缺陷，而且它的確包含有趣而重大的意義。作為開發(fā)者，我們經(jīng)常會忽視客戶端到服務(wù)器的往返時延，但是如果如果我們真有志于建立更快的網(wǎng)站，現(xiàn)在該去研究一下這些選擇了：在和網(wǎng)絡(luò)服務(wù)通信的時候重用TCP連接，建立支持HTTP keep-alive和流水線的網(wǎng)絡(luò)應(yīng)用，重視端到端的時延。噢，還有，別在高于10兆的寬帶上浪費錢了，可能你根本就不需要。
