明白了這兩個機制后，我們再逐條分析TCP對性能的影響因素：

1、TCP滑動窗口：如果要把10塊磚從A地搬到B地，你是一次搬一塊，總共搬10次，還是一口氣搬10塊呢?在力氣允許的條件下，自然是一口氣搬 完速度快，因為節(jié)省了往返時間。網(wǎng)絡傳輸也是如此，如果有10個TCP包要傳，在帶寬允許的情況下應該一起發(fā)送，而不是發(fā)一個就等確認，然后再發(fā)下一個。 舉個例子，假如往返時間 RTT是2毫秒，那10個包逐個傳至少要花20毫秒;一起傳就只需要2毫秒多一點，對性能的提高是顯而易見的。除此之外，在發(fā)生丟包的時候，大窗口可以提 高快速重傳的概率，減少了超時重傳。比如10個包一起傳時，前6個包中任何一個丟失都可以由接下來的4個包觸發(fā)快速重傳。而每次傳4個包是永遠等不到快速 重傳的機會的。

2、多線程：在一個TCP session里，如果存在多個線程，也可以在丟包時提高快速重傳的概率。還記得《NAS性能優(yōu)化之一》里關于smb2的“叫外賣”圖片嗎?在第一個請求 沒有完成的情況下，就可以發(fā)送第二個請求。如果第一個請求有丟包，那第二個請求的包可以幫忙湊滿四個，從而觸發(fā)快速重傳。本文開頭提到的讀者在測試 smb2時得到大幅度的性能提升，很可能就得益于此。除了SMB2和NFS協(xié)議，EMC免費提供的EMCOPY工具也能在SMB中實現(xiàn)多線程拷貝。

3、超時重傳時間(RTO)：這是一個動態(tài)值。RFC規(guī)定了計算該值的方法，但是結果比較大，已經(jīng)不適用當今的網(wǎng)絡環(huán)境了。有些NAS(比如Celerra)提供一個設置，允許強制把該值改小。

4、Jumbo Frame：中文好像翻譯為巨幀。就是把MTU增大到9000，從而減少TCP頭和IP頭在一個網(wǎng)絡包中所占的比例。理論上這是能提高性能的，但是實際效果卻不一定。因為大包的丟失概率更大一點，而且包數(shù)少了，就更有可能發(fā)生超時重傳。

5、網(wǎng)絡擁塞：除了網(wǎng)絡配置出錯(比如兩端的speed/duplex不符合)，另外一個導致丟包的因素就是網(wǎng)絡發(fā)生擁塞。如何避免呢?最有效最簡 單的方法當然是購買更高端的switch，但這也是最難被接受的建議。有一個將就的辦法，就是人為的把TCP滑動窗口強制在擁塞點以下。寧愿每次少傳一 點，也不要丟包。有些 NAS(比如Celerra)提供了強制最大滑動窗口的設置，但是要確定一個合適的擁塞點比較麻煩，需要抓大量的包分析。

寫到這里，突然想到可以寫幾篇如何利用Wireshark分析網(wǎng)絡包的。不過，這個讀者群應該比NAS還小很多吧?

wangzhen