实战网络问题排查（五） -- 利用 wireshark 排查 TCP 快速重传问题

1. 引言

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

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

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

2. 快速重传机制

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

1. 当一个报文段丢失，会等待一定的超时周期然后才重传分组，增加了端到端的时延。
2. 当一个报文段丢失时，由于接收端一直在等待，导致其后的报文段已经被接收端接收但却迟迟得不到确认，造成超时的连锁反应，全部都不得不被重传，浪费了不必要的资源。

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

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

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

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

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

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

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

3. 通过 wireshark 排查 TCP 快速重传

3.1 wireshark 中的快速重传

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

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

<img id="3378730"/>

3.2 问题排查

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

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

4. wireshark 定位乱序现象

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

4.1 wireshark 中的现象

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

1. Previous segment lost -- 收到报文的序列号高于该连接的下一个期望序列号，这说明之前的一个或多个报文未能到达。
2. Out-of-order packet -- 当前报文的序列号低于该连接先前收到的报文，说明发生了乱序。
3. Previous segment not captured -- 报文丢失。

如图所示：

<img id="3378731"/>

4.2 问题定位

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

4.2.1 wireshark 抓包问题

1. 由于 wireshark 仅支持 150Mbit/s 以下的传输速度下进行抓包，如果传输速度超过这一阈值，就有可能导致 wireshark 本身在抓包过程中无法捕获部分包，可以更换其他抓包工具进行抓包。
2. 可以检查计算机的 CPU、内存等硬件资源是否充足。
3. 检查交换机端口缓存容量是否太小。
4. wireshark 本身在抓取无线网卡时，可能会有抓不全的情况。

4.2.2 网络延迟

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

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

参考资料

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

《Network Analysis Using Wireshark Cookbook》