世界を動かす技術を、日本語で。

ゼロサーブにおけるキャディの互換性:スループット3倍、レイテンシ70%低減

2026年6月14日原文(su3.io)

概要

zeroserve は、ユーザ空間で eBPFスクリプト を実行する高性能HTTPSサーバー。 Caddyfile互換モード を搭載し、CaddyfileをeBPF・x86_64/ARM64ネイティブコードへJITコンパイル。 io_uringイベントループ で動作し、圧倒的なスループットを実現。 Caddynginx とのベンチマーク比較で優れた性能を示す。 カスタムeBPFコード の呼び出しやAWS SigV4認証付きリバースプロキシも柔軟に対応。

zeroserveの特徴とベンチマーク

  • ユーザ空間 で動作し、 eBPFスクリプト の実行をサポート
  • Caddyfile互換モード 搭載
    • Caddyfileを eBPF へJITコンパイルし、さらに x86_64/ARM64 機械語へ変換
  • io_uring ベースのイベントループで高効率なI/O処理
  • ベンチマーク(HTTPSリバースプロキシ、2スレッド、AMD Ryzen 7 3700X)
    • zeroserve-clang: 38,948 req/s | p50 1.45ms | p99 3.91ms | RSS 30.9 MiB
    • zeroserve-tcc: 36,653 req/s | p50 1.67ms | p99 4.00ms | RSS 34.2 MiB
    • caddy: 12,529 req/s | p50 4.74ms | p99 13.11ms | RSS 67.4 MiB
    • nginx: 37,424 req/s | p50 1.57ms | p99 4.24ms | RSS 25.7 MiB
  • 公式CI での実行結果も参照可能

zeroserveの導入方法

  • バイナリのダウンロードと実行例
    • curl -fL -o zeroserve https://github.com/losfair/zeroserve/releases/download/v0.2.11/zeroserve-$(uname -m)-linux
    • chmod +x zeroserve
    • ./zeroserve --caddy /etc/caddy/Caddyfile
    • curl http://127.0.0.1:8080 で動作確認

eBPFカスタムコードとCaddyfileの連携

  • Turing完全なeBPF を実行可能
  • Caddyfile 内から独自eBPFコードを呼び出し可能
    • 例:AWS SigV4認証付きS3互換バケットへのリバースプロキシ
      • io.su3.aws-sigv4.cを取得し、プラグインとして指定
      • Caddyfile例:
        example.com {
          route /s3/* {
            uri strip_prefix /s3
            rewrite * /my-bucket{uri}
            # eBPFミドルウェア`io.su3.aws-sigv4.o`の`sign_request`メソッドを呼び出し
            zeroserve_call io.su3.aws-sigv4 sign_request {
              access_key_id "minioadmin"
              secret_access_key "minioadmin"
            }
            reverse_proxy http://127.0.0.1:9000
          }
        }
        
  • 高度な認証・プロキシ処理 を柔軟に実装可能

ライセンス・著作権情報

  • © 2022-2026 Heyang Zhou
  • RSSフィード も利用可能

Hackerたちの意見

技術的な観点から見ると、これらのプロジェクトはいつも印象的だけど、ずっと疑問に思ってたことがあるんだ。Caddyがボトルネックになったケースって、誰か経験したことある?

ほとんどのアプリでは、バックエンドはプロキシよりもかなり遅いから、Caddyはボトルネックにはならないよ。逆転するのは接続の切り替えが激しい時で、TLSハンドシェイクが高コストな部分だから、セッション再開なしで短命の接続が大量に来ると、プロキシのCPUが安定した状態になる前に消費されちゃう。小さなレスポンスの非常に高いRPSもそうで、メモリの割り当てやヘッダーの解析が目立ってくる。

自分の経験では、Caddyはnginxよりもレイテンシとスループットが悪い。nginxで頻繁に600MB/s(約5gbps)を送信するサービスを設定したけど、CPUは50%で余裕だった。でも、そのマシンでCaddyは300MB/sでボトルネックになって、CPUは100%使ってた。AESハードウェアアクセラレーションは両方のソフトウェアで有効だった。これはほとんどの人が体験しない高スループットだけど、ほとんどの人が使うマシンよりもはるかに強力なマシンでの話。Caddyはラズベリーパイからメディアを配信する時には確実にボトルネックになるだろうね。最後に試したのは2025年だったけど、それ以来Caddyは改善されてるかも。ただ、nginxにはひどいデフォルト設定があるから、何も考えずにプロキシとしてベンチマークしてると、Caddyの方が良いかもしれない。例えば、nginxは多くのシナリオでアクティブなリクエストボディを一時ファイルにキャッシュして、バックエンドやアップストリームにできるだけ負担をかけないようにしてるけど、Caddyはもっと透明なプロキシって感じ。

nginxがこんなに頑張るとは驚きだね!

なんで?これは今までで最も最適化されたHTTPサーバーの一つだよ。ベンチマークでnginxを超えたって主張するものは、かなり疑ってかかるべきだと思う。zeroserveの数字はおそらく正確だろうけど、nginxの機能やモジュールエコシステムには及ばないから、私にはその利点はあまりないかな。

nginxは当然そうあるべきだよね?これは本当に合成的なhttp(s)/1.1のテストに過ぎないから。特にCaddyは、GCが必要ないような超短い単一レスポンスのクエリをテストしてるから、GCをオフにすることもできるよ。驚くことに、実際にはnginxやzeroserveよりもパフォーマンスが良くなるけど、このベンチマークの無意味さを考えると、実際のウェブサーバーの使用には何の意味もないね。

eBPFはまだチューリング完全じゃないと思ってる。バリファイアには複雑さの限界があるし、誰かがプログラムにタイマーを設定して自分自身を実行する「ライフゲーム」を実装したとしてもね。 https://isovalent.com/blog/post/ebpf-yes-its-turing-complete...

zeroserveはLinuxカーネルのeBPFランタイムを使ってeBPFを実行してないから、LinuxカーネルのeBPFランタイムの制約(ユーザースペースからLinuxカーネルを守るために選ばれたもの)はzeroserveには適用されないんだ。eBPF命令セットを使ってる他のツールにも同じことが言えるね。

ACMEがないなんて!それは致命的だわ。 https://github.com/losfair/zeroserve/blob/main/CADDY_COMPAT....

うん、zeroserveにACMEを統合する方法があればいいなと思う。zeroserveのプラグインシステムでそれをサポートするプラグインを追加できるかは分からないけど。

他にsu3.io:443のためにどの証明書を使うか聞いてくる変なChromeポップアップが出た人いる?めっちゃ奇妙で、こんなの見たことないよ。フィンガープリント: - 60949a09aab8677f87a0b9eda7099a03ca510fb3 - 1b146798f0dc93773247e86312f1b730c4eeebb3

ゼンでも同じだね。

Hacker Newsで議論の続きを見る