Apache vs Nginx vs Caddy: статика, sendfile, HTTP/2 и HTTP/3

Когда выбирают веб‑сервер, чаще всего обсуждают «что быстрее» и «что проще». Но в реальной эксплуатации всё упирается в приземлённые вещи: как отдаются static files, как ведёт себя sendfile, что происходит с дисковым I/O, насколько корректны заголовки кеширования, работают ли range requests для докачки и как сервер дружит с HTTP/2 и HTTP/3 (QUIC).

Ниже — сравнение Apache vs Nginx vs Caddy именно под раздачу контента: CSS/JS/шрифты/изображения/архивы и large file download. Будет меньше абстрактных «бенчмарков из интернета» и больше практики: что включать, что измерять и где чаще всего ловят грабли.

Ключевые критерии: что важно именно для статики

Для динамики (PHP/Go/Node) выбор часто решают экосистема и reverse proxy. Для статики и скачиваний критерии другие:

• Путь данных: копирование через userspace или «нулевая копия» (zero-copy) через sendfile.

• Дисковый I/O: синхронное чтение vs асинхронное (где применимо) и влияние page cache.

• Сетевой I/O: пакетизация (tcp_nopush/TCP_CORK), keepalive, буферизация.

• Кэш метаданных: удержание открытых файлов и результатов stat() (например, open_file_cache в Nginx), чтобы снизить нагрузку на FS при высокой RPS.

• Компрессия: gzip/brotli и где лучше делать (на лету или заранее).

• Кеширование на клиенте и прокси: ETag/Last-Modified, Cache-Control, Vary, корректные 304.

• Range/206: поддержка range requests для докачки и стриминга, отсутствие конфликтов с zero-copy.

• HTTP/2 и HTTP/3: мультиплексирование, head-of-line blocking, 0-RTT (в QUIC) и реальная отдача на вашей аудитории.

Если хотите быстро найти «дырки» именно в заголовках и поведении кеша, полезно держать под рукой отдельный разбор по стратегии: Cache-Control, ETag и Last-Modified для статики.

Apache: сильная универсальность, но важно не «по умолчанию»

Apache выбирают за совместимость, модульность и привычный стек. Для статики Apache может быть быстрым, но критично, какой MPM включён (event/worker/prefork) и какие модули активны в «горячем пути» запроса.

sendfile в Apache: где помогает и где ломает

За zero-copy отвечают EnableSendfile и частично EnableMMAP. В типовых Linux‑сценариях sendfile ускоряет отдачу больших файлов и снижает CPU, но есть характерные случаи, когда его приходится отключать:

• Сетевые/виртуальные ФС (NFS, некоторые FUSE/overlay) иногда дают странные эффекты: обрывы, битые ответы, проблемы с 206. В диагностику нормально входит временно поставить EnableSendfile Off.

• Разница не всегда «космическая»: если файлы уже в page cache и у вас быстрый NVMe, упираетесь скорее в сеть/latency/заголовки, чем в копирование.

«Мелкая статика» и стоимость syscalls

На большом количестве мелких файлов (иконки, небольшие JS chunks) узким местом чаще становится не сеть, а частые stat()/open() и накладные расходы обработки запроса. Обычно максимум эффекта дают три вещи:

• долгий Cache-Control для неизменяемых ассетов (с хешем в имени);

• предсжатые файлы (если вы отдаёте сжатие для текста);

• контроль лишних модулей и логирования, особенно на высокой RPS.

HTTP/2 и HTTP/3

HTTP/2 в Apache зрелый: важно включить модуль h2 и убедиться, что TLS/ALPN согласуются корректно. С HTTP/3 ситуация более «версионно‑зависимая»: в проде её включают осознанно, с тестами на конкретных клиентах и понятным планом отката.

Практический вывод по Apache: если вы уже на нём и задача — быстрее отдавать static files, чаще всего достаточно привести в порядок кеширование/компрессию и убедиться, что MPM — event, а не prefork (если нет жёсткой необходимости).

Nginx: «рабочая лошадка» для статики и скачиваний

Nginx исторически силён именно в раздаче статики и роли reverse proxy. Его event‑модель и подход к буферам делают его удобным для больших параллельных нагрузок и огромного числа соединений.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

sendfile, aio и tcp_nopush: что реально влияет

В Nginx часто обсуждают тройку sendfile, aio и tcp_nopush. Важно понимать их «зону ответственности»:

• sendfile — уменьшает копирование данных через userspace на отдаче файлов.

• aio — помогает не блокировать worker на чтении, когда есть реальные ожидания диска (холодный кэш, медленное хранилище, очереди I/O).

• tcp_nopush — оптимизирует формирование пакетов (аналог TCP_CORK). Иногда заметно помогает на больших файлах, но не является универсальным ускорителем.

Из практики эксплуатации:

• Если статика «горячая» (в RAM page cache), aio часто почти ничего не даёт: диск не ждём.

• Если это large file download с холодного диска или сетевого хранилища — aio может уменьшить хвосты (p95/p99), но обязательно тестируйте под вашу ФС/ядро.

• Если видите странные обрывы/206 на нестандартной ФС — временно выключайте sendfile и проверяйте воспроизводимость.

open_file_cache: когда это must-have

open_file_cache — одна из самых практичных ручек Nginx для сайтов с огромным количеством мелких файлов и высокой RPS. Идея простая: меньше ходим в файловую систему за метаданными, реже открываем/закрываем файлы, экономим syscalls.

Типичные признаки, что пора смотреть в сторону open_file_cache:

• много 404/403 на статике (например, боты), и каждый запрос «долбит» FS;

• много мелких файлов и высокий concurrency;

• по профилю видно, что узкое место — VFS/syscalls, а не сеть.

Риск тоже понятный: агрессивный кэш + частые деплои с заменой файлов могут давать неожиданные «старые» ответы, если неверно выставлены интервалы проверки. На практике это лечится дисциплиной деплоя (версионирование ассетов) и аккуратными таймингами проверки валидности.

ETag/Last-Modified и caching headers: что проверить в первую очередь

Для экономии трафика и ускорения повторных загрузок правильнее начинать не с «выжать 5% из sendfile», а с заголовков:

• ETag/Last-Modified: обеспечивают 304 и экономят канал/время.

• Cache-Control: определяет поведение браузера и промежуточных прокси.

• Range/206: убедитесь, что докачка работает и не ломается лимитами/прокси.

Для immutable‑ассетов (файлы с хешем в имени) типовая стратегия: долгий TTL + immutable. Для HTML — короткий TTL или no-cache с revalidate, чтобы пользователь видел обновления без «залипания» старой версии.

gzip и brotli: на лету или заранее

Компрессия — баланс CPU vs трафик. Базовая практика:

• gzip — универсальный вариант, почти везде «без сюрпризов».

• brotli — обычно лучше по степени сжатия на текстовых ассетах, но дороже по CPU (особенно на высоких уровнях).

• Предсжатие (br/gz рядом с оригиналом) часто даёт лучший «продовый» результат: CPU не тратим на каждый запрос, отдаём готовое.

Если вы в фазе тюнинга, меряйте не только среднее, а хвосты: CPU на worker, p95/p99 и долю трафика на текстовые типы. Иногда выгоднее чуть хуже сжимать, но держать стабильный p99.

HTTP/2 и HTTP/3 (QUIC)

HTTP/2 в Nginx — привычный стандарт. Для статики он уменьшает «стоимость» множества запросов, но не отменяет кеширование и не спасает от тяжёлых исходных файлов.

HTTP/3/QUIC чаще всего имеет смысл, когда у аудитории заметны потери пакетов и высокая мобильная доля. Он лучше переносит потери отдельных пакетов, потому что убирает head-of-line blocking TCP на уровне транспорта. Цена — сложность диагностики (UDP, QUIC‑метрики, особенности middleboxes) и необходимость внимательно следить за поддержкой клиентами.

Caddy: удобство и «правильно по умолчанию», но проверяйте крайние случаи

Caddy любят за минималистичную конфигурацию и сильную «из коробки» историю вокруг TLS и современного HTTP. В контексте статики Caddy часто выигрывает временем внедрения: быстро поднять сайт с адекватными настройками проще, чем собирать десятки директив вручную.

Отдача static files и «эффективный путь данных»

Caddy умеет эффективную отдачу файлов, используя возможности ОС. На практике разница «Nginx vs Caddy» по чистой статики часто меньше, чем разница между «есть нормальные caching headers» и «кеширования нет вообще».

Где стоит быть внимательнее:

• экстремально высокий трафик на мелкие файлы и желание контролировать каждую накладную (syscalls, метаданные, тайминги);

• сложная схема раздачи (fallback’и, строгие правила range, нестандартные заголовки под CDN) — убедитесь, что конфигурация выражает логику однозначно.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

gzip/brotli и заголовки кеширования

Caddy обычно проще «привести в порядок» по компрессии и базовым заголовкам кеширования: конфигурация декларативнее, меньше шансов случайно включить взаимоисключающие опции. Но универсального рецепта нет: если у вас большой объём трафика на текст, всё равно придётся выбирать стратегию (на лету vs precompressed) и измерять влияние на CPU.

HTTP/2 и HTTP/3 как практическое преимущество

Один из частых аргументов в пользу Caddy — простое включение современных протоколов и адекватные дефолты. Для сайтов с мобильной аудиторией и «длинным хвостом» по качеству сетей HTTP/3 может дать более стабильную загрузку. Но держите план отката и сравнивайте метрики ошибок и времени установления соединения (TLS/QUIC handshake).

Сравнение по «болям» админа: что выбрать под конкретную задачу

Сайт с кучей мелких ассетов (SPA, витрина, лендинг)

Основной выигрыш даст не «магия ядра», а грамотные caching headers, долгий TTL для immutable‑файлов, корректный Vary (если нужно), предсжатые br/gz и понятная стратегия ETag/Last-Modified.

Nginx удобен, когда вы хотите тонко настроить кэш метаданных (open_file_cache) и предсказуемо контролировать поведение на большой RPS. Caddy хорош, если важнее скорость внедрения и современный стек «по умолчанию».

Большие файлы и докачка: large file download + range

В этой задаче критичны range requests, стабильность 206, работа zero-copy на вашей ФС и отсутствие лишней компрессии (большие бинарники обычно не сжимают). Разбор типовых проблем с 206, кешами и прокси удобно держать отдельно: Range requests в Nginx/Apache и нюансы кеширования.

Nginx чаще выбирают за предсказуемость и инструменты вокруг ограничений скорости/буферов. Apache тоже справится, но внимательно проверьте поведение EnableSendfile именно на вашем хранилище.

«Хочу HTTP/3, но без зоопарка конфигов»

Если цель — аккуратно включить HTTP/3 и быстро получить современную конфигурацию TLS/ALPN, часто проще стартовать с Caddy. Но HTTP/3 — это не галочка «ускорить всё»: в плохих сетях помогает заметно, в хороших может дать минимальную разницу.

Нужна максимальная совместимость и легаси‑сценарии

Если у вас много наследия (особые правила, .htaccess‑подход, специфичные модули), Apache часто оказывается самым безболезненным выбором. Но именно для статики стремитесь к конфигурации, где Apache не делает лишней работы на каждый запрос.

Практический чек‑лист performance tuning для статики (любой сервер)

Чтобы не спорить «Apache vs Nginx vs Caddy» абстрактно, полезнее прогнать один и тот же чек‑лист и сравнить цифры.

1. Проверьте caching headers: есть ли Cache-Control и соответствует ли он типу контента; корректны ли ETag/Last-Modified; нет ли лишнего no-store на ассетах.

2. Проверьте 304/206: отдаёт ли сервер 304 на If-None-Match/If-Modified-Since; работают ли range‑запросы (206) и докачка.

3. Оцените компрессию: включены ли gzip/brotli только для текстовых типов; не сжимаете ли то, что не надо; есть ли precompressed для горячих ассетов.

4. Снимите метрики узких мест: CPU (user/sys), контекстные переключения, iowait, сеть (ретрансляции), количество открытых файлов и соединений.

5. Проверьте sendfile/aio: включено ли и даёт ли эффект именно на ваших данных; нет ли регрессий на нестандартном хранилище.

6. HTTP/2/HTTP/3: сравните не только среднее, а p95/p99 и количество ошибок на клиентах; убедитесь, что ALPN/сертификаты не вызывают лишние редиректы и повторные рукопожатия.

Самая частая ошибка в тюнинге статики — пытаться «ускорить сервер», когда проблема на самом деле в отсутствии кеширования на клиенте/CDN и слишком коротком TTL для неизменяемых ассетов. Исправление заголовков обычно даёт эффект на порядок больше, чем точечная настройка sendfile.

Мини-набор тестов, чтобы сравнение было честным

Если вы реально выбираете между тремя серверами, сравнивайте их на одинаковом наборе сценариев и в одинаковых условиях (одна ОС, одна ФС, одинаковые TLS‑параметры, одинаковые файлы):

• 10–50 тыс. запросов на мелкие файлы (1–10 KB) с keepalive;

• смешанный профиль: HTML без долгого кеша + ассеты с долгим кешем;

• скачивание 1–5 GB с докачкой (range);

• холодный кэш диска vs горячий (после прогрева);

• HTTP/1.1 vs HTTP/2 vs HTTP/3 (если включаете).

Смотрите минимум: RPS, среднюю и p95/p99 латентность, CPU system/user, количество открытых файлов/соединений, сетевые ретрансляции. Только так вы поймёте, что именно ограничивает производительность: веб‑сервер, файловая система, диск или сеть.

Итоги: кратко про выбор

• Nginx — отличный выбор, когда важны предсказуемость, тонкая настройка отдачи static files, контроль sendfile/aio/tcp_nopush, кэш метаданных (open_file_cache) и стабильная работа на высоких нагрузках.

• Apache — универсален и удобен в легаси‑сценариях. Для хорошей статики требуются осознанные настройки (MPM, EnableSendfile, заголовки), но при правильной конфигурации он не обязан быть «медленным».

• Caddy — сильный кандидат, если вы хотите быстро получить современный стек, простую конфигурацию и аккуратное включение HTTP/2/HTTP/3. Для экстремального тюнинга и очень тонкого контроля иногда проще Nginx, но «по умолчанию» Caddy часто близок к тому, что хочется в проде.

Если вы выбираете сервер под проект «с нуля», часто удобнее стартовать на виртуальном хостинге для простых сайтов и быстро переезжать на VDS, когда появляется необходимость тонко настраивать сеть, файловую систему и протоколы вроде HTTP/3.