ebpf不解析go tls数据，而是通过uprobe钩住crypto/tls.(*conn).read/write函数，在入口/出口提取明文缓冲区指针与长度，经ebpf map传至用户态；因go内存布局特殊，需按abi解析sarg0-sarg2获取切片ptr/len/cap，并依版本动态适配tls.conn字段偏移。
直接说结论：eBPF 本身不解析 Go 的 TLS 加密数据，而是通过 uprobe 钩住 crypto/tls 包里的关键函数（如 tls.Conn.Read、tls.Conn.Write），在函数入口/出口处提取明文缓冲区指针和长度，再借助 eBPF Map 传到用户态。Go 运行时的内存布局特殊，必须按实际 ABI 解析参数，不能套用 C 的惯例。
为什么不能直接 hook net/http.ServeHTTP？
Go 的 HTTP 服务是先解密再交给 http.Handler 的，ServeHTTP 拿到的已经是明文。但 eBPF uprobe 如果钩在这里，会漏掉 TLS 握手阶段的密钥协商、证书交换等关键信息，也无法区分哪些明文来自哪个 TLS 连接（缺少 session ID、client random 等上下文）。真正要捕获“加密通信数据”，必须下探到 crypto/tls 层。
-
tls.Conn.Read和tls.Conn.Write是最稳定、最通用的钩点，覆盖 TLS 1.2 和 1.3 - Go 1.16+ 后
tls.Conn是非导出结构体，其字段偏移随版本变化，ecapture等工具需内置多版本适配逻辑（比如 Go 1.20 中conn.in偏移是 0x40，Go 1.22 可能变成 0x48） - 避免钩
handshake内部函数——它们是 unexported 且内联频繁，符号不稳定，容易因编译器优化失效
Go 函数参数怎么从 sarg0/sarg1 里正确读出来？
Go 调用约定中，小整数（int8/int16/int32）常被打包进一个 64 位寄存器（如 sarg0），而不是各占一个寄存器。比如 Read(p []byte) 的第一个参数是切片，它由 3 个 64 位字段组成：ptr、len、cap，全部塞在 sarg0、sarg1、sarg2 里。
- 错误做法：
(char*)sarg0直接当地址用 —— 实际上sarg0是切片首地址，sarg1是长度，sarg2是容量 - 正确做法：用
bpf_probe_read_user()先读取sarg0指向的内存块（即[]byte数据本身），再用sarg1控制拷贝长度 - 注意栈偏移：Go 协程栈是动态增长的，uprobe 触发时，函数栈帧位置不固定，不能硬编码栈变量地址
如何拿到 TLS 会话元数据（client random、server random、cipher suite）？
这些数据不在 Read/Write 参数里，而藏在 tls.Conn 结构体内部。eBPF 程序必须根据 Go 版本，用预定义的字段偏移去访问：
-
conn.handshakes[0].clientHello.random偏移通常在+0x18（Go 1.20），但需实测确认 - 用
bpf_probe_read_user(&random, sizeof(random), (void*)conn_addr + 0x18)提取 client random - 密钥材料（如 master secret）根本不会出现在 Go 用户态内存中 —— Go 的
crypto/tls在握手完成后就清零了，所以 eCapture 类工具对 Go TLS 的支持本质上只限于应用层明文，不支持密钥日志模式（SSLKEYLOGFILE） - 如果需要完整 TLS 分析（含握手细节），建议改用 eBPF + XDP 捕获原始 TLS 记录层包，再在用户态做协议解析（绕过 Go 运行时限制）
最易被忽略的一点：Go 编译时加了 -buildmode=pie（默认开启），会导致 tls.Conn 结构体地址每次加载都变，eBPF uprobe 必须配合 perf_event_open 或 bpf_usdt_read 动态定位符号，静态编译的 offset 表在容器重启后大概率失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
