zeroserve v0.2.11：Caddy 兼容性与 eBPF 驱动的性能

zeroserve v0.2.11：Caddy 兼容性与 eBPF 驱动的性能

zeroserve v0.2.11 引入了 Caddy 兼容模式，可通过 eBPF 将 Caddyfile JIT 编译为本机机器码，实现比 Caddy 高达 3 倍的吞吐量和 70% 更低的延迟。

zeroserve v0.2.11：Caddy 兼容性与 eBPF 驱动的性能

zeroserve v0.2.11 引入了 Caddy 兼容模式，允许用户提供 Caddyfile，服务器随后将其 JIT 编译为 eBPF，再进一步编译为本机 x86_64 或 ARM64 机器码。该架构结合 io_uring 事件循环，相比传统 Web 服务器显著降低了开销。

性能基准

zeroserve 在 HTTPS 反向代理场景中相较于 Caddy 展示了显著的性能提升，并且与 Nginx 的结果相当。在一台 AMD Ryzen 7 3700X（两线程）上进行的测试中，使用 clang 后端的 zeroserve 达到了每秒 38,948 请求（req/s），而 Caddy 为每秒 12,529 请求。

协议 服务器 吞吐量 p50 延迟 p99 延迟 峰值 RSS
HTTPS zeroserve-clang 38,948 req/s 1.45ms 3.91ms 30.9 MiB
HTTPS zeroserve-tcc 36,653 req/s 1.67ms 4.00ms 34.2 MiB
HTTPS Caddy 12,529 req/s 4.74ms 13.11ms 67.4 MiB
HTTPS Nginx 37,424 req/s 1.57ms 4.24ms 25.7 MiB

从数据中可以得出关键结论：相较于 Caddy，吞吐量约提升 3 倍，p99 延迟降低约 70%。

eBPF 集成与自定义中间件

zeroserve 在用户空间运行图灵完备的 eBPF，使得可以直接从 Caddyfile 执行自定义代码。这允许实现通常需要单独插件或自定义服务器构建的复杂逻辑。

例如，用户可以通过调用 eBPF 中间件插件，为兼容 S3 的存储桶集成 AWS SigV4 认证。在 Caddyfile 中，这通过 zeroserve_call 指令实现：

example.com {
  route /s3/* {
    uri strip_prefix /s3
    rewrite * /my-bucket{uri}
  
    zeroserve_call io.su3.aws-sigv4 sign_request {
      access_key_id "minioadmin"
      secret_access_key "minioadmin"
    }
  
    reverse_proxy http://127.0.0.1:9000
  }
}

社区反馈与技术批评

尽管性能指标令人印象深刻，社区仍提出了关于 zeroserve 方法的实际用途和安全性的若干担忧。

安全性与攻击面

批评者指出，使用 JIT 编译和 io_uring 可能会扩大服务器的攻击面。

"在一个小项目中对 Web 服务器进行 JIT 编译的想法让我感到相当恐怖。这里的攻击面非常庞大。"

此外，一些用户对与 io_uring 相关的近期安全通告表示谨慎：

"暴露使用 io_uring 的服务是坚决不选的。"

功能等价性与实用性

一些开发者认为，对于大多数使用场景而言，性能提升微乎其微，因为 Caddy 已有的性能足以满足大多数应用。另一些人指出缺少关键功能，例如用于自动 SSL/TLS 证书的 ACME（自动证书管理环境），这正是许多用户选择 Caddy 的主要原因。

"“Caddy 兼容”却缺少所有重要的东西，如 ACME 和插件。"

关于 eBPF 的技术问题

关于用户空间中 eBPF 的本质仍在讨论中。一些用户质疑在用户空间而非内核中运行 eBPF 的目的，另一些人则争论鉴证器施加的复杂度限制是否使 eBPF 真正具备图灵完备性。

Sources