Веб-сервер компилирует Caddyfile в машинный код и обещает 3x — а тред спросил: 35k qps кому?

Caddyfile, скомпилированный до машинного кода

Пост о zeroserve (157 голосов, 49 комментариев) описывает необычный конвейер. zeroserve — это HTTPS-сервер без конфигурации, построенный на io_uring; новый режим Caddy-совместимости берёт Caddyfile, JIT-компилирует его в eBPF, затем опускает до нативного машинного кода x86_64/ARM64 и запускает внутри цикла событий io_uring. Главное заявление — втрое выше пропускная способность и на 70% ниже задержка, чем у Caddy. Поддерживаемая часть выбрана намеренно: маршрутизация запросов, матчеры, изменение заголовков, переписывание URI, отдача статики, reverse_proxy с единственным апстримом, базовая авторизация, карты и переменные.

Подвох — в том, что осталось за бортом. По документу совместимости проекта, здесь нет автоматизации TLS и рантайма ACME, нет плагинов Caddy/Go, нет переписывания тела ответа, нет FastCGI, нет метрик Prometheus, а сжатие — только gzip/zstd. Тред сразу раскололся: стоит ли скорость такого вычитания.

«Caddy-совместимость минус всё, что важно»

Два чаще всего упомянутых пропуска оказались ровно теми, на что люди и опираются:

«Нет ACME! Это сразу мимо» — tln

«„Caddy-совместимость“ минус всё, что важно, — ACME и плагины. А NGINX всё равно вне конкуренции. Не всё нужно переписывать.» — codingjoe

Автоматический HTTPS через ACME — та самая фича, ради которой Caddy чаще всего и выбирают. Режим совместимости, который её выбрасывает, совместим с синтаксисом, но не с причиной. Отдельный наблюдатель заметил, что nginx держался в сравнении на удивление хорошо: чемпион тихо выиграл бенчмарк, по которому его и мерили.

Число, переосмыслившее весь проект

Самый резкий разворот пришёл не от скепсиса к бенчмарку, а от его принятия и вопроса: для кого это. Сеньор-инженер прогнал арифметику по цифрам самого проекта:

«Мой бэкенд на одном хосте не качает 35k qps. Если каждый запрос — 500 байт, то 35k qps — это почти 20 мбит/с непрерывно при нулевом прочем io… И это всего на двух потоках! …Это оптимизация метрики, которая узким местом изначально не была.» — bastawhiz, сеньор-инженер в Runway

Это и есть несущая критика. Более раннюю, мягкую её версию выдал читатель, задавший очевидный вопрос ещё до всяких цифр: «кто-нибудь вообще сталкивался со сценарием, где Caddy оказывался узким местом?» Если горизонтальное масштабирование уже перекрывает реальный трафик, то трёхкратное ускорение веб-сервера оптимизирует ту часть стека, которая ограничением и не была.

io_uring, JIT и счёт за безопасность

Глубже лежало беспокойство не о скорости, а о поверхности атаки. JIT-компиляция конфига в работающий веб-сервер встревожила практиков:

«Идея JIT-компиляции веб-сервера в маленьком проекте меня скорее ужасает. Поверхность атаки здесь огромна.» — bastawhiz, сеньор-инженер в Runway

io_uring собрал собственные предостережения. «Выставлять наружу сервисы на io_uring — категорически нет. С момента последнего бюллетеня по безопасности прошло лишь пара недель», написал один читатель; другой сказал, что каждый найденный им источник называл io_uring менее безопасным для публичного веб-сервера. Французский комментатор увидел в «локфайле на 3400 строк и AGENTS.md» признаки авторства с тяжёлым участием ИИ, а один читатель отмёл проект целиком:

«Очередной vibe-coded Rust-проект, мёртвый через полгода. Тем, кому правда нужна производительность, не станут брать случайный сервер с нулевой поддержкой и репутацией.» — Thaxll

Настоящий инженерный трюк, нацеленный на проблему, которой у большинства нет

Конвейер по-настоящему остроумен: опустить декларативный конфиг до нативного кода на io_uring — это как раз то, что выигрывает бенчмарки. Но вердикт треда связный: пропускная способность реальна и почти бесполезна, потому что для типичного бэкенда узкое место — не веб-сервер, а размен — без ACME, с поверхностью атаки от JIT, с экспозицией io_uring, без истории — стоит больше, чем приносит скорость. Если вы работаете на масштабе, где 35k qps на двух потоках — это ваш пол, проект интересен. Почти никто так не работает.