eBPF无法直接测HTTP handler耗时，因其不能安全访问Go runtime的goroutine上下文，且XDP/TC仅可观测网络包进出，无法捕获应用层WriteHeader/Write调用；它适合测“连接建立到首字节返回”的纯网络路径延迟，而非全链路。
为什么不能直接用eBPF测HTTP handler耗时
eBPF 无法安全访问 Go runtime 的 goroutine 调度上下文，http.HandlerFunc 执行栈不在内核可观察范围内；XDP/TC 程序只能看到网络包进出，看不到应用层 WriteHeader 或 Write 调用。想靠 eBPF “直接测接口延迟”，本质上是错配了观测边界——它适合测“连接建立到首字节返回”这段纯网络路径，不是测“从 net/http 接收请求到 ResponseWriter 写完”的全链路。
哪些延迟能被eBPF可靠捕获
以下三类延迟可用 eBPF 精确打点，且不依赖 Go 应用修改：
-
connect()到accept()的 TCP 建连耗时：在tcp_connect和inet_csk_accepttracepoint 中打时间戳，差值即服务端建连延迟 - 请求首字节（SYN+HTTP）到达网卡到内核 socket 队列的排队延迟：用 XDP 程序在
skb->tstamp记录入队时间，再与sock_recvmsg时间比对 - TLS 握手各阶段耗时：在
ssl:ssl_pre_encrypt、ssl:ssl_post_decrypt等 tracepoint 中采样，避开 Go 的crypto/tls用户态实现盲区
注意：ResponseHeaderTimeout 或 Write 阻塞这类 Go 层超时，eBPF 完全不可见——它只管“包有没有发出去”，不管“Go 是不是还在拼接 JSON”。
Go 进程如何与 eBPF 协同定位延迟归属
单靠 eBPF 或单靠 net/http/pprof 都会漏掉关键断点。必须让两者时间线对齐：
立即学习“go语言免费学习笔记（深入）”；
- 在 Go 启动时调用
runtime.nanotime()获取启动纳秒时间戳，通过bpf_map_update_elem()写入共享 map，供 eBPF 程序读取作为时间基线 - eBPF 程序在捕获到目标端口的 SYN 包时，用
bpf_ktime_get_ns()记录，并减去上述基线，得到绝对时间点 - Go 侧在
http.Server.Handler入口也记录runtime.nanotime()，上报时带上该值；后端用统一时间源做差值，就能判断延迟究竟发生在“网卡→内核→socket”还是“内核→Go runtime→业务逻辑” - 避免用
time.Now()对齐：它受系统时钟调整影响，runtime.nanotime()才是单调递增的硬件计时器读数
容易被忽略的陷阱：eBPF 观测结果与 Go 日志对不上
常见原因不是工具不准，而是时间维度没对齐：
- eBPF 抓的是每个包的时间，但一个 HTTP 请求可能跨多个 TCP segment；只看第一个 SYN 不代表整个请求开始，得用四元组 + TCP sequence 号做流聚合
- Go 日志里
time.Since(start)测的是 handler 执行时间，但若用了gzip.Writer或流式io.Copy，真实发送完成时间远晚于 handler 返回——这时 eBPF 看到的“最后数据包发出时间”反而更准 - 容器环境下，eBPF 程序加载在宿主机，而 Go 进程在 netns 里；若未用
tc clsact绑定到正确 interface，可能根本抓不到流量
真正难的从来不是“怎么画出延迟图”，而是确认图中每一段对应哪段真实代码路径——eBPF 给你精确的“网络脉搏”，但听诊器得你自己拿稳，别把心跳当成咳嗽。
