網絡基本功(二十四):Wireshark抓包實例分析TCP重傳

網絡基本功(二十四):Wireshark抓包實例分析TCP重傳

 

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

 

介紹

 

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服務器發回。

p_w_picpath002.jpg

 

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

  1. Statistics菜單,打開IO Graph

  2. 本例中,可看到鏈路負載非常低。可能是有故障,或有另一條高負載鏈路。

  3. 可以通過登錄到通信設備或SNMP瀏覽器查看引起重傳的原因:報文丟失及錯誤。參考以下截屏:

p_w_picpath003.jpg

 

Case 2:重傳至單一連接

如果所有重傳發生於同一IP,同一TCP端口號,則可能是慢速應用引起。看以下截屏:

p_w_picpath004.jpg

 

對於單一連接的重傳,進行以下操作:

  1. 從Statistics菜單打開Conversations,選擇Limit to display filter,可以看到所有發生重傳的會話,本情況下,是一個單一會話。

  2. 如下圖所示,通過選擇IPv4標籤可看到從哪個IP地址重傳:

p_w_picpath005.jpg

 

   3.  如下圖所示,通過選擇TCP標籤看到重傳來自哪一端口:

p_w_picpath006.jpg

 

要定位問題,進行以下步驟:

  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)。

p_w_picpath007.jpg


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

p_w_picpath008.jpg

可以看見重傳總是週期性的每30ms發生一次。問題是由於客戶端在軟件中執行了財務進程,導致軟件每30-36ms就減速一次。

 

Case 4:應用無響應導致重傳

另一個可能導致重傳的原因是客戶端或服務器沒有響應請求。這種情況下,會看到五次重傳,時間也會逐漸延長。五次連續重傳後,發送方認爲連接斷開(某些情況下,會發送reset來關閉連接,取決於軟件實施)。斷開連接之後,可能會發生兩件事情:

  • 發送SYN請求至客戶端,以打開一個新的連接。這種情況下用戶會看到應用凍結,過了15-20秒之後重新開始工作。

  • 不發送SYN,用戶需要重新運行應用程序(或應用程序的一部分)

下圖顯示了打開新連接的情況:

p_w_picpath009.jpg

 

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重傳 。


以下圖中展示了重傳減少發送方吞吐量(紅色細線):

p_w_picpath010.jpg

 

 

 

參考

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章