ebpf抓http耗时更可靠，因其能在socket、tcp_connect、tcp_sendmsg等内核路径无侵入插桩，覆盖tcp重传、连接建立、tls握手等应用层埋点无法捕获的环节；但需通过sk_addr+pid/tid+时间戳间接匹配，避免go指针失效问题。
为什么用 eBPF 抓 HTTP 请求耗时比应用层埋点更可靠
因为应用层的 time.Now() 只能覆盖到 handler 入口和返回，无法捕获内核协议栈、TCP 重传、连接建立（SYN/SYN-ACK）、TLS 握手等环节的延迟。eBPF 能在 socket、tcp_connect、tcp_sendmsg、tcp_recvmsg 等关键路径上无侵入地插桩，把整个请求生命周期拆成可量化的子阶段。
但要注意：eBPF 不能直接读取 Go 的 http.Request 结构体——Go 的 GC 和栈分配会让指针随时失效，必须靠内核态事件 + 用户态关联（比如用 sk_addr + pid/tid + 时间戳）做间接匹配。
如何用 libbpf-go 捕获 TCP 连接建立与响应时间
核心是挂载两个 eBPF 程序：tracepoint:tcp:tcp_connect 记录发起连接的时间，kprobe:tcp_recvmsg 或 uprobe:/usr/lib/go*/libgo.so:runtime.netpoll（取决于 Go 版本）捕获读完成事件。两者通过 struct sock * 地址关联，避免 PID/TID 冲突误匹配。
- Go 1.20+ 默认启用
netpoll，优先用uprobe挂在runtime.netpoll上比 kprobe 更稳定 - 务必开启
bpf.PerfEventArray并用 ring buffer 模式接收事件，避免 perf event 丢包导致耗时计算错位 - 用户态需对每个
sock*维护一个 map：记录 connect 时间戳、是否已收到响应、当前状态（避免重复计时） - 示例关键字段提取逻辑：
struct { __u64 ts; __u32 pid; __u32 tid; __u64 sk_addr; // 唯一标识连接 } __attribute__((packed));
Go 应用里怎么安全传递 socket 地址给 eBPF 程序
eBPF 无法直接访问 Go runtime 的 net.Conn，但可以通过 socket 系统调用返回的 fd，在 Go 层用 syscall.Syscall(SYS_ioctl, uintptr(fd), uintptr(SIOCGSKNS), 0) 获取 socket 内核地址（即 struct sock *），再用 bpf_map_update_elem 写入 eBPF map 关联 pid/tid/sk_addr。
- 必须在
net.Dial返回后立刻获取 fd，否则 fd 可能被复用；可用conn.(*net.TCPConn).File().Fd()提取 - Go 的
http.Transport默认复用连接，同一个sk_addr可能承载多个 HTTP 请求，需结合http.Request.URL.Path和时间窗口做二次区分 - 不要依赖
net.Conn.RemoteAddr().String()—— 它只含 IP:Port，无法唯一标识连接（NAT、负载均衡下会冲突）
常见超时误判和精度陷阱
最常踩的坑是把「SYN 重传」当成「应用慢」：eBPF 在 tcp_connect 触发时只是发了 SYN，若服务端没响应，该连接可能卡住几秒才超时，而你的程序还在等 tcp_recvmsg —— 这时候不加状态机就会漏掉超时事件。
- 所有连接必须设超时阈值（如 3s），在用户态定时扫描未完成的
sk_addr条目并标记为「connect_timeout」 - eBPF 时间戳用
bpf_ktime_get_ns()，用户态用time.Now().UnixNano()，两者误差通常 - HTTP/2 多路复用下，单个
sk_addr对应多个 stream，此时要解析http2.FrameHeader才能拆出单个请求耗时，纯 TCP 层无法做到
真正难的是把内核事件和 Go 的 goroutine 生命周期对齐——比如某个请求在 netpoll 等待时被调度器切走，eBPF 看到的是“空闲”，但实际是 Go runtime 在做 GC 或抢占。这部分只能靠 pprof + eBPF 耗时交叉验证，没法全自动。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
