OpenSandbox Egress 性能基准测试指南量化 DNS/nft 管控与透明 MITM 的开销【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox本文基于 OpenSandbox 仓库中 egress 组件的基准测试文档components/egress/docs/benchmark.md及其配套的测试脚本系统讲解如何在本机 Docker 环境里量化沙箱出站管控的端到端延迟与吞吐开销一是bench-dns-nft.sh对「无管控基线 / dns / dnsnft」三种模式的对比二是bench-mitm-overhead.sh对「是否叠加透明 mitmproxy 中间人」的开销测量。读完后你将能够复现这两套基准、正确解读 Req/s、P50、P99、CPU/内存趋势等结果并理解每种模式在源码层面的实现位置与开销来源。一、被测对象egress 的三种流量模式OpenSandbox 的 egress 组件以 sidecar 容器形式接管沙箱的出站流量。它的强制模式由环境变量OPENSANDBOX_EGRESS_MODE决定取值在 pkg/constants/configuration.go 中定义解析逻辑位于 pkg/constants/mode.go 的ParseEgressMode模式由dns必需和nft两个 token 以连接、顺序无关非法值会回退到dns并打印告警。基准测试覆盖的三种形态正是baseline普通curl容器不经过 egress作为无代理对照dns仅启用 DNS 代理做解析层拦截pass-through不写 nftables 规则dnsnftDNS 代理 在每次 DNS 应答前同步调用 nftables 的AddResolvedIPs把解析出的 IP 加入动态放行集合实现 L2网络层强制。这条同步写路径可以在 nft.go 的setupNft中看到——它将 DNS 应答回调接入 pkg/nftables/manager.go 的AddResolvedIPs并有 pkg/nftables/manager_test.go 的单测覆盖 TTL 钳制、空集 no-op 等边界dnsnft 透明 mitmproxy在dnsnft之上通过OPENSANDBOX_EGRESS_MITMPROXY_TRANSPARENTtrue启用mitmdump --mode transparent对 TCP 80/443 做 TLS 解密与 L7 处理详见 docs/mitmproxy-transparent.md。理解这几种模式的差异是理解后续所有基准数字的前提dns模式只多一跳本地 DNS 代理127.0.0.1:15353dnsnft额外多出每次解析后的内核态 nftables 集合写入而 MITM 则额外引入 TLS 双向握手重做与 mitmdump 常驻进程的 CPU/内存开销。二、bench-dns-nft.shbaseline / dns / dnsnft 端到端对比2.1 前置条件宿主机安装Docker与curl脚本用宿主机curl等待healthz并向策略服务器推送策略域名列表文件 tests/hostname.txt格式为一行一个域名#注释与空行被忽略当前仓库中该文件包含 101 个域名在components/egress目录下执行脚本或自行调整脚本内路径。2.2 运行方式cd components/egress ./tests/bench-dns-nft.sh脚本行为与可调参数见 bench-dns-nft.sh 头部注释与变量定义参数默认值说明IMGopensandbox/egress:localegress 镜像名。脚本默认会先docker build构建该镜像构建上下文为仓库根目录、Dockerfile 为 components/egress/Dockerfile设置IMG...可跳过重新构建的语义替换BASELINE_IMGcurlimages/curl:latestbaseline 阶段使用的普通 curl 镜像要求镜像内自带curlBENCH_SAMPLE_SIZE0使用全部域名随机抽取 n 个域名参与测试。脚本优先用shuf/gshuf洗牌不可用时回退到awk sort的可移植实现LOG_HOST_DIR/LOG_FILE/tmp/egress-logs/egress.logegress 日志落盘位置容器内挂载到/var/log/opensandbox工作负载的关键参数硬编码在脚本中ROUNDS10每轮对每个域名发 1 个并发HEAD请求、CURL_TIMEOUT10秒单请求超时、BENCH_EXEC_TIMEOUT300秒整体墙钟上限总请求数为ROUNDS × NUM_DOMAINS。2.3 每个阶段的执行细节脚本按baseline → dnsnft → dns的顺序依次执行三个 phaserun_phase_baseline/run_phase每个 phase 的完整流程是起容器docker run -d --cap-addNET_ADMIN并通过--sysctl关闭 IPv6dns/dnsnft模式还会注入OPENSANDBOX_EGRESS_MODE并把策略端口-p 18080:18080映射到宿主机18080 即源码中 DefaultEgressServerAddr 的默认监听地址等待就绪宿主机轮询http://127.0.0.1:18080/healthz最多 30 次每次间隔 0.5s。该端点由 policy_server.go 注册同时暴露运行时POST/GET /policy与GET /healthz推送策略把全部基准域名拼成{defaultAction:deny,egress:[{action:allow,target:域名}]}通过POST /policy下发——即默认拒绝、逐域名放行这正是 egress 策略服务器的标准用法预热先对首个域名发 1 个HEAD验证连通性再跑 1 个域名、1 轮、10 条 URL 的 warm-up排除冷启动DNS 首查、nft 集合初始化、连接建立对计时相位的污染计时相位在容器内循环ROUNDS轮每轮并发对每个域名执行curl -s -I -w %{time_namelookup}\t%{time_total}\n --max-time 10 url把 DNS 解析耗时time_namelookup与端到端总耗时time_total逐行写入容器内/tmp/bench-raw.txt结束后docker cp回宿主机。使用HEAD无响应体是有意为之它只覆盖 DNS TCP TLS HTTP 响应头路径从而聚焦管控栈本身的开销而不是网络带宽。2.4 结果与产物终端脚本末尾打印三行对比表baseline/dns/dnsnft列出Req/s、Avg、P50、P99括号内百分比为相对 baseline 的变化量延迟%表示变慢Req/s-X%表示吞吐下降宿主机/tmp原始数据bench-e2e-baseline-total.txt、bench-e2e-dns-total.txt、bench-e2e-dnsnft-total.txt—— 每行一个time_total秒bench-e2e-{mode}-namelookup.txt—— 每行一个time_namelookup用于单独观察 DNS 解析耗时受代理的影响bench-e2e-{mode}-wall.txt—— 该 phase 的墙钟耗时Req/s 即「成功请求数 / wall」。统计口径由脚本内的stats()函数定义sort -n排序后按int(n*0.50.5)、int(n*0.990.5)取分位数均值由awk累加得出。这个实现意味着 P99 对样本量敏感第 5 节会展开。三、bench-mitm-overhead.sh透明 MITM 开销专项3.1 对比维度与场景该脚本固定模式为dnsnft比较「不开 mitm」与「叠加透明 mitmproxy」两组容器run_phase dns_nft 0/run_phase dns_nft_mitm 1并在 mitm 组额外注入OPENSANDBOX_EGRESS_MITMPROXY_TRANSPARENTtrue与OPENSANDBOX_EGRESS_MITMPROXY_PORT默认 18081与 configuration.go 中DefaultMitmproxyPort一致。默认BENCH_SCENARIOSshort,download两个场景short大量 HTTPSHEAD请求HEAD storm模拟高频短连接场景。工作负载为ROUNDS × NUM_DOMAINS × BENCH_SHORT_INFLIGHT_PER_DOMAIN默认 10 轮 × N 域名 × 1 并发/域名download向同一 URL 发起并行GET默认 URL 是 Cloudflare 的测速下载端点__down?bytes20971520约 20 MiB默认BENCH_DOWNLOAD_PARALLEL4路并行、BENCH_DOWNLOAD_ROUNDS1轮、BENCH_DOWNLOAD_MAXTIME600秒单流超时、BENCH_DOWNLOAD_EXEC_TIMEOUT900秒墙钟上限。3.2 运行方式cd components/egress ./tests/bench-mitm-overhead.sh完整参数表摘自 bench-mitm-overhead.sh 头部注释参数默认值说明SKIP_BUILD未设置设为1跳过镜像构建直接复用IMG脚本顶部固定为opensandbox/egress:localBENCH_SAMPLE_SIZE0同前随机抽取 n 个域名BENCH_SCENARIOSshort,download逗号分隔只测一个场景可设BENCH_SCENARIOSshort或downloadBENCH_SHORT_INFLIGHT_PER_DOMAIN1short场景每个 URL 每轮的并发 HEAD 数调高可压出更高并发BENCH_DOWNLOAD_URLCloudflare__down~20 MiBdownload场景的下载目标脚本会自动解析其 host 并加入放行策略download_url_host否则默认拒绝策略会挡住该流量BENCH_DOWNLOAD_PARALLEL/BENCH_DOWNLOAD_ROUNDS/BENCH_DOWNLOAD_MAXTIME4 / 1 / 600并行流数 / 轮数 / 单流最大时长BENCH_DOCKER_STATS_INTERVAL1容器指标采样间隔秒调小如0.5可获得更密的时序数据LOG_HOST_DIR/LOG_FILE/tmp/egress-logs/egress.log同前除流量指标外该脚本还内置了容器资源遥测start_docker_stats_log会在整个 phase 期间按BENCH_DOCKER_STATS_INTERVAL周期采集容器内/proc/loadavgload1/5/15 及 runnable/total_tasks与docker statsCPUPerc、MemUsage、MemPerc、NetIO、BlockIO追加写入 TSV 文件表头为unix_ts、load1、load5、load15、runnable、total_tasks、CPUPerc、MemUsage、MemPerc、NetIO、BlockIO。另一个值得注意的细节mitm 相位在推送策略之后、正式计时之前会轮询最多 90 秒等待首个域名 HTTPS 可达等待 mitmdump 启动 客户端信任 CA 建立。这与源码中的健康门控一致——透明模式下在 mitm、iptables 重定向与 CA 导出就绪前GET /healthz会返回503 (mitm not ready)以防过早进入就绪状态见 docs/mitmproxy-transparent.md。3.3 结果与产物终端每个场景一张表。short表列为 Req/s、Avg(s)、P50(s)、P99(s)download表列为 Agg MB/s总字节数 / 下载相位墙钟流重叠、Avg(s)/stream、P50、P99、Total MiB两组数据下方给出E2E latency loss (avg time_total)单位为ms/request与%由calc_e2e_latency_loss计算(mitm均值 - 无mitm均值) × 1000宿主机/tmp原始数据延迟类bench-mitm-{mode}-short-*.txttotal/namelookup/wall、bench-mitm-{mode}-download-raw.tsvtime_total\tsize_download两列、-download-wall.txt、-download-bytes.txt容器指标两个 phase 都写bench-mitm-docker-stats-dns_nft.tsv与bench-mitm-docker-stats-dns_nft_mitm.tsv。文档特别提示容器内loadavg在很多情况下跟随宿主机 load应作为相对趋势参考而非绝对值。四、参考基线示例运行原文档给出了一组示例运行的参考基线明确声明仅作示意same machine, same script不构成 SLA。MITM 列均为dnsnft 透明 mitmproxy。4.1download场景4 流并行 GET~20 MiB1 轮1 秒采样指标dnsnft mitmCPUPercdocker stats大多~2–5%峰值~5.6%常~5–11%峰值~10.9%MemUsage~9–18 MiB~68–91 MiBload1最高~0.23尖峰~0.66随后~0.4–0.6结论在该 trace 中叠加 MITM 后峰值 CPU% 约为 2 倍、常驻内存RSS约为 5 倍。这与 mitmdump 常驻进程 TLS 会话缓冲的行为相符——download相位 CPU 占用低吞吐受带宽限制但内存占用是稳定的、与流量类型无关的固定成本。4.2short场景HEAD storm短相位行数稀疏示例运行的负载画像10 rounds × 40 URLs × 1 inflight 400 requests。指标dnsnft mitmReq/s3.641.90-47.6%Avg latencytime_total0.315 s0.605 s91.9%P50 latency0.136 s0.143 s5.2%P99 latency1.439 s10.006 s595.2%E2E latency loss (avg)baseline289.88 ms/request91.95%指标dnsnft mitmCPUPerc热样本~132%热样本~232%MemUsage~6–10 MiB~58–88 MiB需要说明多核环境下CPUPerc 100%属正常现象——Docker 的 CPU 指标允许容器同时占用多个核的当量。结论该样本显示出透明 MITM 明显的需求侧开销——平均每个请求多289.88 ms吞吐降到约一半P50 接近基线而 P99 急剧放大说明尾延迟被显著放大TLS 重协商、证书签发/缓存未命中等慢路径主要落在少数请求上。五、如何正确解读这些数字结合脚本实现与原文档的提示解读基准结果时有四个注意点小样本下 P99 高度敏感。stats()用排序后取第int(n*0.990.5)个值400 个样本中 P99 只由约 4 个最慢样本决定。原文档明确建议对尾延迟指标要增大轮数或域名数提高ROUNDS、BENCH_SAMPLE_SIZE或BENCH_SHORT_INFLIGHT_PER_DOMAIN才能得到稳定的 P99dns与dnsnft的差值衡量的是 nft 动态写路径每解析一个域名就多一次同步的 nftables 集合元素写入nft.go 中回调触发因此该差值直接反映 L2 强制的边际成本而baseline与dns的差值则主要反映本地 DNS 代理这一跳CPU 与内存趋势相互印证示例中 CPU 峰值约 1.8 倍232/132、RSS 在 mitmdump 下明显更高两个脚本的产物-total.txt、-namelookup.txt、docker-stats-*.tsv都是原始数据可自行重算任意分位数或时间窗更密的遥测需要更细粒度的主机/容器趋势时跑更长相位或设置BENCH_DOCKER_STATS_INTERVAL0.5。六、相关源码与延伸阅读模式解析与回退pkg/constants/mode.go环境变量与默认值18080 策略端口、18081 mitm 端口、4096 条策略上限等pkg/constants/configuration.go启动链路DNS 代理 15353、iptables OUTPUT 53 重定向、nft 装配、策略服务器、mitm 透明模式门控main.gonftables 动态放行集合pkg/nftables/manager.go 及其单测 pkg/nftables/manager_test.go策略服务器/policy、/healthz、mitm 未就绪时 503 的门控policy_server.go透明 mitmproxy 的完整配置参考环境变量表、config.yaml静态项、优先级规则docs/mitmproxy-transparent.mdegress 组件总览与网络隔离设计docs/components/egress.md、docs/architecture/network-isolation.md。复现提示基准结果强依赖宿主机 CPU/网络栈与容器运行时版本跨机器对比请保持「同机、同脚本、同镜像」hostname.txt中的域名需在当前网络可达否则失败请求不会写入time_total脚本会以WARN: only x/y responses captured提示捕获量不足此时应检查容器日志LOG_HOST_DIR再下结论。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenSandbox Egress 性能基准测试指南：量化 DNS/nft 管控与透明 MITM 的开销
OpenSandbox Egress 性能基准测试指南量化 DNS/nft 管控与透明 MITM 的开销【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox本文基于 OpenSandbox 仓库中 egress 组件的基准测试文档components/egress/docs/benchmark.md及其配套的测试脚本系统讲解如何在本机 Docker 环境里量化沙箱出站管控的端到端延迟与吞吐开销一是bench-dns-nft.sh对「无管控基线 / dns / dnsnft」三种模式的对比二是bench-mitm-overhead.sh对「是否叠加透明 mitmproxy 中间人」的开销测量。读完后你将能够复现这两套基准、正确解读 Req/s、P50、P99、CPU/内存趋势等结果并理解每种模式在源码层面的实现位置与开销来源。一、被测对象egress 的三种流量模式OpenSandbox 的 egress 组件以 sidecar 容器形式接管沙箱的出站流量。它的强制模式由环境变量OPENSANDBOX_EGRESS_MODE决定取值在 pkg/constants/configuration.go 中定义解析逻辑位于 pkg/constants/mode.go 的ParseEgressMode模式由dns必需和nft两个 token 以连接、顺序无关非法值会回退到dns并打印告警。基准测试覆盖的三种形态正是baseline普通curl容器不经过 egress作为无代理对照dns仅启用 DNS 代理做解析层拦截pass-through不写 nftables 规则dnsnftDNS 代理 在每次 DNS 应答前同步调用 nftables 的AddResolvedIPs把解析出的 IP 加入动态放行集合实现 L2网络层强制。这条同步写路径可以在 nft.go 的setupNft中看到——它将 DNS 应答回调接入 pkg/nftables/manager.go 的AddResolvedIPs并有 pkg/nftables/manager_test.go 的单测覆盖 TTL 钳制、空集 no-op 等边界dnsnft 透明 mitmproxy在dnsnft之上通过OPENSANDBOX_EGRESS_MITMPROXY_TRANSPARENTtrue启用mitmdump --mode transparent对 TCP 80/443 做 TLS 解密与 L7 处理详见 docs/mitmproxy-transparent.md。理解这几种模式的差异是理解后续所有基准数字的前提dns模式只多一跳本地 DNS 代理127.0.0.1:15353dnsnft额外多出每次解析后的内核态 nftables 集合写入而 MITM 则额外引入 TLS 双向握手重做与 mitmdump 常驻进程的 CPU/内存开销。二、bench-dns-nft.shbaseline / dns / dnsnft 端到端对比2.1 前置条件宿主机安装Docker与curl脚本用宿主机curl等待healthz并向策略服务器推送策略域名列表文件 tests/hostname.txt格式为一行一个域名#注释与空行被忽略当前仓库中该文件包含 101 个域名在components/egress目录下执行脚本或自行调整脚本内路径。2.2 运行方式cd components/egress ./tests/bench-dns-nft.sh脚本行为与可调参数见 bench-dns-nft.sh 头部注释与变量定义参数默认值说明IMGopensandbox/egress:localegress 镜像名。脚本默认会先docker build构建该镜像构建上下文为仓库根目录、Dockerfile 为 components/egress/Dockerfile设置IMG...可跳过重新构建的语义替换BASELINE_IMGcurlimages/curl:latestbaseline 阶段使用的普通 curl 镜像要求镜像内自带curlBENCH_SAMPLE_SIZE0使用全部域名随机抽取 n 个域名参与测试。脚本优先用shuf/gshuf洗牌不可用时回退到awk sort的可移植实现LOG_HOST_DIR/LOG_FILE/tmp/egress-logs/egress.logegress 日志落盘位置容器内挂载到/var/log/opensandbox工作负载的关键参数硬编码在脚本中ROUNDS10每轮对每个域名发 1 个并发HEAD请求、CURL_TIMEOUT10秒单请求超时、BENCH_EXEC_TIMEOUT300秒整体墙钟上限总请求数为ROUNDS × NUM_DOMAINS。2.3 每个阶段的执行细节脚本按baseline → dnsnft → dns的顺序依次执行三个 phaserun_phase_baseline/run_phase每个 phase 的完整流程是起容器docker run -d --cap-addNET_ADMIN并通过--sysctl关闭 IPv6dns/dnsnft模式还会注入OPENSANDBOX_EGRESS_MODE并把策略端口-p 18080:18080映射到宿主机18080 即源码中 DefaultEgressServerAddr 的默认监听地址等待就绪宿主机轮询http://127.0.0.1:18080/healthz最多 30 次每次间隔 0.5s。该端点由 policy_server.go 注册同时暴露运行时POST/GET /policy与GET /healthz推送策略把全部基准域名拼成{defaultAction:deny,egress:[{action:allow,target:域名}]}通过POST /policy下发——即默认拒绝、逐域名放行这正是 egress 策略服务器的标准用法预热先对首个域名发 1 个HEAD验证连通性再跑 1 个域名、1 轮、10 条 URL 的 warm-up排除冷启动DNS 首查、nft 集合初始化、连接建立对计时相位的污染计时相位在容器内循环ROUNDS轮每轮并发对每个域名执行curl -s -I -w %{time_namelookup}\t%{time_total}\n --max-time 10 url把 DNS 解析耗时time_namelookup与端到端总耗时time_total逐行写入容器内/tmp/bench-raw.txt结束后docker cp回宿主机。使用HEAD无响应体是有意为之它只覆盖 DNS TCP TLS HTTP 响应头路径从而聚焦管控栈本身的开销而不是网络带宽。2.4 结果与产物终端脚本末尾打印三行对比表baseline/dns/dnsnft列出Req/s、Avg、P50、P99括号内百分比为相对 baseline 的变化量延迟%表示变慢Req/s-X%表示吞吐下降宿主机/tmp原始数据bench-e2e-baseline-total.txt、bench-e2e-dns-total.txt、bench-e2e-dnsnft-total.txt—— 每行一个time_total秒bench-e2e-{mode}-namelookup.txt—— 每行一个time_namelookup用于单独观察 DNS 解析耗时受代理的影响bench-e2e-{mode}-wall.txt—— 该 phase 的墙钟耗时Req/s 即「成功请求数 / wall」。统计口径由脚本内的stats()函数定义sort -n排序后按int(n*0.50.5)、int(n*0.990.5)取分位数均值由awk累加得出。这个实现意味着 P99 对样本量敏感第 5 节会展开。三、bench-mitm-overhead.sh透明 MITM 开销专项3.1 对比维度与场景该脚本固定模式为dnsnft比较「不开 mitm」与「叠加透明 mitmproxy」两组容器run_phase dns_nft 0/run_phase dns_nft_mitm 1并在 mitm 组额外注入OPENSANDBOX_EGRESS_MITMPROXY_TRANSPARENTtrue与OPENSANDBOX_EGRESS_MITMPROXY_PORT默认 18081与 configuration.go 中DefaultMitmproxyPort一致。默认BENCH_SCENARIOSshort,download两个场景short大量 HTTPSHEAD请求HEAD storm模拟高频短连接场景。工作负载为ROUNDS × NUM_DOMAINS × BENCH_SHORT_INFLIGHT_PER_DOMAIN默认 10 轮 × N 域名 × 1 并发/域名download向同一 URL 发起并行GET默认 URL 是 Cloudflare 的测速下载端点__down?bytes20971520约 20 MiB默认BENCH_DOWNLOAD_PARALLEL4路并行、BENCH_DOWNLOAD_ROUNDS1轮、BENCH_DOWNLOAD_MAXTIME600秒单流超时、BENCH_DOWNLOAD_EXEC_TIMEOUT900秒墙钟上限。3.2 运行方式cd components/egress ./tests/bench-mitm-overhead.sh完整参数表摘自 bench-mitm-overhead.sh 头部注释参数默认值说明SKIP_BUILD未设置设为1跳过镜像构建直接复用IMG脚本顶部固定为opensandbox/egress:localBENCH_SAMPLE_SIZE0同前随机抽取 n 个域名BENCH_SCENARIOSshort,download逗号分隔只测一个场景可设BENCH_SCENARIOSshort或downloadBENCH_SHORT_INFLIGHT_PER_DOMAIN1short场景每个 URL 每轮的并发 HEAD 数调高可压出更高并发BENCH_DOWNLOAD_URLCloudflare__down~20 MiBdownload场景的下载目标脚本会自动解析其 host 并加入放行策略download_url_host否则默认拒绝策略会挡住该流量BENCH_DOWNLOAD_PARALLEL/BENCH_DOWNLOAD_ROUNDS/BENCH_DOWNLOAD_MAXTIME4 / 1 / 600并行流数 / 轮数 / 单流最大时长BENCH_DOCKER_STATS_INTERVAL1容器指标采样间隔秒调小如0.5可获得更密的时序数据LOG_HOST_DIR/LOG_FILE/tmp/egress-logs/egress.log同前除流量指标外该脚本还内置了容器资源遥测start_docker_stats_log会在整个 phase 期间按BENCH_DOCKER_STATS_INTERVAL周期采集容器内/proc/loadavgload1/5/15 及 runnable/total_tasks与docker statsCPUPerc、MemUsage、MemPerc、NetIO、BlockIO追加写入 TSV 文件表头为unix_ts、load1、load5、load15、runnable、total_tasks、CPUPerc、MemUsage、MemPerc、NetIO、BlockIO。另一个值得注意的细节mitm 相位在推送策略之后、正式计时之前会轮询最多 90 秒等待首个域名 HTTPS 可达等待 mitmdump 启动 客户端信任 CA 建立。这与源码中的健康门控一致——透明模式下在 mitm、iptables 重定向与 CA 导出就绪前GET /healthz会返回503 (mitm not ready)以防过早进入就绪状态见 docs/mitmproxy-transparent.md。3.3 结果与产物终端每个场景一张表。short表列为 Req/s、Avg(s)、P50(s)、P99(s)download表列为 Agg MB/s总字节数 / 下载相位墙钟流重叠、Avg(s)/stream、P50、P99、Total MiB两组数据下方给出E2E latency loss (avg time_total)单位为ms/request与%由calc_e2e_latency_loss计算(mitm均值 - 无mitm均值) × 1000宿主机/tmp原始数据延迟类bench-mitm-{mode}-short-*.txttotal/namelookup/wall、bench-mitm-{mode}-download-raw.tsvtime_total\tsize_download两列、-download-wall.txt、-download-bytes.txt容器指标两个 phase 都写bench-mitm-docker-stats-dns_nft.tsv与bench-mitm-docker-stats-dns_nft_mitm.tsv。文档特别提示容器内loadavg在很多情况下跟随宿主机 load应作为相对趋势参考而非绝对值。四、参考基线示例运行原文档给出了一组示例运行的参考基线明确声明仅作示意same machine, same script不构成 SLA。MITM 列均为dnsnft 透明 mitmproxy。4.1download场景4 流并行 GET~20 MiB1 轮1 秒采样指标dnsnft mitmCPUPercdocker stats大多~2–5%峰值~5.6%常~5–11%峰值~10.9%MemUsage~9–18 MiB~68–91 MiBload1最高~0.23尖峰~0.66随后~0.4–0.6结论在该 trace 中叠加 MITM 后峰值 CPU% 约为 2 倍、常驻内存RSS约为 5 倍。这与 mitmdump 常驻进程 TLS 会话缓冲的行为相符——download相位 CPU 占用低吞吐受带宽限制但内存占用是稳定的、与流量类型无关的固定成本。4.2short场景HEAD storm短相位行数稀疏示例运行的负载画像10 rounds × 40 URLs × 1 inflight 400 requests。指标dnsnft mitmReq/s3.641.90-47.6%Avg latencytime_total0.315 s0.605 s91.9%P50 latency0.136 s0.143 s5.2%P99 latency1.439 s10.006 s595.2%E2E latency loss (avg)baseline289.88 ms/request91.95%指标dnsnft mitmCPUPerc热样本~132%热样本~232%MemUsage~6–10 MiB~58–88 MiB需要说明多核环境下CPUPerc 100%属正常现象——Docker 的 CPU 指标允许容器同时占用多个核的当量。结论该样本显示出透明 MITM 明显的需求侧开销——平均每个请求多289.88 ms吞吐降到约一半P50 接近基线而 P99 急剧放大说明尾延迟被显著放大TLS 重协商、证书签发/缓存未命中等慢路径主要落在少数请求上。五、如何正确解读这些数字结合脚本实现与原文档的提示解读基准结果时有四个注意点小样本下 P99 高度敏感。stats()用排序后取第int(n*0.990.5)个值400 个样本中 P99 只由约 4 个最慢样本决定。原文档明确建议对尾延迟指标要增大轮数或域名数提高ROUNDS、BENCH_SAMPLE_SIZE或BENCH_SHORT_INFLIGHT_PER_DOMAIN才能得到稳定的 P99dns与dnsnft的差值衡量的是 nft 动态写路径每解析一个域名就多一次同步的 nftables 集合元素写入nft.go 中回调触发因此该差值直接反映 L2 强制的边际成本而baseline与dns的差值则主要反映本地 DNS 代理这一跳CPU 与内存趋势相互印证示例中 CPU 峰值约 1.8 倍232/132、RSS 在 mitmdump 下明显更高两个脚本的产物-total.txt、-namelookup.txt、docker-stats-*.tsv都是原始数据可自行重算任意分位数或时间窗更密的遥测需要更细粒度的主机/容器趋势时跑更长相位或设置BENCH_DOCKER_STATS_INTERVAL0.5。六、相关源码与延伸阅读模式解析与回退pkg/constants/mode.go环境变量与默认值18080 策略端口、18081 mitm 端口、4096 条策略上限等pkg/constants/configuration.go启动链路DNS 代理 15353、iptables OUTPUT 53 重定向、nft 装配、策略服务器、mitm 透明模式门控main.gonftables 动态放行集合pkg/nftables/manager.go 及其单测 pkg/nftables/manager_test.go策略服务器/policy、/healthz、mitm 未就绪时 503 的门控policy_server.go透明 mitmproxy 的完整配置参考环境变量表、config.yaml静态项、优先级规则docs/mitmproxy-transparent.mdegress 组件总览与网络隔离设计docs/components/egress.md、docs/architecture/network-isolation.md。复现提示基准结果强依赖宿主机 CPU/网络栈与容器运行时版本跨机器对比请保持「同机、同脚本、同镜像」hostname.txt中的域名需在当前网络可达否则失败请求不会写入time_total脚本会以WARN: only x/y responses captured提示捕获量不足此时应检查容器日志LOG_HOST_DIR再下结论。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考