Nginx

Архитектура, концепция C10k и механизм Event-Driven

Разработка Nginx началась в 2002 году российским инженером Игорем Сысоевым в период работы над инфраструктурой портала Rambler. Главным вызовом того времени была так называемая «проблема C10k» — неспособность существовавших веб-серверов обслуживать более 10 000 одновременных клиентских соединений на одном физическом сервере.

• Крах потоковой модели Apache: традиционный веб-сервер Apache выделял отдельный системный процесс или поток (Thread-per-Connection) под каждого подключённого пользователя. При наплыве десятков тысяч клиентов оперативная память мгновенно исчерпывалась, а процессор тратил все ресурсы на переключение контекста (Context Switching).
• Событийно-ориентированная модель (Event-Driven): Nginx построен по архитектуре «мастер — рабочие процессы» (Master-Worker). Главный процесс управляет конфигурацией, а небольшой пул неблокирующих воркеров (Worker Processes, обычно по одному на каждое ядро CPU через worker_cpu_affinity) обслуживает весь поток входящих соединений.
• Системный мультиплексинг (epoll и kqueue): рабочий процесс непрерывно опрашивает ядро операционной системы через эффективные механизмы мультиплексирования ввода-вывода (epoll в Linux, kqueue во FreeBSD). Соединение потребляет память только в момент фактической передачи данных, требуя всего около 2,5 МБ оперативной памяти на 10 000 неактивных HTTP-сессий (Keep-Alive).
• Прямая отдача статики (Zero-Copy): благодаря системному вызову sendfile() передача графики, стилей и скриптов с диска клиенту происходит напрямую через сетевой сокет на уровне ядра, минуя буфер в пространстве пользователя.
• Сетевые протоколы HTTP/2 и HTTP/3 (QUIC): нативная поддержка мультиплексирования потоков в HTTP/2 и протокола нового поколения HTTP/3 на базе UDP устраняет задержки рукопожатий и блокировку заголовка очереди (Head-of-Line Blocking) в нестабильных мобильных сетях.

Обратный прокси (Reverse Proxy) и буферизация

Nginx исключительно эффективен в роли промежуточного шлюза (Reverse Proxy), принимающего трафик из внешней сети и перенаправляющего его на внутренние серверы приложений (PHP-FPM, Node.js, Python, Go):

• Защита бэкенда через proxy_buffering: Nginx моментально вычитывает ответ от медленного интерпретатора PHP и сам порционно отдаёт его клиенту с медленным интернет-каналом, немедленно освобождая ценные PHP-воркеры для следующих пользователей.
• Балансировка нагрузки: гибкая директива upstream поддерживает интеллектуальные алгоритмы распределения запросов (Round Robin, Least Connections, IP Hash) с автоматическим отключением сбойных серверов.
• Кэширование на уровне сервера: встроенный механизм fastcgi_cache позволяет сохранять готовые HTML-страницы и отдавать их за доли миллисекунды без запуска движка CMS.