如何使用Golang和eBPF追踪TCP重传事件-Golang-PHP中文网

不能在go微服务代码中直接调用cilium/ebpf加载tcp重传探针，因其不支持btf自动解析，依赖硬编码字段偏移，而不同内核版本中trace_event_raw_tcp_retransmit_skb结构体字段顺序和填充易变，导致读取乱码或静默失败；正确做法是使用libbpf-go配合btf，在满足config_debug_info_btf=y等前提下，通过tracepoint:tcp:tcp_retransmit_skb稳定获取重传事件。

如何使用golang和ebpf追踪tcp重传事件

不能在 Go 微服务代码里直接调用 cilium/ebpf 加载 TCP 重传探针——这不是权限问题，而是架构错位。eBPF 追踪必须运行在内核态，由独立进程（如 cilium-agent 或自研用户态加载器）挂载，Go 应用只负责暴露可观测性上下文。

为什么 `cilium/ebpf` 在生产环境追踪 `tcp_retransmit_skb` 容易失败

常见报错 failed to load object: invalid argument 或静默提交空数据，根本原因不是代码写错，而是：

cilium/ebpf 不读取 BTF 信息，靠硬编码字段偏移解析 tracepoint 参数；不同内核版本（尤其 5.15+）中 struct trace_event_raw_tcp_retransmit_skb 的字段顺序、填充可能变化，导致读到错误地址
你写的 bpf_probe_read_kernel(&e->saddr, ..., &e->saddr) 实际读的是垃圾值，bpf_probe_read_kernel 返回 -EFAULT 却被静默忽略
即使编译通过，ringbuf 提交的事件里 saddr、daddr、sport、dport 大概率为空或乱码

正确做法：用 `libbpf-go` + BTF 自动解析 tracepoint

必须确保系统满足三个前提，否则一切 attach 都会失败：

内核开启 CONFIG_DEBUG_INFO_BTF=y（检查 /sys/kernel/btf/vmlinux 是否存在）
安装对应内核版本的 kernel-devel 或 linux-headers 包（libbpf-go 构建时需读取 BTF）
eBPF 程序编译时加 -target bpf，禁用 -O3（verifier 对复杂控制流容忍度低）

Go 侧无需手动算偏移，直接用 BTF 推导后的字段名：

ctx := (*tcpRetransmitEvent)(unsafe.Pointer(&data[0]))
fmt.Printf("retrans from %s:%d to %s:%d\n",
    net.IP(ctx.Saddr[:]).String(), uint16(ctx.Sport),
    net.IP(ctx.Daddr[:]).String(), uint16(ctx.Dport))

该监听哪个内核事件？`tracepoint:tcp:tcp_retransmit_skb` 是唯一可靠入口

不要用 kprobe:tcp_retransmit_skb 或 uprobe，原因很实际：

Golang Google Wire

在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface

下载

kprobe 无法稳定获取 socket 地址、端口等关键字段（参数不在寄存器或栈顶固定位置，Go 1.17+ ABI 更加剧混乱）
tcp_retransmit_skb 函数在不同内核路径下可能被内联或跳过，kprobe attach 点不稳定
tracepoint:tcp:tcp_retransmit_skb 是内核 TCP 栈明确 emit 的事件点，结构体定义稳定、字段完整，且自带 saddr/daddr/sport/dport/reason

验证是否可用：

bpftrace -l 'tracepoint:tcp:tcp_retransmit_skb'

若无输出，说明内核未启用该 tracepoint（检查 CONFIG_TRACEPOINTS=y 和 CONFIG_INET=y）。

别漏掉的关键点：重传事件 ≠ 应用层感知到的失败

抓到 tcp_retransmit_skb 只代表内核触发了一次重传，但业务是否受影响，取决于重传次数和 RTO 超时逻辑：

单次重传不丢连接，用户无感；连续 3 次以上重传往往伴随连接中断或超时
必须关联 tcp_retransmit_skb 与 tcp:tcp_drop 或 sock:inet_sock_set_state（状态变为 TCP_CLOSE）才能归因失败
单纯统计重传数没意义，要计算单位时间窗口内的重传率（如每秒重传数 / 总发包数），才反映链路质量

真正难的是把重传事件和你的 Go HTTP handler 关联起来——这需要你在用户态做 PID/comm 匹配，并结合 /proc/[pid]/fd/ 反查 socket fd 绑定的监听端口，而不是幻想 eBPF 能直接吐出 handler 名字。