TCP協議中有個慢啟動，在《TCP/IP詳解卷一》中占據的篇幅很小，但是這個東西，在某些業務場景下，對性能的影響非常大。
什么是慢啟動
最初的TCP的實現方式是，在連接建立成功后便會向網絡中發送大尺寸的數據包，假如網絡出現問題，很多這樣的大包會積攢在路由器上，很容易導致網絡中路由器緩存空間耗盡，從而發生擁塞。因此現在的TCP協議規定了，新建立的連接不能夠一開始就發送大尺寸的數據包，而只能從一個小尺寸的包開始發送，在發送和數據被對方確認的過程中去計算對方的接收速度，來逐步增加每次發送的數據量（最后到達一個穩定的值，進入高速傳輸階段。相應的，慢啟動過程中，TCP通道處在低速傳輸階段），以避免上述現象的發生。這個策略就是慢啟動。
畫個簡單的圖從原理上粗略描述一下
慢啟動引起的性能問題
在海量用戶高並發訪問的大型網站后台，有一些基本的系統維護需求。比如遷移海量小文件，就是從一些機器拷貝海量小碎文件到另一些機器，來完成一些系統維護的基本需求。
請不要小看這樣的需求，這是服務器領域乃至雲計算領域幾個最復雜的問題之一，量變到質變，由量大引起的難題。今天在我這篇文章中，我只說這個如何避免慢啟動來提升TCP層的傳輸加速問題。
言歸正傳，慢啟動為什么會對拷貝海量小文件的需求造成重大性能損失？
舉個簡單的例子，我們對每個文件都采用獨立的TCP連接來傳輸（循環使用scp拷貝就是這個例子的實際場景，很常見的用法）。那么工作過程應該是，每傳輸一個文件建立一個連接，然后連接處於慢啟動階段，傳輸小文件，每個小文件幾乎都處於獨立連接的慢啟動階段被傳輸，這樣傳輸過程所用的TCP包的總量就會增多。更細致的說一說這個事，如果在慢啟動過程中傳輸一個小文件，我們可能需要2至3個小包，而在一個已經完成慢啟動的TCP通道中（TCP通道已進入在高速傳輸階段），我們傳輸這個文件可能只需要1個大包。網絡拷貝文件的時間基本上全部消耗都在網絡傳輸的過程中（發數據過去等對端ACK，ACK確認歸來繼續再發，這樣的數據來回交互相比較本機的文件讀寫非常耗時間），撇開三次握手和四次握手那些包，粗略來說，慢啟動階段傳輸這些文件所用的包的數目是高速通道傳輸這些文件的包的數目的2-3倍！那么時間上應該也是2-3倍的關系！如果文件的量足夠大，這個總時間就會被放大到需求難以忍受的地步。
因此，在遷移海量小文件的需求下，我們不能使用“對每個文件都采用獨立的TCP連接來傳輸（循環使用scp拷貝）“這樣的策略，它會使每個文件的傳輸都處於在一個獨立TCP的慢啟動階段。
如何避免慢啟動，進而提升性能
很簡單，盡量把大量小文件放在一個TCP連接中排隊傳輸。起初的一兩個文件處於慢啟動過程傳輸，后續的文件傳輸全部處於高速通道中傳輸，用這樣的方式來減少發包的數目，進而降低時間消耗。
題外話，實際上這種傳輸策略帶來的性能提升的功勞不僅僅歸於避免慢啟動，事實上也避免了大量的3次握手和四次握手，這個對海量小文件傳輸的性能消耗也非常致命，但是這是另一個問題，本篇不多加介紹。
隨着多核服務器的興起，以及現代網卡的多通道技術的迅猛發展，現在我們解決這一問題的通常做法是綁定多CPU的多核到網卡的多個通道，然后由CPU的核來均分傳輸這些小文件，每個核用一個TCP連接來排隊發送分到的小文件。
講到這兒，我想大家對於大文件的傳輸策略應該也心里有數了，（不考慮網卡帶寬的前提下）就是分塊傳輸，在目標機器合並。
后續我會專門介紹利用網卡多通道提升服務器性能。
原文地址：http://blog.chinaunix.net/uid-29075379-id-3905104.html