Apache или Nginx — или Apache и Nginx?

Два самых популярных в мире веб-сервера, Apache и Nginx — оба разработаны как OpenSource-продукты и распространяются вполне свободно. Связка из этих двух программ закрывает практически любые потребности хостинга и способна обслуживать большинство веб-проектов.

Веб-сервер Apache — старожил отрасли, первые версии его увидели свет в далеком 1995 году. За это время он стал самым популярным продуктом “все-в-одном” для веб-хостинга самого широкого круга, и оброс впечатляющей документацией и руководствами “how-to-make”.
Nginx родился в 2004 году усилиями одного разработчика — Игоря Сысоева, который задался целью создать веб-сервер, обрабатывающий до 10 тыс. одновременных подключений. В общих чертах, изюминка Nginx — асинхронная архитектура, которая собственно и служит для обработки такого количества запросов. Легковесность, масштабируемость и переносимость позволяют использовать Nginx на “железе” практически любых конфигураций.
Родная среда Nginx-а — статические страницы, в скоростной выдаче которых ему нет равных, ну а запросы к динамическим сайтам он успешно передает Apache, работая как кэширующий прокси.

Функционально, различие Nginx и Apache заключается в различных схемах обработки соединений для разных видов трафика. В Apache за параллельную обработку запросов клиентов отвечают модули мультипроцессинга (multi-processing modules или MPM).
Самый простой из этих модулей — mpm_prefork. Он работает по схеме “один запрос — один системный процесс с одним потоком”. Очевидный недостаток такого метода — как только запросов становится больше, чем процессов с mpm_prefork, производительность веб-сервера резко падает. По этой причине, mpm_prefork плохо подходит для хостинга со слабым аппаратным обеспечением.
Модуль mpm_worker работает по примерно какой же схеме с той разницей, что каждое соединение обрабатывает один поток, а не процесс — а значит и производительность намного выше.
В модуле mpm_event дополнительно добавлена работа с keep-alive соединениями, оптимизирующая загрузку потоков.

Nginx изначально задумывался как система с высокой степенью параллелизма, ее асинхронный код не создает блокировок, а соединения обрабатываются по схеме событий.
Процессы Nginx способны обрабатывать до 1 тыс. соединений одновременно — и это происходит моментально, при появлении нового события.

Обработка динамического содержимого в Apache выполняется через инкапсуляцию интерпретатора (например, php) в отдельные процессы веб-сервера. Nginx не имеет встроенных средств для динамики, и поэтому использует внешние интерпретаторы и библиотеки, либо транслирует запросы динамическому веб-серверу.

Настройка Apache для различных хостов выполняется через главный конфигурационный файл, а также для через файлы  .htaccess для каждого из виртуальных каталогов. При этом настройки “перечитываются” при каждом обращении к соотв. каталогу, без необходимости перегружать сам веб-сервер.
Nginx в большинстве случаев не позволяет пользователям менять свои настройки, что ограничивает гибкость конфигурирования, но дает выигрыш в безопасности и скорости работы.

Оба веб-сервера могут расширять свой функционал через дополнительные модули, однако схемы их подключения существенно различаются. Модули Apache загружаются и выгружаются динамически, разрешение на запуск определенных модулей может быть выдано для конкретных хостов (веб-сайтов).
Модули Nginx компилируется в монолитный код для каждой из сборок веб-сервера. Большинство функциональных пакетов включается в стандартную сборку, однако для специфических задач может понадобиться перекомпиляция программы.

Подводя итог — Apache и Nginx не конкурируют, но эффективно дружат. Безусловно, есть ряд специализированных решений, где Nginx работает с динамическим контентом через сторонние библиотеки и модули для PHP, однако это не дает всей гибкости и мощи связки Nginx+Apache.

Узнать все детали и нюансы конфигурирования связки Apache+Nginx и уверенно закрепить знания на практике наши читатели смогут на авторском курсе «Linux. Средний уровень«.

Желаем всем быстрого хостинга и удачных проектов!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *