在上一篇文章中提到了TCP的延遲確認，延遲確認並不一定能提高效能，在某些場景下，開啟延遲確認甚至會嚴重降低網路傳輸效能。

（一）下面列出幾個開啟延遲確認降低網路效能的場景：

場景一：

想象這樣一個場景，服務端開啟了延遲確認，客戶端在同一時刻傳送了9個TCP包，其中3、4、5號因為擁塞丟失了。

那麼傳輸過程中發生了以下事件：

1. 到達伺服器的6、7、8、9號包觸發了4個“Ack 3”，於是客戶端快速重傳3號包，此時它並不知道4號包也丟失了。
2. 由於伺服器上開啟了延遲確認，所以它收到3號包之後，等待了200ms才回復Ack 4。
3. 客戶端重傳4號包，然後伺服器又等待了200ms才回復Ack 5。
4. 客戶端重傳5號包，然後伺服器又等待了200ms才回復Ack 10。
5. 客戶端傳輸新的10號包，自此網路擁塞就完全恢復了。

這樣不斷的等待回覆，造成了傳輸效率的大幅降低。還有另一種可能是在某個200ms的延遲過程中，那些丟包的RTO已經被觸發，所以進入了超時重傳階段，由於RTO階段網路已經擁塞，發出的包幾乎都沒有達到目的地，所以這段時間相當於並沒有傳輸任何資料。無論符合哪一種可能，效能都會嚴重下降。

解決方案：

1. 關閉延遲確認，這樣浪費在延遲確認上的600ms就省下來了。只要RTT不是太長，那麼丟包也不會觸發超時重傳。

2. 啟用TCP SACK（Selective Acknowledgment）功能，在Ack的時候可以告知對方自己已經收到拿些包了，這樣在大量丟包的時候不需要每個重傳包都確認一次，也就不怕延遲確認的影響了。

如上圖，SACK在wireshark中很容易看到，只要把SACK: 694121-702161 651241-672681 和Ack=623101 綜合起來，我們就知道623101-651240，672682-694120已經丟失。因此它只需要重傳這段資料。由此可見啟用SACK其實比關閉延遲確認更高效，因為它可以一次性重傳多個丟包，而不用每重傳一個就等待一次Ack，白費多個RTT。

場景二：

從本質上看，延遲確認之所以會在大量重傳時影響效能，是因為它在該場景下會多次出現，那麼還有什麼場景會導致延遲確認多次出現呢？當TCP視窗極小的情況下，此時啟用延遲確認簡直就是雪上加霜。因為假如伺服器的接收視窗只有2920位元組（兩個MSS），客戶端每傳送兩個包就會耗光視窗，所以不得不停下來等待伺服器的確認。假如這時候伺服器上啟用了延遲確認，傳輸效率會大受影響。

場景三：

Nagle和延遲確認本身都沒問題，但是一起用就會影響效能。Nagle演算法用程式設計師喜聞樂見的方式表達就是這樣的：

if有新資料要傳送
    if資料量超過MSS（即一個TCP包所能攜帶的最大資料量）
        立即傳送
    else
        if之前發出去的資料尚未確認
            把新資料快取起來，湊夠MSS或確認到達後再發送
        else
            立即傳送
        endif
    endif
endif

在ssh客戶端等小包環境下，啟用Nagle的客戶端攜帶資料量很小的情況下（小於MSS），只能等待上一個包被確認才能接著發。但此時服務端若啟用了延遲確認的話，一等就是200ms，嚴重影響傳輸效率。

（二）估算網路擁塞點

先說一個概念，在途位元組數。注意，只有在資料傳送方抓到的包才能用來分析在途位元組數。某一時刻的計算在途位元組數的公式為在途位元組數=Seq+Len-Ack，其中Seq和Len是來自上一個資料傳送方的包，而Ack則是來自上一個資料接收方的包。

先從Wireshark中找到一連串重傳包中的第一個，再根據該重傳包的Seq值找到其原始包，最後計算該原始包傳送時刻的在途位元組數。由於網路擁塞就是在該原始包發出去的時刻發生的，所以這個在途位元組數就大致代表了擁塞點的大小。多次取樣後建議選一個較小的值，參考這個值來設定視窗，從而儘量避免擁塞。

（三）奇怪的接受視窗

如下圖，接收視窗為什麼只有這麼小？！

很多人的直覺是這個伺服器存在問題，因為接收視窗太小了，肯定會影響網路效能。但是你忽略了一個重要的提示就是“window size scaling factor: -1(unknown)”，上一篇文章中的問題三，我們提及了“Window Scale”這個引數的意義，真實的接收視窗的值需要乘上2的指數（引數作為指數）。

由於這個值是在三次握手期間宣告的，所以如果你在三次握手之後才開始抓包的話，wireshark無從知曉Window Scale的值，也就無法計算出係數，只好顯示出沒有係數時的大小，“window size scaling factor：-1(unknown)”正好提示了這種情況。所以，wireshark此時顯示出的值並不是真實的接收視窗的值。

（四）網路加速器：

一般網路加速器的採用的技術手段：

1. 啟用TCP window scale。這樣可以使最大接收視窗突破65535的限制，只要記憶體跟得上，接收視窗幾乎不受限制。

2. 監測延遲來避免擁塞。網路包是以佇列的方式通過網路裝置的，當擁塞即將發生時，佇列變長，延遲就會顯著提高。根據這一特點，我們可以讓加速器在延遲明顯增加時，自動放慢傳送速度，從而避免擁塞的發生。這其實是TCP Vegas的理念。

3. 利用傳送視窗實現優先順序控制，使用者體驗就會更好。

4. 啟用SACK。SACK必須在傳送方和接收方都啟用，這就是我們在兩邊各架設一臺加速器的優勢。單邊加速器的效果很可能因為另一端沒有啟用SACK而大打折扣。

（五）wireshark常見提示

參考資料

《wireshark網路分析的藝術》
《計算機網路》謝希仁
RFC文件