本節書摘來自異步社群《wireshark網絡分析的藝術》一書中的來點有深度的，作者林沛滿,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
來點有深度的
wireshark網絡分析的藝術
前一篇文章釋出後，被一些公衆号轉發了。于是就有資深技術人員找到我，說讀完覺得不過瘾，希望來點有深度的。好吧，那篇的确隻從表面上介紹了延遲确認在網絡發生擁塞時的影響，要往深處分析的話還是有不少料的。
先發散一下思維：除了vmware所建議的關閉延遲确認，還有其他的方法可以解決這個問題嗎？
答案是肯定的。既然vmware的文章說“某些提供iscsi通路的存儲陣列在出現網絡擁塞時處理不當”，就說明還有些存儲陣列是處理得當的，即使打開延遲确認也不怕。那它們又是如何處理的呢？我做了很多研究之後，發現它們其實就是啟用了tcp sack（selective acknowledgement）功能，是以在大量丢包的時候不需要每個重傳包都确認一次，也就不怕延遲确認的影響了。圖1從用戶端的角度示範了同樣丢包的情況下，啟用sack的tcp協定棧是怎樣處理重傳的。
這個傳輸過程發生了以下事件。
1．用戶端在同一時刻（或者說同一視窗）發送了9個tcp包，其中3、4、5号因為擁塞丢失了。
2．到達伺服器的6、7、8、9号包觸發了4個“ack 3”。
3．由于啟用了sack，是以伺服器可以在4個“ack 3”中告知用戶端哪些包已經收到了。
4．因為用戶端已經知道哪些包丢了，哪些包已經收到，是以它可以一口氣完成重傳。
sack資訊在wireshark中很容易看到。如圖2所示，隻要把“ack=656925”和“sack: 661857-663035”這兩個因素結合起來，用戶端就知道排在後面的資料段661857-663035已經送達，但排在前面的656925-661856（共4932位元組）反而丢失了，是以它需要重傳這段資料。從圖3可以看到每個重傳包的len值，四個包加起來恰好就等于4932位元組。
由此可見啟用sack其實比關閉延遲确認更高效，因為它可以一次性重傳多個丢包，而不用每重傳一個就等待一次ack，白費多個往返時間。這在區域網路環境中的優勢還不太明顯，如果是在遠端鏡像中，一個正常的往返時間都要花上百毫秒，那就更應該啟用sack了。我真的很好奇vmware為什麼不提供這個建議。
說完sack，再講一個更加有深度的知識點：除了大量重傳之外，延遲确認還會在什麼場景下嚴重影響性能？
從本質上看，延遲确認之是以會在大量重傳時影響性能，是因為它在該場景下會多次出現（甚至因為延遲太久而導緻逾時重傳）。那麼還有什麼場景會導緻延遲确認多次出現呢？憑空想象是很難得到答案的，不過當你看過的網絡包足夠多時，肯定會遇到一些。我個人遇到最多的是tcp視窗極小的情況，此時啟用延遲确認簡直就是雪上加霜。圖4示範了伺服器接收視窗隻有2920位元組（相當于兩個mss），且關閉了延遲确認時的場景。因為用戶端每發兩個包就會耗光視窗，是以不得不停下來等待伺服器的确認。假如這時候在伺服器上啟用了延遲确認，那29号和30号之間、32号與33号之間……以及38号和39号之間都需要多等待200毫秒，意味着傳輸效率會下降數百倍。這個場景下的延遲确認殺傷力巨大，又非常隐蔽，是以第一次遇上的工程師根本不知所措。
其他的場景我也遇到過一些，不過次數很少，就不一一列舉了。更值得關注的，是如何在wireshark中發現延遲确認，并計算它所帶來的影響。
由于延遲确認是一個正常的tcp機制，有其積極的一面，是以wireshark是不會把它當作問題标志出來的，而且點選analyzeexpert info菜單也是不會統計延遲确認的。難道我們隻能靠人工去計算每個确認包的等待時間嗎？我幾年前就是以吃過一次虧——有位同僚找我分析一個性能相關的網絡包，我用wireshark看了半天都沒有發現問題，是以就斬釘截鐵地說跟網絡無關。後來客戶自己嘗試關閉了延遲确認，性能居然就飙升了，導緻我和同僚都非常尴尬。最後寫分析報告的時候才想到辦法：隻要用“tcp.analysis.ack_rtt > 0.2 and tcp.len==0”過濾一下，就可以把所有超過200毫秒的确認都篩出來了（當然篩出來的不一定全都是延遲确認，追求精确的話就逐個檢查）。圖5正是我當年遇到的那個網絡包，隻要把過濾出來的包數乘以0.2秒，就知道大概浪費了多少時間。
這兩篇文章所列舉的案例，其實在現實環境中廣泛存在。不過由于症狀隻是性能差，是以很多使用者以為是帶寬不足導緻的，就一直忍着。用wireshark抓個包看看吧，很可能無需更新硬體，也可以幫你的系統大幅度提升性能的。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。