zeroserve v0.2.11: Caddy 相容性與 eBPF 到 Native JIT 編譯

zeroserve v0.2.11 引入了 Caddy 相容模式，允許使用者提供 Caddyfile，接著伺服器會將其 JIT 編譯為 eBPF，隨後編譯為 native x86_64 或 ARM64 機器碼。此過程使伺服器能夠在 io_uring 事件迴圈中執行配置邏輯，與傳統的解釋型或高階伺服器配置相比，顯著提升了效能。

效能基準測試

在 HTTPS 反向代理情境下，zeroserve 展現出比 Caddy 更顯著的效能提升。在 AMD Ryzen 7 3700X（使用兩個執行緒）上進行的測試中，zeroserve（使用 clang 編譯器）達到了約 38,948 req/s，而 Caddy 僅為 12,529 req/s。

關鍵效能指標包括：

Protocol	Server	Throughput	p50 Latency	p99 Latency	Peak 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

這些結果顯示 zeroserve-clang 提供的吞吐量約為 Caddy 的 3 倍，且 p99 延遲降低了 70%（3.91ms 對比 13.11ms）。

透過 eBPF 中間件實現擴充性

由於 zeroserve 在使用者空間執行 Turing-complete eBPF，因此它允許透過 Caddyfile 直接將自定義的 native code 整合到請求管線中。使用者可以載入 eBPF 插件，並使用 zeroserve_call 指令來呼叫這些插件中的特定方法。

例如，為 S3 相容的儲存桶實作 AWS SigV4 驗證，需要載入插件 (io.su3.aws-sigv4.c) 並在路由區塊中使用 zeroserve_call 指令，以便在請求被反向代理之前進行簽署。

技術實作與社群回饋

架構

zeroserve 的核心創新在於將高階配置 (Caddyfile) $\rightarrow$ eBPF $\rightarrow$ Native Machine Code 的轉換過程。這讓伺服器能夠利用 io_uring 的非同步 I/O 效率，同時保持靈活的配置格式。

社群評論

技術使用者之間的討論突顯了關於採用 zeroserve 的幾個關鍵權衡與疑慮：

• 功能對等性： 評論者指出，「Caddy 相容性」僅限於配置語法，並不包含 Caddy 的核心功能，例如自動 ACME (SSL/TLS 憑證管理) 以及更廣泛的插件生態系統。
• 安全性疑慮： 使用 io_uring 和 JIT 編譯引發了安全警報。部分使用者認為，由於最近的安全公告，使用 io_uring 暴露服務是有風險的；而其他人則認為 JIT 編譯產生的攻擊面「非常巨大」。
• 實際效用： 幾位評論者質疑 Caddy 的效能是否對絕大多數使用者而言都是瓶頸，並認為水平擴展 (horizontal scaling) 比切換到專門的 JIT 編譯伺服器更具實用性。
• 與 Nginx 的比較： 基準測試顯示 Nginx 仍具備高度競爭力，其吞吐量 (37,424 req/s) 幾乎與 zeroserve-clang 持平，同時擁有長期穩定的紀錄與支援。