nginx Builder: как event-driven архитектура ответила на C10K
В начале 2000-х веб быстро менялся: страницы становились тяжелее, число пользователей росло, а открытое соединение всё чаще проводило большую часть времени в ожидании данных. Для сервера это создавало непривычную нагрузку, поскольку проблема заключалась уже не только в скорости обработки запроса, но и в способности недорого держать тысячи клиентских соединений одновременно. Именно в этом контексте появился nginx, архитектура которого была рассчитана на большое число соединений с самого начала.
C10K: десять тысяч соединений, а не десять тысяч вычислений
В 1999 году разработчик Дэн Кегель начал собирать заметки под названием The C10K Problem, посвящённые обслуживанию 10 000 клиентов одним сервером. Такая цифра сегодня выглядит скромно, но тогда она хорошо показывала предел привычной архитектуры: каждое соединение само по себе почти ничего не делает, однако требует памяти, файлового дескриптора и способа дождаться следующего события в сети.
Здесь важно не смешивать параллельные соединения с производительностью приложения. Сервер может быстро выполнить десять тысяч коротких запросов подряд и при этом плохо переносить десять тысяч медленных клиентов, которые понемногу отправляют или получают данные. Если каждому такому клиенту выделить отдельный процесс или поток, значительная часть системных ресурсов уйдёт на ожидание, хранение стеков и переключение контекста, хотя полезной работы в конкретный момент будет немного.
Что на самом деле делал Apache 1.3
Популярное изложение этой истории часто говорит, что Apache 1.3 создавал новый процесс для каждого входящего соединения. Это неточно. На Unix он обычно работал по модели, которую позднее назвали prefork: родительский процесс заранее поддерживал пул дочерних процессов, а каждый свободный дочерний процесс принимал и обслуживал одно соединение за раз. Такой подход избавлял от запуска процесса при каждом запросе, но сохранял главное ограничение: медленный клиент надолго занимал отдельного исполнителя.
Поэтому историческое сравнение нужно формулировать как «Apache 1.3 prefork против event-driven nginx», а не как вечное противостояние двух серверов. Начиная с Apache 2.0 модель обработки стала модульной, а современный Apache HTTP Server поддерживает в том числе многопоточные worker и event MPM. Он давно не сводится к схеме «один процесс на соединение».
Почему цикл событий масштабируется иначе
Игорь Сысоев начал разрабатывать nginx в 2002 году, работая в Rambler и сталкиваясь с высокой нагрузкой на его проекты. До отдельного сервера он экспериментировал с модулями Apache, включая mod_accel, однако затем перешёл к собственной реализации, построенной вокруг асинхронного цикла событий. История проекта nginx связывает первый рабочий прототип со второй половиной 2003 года, а публичный выпуск версии 0.1.0 состоялся 4 октября 2004 года.
В nginx мастер-процесс читает конфигурацию, открывает порты и запускает небольшое число worker-процессов. Каждый worker следит сразу за множеством сокетов и обращается к соединению, когда ядро сообщает, что оно готово принять или передать данные. На Linux для этого обычно применяется epoll, на системах семейства BSD и macOS доступен kqueue; полный список механизмов приводит документация nginx.
Эту разницу удобно представить как работу справочной службы. В модели с выделенным исполнителем каждый оператор остаётся на линии с одним клиентом, даже когда тот молчит и ищет документы. В событийной модели несколько операторов получают уведомления только тогда, когда конкретный клиент готов продолжить разговор, поэтому один оператор может последовательно продвигать много обращений. Соединения никуда не исчезают, но ожидание больше не требует отдельного процесса для каждого из них.
Неблокирующая архитектура не делает сервер бесконечно быстрым. Количество файловых дескрипторов, память под буферы, TLS, скорость диска и работа upstream-приложения остаются реальными ограничениями. Более того, блокирующий модуль внутри worker-процесса способен задержать все соединения, которыми тот занимается. Преимущество nginx состоит не в отмене этих затрат, а в том, что ожидание сетевого события обычно обходится гораздо дешевле; подробную схему master, worker и event loop разбирает описание архитектуры nginx.
Как nginx распространялся
Первые установки часто не заменяли Apache целиком. nginx ставили перед ним, чтобы отдавать статические файлы, принимать медленные клиентские соединения, буферизовать ответы и передавать динамические запросы приложению. Такая схема позволяла сохранить существующий стек и одновременно снять с него наиболее неудобную часть сетевой нагрузки, поэтому проект распространялся постепенно через практические рекомендации администраторов.
В 2011 году Сысоев вместе с Максимом Коноваловым и Андреем Алексеевым основал NGINX, Inc., чтобы развивать проект и коммерческие продукты вокруг него. В марте 2019 года F5 объявила о покупке компании с оценкой примерно в $670 млн, а 9 мая сделка была закрыта. В январе 2022 года Сысоев отошёл от работы в NGINX и F5.
Указывать долю nginx одним числом не очень полезно: одни исследования считают все домены, другие только активные сайты или наиболее посещаемые ресурсы, а CDN и прокси могут скрывать сервер приложения. Достаточно сказать, что nginx стал одним из наиболее распространённых веб-серверов и reverse proxy, не превращая меняющиеся данные измерений в постоянное свойство продукта.
Почему появился freenginx
После покупки открытый nginx продолжил развиваться внутри F5, но вопрос о том, кто принимает окончательные решения, никуда не исчез. 14 февраля 2024 года Максим Дунин, много лет участвовавший в разработке nginx, объявил о создании freenginx. Он объяснил решение вмешательством руководства F5 в сложившуюся политику безопасности и тем, что больше не мог отвечать за изменения в проекте.
freenginx не заменил nginx и не завершил его историю: это отдельная ветвь с собственным управлением и выпусками. Сам факт форка показывает другое следствие зрелости инфраструктурного проекта. Когда код становится частью множества систем, техническая архитектура остаётся важной, но рядом с ней появляется архитектура управления, от которой зависят правила разработки, исправления безопасности и доверие сообщества.
Что умеет nginx Builder
nginx Builder помогает собрать конфигурацию без необходимости помнить расположение каждой директивы. Он предлагает четыре отправные точки: Reverse Proxy, API Gateway, Static SPA и High Traffic, после чего позволяет выбрать отдельный site config или полный nginx.conf и вручную изменить результат.
Настройки распределены по шести вкладкам: General, Upstreams, Routes, Security, Performance и Advanced. В них можно описать несколько upstream-серверов и стратегию балансировки, добавить proxy, static и fixed-response маршруты, настроить TLS, редиректы, заголовки безопасности, CORS, Gzip или Brotli, proxy cache и ограничение запросов по IP. Расширенный раздел управляет worker-процессами, соединениями, логами, DNS resolver и пользовательскими директивами.
Конструктор учитывает контекст директив: upstream, map, proxy_cache_path и limit_req_zone выводятся на HTTP-уровне, а маршруты остаются внутри server и location. Опции, которым нужен внешний модуль или дополнительная проверка окружения, попадают в Notes. Готовый конфиг можно скопировать или скачать, однако перед перезагрузкой nginx его всё равно нужно проверить командой nginx -t на целевом сервере.
Для быстрого старта выберите подходящий preset, укажите домен и адрес приложения, затем добавьте маршруты и нужные параметры безопасности. После просмотра Notes сохраните конфигурацию, перенесите её на сервер и только после успешного nginx -t выполняйте reload.
Похожие инструменты
Частые вопросы
Кто создал nginx?
Игорь Сысоев начал разрабатывать nginx в 2002 году, когда работал в Rambler. Первую общедоступную версию он выпустил 4 октября 2004 года под разрешительной BSD-подобной лицензией. Название nginx произносится как engine x.
Что такое проблема C10K?
C10K означает задачу обслуживания 10 000 одновременных клиентских соединений одним сервером. Речь идёт именно о множестве открытых соединений, значительная часть которых может ждать данные, а не о 10 000 сложных запросов, одновременно потребляющих процессорное время.
Почему nginx сравнивали с Apache?
Историческое сравнение относилось прежде всего к распространённой в эпоху Apache 1.3 модели prefork: заранее созданные дочерние процессы обслуживали по одному соединению за раз. nginx позволял одному worker-процессу следить за множеством соединений через неблокирующий цикл событий. Современный Apache поддерживает worker и event MPM, поэтому утверждение, что любой Apache всегда использует отдельный процесс на соединение, неверно.
Когда выбирать nginx, а когда Apache?
nginx часто используют для раздачи статики, reverse proxy, балансировки и ограничения трафика. Apache может быть удобнее там, где нужны .htaccess, определённые модули или совместимость со старым приложением. Выбор зависит от конфигурации и нагрузки, поэтому универсально более быстрого сервера нет.
Что такое freenginx?
freenginx представляет собой независимый форк nginx, который Максим Дунин запустил 14 февраля 2024 года после разногласий с F5 по поводу управления открытым проектом и его политики безопасности. nginx и freenginx с тех пор развиваются как отдельные проекты.
Автор
Alex RelFullstack Engineer
В коммерческой разработке с 2011 года — больше 15 лет. Автор двух SaaS-продуктов: TeleGo.io и LingvoHabit.com. Статьи здесь выросли из реальной клиентской и продуктовой работы.
