網絡基本功（二十五）：Wireshark抓包實例分析TCP重複ACK與亂序
轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 
介紹
TCP的一大常見問題在於重複ACK與快速重傳。這一現象的發生也是由於性能問題，本章討論如何發現這一問題以及他們意味着什麼。
另一個常見問題是前一片段丟失以及亂序片段。某些情況下，這一現象喻示着故障發生，可能是由於網絡問題或是抓包中斷。
更多信息
重複ACK與快速重傳:
當網速變慢時，重複ACK是可能的原因之一。大多數情況下，重複ACK的發生是由於高延時，延遲的變化，或無法響應ACK請求的慢速終端。
當重複ACK的數量保持在合理範圍時，即1或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對於收到亂序報文的響應。
抓包問題：這時僅看到亂序報文，但沒有看到對可能丟失及亂序報文的響應，可能實際上並沒有問題。