eBPF监控Nginx SSL握手需聚焦关键路径：uprobe捕获ngx_ssl_handshake/SSL_do_handshake，kretprobe跟踪do_tls_handshake等内核函数，并关联accept4与inet_sock_set_state；strace/sysdig因全量拦截开销大，不适用于生产，而eBPF仅在指定点执行轻量逻辑，性能损耗
直接用 eBPF 监控 Nginx SSL 握手过程的系统调用，核心不是“抓所有 syscall”，而是聚焦握手路径中真正关键的内核与用户态交互点。eBPF 的优势在于精准、低开销、无侵入——它不靠泛式拦截，而是沿着 TLS 握手的实际执行链布设探针。
关键系统调用与内核函数需联合观测
SSL 握手本身不直接对应某个单一 syscall（如 connect 或 accept），而是一系列用户态函数调用触发的内核 TLS 处理逻辑。因此需同时跟踪：
-
用户态入口：uprobe 挂在
ngx_ssl_handshake和SSL_do_handshake，捕获调用起始、SSL 结构体地址、返回值 -
内核 TLS 路径：kretprobe 挂在
do_tls_handshake（内核 5.10+）、tls_push_record、tls_sw_sendmsg，识别内核侧阻塞或慢路径 -
底层网络关联：tracepoint
syscalls:sys_enter_accept4和sock:inet_sock_set_state，将连接建立时间与握手阶段对齐
为什么不用 strace 或 sysdig 直接跟踪 syscall？
strace 对每个系统调用做上下文切换和日志输出，实测会使 Nginx 握手延迟飙升 5–10 倍，无法用于生产环境；sysdig 虽比 strace 轻量，但仍属全量 syscall 拦截，噪声大、聚合难。eBPF 则只在你指定的函数入口/出口执行极简逻辑（如打时间戳、存指针、更新直方图），性能损耗通常低于 0.5%。
一个可运行的 bpftrace 脚本示例
以下脚本能实时统计每次握手在内核 TLS 栈中的耗时（排除用户态证书加载等）：
#!/usr/sbin/bpftrace
kprobe:do_tls_handshake { @start[tid] = nsecs; }
kretprobe:do_tls_handshake /@start[tid]/ {
$d = nsecs - @start[tid];
@tls_ns = hist($d);
printf("TLS kernel handshake: %dns (tid:%d)\n", $d, tid);
delete(@start[tid]);
}
运行 sudo bpftrace ./tls_kernel.bt，若直方图中大量落在 50ms–500ms 区间，说明内核 TLS 处理存在瓶颈（如 CPU 不足、密钥交换算法未硬件加速）；若集中在
结合配置快速验证三类高频根因
-
会话复用失效：检查
ssl_session_cache是否启用 shared cache 且容量充足（如shared:SSL:50m），再用 eBPF 脚本对比SSL_SESSION_get_id调用频次与ngx_ssl_handshake完整握手次数比例 -
OCSP Stapling 超时：uprobe
ngx_ssl_stapling_fetch，观察其调用是否频繁失败或超时；同时确认resolver配置指向低延迟 DNS 且未被防火墙拦截 -
证书加载慢：uprobe
ngx_ssl_certificate，测量从读取磁盘到调用SSL_CTX_use_certificate_chain_file的耗时；避免使用 PEM 中含多级中间证书且未预解析的配置
