上一篇文章中，我们利用 wireshark 排查定位了 TCP 的连接问题与重传问题：

实战网络问题排查（四） -- 利用 wireshark 排查 TCP 连接与重传问题

TCP 有另一个常见的问题 -- 重复 ACK 与快速重传，本文我们就来看看这样的问题如何通过 wireshark 来排查和定位。

超时重传机制让 TCP 避免了因为网络异常等原因导致的丢包，但超时重传机制也伴随着许多问题，比如：

由此，TCP 诞生了快速重传机制。

接收方只要收到了比期望的序列号大的报文，这就说明发生了乱序，此时不必等待超时的发生，而是立即重复 ACK 当前期望的序列号。

当发送方接收到 N 个重复的额外 ACK，也就是第 N+1 次接收到同一个序列号的报文时，就认为该报文已经丢失，立即重传该报文。

相比于超时重传机制，快速重传机制将时间触发机制改为了事件触发机制，接收端接收三个报文的耗时通常要远低于重传超时，同时，已经接收到的后续报文在快速重传发生后，也不会被清除，而是会 ACK 后续未收到的序列号。

下图展示了这一机制的过程：

同时，伴随着快速恢复算法，在发生快速重传后，发送方会立即将发送速率减半甚至降到最低，这对通信效率的影响是非常大的。

但是，由于 IP 协议包的无序性，偶发的 TCP 快速重传是可以接受的，如果有 1% 以上的快速重传，那就需要引起注意了。

在 wireshark 中，重复 ACK 的关键字是“TCP Dup ACK”，快速重传的关键字是“TCP Fast Retransmission”。

如图所示，就是一个51个重复ACK之后发生了快速重传的例子：

快速重传是由于乱序或丢包引起的，通常原因是网络延迟或抖动造成的。

可以重点检查服务器或链路中的各个节点的缓存和 CPU 负载情况或者有条件的话可以更换网络环境。

根据上文所述，多次连续的重复 ACK 会触发 TCP 快速重传机制，但即使没有达到连续触发次数，重复 ACK 可能也同样意味着网络异常的存在。

报文乱序的情况在 wireshark 中有三种现象：

如图所示：

如果你是在通过 wireshark 抓包时发现这一现象，那么有可能是 wireshark 本身的原因造成的，如果你仅仅看到乱序报文，但没有看到对可能丢失及乱序报文的响应，这说明实际上可能并没有问题。

在 TCP 传输过程中，如果封装 TCP 报文段的 IP 数据包走了不同的路由线路，就有可能造成乱序情况发生，可以借助 traceroute 工具检查路由情况，进而判断是否某个路由链路传输效率存在问题。

对于内部网络，可以在路由器上配置 SNMP trap，让网管软件自动报警。

https://datatracker.ietf.org/doc/html/rfc793

《Network Analysis Using Wireshark Cookbook》