本節書摘來自異步社群《wireshark網絡分析的藝術》一書中的一篇關于vmware的文章，作者林沛滿,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
一篇關于vmware的文章
wireshark網絡分析的藝術
有位讀者在vmware的知識庫裡找到一篇文章，覺得很像他正在遭遇的一個性能問題，便轉發給我确認。作為好為人師的技術員，我當然不能讓讀者失望。
這篇文章大概講了這樣一件事。
問題描述
某些iscsi存儲陣列在出現網絡擁塞時處理不當，會嚴重影響vmware的讀寫性能。這和它們的tcp實作方式有關。
解決方式
在vmware和存儲陣列上關閉延遲确認（delayed ack）
vmware和iscsi存儲陣列是什麼？我在知識庫裡找到一個網絡拓撲，看起來很簡單，大概如圖1所示。我們無需了解得很深，隻要把iscsi存儲陣列當作一台伺服器，再把vmware當作其用戶端就行了，兩者通過以太網傳輸資料。
乍一看，這個“問題描述”與“解決方式”簡直風馬牛不相及。網絡擁塞怎麼能靠關閉延遲确認來解決？不過出于對vmware的一貫信任，我決定還是好好研究一下。
我們先要明白什麼叫延遲确認，它可以用一個簡單的例子來說明：在上海的筆記本上啟動wireshark抓包，然後用putty遠端登入一台位于悉尼的伺服器。由圖2可見，在上海發出一個ssh請求之後，經過149毫秒左右（即1号包和2号包之間的時間差）收到了悉尼的回複，這是正常的往返時間。但是筆記本收到回複之後，卻沒有立即确認，而是延遲了200毫秒以上（即2号包和3号包之間的時間差）才确認。
這個現象就是傳說中的延遲确認，我在上一本書中也介紹過。為了讓大家更好地了解它，我們再做個對比實驗：我在筆記本上關閉了延遲确認，然後再次連接配接悉尼的伺服器。從圖3可見2号包和3号包之間幾乎沒有時間差了（隻有0.000121秒，可以忽略）。
啟用延遲确認是有好處的，假如在這等待的200毫秒裡，上海的筆記本恰好有資料要發，就可以在發資料時捎帶确認資訊，省去了一個純粹的确認包。圖4就符合這種情況。筆記本收到11号包之後，等了41毫秒左右（即11号包和12号包之間的時間差）恰好又有一個ssh請求要發，就順便把确認捎帶過去了，是以省掉了一個純粹的确認包。之是以有很多tcp協定棧預設啟用延遲确認，正是基于這個原因——少一些确認包可以節省帶寬嘛。
延遲确認的壞處也很明顯，就是會憑空多出一段延遲。這個機制的作用很像你中午懶得去食堂吃飯，便等到下午出門上課時順便去吃一點。結果就是少跑了一趟食堂，但是吃飯時間卻被延後了。
了解了延遲确認的原理，我們再回顧vmware的那篇文章。一般來說，偶爾浪費200毫秒的等待時間并不算嚴重的問題，vmware為什麼要這麼在意呢？又不是等待很多個200毫秒。當我聯想到“很多個”時，終于明白了——這世界上還真的存在一種很老的tcp的實作（rfc 2582），會導緻擁塞時出現多個200毫秒的等待時間。詳情且看下文分析。
圖5從用戶端的視角示範了啟用延遲确認時，某些tcp協定棧在處理網絡擁塞時的狀況。
這個傳輸過程發生了以下事件。
1．用戶端在同一時刻（或者說同一視窗）發送了9個tcp包，其中3、4、5号因為擁塞丢失了。
2．到達伺服器的6、7、8、9号包觸發了4個“ack 3”，于是用戶端快速重傳3号包，此時它并不知道4号包也丢了。
3．由于伺服器上啟用了延遲确認，是以它收到3号包之後，等待了200毫秒才回複ack 4。
4．用戶端重傳4号包，然後伺服器又等待了200毫秒才回複ack 5。
5．用戶端重傳5号包，然後伺服器又等待了200毫秒才回複ack 10。
6．用戶端傳輸新的10号包，自此該網絡擁塞就完全恢複了。
由于當時沒有抓包，是以以上分析僅是我的推測。還有另一種可能是在某個200毫秒的延遲過程中，那些丢包的rto（retransmission timeout）已經被觸發，是以進入了逾時重傳階段。無論符合哪一種可能，性能都會嚴重下降，是以vmware建議關閉延遲确認是很有道理的，隻不過沒把原理說清楚。我甚至懷疑寫這篇文章的人也沒真正了解，因為裡面還提到了慢啟動之類不太相關的東西。
假如把延遲确認關閉掉，那該tcp協定棧處理擁塞的過程就變成圖6所示。包還是那些包，不過浪費在延遲确認上的600毫秒就省下來了。隻要往返時間不是太長，那些丢包也不會觸發逾時重傳，是以避免了第二種可能。
我把分析結果告訴了那位讀者，確定這個修改沒什麼副作用。于是他壯着膽子關閉了延遲确認，果然vmware的性能就飙升了。圖7是他在關閉之後抓的網絡包，和上文分析的一模一樣，果然連續丢了很多包，而且每個重傳都需要确認一次。
我以前分享的案例都是先在wireshark中找到症狀，然後再結合協定分析找到原因的。而這次純粹是依靠協定分析，預測能從包裡看到什麼，然後再用wireshark驗證的。聽起來似乎是完全靠靈感，但靈感不是天生的，它來自長期的訓練。隻有在wireshark中看過了延遲确認和大量重傳的樣子，才可能意識到它們放在一起會出大問題。
注意：
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。