ebpf无法直接解析rpc请求内容，因其运行于内核态，受验证器限制不能反序列化go的gob/protobuf数据，也无法访问用户态堆内存中的rpc.server或grpc.serverstream对象。
直接用 eBPF 抓 RPC 调用延迟是行不通的——eBPF 无法解析 Go runtime 的 goroutine 调度上下文，也不能直接读取 net/rpc 或 gRPC 的请求结构体。真正可行的路径是：用 eBPF 监控底层网络事件（如 TCP connect、send、recv），再结合 Go 自身的 trace 和 pprof 定位应用层耗时，最后对齐时间戳做归因分析。
为什么不能在eBPF里直接解析RPC请求内容
eBPF 程序运行在内核态，受限于验证器规则，无法安全地反序列化 Go 的 gob 或 protobuf 数据；它也看不到用户态堆内存布局，无法访问 rpc.Server 实例或 grpc.ServerStream 对象。常见错误是试图在 kprobe 上 hook net.(*conn).Write 并尝试读取参数指针——这会触发验证失败或返回空数据。
真正能稳定采集的是：
- TCP 连接建立耗时（SYN → SYN-ACK）
- 首次数据包发送延迟（从
write()系统调用到 skb 出队） - 服务端 recv() 到第一个字节的时间点（对应 RPC 请求头到达）
- 客户端 recv() 返回的时间（对应响应 body 完整接收）
如何用eBPF捕获关键网络延迟点
使用 bpftrace 或 libbpf-go 挂载以下 hook 是最实用的组合：
-
tracepoint:syscalls:sys_enter_connect+tracepoint:syscalls:sys_exit_connect：测建连耗时 -
kprobe:tcp_sendmsg：标记请求发出时刻（需过滤目标端口，如1234） -
kprobe:tcp_recvmsg：标记响应接收完成时刻（同样按端口过滤） -
uprobe:/path/to/your/binary:"runtime.gopark"（谨慎）：仅用于关联 goroutine 阻塞，但不可靠
示例 bpftrace 命令抓取一次 gRPC 调用的网络往返：
sudo bpftrace -e '
kprobe:tcp_sendmsg /pid == 12345 && args->size > 100/ {
@start[tid] = nsecs;
}
kprobe:tcp_recvmsg /pid == 12345 && args->size > 100/ {
$delta = nsecs - @start[tid];
printf("RPC network RTT: %d us\n", $delta / 1000);
delete(@start[tid]);
}'
注意：pid == 12345 必须替换成你的 Go 进程 PID，且需提前用 ss -tulnp | grep :port 确认端口绑定关系。
怎么把eBPF网络延迟和Go应用延迟对齐
单纯看网络 RTT 没法区分是服务端处理慢，还是网络卡。必须和 Go 的 runtime/trace 时间线对齐：
- 在 RPC handler 开头插入
trace.Log(ctx, "rpc-start", "method:"+method) - 在 handler 结尾插入
trace.Log(ctx, "rpc-end", "status:"+status) - 用
go tool trace trace.out打开后，在「View trace」中打开「Network I/O」面板，找到对应 goroutine 的net.(*conn).Read和Write事件 - 对比 eBPF 记录的
tcp_sendmsg时间戳与 trace 中Write的起始时间差 —— 若差值 > 1ms，说明 Go runtime 层有调度延迟或 GC STW
这个对齐过程必须用纳秒级时间戳（time.Now().UnixNano()），且两路数据要通过同一台机器的硬件时钟同步，跨节点部署时误差可能达毫秒级，不可直接相减。
容易被忽略的陷阱：Go HTTP/2 与 gRPC 的多路复用干扰
gRPC 默认走 HTTP/2，一个 TCP 连接上并发多个 stream，tcp_sendmsg 和 tcp_recvmsg 事件不再一一对应单次 RPC。此时：
- eBPF 无法区分哪个 send 对应哪个 recv，除非解析 HTTP/2 frame header（超出 eBPF 安全边界）
- 更可靠的做法是：在 Go client 端用
context.WithValue(ctx, "rpc_id", uuid.New())注入唯一标识，再通过http.Transport.RoundTrip的日志或 OpenTelemetry span 记录收发时间 - 只用 eBPF 做宏观监控（如连接池健康度、重传率），不用它定位单次 RPC 延迟
真正落地时，eBPF 的价值不在“测量单次 RPC”，而在发现系统级异常：比如某台机器的 tcp_retrans_seg 突增，或 tcp_slow_start 触发频繁，这时才值得深入查网络栈配置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
