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