TCP重传率飙升怎么查？一次生产环境排障的完整复盘

TCP重传率飙升怎么查？一次生产环境排障的完整复盘

故障背景

某制造企业 ERP 系统运行稳定了三年，某个周一早上业务方突然反映：系统登录极慢，有时需要 30 秒以上，但偶尔又完全正常。

运维团队检查了一遍常规指标：

• 服务器 CPU / 内存：正常
• 数据库响应时间：正常
• 交换机接口利用率：<20%
• ICMP 延迟：<1ms

一切看起来都没问题。但用户的投诉没有停。

这种"指标正常但体验很差"的故障，往往是 TCP 层的问题。本文完整复盘这次排障过程，以及如何系统性地识别和定位 TCP 重传、连接异常。

---

什么是 TCP 重传？为什么它会影响用户体验？

TCP 是可靠传输协议。当发送方发出一个数据包后，等待一段时间（RTO，重传超时）没有收到确认，就会重发这个包。

重传的代价：

1. 延迟翻倍甚至更多：初始 RTO 通常在 200ms～1s，每次重传后 RTO 指数退避，第二次重传等待 2s，第三次 4s，以此类推
2. 吞吐量下降：TCP 拥塞控制会在检测到丢包后将发送窗口减半
3. 连接假死：大量重传堆积时，应用层会感知到响应"卡住"

对于交互式应用（ERP、数据库、SSH），哪怕 0.1% 的重传率，用户也能明显感受到延迟。

---

第一步：用 Wireshark / tcpdump 捕获流量

首先在 ERP 服务器的网卡上抓包：

# 抓取与 ERP 服务器（192.168.10.50）的所有 TCP 流量，保存 5 分钟
tcpdump -i eth0 host 192.168.10.50 and tcp -w /tmp/erp_capture.pcap -G 300 -W 1

或者在核心交换机配置 SPAN 口，用独立的抓包设备持续捕获。

抓到包后，用 Wireshark 打开，第一步是快速定位重传：

方法一：过滤器直接找重传包

tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.spurious_retransmission

方法二：Statistics → TCP Stream Graphs → Time-Sequence Graph

可以直观看到传输窗口收缩和包的重传时间点。

方法三：Expert Information 一键扫描

Analyze → Expert Information，Wireshark 会列出所有异常，包括重传、乱序、窗口满、重置等，按严重程度分类。

---

第二步：识别重传的根因类型

不同类型的重传，根因完全不同。

类型一：超时重传（RTO Retransmission）

特征：

• 重传发生在原始包之后 200ms 以上
• 重传后通常跟着窗口减小
• 经常伴随 TCP Zero Window 或长时间无响应

常见原因：

• 链路丢包（光纤接头脏、光模块老化、网线质量差）
• 网络设备队列拥塞（QoS 配置不当，突发流量）
• 接收方处理慢，ACK 回来太迟

类型二：快速重传（Fast Retransmission）

特征：

• 收到 3 个重复 ACK 后立刻重传
• 重传时间间隔极短（<1ms）
• 说明包确实丢了但后续包到达了

常见原因：

• 路径上存在随机丢包（无线网络、运营商链路）
• 多条负载均衡路径的乱序

类型三：虚假重传（Spurious Retransmission）

特征：

• Wireshark 标记为 [Spurious Retransmission]
• 重传后收到原始 ACK（说明原始包其实到了）

常见原因：

• RTO 设置过小（服务器 TCP 参数配置问题）
• 网络延迟突然抖动超过 RTO

---

第三步：案例分析------这次故障的定位过程

回到这次 ERP 故障。打开抓包文件后，过滤重传：

tcp.analysis.retransmission

发现重传包集中在 ERP 服务器（192.168.10.50）→ 数据库服务器（192.168.10.20） 方向，时间间隔约 220ms，符合超时重传特征。

重点关注了两台服务器之间的 TCP 流（tcp.stream eq 47），发现一个规律：每隔约 3 分钟，就会出现一段 2-4 秒的传输停滞，然后出现一次 RTO 重传。

3 分钟一次，这个周期很有规律。不像随机丢包，更像是某个定时任务或设备行为。

排查方向转向网络设备：

检查 ERP 服务器和数据库服务器之间经过的接入层交换机，发现该交换机开启了 Spanning Tree TCN（拓扑变更通知），每次 TCN 触发时，MAC 地址表会被清空，在 MAC 表重建期间，单播流量会被泛洪，引发短暂的拥塞和丢包。

进一步查 STP 日志，发现每 3 分钟左右有一台 IP 摄像头在重连，每次重连触发一次 TCN。

解决方案：

1. 在摄像头连接的端口上启用 portfast + bpduguard，防止终端设备触发 STP TCN
2. 同时优化 ERP 服务器的 TCP keepalive 参数，避免连接假死

故障修复后，重传率从 0.8% 降至 0.02%，用户投诉清零。

---

第四步：TCP 连接异常的其他常见场景

除了重传，以下几类 TCP 异常也值得关注：

连接重置（RST）

tcp.flags.reset == 1

常见原因：

• 防火墙 ACL 拒绝（RST 由防火墙注入）
• 应用崩溃或异常退出
• NAT 超时后收到迟到的包

窗口满（Zero Window）

tcp.analysis.zero_window

接收方缓冲区已满，发送方被迫等待。说明接收方处理能力不足，可能是应用性能问题，也可能是服务器内存压力。

连接建立失败（SYN 无响应）

tcp.flags.syn == 1 and tcp.flags.ack == 0

过滤出所有 SYN 包，找没有对应 SYN-ACK 的------这是连接根本没建立成功，通常指向防火墙、路由黑洞或服务端口未监听。

---

生产环境建议：从被动抓包到持续监控

上面的流程有一个前提：你得在故障发生时恰好在抓包。

但很多间歇性故障不会等你去抓。用户说"刚才又慢了"，你打开 Wireshark，什么都看不到了。

更实用的生产环境方案是部署持续全流量捕获系统：

• 7×24 持续在关键链路上捕获，保留历史 72 小时或更长
• 实时计算重传率、RTT、连接成功率等指标
• 故障发生后，可以回溯任意时间段的流量，复现问题

这类系统不需要你猜"要不要抓包"，所有数据都在那里等你。

AnaTraf 网络全流量分析仪 就是做这个的：在核心交换机 SPAN 口部署，持续捕获并分析全流量，支持按 IP、端口、协议、时间段快速检索，定位 TCP 重传、连接异常、应用延迟的根因，平均排障时间从小时级降到分钟级。

---

总结

问题现象	可能的 TCP 异常	定位方法
应用偶发超时	RTO 重传	过滤 tcp.analysis.retransmission，看时间间隔
吞吐量低于预期	拥塞窗口收缩	TCP Stream Graph，观察 cwnd 变化
连接频繁断开	RST 注入	过滤 tcp.flags.reset，查 RST 来源
应用响应卡顿	Zero Window	过滤 tcp.analysis.zero_window
间歇性连接失败	SYN 无响应	过滤无 ACK 的 SYN，查路由/防火墙

TCP 问题的排查核心是：看数据包，不要只看指标。指标告诉你"有问题"，数据包告诉你"为什么"。