網絡基本功（二十四）：Wireshark抓包實例分析TCP重傳

網絡基本功（二十四）：Wireshark抓包實例分析TCP重傳

 

轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 

 

介紹

 

TCP發送一個或一組報文，會等待收到報文的確認信息。重傳，即發生在報文沒有到達或確認信息沒有及時返回的狀況下。當發現網速變慢時，緣由之一可能就是重傳。發生重傳的緣由有多種，在客戶機或服務器兩邊端口應用Wireshark有助於診斷問題。本文經過抓包實例闡述各類可能性。

更多信息

 

診斷過程:

 

1. 在相應端口開始抓數據。

2. 找到Analyze | Expert Info菜單。

3. 在Notes之下，查找Retransmission。

4. 點擊（+）符號便可打開重傳列表。鼠標點擊各行可在抓包面板看到重傳報文。

5. 如今問題來了，怎樣定位問題呢？

6. 經過如下方式查看重傳來自哪裏：

• 在Expert Info窗口一個一個查看報文，在抓包面板查看哪些是重傳報文（適合於有經驗的用戶）

• 在報文面板，配置顯示過濾器expert.message == 「Retransmission (suspected)」，便可看到抓包文件中全部重傳報文

• 應用過濾器，在Statistics & Conversations窗口查看Limit to display filter部分。

 

Case 1：重傳至多個目的地址

如下截屏中，可看到有屢次重傳，分佈於多臺服務器，目的端口號爲80（HTTP）。也能夠發現重傳由端口10.0.0.5發送，所以報文是丟失在發往Internet的途中，或確認信息沒有及時從web服務器發回。

 

問題發生在發往Internet的線路上，怎樣知道是什麼問題呢？

1. 從Statistics菜單，打開IO Graph。

2. 本例中，可看到鏈路負載很是低。多是有故障，或有另外一條高負載鏈路。

3. 能夠經過登陸到通訊設備或SNMP瀏覽器查看引發重傳的緣由：報文丟失及錯誤。參考如下截屏：

 

Case 2：重傳至單一鏈接

若是全部重傳發生於同一IP，同一TCP端口號，則多是慢速應用引發。看如下截屏：

 

對於單一鏈接的重傳，進行如下操做：

1. 從Statistics菜單打開Conversations，選擇Limit to display filter，能夠看到全部發生重傳的會話，本狀況下，是一個單一會話。

2. 以下圖所示，經過選擇IPv4標籤可看到從哪一個IP地址重傳：
   

 

   3.  以下圖所示，經過選擇TCP標籤看到重傳來自哪一端口：

 

要定位問題，進行如下步驟：

1. 查看IO graph，確保鏈路不忙。（鏈路忙的表徵例如流量接近帶寬。例如，帶寬爲10Mbps，在IO graph中看見流量接近10Mbps，這就代表鏈路負載較高。不忙的鏈路IO會有不少高低起落，峯值以及空閒間隙）。

2. 若是鏈路不忙，則多是服務器對於IP地址10.1.1.200有問題（10.90.30.12發送了絕大多數重傳，因此多是10.1.1.200響應較慢）

3. 從報文面板能夠看出應用是FTP數據。有可能FTP服務器工做於active模式。所以在端口2350打開鏈接，服務器將端口更改成1972，因此多是慢速FTP軟件響應問題引發的重傳。

 

Case 3：重傳模式

觀察TCP重傳的一個重要考量是是否能看出一些重傳模式。在如下截屏中，能夠看見全部重傳來自單一鏈接，位於客戶端與服務器的NetBIOS會話服務（TCP端口139）。

看起來像一個簡單的服務器/客戶端問題，但查看抓包面板，以下圖所示：

能夠看見重傳老是週期性的每30ms發生一次。問題是因爲客戶端在軟件中執行了財務進程，致使軟件每30-36ms就減速一次。

 

Case 4：應用無響應致使重傳

另外一個可能致使重傳的緣由是客戶端或服務器沒有響應請求。這種狀況下，會看到五次重傳，時間也會逐漸延長。五次連續重傳後，發送方認爲鏈接斷開（某些狀況下，會發送reset來關閉鏈接，取決於軟件實施）。斷開鏈接以後，可能會發生兩件事情：

• 發送SYN請求至客戶端，以打開一個新的鏈接。這種狀況下用戶會看到應用凍結，過了15-20秒以後從新開始工做。

• 不發送SYN，用戶須要從新運行應用程序（或應用程序的一部分）

下圖顯示了打開新鏈接的狀況：

 

Case 5：因爲延時變化致使重傳

TCP可以充分容忍延時，前提是延時大小不發生變化。當延時改變時，就會發生重傳。診斷是否由該緣由引發的方法：

1. 第一件事是ping目的地址，而且獲得檢查通訊鏈路延時的第一條信息。

2. 檢查延時變量，可能由如下緣由引發：

• 因爲不穩定或繁忙通訊鏈路引發。這種狀況下，能夠看到ping命令的延時變化，一般因爲帶寬較窄。

• 因爲應用過載或資源不足，這種狀況下，只有該應用發生不少重傳。

• 通訊設備過載（CPU,緩存）引發延時。檢查方式直接鏈接通訊設備。

   3.  使用Wireshark工具診斷延時問題。

若是重傳達到0.5個百分比，性能就會降低，斷開鏈接將會達到5個百分比。這取決於應用及其對於重傳的敏感性。

 

定位重傳問題

當你看到通訊鏈路上發生重傳，進行如下步驟：

1. 定位問題——是一個特定IP地址，特定鏈接，特定應用，仍是其餘問題。

2. 查看問題是否因爲通訊鏈路，丟包，慢速服務器仍是PC。查看應用是否慢速。

3. 若是不是因爲上述緣由，檢查延時變化。

 

工做原理:

 

TCP序列號/確認機制詳見前文：網絡基本功（十）：細說TCP確認機制 。那麼重傳是由什麼緣由引發呢？當報文確認信息丟失，或ACK沒有及時到達，發送方會進行如下兩步操做：

1. 再次發送報文

2. 減小吞吐量。

更多TCP重傳內容詳見前文：網絡基本功（九）：細說TCP重傳 。

如下圖中展現了重傳減小發送方吞吐量（紅色細線）：

 

 

 

參考