Linux 网络抖动怎么用 bpftrace 观察 TCP 重传：从 tracepoint 到最小脚本

线上接口偶发超时，应用日志里只剩一行“上游响应慢”，这时先别急着抓一整段报文。Linux 内核已经在 TCP 重传路径上提供了 tracepoint，配合 bpftrace 可以用几行脚本确认“重传是否真的发生、由哪个进程触发、频率有没有持续升高”。这一步不替代抓包，却能很快把排查范围从应用、主机、网络三层缩到更小的区域。

先确认：网络抖动是不是 TCP 重传

“请求变慢”和“TCP 重传”不是同一个现象。连接池耗尽、远端服务排队、DNS 延迟，都可能让接口超时。bpftrace 的价值在于给出一条主机侧证据：内核是否频繁进入 TCP 重传事件。

先列出当前机器支持的探针：

sudo bpftrace -l 'tracepoint:tcp:*retrans*'

如果能看到 tracepoint:tcp:tcp_retransmit_skb，再查看事件字段：

sudo bpftrace -lv 'tracepoint:tcp:tcp_retransmit_skb'

这里的输出以本机内核为准。不同发行版、内核配置和 bpftrace 版本，字段名称可能不完全一致；脚本只依赖事件计数时，反而更容易跨环境使用。

用一个最小脚本把重传按进程聚合

下面的脚本不读取数据包内容，只统计事件命中次数，并在 10 秒后打印一次结果：

tracepoint:tcp:tcp_retransmit_skb
{
  @retry[comm] = count();
}

interval:s:10
{
  print(@retry);
  clear(@retry);
}

保存为 tcp-retry.bt 后运行：

sudo bpftrace tcp-retry.bt

输出里的 comm 是触发事件时的进程名。若某个网关进程持续占据计数，再结合连接数、目标地址和应用访问日志，就能判断它是主动连接外部服务，还是被动承接了异常流量。没有计数也不是“网络绝对正常”，只能说明观察窗口内没有命中这个事件。

把计数变成可验证的排查线索

重传计数出现后，我通常按下面顺序补证据：

1. 看时间：把 10 秒统计窗口和接口 p95、超时日志的时间戳对齐。
2. 看对象：用连接统计、目标端口和服务日志确认是哪一类流量在重试。
3. 看主机：检查网卡丢包、软中断、队列拥塞和 CPU 是否同时异常。
4. 看链路：只有在主机侧证据指向网络路径时，再用抓包确认 SYN、ACK 或数据段的重传细节。

这一步很关键：bpftrace 看到的是内核事件，不是完整的网络因果链。比如对端处理慢导致发送窗口变化，也可能让上层感觉“网络抖动”；反过来，网卡丢包、虚拟机邻居链路异常，也可能只在 TCP 层暴露出来。

它和 tcpdump、传统指标怎么配合

tcpdump适合回答“哪一个连接、哪一个序号、哪一个方向发生了重传”，但持续抓包会产生文件和过滤成本；内核 TCP 指标适合看总体趋势，却不一定能把异常和进程对应起来。bpftrace 处在两者之间：先用事件计数快速定位，再决定是否抓取更细的数据。

生产环境建议给脚本加观察时限，不要把全量事件长期输出到终端。若计数突然暴涨，应保留同一时间窗口的接口延迟、网卡统计和应用请求日志，避免只拿一张“重传次数很高”的截图下结论。

探针不可用或结果异常时怎么办

列不到 tcp_retransmit_skb

先确认 bpftrace 版本、内核配置和权限，再执行 sudo bpftrace -l 'tracepoint:tcp:*' 查看实际事件集合。不要直接把别的机器上的 kprobe 名称替换过来，因为 kprobe 依赖内核函数存在，稳定性通常不如 tracepoint。

脚本能运行但没有进程名

先把脚本简化为单纯 count()，确认事件本身能命中；再检查运行权限和流量是否经过当前主机。某些内核路径上的事件未必能提供你想要的所有上下文，字段信息应以 -lv 的现场输出为准。

重传很多但接口没超时

这可能只是短暂丢包、后台同步或高吞吐连接的正常波动。把事件计数与请求延迟、错误率和重传持续时间放在一起看，短时尖峰和持续高位的处理方式不同。

常见问题：bpftrace 观察 TCP 重传的边界

bpftrace 会不会修改 TCP 行为？

这个示例只挂载观察事件并计数，不修改 TCP 参数或数据包。但仍应控制脚本范围和输出量，生产主机上先在低流量窗口验证。

只看重传次数能定位丢包设备吗？

不能。它能证明 TCP 重传路径被触发，不能直接区分应用、主机网卡、虚拟网络、路由链路或对端问题。设备归因需要结合接口统计、连接信息和抓包。

什么时候应该直接抓包？

当你已经确认重传持续发生，且需要区分方向、序号、窗口或握手阶段时，再用过滤后的抓包补证据。先缩小时间和连接范围，文件更小，分析也更快。

排查网络抖动时，最小的 bpftrace 脚本适合做第一道筛选：它用较低的信息采集成本回答“TCP 是否在重试”。拿到这条线索后，再把时间戳、进程、接口指标和抓包拼起来，结论才足够稳。