基于 eBPF 与 tc 的 Linux 网络延迟定位和流量治理实践

微服务调用出现间歇性超时，原因可能并不在应用代码：连接建立变慢、重传增加、队列拥塞或网卡丢包，都可能把一次请求拖成数秒。仅查看应用日志和平均 CPU 使用率，很容易错过短时、局部的网络问题。本文以 Linux 云主机为例，介绍一套从确认现象、观测内核事件到验证治理效果的实践方法。

先建立可比较的基线

排查前先明确受影响的时间段、客户端与服务端地址、端口和请求类型，并记录正常与异常时的延迟分位数，而不只看平均值。使用 ping 或应用层探测确认连通性，再结合 ss、ip -s link 查看连接状态、网卡错误与丢包计数。若问题只发生在特定节点，应同时核对实例规格、虚拟网卡指标和安全组等云侧配置，避免把云网络路径问题误判为单机内核问题。

用 eBPF 观测内核网络路径

eBPF 程序能够在内核事件发生时采集数据，减少全量抓包带来的开销。实际使用中，可借助 BCC 或 bpftrace 工具观察 TCP 重传、连接建立耗时和队列变化；工具名称与可用探针受内核版本、发行版及权限影响，应先在目标主机上检查支持情况。排查时建议按目标进程、端口或地址过滤，并以短时间窗口采集，避免无边界地输出高频事件。

下例展示一个简化的 bpftrace 思路，用于统计 TCP 重传事件。不同内核版本的探针参数可能不同，执行前应通过工具帮助信息确认函数和参数，并在测试环境验证：

#!/usr/bin/env bpftrace
// 统计 TCP 重传事件；探针及参数需按内核版本核验
kprobe:tcp_retransmit_skb
{
  @[comm] = count();
}

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

如果异常期间某个服务进程的重传计数明显上升，可进一步结合 ss -ti 查看 TCP 连接的重传与拥塞信息，并将时间戳和应用请求日志关联。需要注意，计数只能说明现象相关，不能单独证明根因；还要检查对端负载、链路质量、连接池配置和实例资源压力。

用 tc 验证系统的韧性

定位之后，可在隔离的测试环境中使用 tc 模拟延迟、抖动或丢包，验证重试、超时和熔断策略是否有效。例如，对测试网卡施加有限的网络延迟，再观察调用方的尾延迟与错误率。实验前记录原有队列规则，确认命令只作用于目标接口，并设置明确的恢复步骤；不要在生产网卡上直接试验，否则可能影响整台主机的业务流量。

治理应优先解决证据明确的问题：检查网卡丢包和队列积压，评估连接复用是否合理，避免过多短连接，并按服务的延迟预算设置超时与有限重试。重试必须有退避和上限，否则网络变差时可能放大流量，形成级联故障。

形成可复用的排查闭环

一套有效流程应包含基线指标、短时内核观测、应用请求关联、根因验证和变更后复测。将 eBPF 输出与节点、容器和服务标签关联，便于比较不同实例；同时控制采样范围、保留周期和执行权限。通过先观测、再验证、最后调整配置，团队可以减少盲目扩容和无依据调参，让 Linux 网络问题的定位更可解释、更安全。