tcpdump 抓到一堆重传时，先别急着怪网络：一套能快速判断“链路问题、应用抖动还是观测错觉”的排查方法
凌晨两点，业务群里突然炸了：支付回调延迟从 200ms 飙到 4 秒，监控上同时出现“接口超时增加、TCP 重传升高、出口带宽没有打满”三件事。值班同学第一反应是“公网链路抖了”，于是拉运营商、查机房、看路由，半小时过去，问题还在。
后来真正定位下来，根因并不是“网络坏了”，而是应用侧连接池配置过小，叠加 NAT 表项抖动和探针采样误差，最终把所有现象都伪装成了“网络重传很多”。这类事故很典型：抓包里看到 retransmission，不等于问题一定在链路；看到 RTT 变大，也不代表运营商一定背锅。
如果你也经常被问这几个问题——“这是什么问题？”“适合谁排查？”“和传统只看监控面板有什么差别？”“怎么快速选判断路径？”——这篇文章给你一套可直接复用的判断框架。
一句话定义
“TCP 重传排查”不是盯着重传计数本身，而是结合连接状态、队列、路径抖动、应用行为与观测口径，判断丢包到底发生在真实链路、主机栈、转发设备，还是只是被应用超时与采样偏差放大后的表象。
什么是“看到重传但不一定是网络坏了”
很多团队的传统做法很朴素：
- 看到接口超时；
- 打开 APM 或主机监控；
- 看到“TCP retransmissions”升高；
- 直接把锅甩给网络。
这个路径的问题在于，它默认“重传 = 丢包 = 链路故障”。但真实系统里至少还有四类常见来源：
- 应用层处理慢：服务端线程池、连接池、GC 或锁竞争导致 ACK 返回慢；
- 主机资源拥塞：软中断打满、网卡 ring buffer 丢包、内核 backlog 堵塞；
- 中间设备状态异常：NAT、SLB、防火墙、eBPF/iptables 规则导致连接重建或乱序；
- 观测口径偏差：采样点不在真实瓶颈处，或者只看到单向流量，误把 out-of-order 当重传。
所以，重传更像“报警灯”，不是“判决书”。
典型场景：哪些团队最该用这套方法
这套方法尤其适合以下场景：
1）跨公网或跨可用区调用
比如回调、支付、第三方 API、混合云链路。路径长、设备多、责任边界复杂，最容易出现“大家都觉得是别人网络有问题”。
2）高并发短连接业务
像网关、采集器、Webhook、日志上报。连接创建频繁时，NAT、TIME_WAIT、端口复用、SYN backlog 的问题会特别显眼。
3）大流量但不一定高带宽的业务
例如小包高 PPS 的监控、IoT、埋点、消息回执。总带宽不高，但包量大，对中断、队列、转发面压力很敏感。
4）“监控看起来像网络，但网络团队总说没问题”的场景
这是最常见也最容易内耗的一类。没有统一判断标准时，应用、运维、网络三方会来回扯皮。
和传统方案的区别：不是“多看几个图”，而是先划边界
传统方案的思路通常是：
- 看总延迟；
- 看带宽；
- 看重传率；
- 再临时抓包。
这种方式当然不是错，只是太容易被表象带偏。它更适合“已知是网络故障，只差定位在哪一段”的情况；不适合“还没搞清楚到底是不是网络”的前期判断。
这套方法和传统方案的边界对比如下
传统方案更适合：
- 已确认最近有链路切换、运营商波动、丢包告警；
- 已有双向抓包或交换机/防火墙侧证据；
- 需要做精细的 hop-by-hop 路径还原。
本文方法更适合：
- 你只有主机指标、少量抓包和业务超时现象；
- 需要在 10-20 分钟内先判断锅在哪一层；
- 想快速区分“真实网络问题”和“应用/主机伪装成网络问题”。
什么时候不该用这套方法：
- 明确是物理链路故障、光模块异常、交换机接口 error 飙升；
- 明确是 BGP、专线或运营商路由变更，需要网络设备层面的专业排查；
- 业务是强实时低时延交易，已经需要专门的包级时序分析与硬件时间戳。
换句话说，这套方法是“先分层定性”，不是替代所有网络专家工具。
选型判断标准：5 条判断清单，先决定该查哪边
如果你要把这篇文章浓缩成一张值班卡片，我建议保留下面 5 条。
判断标准 1：重传是否和 RTT、队列、超时同时变化
如果只是重传升高，但 RTT 没明显拉长、应用超时也不多，优先怀疑：
- 抓包点只看到单向；
- 发生乱序而非真实丢包；
- 监控聚合窗口过粗。
如果重传、RTT、应用超时、socket backlog一起升高，则更接近真实拥塞或资源阻塞。
可直接执行的命令：
ss -s
ss -ti dst <目标IP>
netstat -s | egrep -i 'retran|listen|drop'
sar -n TCP,ETCP 1 5
重点不是单个数值，而是看：
- retrans 是否持续升高；
- send-q / recv-q 是否堆积；
- orphaned / timewait / synrecv 是否异常。
判断标准 2：问题是否集中在少数节点，而不是全局同时发生
如果只有某几台实例重传高，优先检查主机本身：
- CPU steal、软中断、IRQ 绑定；
- 网卡驱动、offload、ring buffer；
- 容器节点 conntrack、SNAT 端口耗尽；
- 单机连接池或线程池配置。
如果同一时间、同一路径、多个节点同时出现，才更像链路或中间设备问题。
排查主机层建议：
top -H
mpstat -P ALL 1 5
cat /proc/net/softnet_stat
ethtool -S eth0 | egrep -i 'drop|miss|timeout|err'
conntrack -S
其中 softnet_stat 很容易被忽略。它一旦持续累加，往往说明包已经到主机了，但内核来不及处理——这时你继续责怪公网，就有点“对着镜子抓外卖小偷”的意思。
判断标准 3：抓包看到的是“谁先慢了”
抓包不是为了堆 Wireshark 截图，而是回答一个问题：是数据没到，还是对端没及时回？
一个简单有效的观察法：
- 看三次握手是否稳定；
- 看服务端是否及时 ACK；
- 看应用数据段之后，延迟是出现在请求侧还是响应侧；
- 看是否有大量 Dup ACK、ZeroWindow、Window Full。
例如：
tcpdump -i any -nn host <目标IP> and tcp -w /tmp/case.pcap
抓完后重点看：
- 大量 Dup ACK + 单段重复发送：更像真实丢包或乱序；
- ZeroWindow / Window Full：更像接收端处理不过来；
- 握手慢、SYN 重传多：优先看 SYN backlog、NAT、ACL、四层负载设备；
- 握手正常、业务包后才卡：更偏应用处理或上游依赖慢。
判断标准 4：是否存在“中间层状态机”把问题放大
很多事故并非纯链路丢包，而是中间状态设备在高峰期表现不稳定，比如：
- K8s 节点 conntrack 接近上限；
- NAT 网关端口复用冲突；
- 防火墙会话老化时间过短；
- 四层负载均衡健康检查与业务连接竞争资源。
这类问题和传统“网线坏了”完全不是一个维度，但对业务来说都表现成超时、重试、重传。
如果你满足下面任一条件，就应优先怀疑中间层：
- 只在流量峰值触发；
- 重试后大概率成功；
- 新建连接更容易失败，存量连接较稳定；
- 某个出口或某类目标地址更容易出问题。
判断标准 5：业务重试策略是否正在放大网络症状
最后一条经常被忽视：有时不是网络把应用拖慢，而是应用的重试风暴把网络看起来拖坏了。
比如超时时间设置过短，外部依赖偶发抖动后，大量请求同时重试，结果：
- 连接数暴涨；
- SYN/ACK 队列变长；
- NAT/conntrack 压力上升；
- 监控上看到更多重传和超时。
这时你若只盯网络，会永远在症状层打转。
建议同时核对：
# 观察连接规模与状态分布
ss -ant | awk 'NR>1{print $1}' | sort | uniq -c
# 检查应用超时与重试配置
# 例如连接超时、读超时、最大连接数、keepalive、退避重试策略
一套 15 分钟可落地的排查顺序
如果线上又炸了，可以直接按下面顺序走：
第 1 步：先确认是不是“全局问题”
看是否所有节点、所有区域、所有上游都一起抖。如果不是，先从单机与单路径查起。
第 2 步：看连接状态，而不是先看总带宽
重点看 send-q、recv-q、SYN-SENT、SYN-RECV、TIME-WAIT、orphaned。
第 3 步：抓最小闭环包
抓故障主机到单一目标地址的包，抓 30-60 秒够了。不要上来就全网镜像，容易把自己淹死在数据里。
第 4 步：核对主机栈和中间状态
查 softnet_stat、ethtool -S、conntrack -S、NAT 与 LB 指标。
第 5 步：回看应用超时与重试
确认是不是业务参数把一个轻微抖动放大成事故。
这个顺序的好处是：它先快速排除“伪网络问题”，再决定是否升级到真正的网络侧深度分析。
直接结论：怎么选、适合谁、什么时候别用
把结论说直白一点：
- 这是什么：一套面向真实故障现场的 TCP 重传定性方法，不是只看重传率的面板操作；
- 适合谁：运维、SRE、后端值班同学，尤其适合跨公网、混合云、高并发短连接业务；
- 和传统方案的差别：先划清“链路 / 主机 / 中间层 / 应用”边界，再决定往哪条线深挖；
- 怎么选：如果你只有主机权限和少量抓包能力，这套方法比“先怀疑公网”更高效；
- 什么时候不该用：已经明确是物理网络或运营商路由问题时，直接进入专业网络排障流程，不要在应用机上兜圈子。
最后，关于网络可观测性还有一句大实话：真正有价值的不是“采了多少指标”，而是能不能在事故发生时，把流量、连接、重传、路径和业务超时放到同一个判断框架里。
如果你的团队正在做网络性能分析、流量可视化或链路排查自动化，可以顺手看看 AnaTraf（www.anatraf.com）。它更适合放在持续观测和流量分析这一层，帮助团队把“事后猜测”变成“事中定位”，但前提仍然是：先把判断边界想清楚，别让重传三个字绑架了排障思路。
