一站式學習Wireshark（六）：狙擊網路高延時點

emc.com發表於2015-11-21

在某些情況下，丟包可能並不是造成延時的原因。你可能會發現儘管兩臺主機之間通訊速度很慢，但這種慢速並沒有伴隨著TCP重傳或是重複ACK的徵兆。在這種情況下，需要使用另一種方式來定位高延時點。

查詢高延時點最有效的方法之一是檢查最初的握手訊號以及跟隨其後的幾個報文。例如，一個簡單的客戶端與網路伺服器的連線，客戶端嘗試通過瀏覽器訪問網路伺服器的站點。我們只關心這一通訊序列的前六個報文，包括TCP握手過程，首次HTTP GET請求，對此GET請求的確認，以及從伺服器發至客戶端的第一個資料包文。

更多資訊

正常通訊:

在討論高延時狀況之前，找一個正常的通訊作為參照。在第二節已經介紹過TCP握手過程以及HTTP通訊，這裡不再贅述。在下面這張圖裡，我們關心的部分只有Time列：

這一通訊序列是非常快速的，整個過程耗時不到0.1秒。

接下來幾個抓包檔案包含同樣的traffic模式，但是在報文時序上有所不同。

慢速通訊——線路延時：

讓我們看看下面這個報文。注意到所有報文都是相同的，除了報文2和5的時間延時較長：

逐一分析這六個報文，立刻就會看到第一次延時。客戶端（172.16.16.128）傳送首次SYN報文以開始TCP握手，在伺服器（74.125.95.104）返回SYN/ACK之前，有0.87秒的延時。這是線路延時的第一個訊號，這是由客戶端和伺服器之間的裝置引起的。

我們判斷這是線路延時的依據是所傳送的報文型別特徵。當伺服器接收到一個SYN報文，只需花費很少的處理過程就可傳送回覆，因為這一工作負載並不包含任何傳輸層之上的處理。即使伺服器工作負載非常繁重，它通常也會快速地以SYN/ACK來回復SYN報文。這就排除了伺服器是高延時的潛在原因。

客戶端也被排除的原因在於，它除了接收SYN/ACK報文之外，沒有進行任何處理。

這一抓包的前兩個報文幫我們排除了客戶端和伺服器，並指出了潛在原因。

繼續分析，我們發現結束三步握手訊號的ACK報文快速出現，客戶端傳送的HTTP GET請求也是如此。產生這兩個報文的所有處理在本地客戶端接收到SYN/ACK之後進行，因此在客戶端沒有繁重的負載需要處理的情況下，這兩個報文預計會很快傳送。

到了報文5，我們看到另一個延時高得離譜的報文。出現在最初的HTTP GET請求傳送過後，從伺服器返回的ACK報文花費了1.15秒才收到。接收到HTTP GET請求之後，伺服器在開始傳送資料之前首先傳送了一個TCP ACK，同樣只需佔用伺服器很少的處理。這是另一個線路延時的訊號。

不管何時你經歷著線路延時，你幾乎總是會看到：在最初的握手訊號期間的SYN/ACK報文，以及整個通訊過程的ACK報文中，存在著高延時。即使這一資訊並沒有告訴你網路上延時的確切原因，至少讓你明白客戶端和伺服器都不是延時點所在，因此延時發生在兩者之間的裝置。這時，你應當開始檢查受影響主機之間的各種防火牆，路由器，以及代理，以定位罪魁禍首。

慢速通訊——客戶端延時：

下一個延時場景的抓包如下圖所示：

這一抓包開始時很正常，TCP握手非常迅速，沒有任何延時的跡象。正常狀態持續至第四個報文：握手訊號結束之後接收到一個HTTP GET請求。這個報文距離前一個接收到的報文有1.34秒的延時。

要確認網路的延時點，需要檢查第3和第4個報文之間發生了什麼。報文3是客戶端傳送到伺服器的TCP握手訊號中的最後一個ACK，報文4是從客戶端傳送至伺服器的GET請求。這兩個報文的共同之處在於都是由客戶端傳送，並且獨立於伺服器。由於所有這些操作都集中在客戶端上，GET請求應當在傳送了ACK之後快速傳送。

不幸的是對於終端使用者，從ACK到GET的傳送並沒有快速發生。GET報文的建立與傳輸取決於應用層的處理，這一過程中的延時意味著客戶端無法及時的執行這一功能。這表示客戶端最終為通訊中的高延時負責。

慢速通訊——伺服器延時：

最後一個延時場景的抓包如下圖所示：

在這一抓包中，兩個主機之間的TCP握手過程完成得乾脆利落，因此開始時並無問題。接下來幾個報文也很順利，首個GET請求及回覆ACK報文也在快速交付。直到最後一個報文，我們看到了高延時的訊號。

第六個報文是伺服器響應客戶端GET請求的第一個HTTP資料包文，但是在伺服器傳送GET請求的TCP ACK 0.98秒之後才到達。報文5和6的傳送過程與我們在前一個場景所見ACK和GTE請求的傳送類似。但是，在這一情況下，伺服器是我們關注的焦點。

報文5是伺服器對從客戶端接收GET請求的回應。只要該報文被髮送，伺服器就應當立即傳送資料。這一讀取，封裝，傳送的過程是由HTTP協議完成的，由於這是應用層協議，需要伺服器參與處理過程。這一報文的延遲接收表明伺服器無法在合理的時間內處理資料，最終指向伺服器是延時點。

延時定位思路：

通過六個報文，我們能夠定位伺服器與客戶端之間的網路高延時點。這些場景可能看起來有點複雜，但是下圖能使你的定位延時過程變得簡單快捷。這一原則幾乎能應用於任何基於TCP的通訊。

本文系列目錄：

相關文章