eCapture 性能基准测试指南量化 eBPF uprobe 捕获 SSL/TLS 明文的开销与调优实践【免费下载链接】ecaptureCapturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64.项目地址: https://gitcode.com/GitHub_Trending/ec/ecaptureeCapture旁观者是一款基于 eBPF 的 SSL/TLS 明文捕获工具它通过在用户态库OpenSSL、GnuTLS 等的函数上挂载 uprobe 来拦截加密数据无需安装 CA 证书。本指南围绕仓库中的性能基准文档 docs/performance-benchmarks.md系统讲解 eCapture 性能开销的来源、基于wrk的完整测量方法、预期性能特征、Perf 缓冲区调优以及已知限制帮助你在自己的环境中复现基准测试并合理规划捕获场景。性能开销的来源一条事件要经过的四个环节eCapture 通过 eBPF uprobe 在用户态库函数入口/出口拦截调用其性能开销主要由四个环节构成Uprobe 入口/出口Entry/Exit每次被拦截的函数调用都会产生内核级钩子处理开销单个事件约 1–2μs。在 OpenSSL 探测器的实现中SSL_write与SSL_read均同时挂载了uprobe和uretprobe见 openssl_probe.go因此一次读写调用实际触发两个探针。eBPF 程序执行在内核中提取数据如从寄存器/栈中读取明文、连接四元组等约 0.1–0.5μs/事件。Perf Buffer 传输内核将采样数据拷贝到用户态开销取决于事件大小与流量强度。用户态处理事件解码Decoder、分发Dispatcher以及格式化与写入Text/Keylog/Pcap 输出见 dispatcher.go 与 base_probe.go 中的读取循环实现。其中环节 3、4 是主要瓶颈所在perfEventLoop以每 CPU 一个读者 goroutine 的形式运行读取、解码、分发串行处理详见 base_probe.go 的GoReaderLoop。基准测试方法论记录测试环境有意义的基准结果必须附带完整的环境信息。在开始测量前先收集以下系统信息# System information uname -a cat /proc/cpuinfo | head -20 free -h cat /etc/os-release # Kernel BTF support ls -la /sys/kernel/btf/vmlinux # OpenSSL version openssl version其中 BTF 支持与否会影响字节码加载路径BaseConfig中的BtfMode支持 0自动检测、1CO-RE、2非 CO-RE三档见 base_config.go而GetBPFName会根据BtfMode选择_core.o或_noncore.o字节码见 base_probe.go。测试时建议固定同一内核版本与 OpenSSL 版本以保证基线可比。基准工具wrk HTTPS 服务器wrk是常用的 HTTP 基准压测工具与一个使用系统 OpenSSL/libssl 的 HTTPS 服务器nginx 或简单 Go 服务配合即可完成测量。# Install wrk (HTTP benchmarking tool) sudo apt-get install wrk # Start an HTTPS server (using nginx or a simple Go server) # Ensure it uses the systems OpenSSL/libssl前提条件eCapture 需要 Linux 内核支持官方支持范围为 x86_64 4.18 / aarch64 5.5见 root.go 的命令行描述基准脚本同样以此为约束。基线未运行 eCapture# Run wrk for 60 seconds with 4 threads and 100 connections wrk -t4 -c100 -d60s https://localhost:8443/记录三个核心指标Requests/sec吞吐、Latencyavg 与 p99、Transfer/sec。运行 eCaptureText 模式# Terminal 1: Start eCapture sudo ecapture tls -m text --pidnginx_pid # Terminal 2: Run the same benchmark wrk -t4 -c100 -d60s https://localhost:8443/Text 模式是默认捕获模式-m参数缺省值为text见 tls.go在捕获的同时持续输出解码后的明文事件属于开销最高的场景因此最能反映最坏情况。运行 eCapturePcapNG 模式# Terminal 1: Start eCapture in pcapng mode sudo ecapture tls -m pcap -i lo --pcapfile/tmp/bench.pcapng --pidnginx_pid # Terminal 2: Run the same benchmark wrk -t4 -c100 -d60s https://localhost:8443/Pcap 模式通过 TCTraffic Control分类器挂载抓包程序并写入 pcapng 文件需要指定网络接口-i与输出文件--pcapfile。配置校验逻辑要求 pcap 模式必须同时提供PcapFile与Ifname且接口必须存在、处于 up 状态见 config.go。此外还有开销相对更低的Keylog 模式-m keylog只导出 TLS 会话密钥而非明文数据事件体积更小适合高流量场景其输出遵循 NSS Key Log 格式可直接用于 Wireshark 解密见 keylog_handler.go。需要采集的指标指标测量方式工具CPU 开销对比目标进程在有无 eCapture 时的 CPU 占用pidstat -p pid 1eCapture 自身 CPU 占用eCapture 进程自身的 CPU 消耗pidstat -p ecapture_pid 1内存占用eCapture 进程的 RSSps -o rss -p ecapture_pid请求延迟影响p50/p99 延迟增量wrk --latency吞吐影响Requests/sec 降幅wrk输出事件丢失率Perf 缓冲区溢出事件eCapture 日志查找 lost events关于事件丢失可以在源码中找到对应实现读取循环中对record.LostSamples ! 0的情况会打印Perf buffer full, samples lost警告见 base_probe.go。如果你看到这类日志说明用户态读取速度已跟不上内核产生事件的速度需要参考下文“Perf 缓冲区调优”处理。自动化基准脚本仓库文档提供了一个可直接运行的完整基准脚本它会自动执行基线与带 eCapture 的两轮压测并保存结果#!/bin/bash # benchmark.sh - eCapture performance benchmark # Must run on Linux with kernel 4.18 (x86_64) or 5.5 (aarch64) set -euo pipefail if [[ $(uname -s) ! Linux ]]; then echo ERROR: This script must run on Linux. 2 exit 1 fi TARGET_URL${1:?Usage: $0 https_url [pid]} TARGET_PID${2:-} DURATION60s THREADS4 CONNECTIONS100 echo eCapture Performance Benchmark echo Date: $(date -Iseconds) echo Kernel: $(uname -r) echo CPU: $(grep model name /proc/cpuinfo | head -1 | cut -d: -f2 | xargs) echo Target: ${TARGET_URL} echo # Baseline echo --- Baseline (no eCapture) --- wrk -t${THREADS} -c${CONNECTIONS} -d${DURATION} --latency ${TARGET_URL} | tee /tmp/bench_baseline.txt echo # With eCapture text mode echo --- With eCapture (text mode) --- PID_FLAG if [[ -n ${TARGET_PID} ]]; then PID_FLAG--pid${TARGET_PID} fi sudo ecapture tls -m text ${PID_FLAG} /tmp/ecapture_bench.log ECAP_PID$! sleep 3 # Wait for eCapture to initialize wrk -t${THREADS} -c${CONNECTIONS} -d${DURATION} --latency ${TARGET_URL} | tee /tmp/bench_ecapture.txt sudo kill ${ECAP_PID} 2/dev/null || true wait ${ECAP_PID} 2/dev/null || true echo echo Results saved to /tmp/bench_baseline.txt and /tmp/bench_ecapture.txt echo Compare Requests/sec and Latency between the two runs 脚本用法./benchmark.sh https_url [pid]。注意sleep 3用于等待 eCapture 完成探测器初始化加载字节码、attach uprobe 需要一定时间实际使用中若机器较慢可适当延长该等待值。若TARGET_PID未指定脚本会省略--pid参数此时 eCapture 会捕获系统上全部目标进程基线对比时应尽量保持场景单一。预期性能特征基于 eBPF uprobe 机制的固有特性不同流量强度下的预期开销大致如下场景预期开销说明低流量 100 req/s可忽略 1% CPUuprobe 成本被少量事件摊薄中等流量100–1K req/s较低1–3% CPUPerf 缓冲区容量充足高流量1K–10K req/s中等3–8% CPU可能需要调大 Perf 缓冲区超高流量 10K req/s显著 10% CPU有 Perf 缓冲区溢出风险建议用--pid缩小捕获范围需要强调的是上表是基于 eBPF uprobe 机制推演出的预期参考区间并非官方基准结论。不同 CPU 型号、内核版本、事件大小与输出模式text/keylog/pcap都会显著改变实际数值务必在你自己的环境中按前述方法论实测。Perf 缓冲区大小与调优当出现Perf buffer full, samples lost警告时说明用户态读取跟不上内核侧的生产速度。缓冲区大小的实际默认值与文档描述需要结合源码理解代码层默认常量DefaultMapSizePerCpu 8 * 1024 * 10248MB/CPU见 base_config.go但命令行全局参数--mapsize的默认值为1024其语义是“以 KB 为单位的每 CPU 事件缓冲 map 大小”实际生效时通过SetPerCpuMapSize换算为size * os.Getpagesize()字节见 base_config.go 与 root.go。在常见的 4KB 页大小系统上1024 × 4096 4MB这与文档所述“默认 4 MB/CPU”一致。因此在高流量场景下可以通过--mapsize参数显式调大缓冲例如sudo ecapture tls -m text --mapsize8192 --pidnginx_pid三个常用的缓解策略使用--pid只捕获指定进程从根因上缩减事件产生速率是超高流量下的首选改用keylog模式替代text模式每个事件携带的数据更少只写密钥而非明文可显著降低每事件字节数增大 Perf 缓冲区通过--mapsize提升单 CPU 缓冲容量为用户态读取争取时间。此外当前版本还提供了--perf-reorder与--perf-reorder-lag-ms参数见 tls.go用于在用户态按 eBPF 单调时钟bpf ktime对每 CPU 的 perf 事件做滞后排序后再分发默认滞后窗口 10ms见 base_config.go。排序会引入短暂的批量等待延迟因此基准测试时默认关闭该功能在启用的场景中需要把它带来的延迟影响计入结果。已知限制源码层面验证Uprobe 开销与调用频率成正比SSL_read/SSL_write的每次调用都会产生开销与数据大小无关见 openssl_probe.go 的入口/返回探针挂载。高频率小数据包的流量比低频大包更具开销放大效应。无采样机制eCapture 捕获所有事件没有概率采样模式。要控制事件量只能通过--pid、--uid或 cgroup 过滤--cgroup_path见 tls.go收窄范围。用户态处理为单线程读取循环每个 perf map 由一个 reader goroutine 顺序执行读→解码→分发见 base_probe.go在超高负载下可能成为瓶颈。无背压机制用户态落后时事件被静默丢弃perf 缓冲区溢出仅记录日志不存在让内核侧暂停或降速的反馈通道。另外从工程角度还有一个隐含成本需要关注启动时的版本探测与字节码加载。OpenSSL 探针在启动阶段会读取libssl.so的.rodata段正则匹配版本字符串如OpenSSL 3.2.0 23 Nov 2023并据此从sslVersionBpfMap选择对应的 eBPF 程序见 config.go。若目标版本未精确命中会自动降级到最接近的已支持版本。这一过程发生在基准测试的sleep 3等待期内不影响稳态测量但在评估“启动即捕获”场景时需要预留该时间。在受控范围内的最小权限部署性能基准测试建议在具备最小必要权限的环境中运行避免额外权限引入不可控干扰。eCapture 的权限需求与 cgroup 过滤等最小化配置可参考仓库文档 最小权限指南原文链接已按仓库根路径转换。结合--uid、--pid、--cgroup_path等过滤参数定义见 root.go可以将捕获范围收敛到单个目标容器或进程既降低性能影响面也符合审计场景的最小化原则。贡献基准结果如果你在自己的基础设施上完成了基准测试欢迎向社区提交结果建议包含测试环境细节CPU、内存、内核版本、OpenSSL 版本使用的基准方法与命令原始结果基线与带 eCapture 两轮数据结论总结吞吐/延迟/CPU 的变化百分比。小结eCapture 的性能开销可归纳为一条清晰的数据链路uprobe 触发 → eBPF 程序执行 → perf 缓冲区传输 → 用户态解码分发。测量它并不复杂——固定环境、用wrk做基线再以相同参数叠加 text/pcap/keylog 模式各跑一轮对比 Requests/sec、p50/p99 延迟、进程 CPU 与 RSS 即可。若在高流量下遇到samples lost警告优先使用--pid缩小范围其次切换 keylog 模式或通过--mapsize调大每 CPU 缓冲同时牢记当前版本单线程读取、无采样、无背压的固有限制把 eCapture 部署在与其能力匹配的流量区间内。【免费下载链接】ecaptureCapturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64.项目地址: https://gitcode.com/GitHub_Trending/ec/ecapture创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考