網絡基本功（二十五）：Wireshark抓包實例分析TCP重複ACK與亂序

網絡基本功（二十五）：Wireshark抓包實例分析TCP重複ACK與亂序

 

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

 

介紹

 

TCP的一大常見問題在於重複ACK與快速重傳。這一現象的發生也是因爲性能問題，本章討論如何發現這一問題以及他們意味着什麼。

另外一個常見問題是前一片斷丟失以及亂序片斷。某些狀況下，這一現象喻示着故障發生，多是因爲網絡問題或是抓包中斷。

更多信息

 

重複ACK與快速重傳:

 

當網速變慢時，重複ACK是可能的緣由之一。大多數狀況下，重複ACK的發生是因爲高延時，延遲的變化，或沒法響應ACK請求的慢速終端。

 

1. 當重複ACK的數量保持在合理範圍時，即1或2個百分比，則可能不是本機問題。

2. 當有大量的重複ACK時（假設有10個），則可能：

• 通訊鏈路繁忙引發延遲改變

• 服務器或客戶端無響應

   3.  快速重傳是對重複ACK的響應報文。

   4. 下圖是該問題的示例。本例中51個重複ACK以後發生了快速重傳：

 

    5. 如下是如何解決該問題：

• 若是重複ACK和重傳數量較少（少於1個百分比），是能夠接受的。

• 若是重複ACK發生在無線網絡環境，或是Internet之上的鏈接，延時或是延時的改變對於這類網絡來講很常見，因此也沒有什麼可作的。

• 若是發生在組織內的網絡，則可能有問題。若是發生在LAN之上，檢查嚴重的問題，例如緩存和CPU負載，慢速服務器，等等。若是發生在WAN之上，查看延時，負載以及線路不穩定。

 

工做原理

當發現有丟失報文時（指望的序列號沒有收到），或者收到了預期以外的序列號。這種狀況下，接收端生成一個ACK，聲明本身但願收到的下一個序列號。接收方持續生成丟失片斷的ACK請求，直到實際收到。

 

在發送方，當它收到三個相同的ACK（初始ACK和兩個重複ACK），就會假設有報文丟失並重傳該報文，不管重傳計時器是否過時。再次發送的報文稱爲快速重傳。

 

重複ACK也減小了發往網絡的吞吐量。減小了多少吞吐量取決於TCP版本。比較早期的TCP版本中出現了重複ACK，發送方將吞吐量減小爲以前的一半。在多個DupACK的狀況下，吞吐量減到最小。

 

下圖顯示了重複ACK和重傳的典型例子，本圖中第一次重複ACK將吞吐量下降至大約40%，以後重傳將吞吐量減至最小。

 

 

亂序報文:

 

在兩端抓包，亂序狀況下須要關注三種現象：

• 先前片斷丟失：當前收到報文的序列號高於該鏈接的下一個指望序列號時，代表以前的一個或多個報文未能到達

• 亂序報文：當前報文的序列號低於該鏈接先前收到的報文

• 先前片斷未能捕捉：（Wireshark 1.8.x及以上版本）：同先前報文丟失。

 

什麼時候發生？

用戶可能在如下狀況看到亂序報文：

• 鏈接開始時抓包：當創建鏈接時抓包，這時，看到鏈接上的報文沒有SYN/SYN-ACK/ACK，所以，Wireshark認爲鏈接有問題。

 

• 確實有報文丟失：這時會看到丟失報文重傳和/或重複ACK告知發送方重傳丟失報文。

 

上圖是報文丟失的典型示例。從圖中可見，10.0.0.6嘗試瀏覽站點62.90.90.210。這一過程當中， TCP片斷每一個1420字節發送到web服務器，334到336之間3個報文丟失，338到340之間2個報文丟失。二者Wireshark都有提示：TCP’s previous segment is not captured.

 

• 延時變化：這多是因爲報文從源地址到目的地址經由不一樣的路由。檢查這一點可使用Tracert，在源和目的地址之間查找路由改變。若是在公司內部網絡上是能夠作到的，例如，在路由器上配置trap。

 

• 數據捕捉問題：可能報文正常收發，但Wireshark沒有捕捉到。可能有如下幾種緣由：

  • 數據量比較大時，Wireshark在高比特率的狀況下可能會丟失報文（高於150-180 Mbps）。要避免這一問題，使用其餘工具（大多數須要付費）。

  • 臺式機不夠強大，內存或CPU沒法讓Wireshark工做的足夠快。這一點很好發現。

  • 當LAN交換機的端口緩存過小，報文可能被丟棄。鏈接到交換機（用控制檯或telnet鏈接）使用交換機命令行來檢查該問題。

  • 無線網絡抓包，因爲某種緣由沒有看到全部發送報文。

 

總結

亂序報文的原理很簡單。TCP發送以其字節數爲編號的報文到接收方。當一個報文沒有按照順序到達時，Wireshark就會注意到。緣由有兩點：

• 確實有問題：這時會看到重傳和重複ACK，這是TCP對於收到亂序報文的響應。

• 抓包問題：這時僅看到亂序報文，但沒有看到對可能丟失及亂序報文的響應，可能實際上並無問題。