2023年7月3日发(作者：)

Wireshark抓包实例分析TCP重复ACK与乱序介绍

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对于收到乱序报⽂的响应。抓包问题：这时仅看到乱序报⽂，但没有看到对可能丢失及乱序报⽂的响应，可能实际上并没有问题。