NGINX против Apache: Сравнение самых популярных веб-серверов с открытым исходным кодом

Первая версия HTTP-сервера Apache появилась в 1995 году. Сегодня, более 20 лет спустя, это программное обеспечение продолжает оставаться королем веб-серверов — но не без конкуренции. В частности, российский веб-сервер NGINX (произносится как «Engine-X»), также являющийся проектом с открытым исходным кодом, завоевывает рынок — причем с бешеной скоростью. Что наиболее вредно для Apache Foundation: Большинство сайтов, которые сегодня занимают высокие позиции в рейтинге Alexa, уже работают на NGINX. Вы можете посмотреть регулярно обновляемую статистику использования веб-серверов на сайте W3Techs.

Не только российские интернет-гиганты, такие как поисковые системы Ramblex и Yandex, почтовый сервис Mail.RU или социальная сеть VK, полагаются на легкий веб-сервер; международные провайдеры, такие как Dropbox, Netflix, WordPress и FastMail.com, также используют NGINX для повышения производительности своих сервисов. Скоро ли устареет HTTP-сервер Apache?

Примечание

HTTP-сервер Apache — это программный проект, работающий под спонсорством Apache Foundation. В экономических терминах интернет-сообщества название веб-сервера обычно сокращается до просто «Apache». Мы также будем следовать этому соглашению: В следующем руководстве «Apache» будет использоваться для обозначения программного обеспечения, а не его производителя.

Вызов Web 2.0

Оуэн Гарретт, руководитель отдела продуктов Nginx, Inc., в своем блоге от 9 октября 2015 года называет веб-сервер Apache «основой» Веб 1.0 и подчеркивает его значение для развития интернета на рубеже тысячелетий. Большой успех веб-сервера в первую очередь объясняется простой архитектурой программного обеспечения. Однако это основано на дизайнерских решениях, соответствующих Всемирной паутине, которые нельзя сравнивать с сегодняшними решениями. Двадцать лет назад веб-сайты были значительно более простыми, пропускная способность была ограниченной и дорогой, а вычислительное время процессора было сравнительно дешевым.

Сегодня мы имеем дело со Всемирной паутиной второго поколения, которая показана под совершенно другим углом: Количество пользователей и веб-трафик во всем мире увеличились в несколько раз. То же самое касается среднего размера веб-сайтов в Интернете и количества компонентов, которые веб-браузер должен запросить и отобразить, чтобы иметь возможность их представить. Все большая часть интернет-сообщества с детства знакома с возможностями Веб 2.0. Эта группа пользователей не знакома с ожиданием загрузки веб-сайта в течение нескольких секунд или даже минут.

В последние годы эти события неоднократно бросали вызов HTTP-серверу Apache. Оуэн Гарретт винит в этом процессно-ориентированную архитектуру Apache, поскольку она не может хорошо масштабироваться с учетом быстро растущего объема трафика. Эта трудность стала одной из основных мотиваций для разработки в 2002 году NGINX, который использует совершенно иной подход с его событийно-управляемой архитектурой. NGINX ведет свою историю от российского разработчика программного обеспечения Игоря Сысоева, который создал программное обеспечение, используемое в качестве веб-сервера, обратного прокси и почтового прокси, специально для нужд российской поисковой системы Rambler.

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

Совет

Вы можете найти полное описание обоих веб-серверов с открытым исходным кодом в нашем сравнении, а также руководства по их установке и настройке в наших базовых статьях по Apache и NGINX.

Архитектурные различия

Веб-серверы Apache и NGINX основаны на принципиально разных программных архитектурах. Различные концепции встречаются в отношении управления соединениями, конфигурации, интерпретации клиентских запросов и обработки статического и динамического веб-контента.

Управление соединениями

Веб-серверы с открытым исходным кодом Apache и NGINX существенно отличаются друг от друга тем, как они обрабатывают входящие запросы клиентов. В то время как Apache работает на основе архитектуры, основанной на процессах, управление соединениями в NGINX происходит по алгоритму обработки, управляемому событиями. Это позволяет эффективно обрабатывать запросы, даже если они поступают одновременно от большого количества соединений. Разработчики NGINX, в частности, называют это большим преимуществом перед HTTP-сервером Apache. А начиная с версии 2.4, он также предлагает возможность реализации событий. Различия, таким образом, заключаются в деталях.

Веб-сервер Apache придерживается подхода, при котором каждый запрос клиента обрабатывается отдельным процессом или потоком. При однопоточности — первоначальном режиме работы HTTP-сервера Apache — это рано или поздно связано с проблемами блокировки ввода-вывода: Процессы, требующие операций чтения или записи, выполняются строго последовательно. Последующий запрос будет оставаться в очереди до тех пор, пока не будет получен ответ на предыдущий. Этого можно избежать путем одновременного запуска нескольких однопоточных процессов — стратегия, связанная с высоким потреблением ресурсов.

В качестве альтернативы используются многопоточные механизмы. В отличие от однопоточности, когда только один поток доступен для ответа на запросы клиентов для каждого процесса, многопоточность дает возможность запускать несколько потоков в одном процессе. Поскольку потоки Linux требуют меньше ресурсов, чем процессы, многопоточность дает возможность компенсировать большие требования к ресурсам процессно-ориентированной архитектуры HTTP-сервера Apache.

Интеграция механизмов параллельной обработки клиентских запросов в Apache может быть выполнена с помощью одного из трех многопроцессорных модулей (MPM):mpm_prefork, mpm_worker, mpm_event.

  • mpm_prefork: Модуль Apache «prefork» предлагает многопроцессное управление на основе однопоточного механизма. Модуль создает родительский процесс с доступным набором дочерних процессов. В каждом дочернем процессе запускается поток, который позволяет отвечать на один клиентский запрос за раз. Пока однопоточных процессов больше, чем входящих клиентских запросов, запросы обрабатываются одновременно. Количество доступных однопоточных процессов определяется с помощью опций конфигурации сервера «MinSpareServers» и «MaxSpareServers». Prefork содержит недостатки однопоточности, о которых говорилось выше. Однако одним из преимуществ является широкая независимость отдельных процессов: Если соединение теряется из-за неисправного процесса, это, как правило, не влияет на соединения, обрабатываемые в других процессах.
  • mpm_worker: С помощью модуля «worker» пользователи Apache получают доступный многопоточный механизм для параллельной обработки клиентских запросов. Сколько потоков может быть запущено в каждом процессе, определяется с помощью параметра конфигурации сервера «ThreadsPerChild». Модуль предоставляет один поток для каждого TCP-соединения. Пока доступных потоков больше, чем входящих клиентских запросов, запросы обрабатываются параллельно. Родительский процесс (httpd) следит за простаивающими потоками.
    Команды «MinSpareThreads» и «MaxSpareThreads» позволяют пользователям определить, при каком количестве простаивающих потоков будут создаваться новые потоки или удаляться из памяти работающие потоки. Модуль worker требует гораздо меньше ресурсов, чем модуль prefork. Но поскольку соединения обрабатываются не в отдельных процессах, неисправный поток может повлиять на все соединения, обрабатываемые в одном многопоточном процессе. Как и prefork, worker также подвержен перегрузке, вызванной так называемыми keep-alive соединениями (см. ниже).
  • mpm_event: С помощью event, начиная с версии 2.4, HTTP-сервер Apache имеет третий многопроцессорный модуль, доступный для продуктивного использования. Он представляет собой вариант модуля worker, который распределяет рабочую нагрузку между запущенными потоками. Для каждого многопоточного процесса используется поток listener, который получает входящие запросы клиентов и распределяет соответствующие задачи между рабочими потоками.
    Модуль событий был разработан для оптимизации контакта с keep-alive соединениями, то есть TCP-соединениями, которые поддерживаются для передачи дальнейших клиентских запросов или ответов сервера. При использовании классического рабочего модуля рабочие потоки обычно поддерживают соединения, которые были установлены один раз, и поэтому становятся заблокированными — даже если не поступает новых запросов. Это может привести к перегрузке сервера большим количеством соединений keep-alive. Модуль событий, с другой стороны, передает поддержание соединений keep-alive независимому потоку слушателя. После этого рабочие потоки больше не блокируются и доступны для обработки дальнейших запросов.

На следующем графике показано схематическое представление архитектуры веб-сервера Apache, основанной на процессах, с использованием рабочего модуля:

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

Огромные затраты ресурсов при подходе «один процесс на соединение» обусловлены тем, что для каждого дополнительного процесса должна быть создана отдельная среда выполнения. Это требует выделения процессорного времени и отдельного хранилища. Каждый модуль Apache, доступный для рабочего процесса, также должен быть загружен отдельно для каждого процесса. Потоки, с другой стороны, разделяют среду выполнения (программу) и адресное пространство в памяти. Поэтому накладные расходы на дополнительные потоки значительно меньше, чем на процессы. Однако многопоточность также требует больших вычислений, если используются контекстные переключатели.

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

Модуль mpm_event имеет механизм событий, доступный для HTTP-сервера Apache, который передает обработку входящего соединения потоку-слушателю. Это позволяет завершать соединения, которые больше не нужны (включая соединения keep-alive), и таким образом снижать потребление ресурсов. Однако это не решает проблему изменения контекста, требующего больших вычислительных затрат, которая возникает, когда поток-слушатель передает запросы отдельным рабочим потокам через свои удерживаемые соединения.

В отличие от этого, архитектура NGINX, основанная на событиях, реализует параллелизм, не требуя дополнительного процесса или угрозы для каждого нового соединения. Один процесс NGINX может одновременно обрабатывать тысячи HTTP-соединений. Это достигается с помощью механизма циклов, называемого циклом событий. Это позволяет асинхронно обрабатывать запросы клиентов внутри угрозы.

Совет

Теоретически NGINX использует только один однопоточный процесс при обработке соединений. Однако для оптимального использования аппаратного обеспечения веб-сервер обычно запускается с одним рабочим процессом на каждое процессорное ядро (CPU) базовой машины.

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

  • Главный процесс: Главный процесс — это родительский процесс, который выполняет все основные операции. К ним относятся, в частности, импорт конфигурации сервера, привязка портов и создание всех следующих типов процессов.
  • Вспомогательные процессы: NGINX использует два вспомогательных процесса для управления кэшем: загрузчик кэша и менеджер кэша.
    • Загрузчик кэша: Загрузчик кэша отвечает за загрузку кэша на основе жесткого диска в память.
    • Менеджер кэша: Задача менеджера кэша — следить за тем, чтобы записи из кэша на жестком диске имели заданный размер, и при необходимости обрезать их. Этот процесс происходит периодически.
  • Рабочий процесс: Рабочие процессы отвечают за обработку соединений, доступ на чтение и запись к жесткому диску и связь с вышестоящими серверами (серверами, предоставляющими услуги другим серверам). Это означает, что это единственные процессы в модели процессов NGINX, которые постоянно активны.

Следующий график представляет собой схематическое изображение модели процессов NGINX:

Все рабочие процессы, запущенные главным процессом NGINX во время настройки, имеют общий набор сокетов слушателей. Вместо того чтобы запускать новый процесс потока для каждого входящего соединения, в каждом рабочем процессе выполняется цикл событий, который позволяет асинхронно обрабатывать тысячи соединений в рамках одного потока без блокировки процесса. Для этого рабочие процессы на сокетах-слушателях постоянно прослушивают события, вызванные входящими соединениями, принимают их и выполняют процессы чтения и записи на сокете во время обработки HTTP-запросов.

NGINX не имеет собственного механизма для распределения соединений между рабочими процессами. Вместо этого используются основные функции операционной системы. Схемы обработки входящих запросов предоставляются отдельными машинами состояний для HTTP, сырого TCP, SMTP, IMAP и POP3.

В целом, NGINX можно описать как обработчик событий, который получает информацию о событиях от ядра и сообщает операционной системе, как обрабатывать связанные с ними задачи. Асинхронная обработка задач с помощью цикла обработки событий основана на четных уведомлениях, обратных вызовах и таймерах. Эти механизмы позволяют рабочему процессу делегировать операционной системе одну операцию за другой, не дожидаясь результата операции или ответа клиентских программ. NGINX выступает в роли оркестратора для операционной системы и берет на себя чтение и запись байтов.

Такой тип управления соединениями создает лишь минимальные накладные расходы на дополнительные соединения. Все, что требуется — это дополнительный дескриптор файла (FD) и минимум дополнительной памяти в рабочем процессе. С другой стороны, контекстные переключения, требующие больших вычислительных затрат, происходят только в случае отсутствия дальнейших событий в цикле событий. Такая эффективность обработки запросов через различные соединения делает NGINX идеальным распределителем нагрузки для высоко посещаемых сайтов, таких как WordPress.com.

Резюме

Благодаря своей событийно-ориентированной архитектуре, NGINX предлагает альтернативу основанному на процессах управлению соединениями HTTP-сервера Apache. Но этого недостаточно, чтобы объяснить, почему NGINX показывает такие высокие результаты в эталонных тестах. Apache, начиная с версии 2.4, также поддерживает механизм обработки клиентских запросов на основе событий. При сравнении веб-серверов, например, Apache vs. NGINX, всегда обращайте внимание на то, какие модули используются в тестах, как они настроены и какие задачи должны быть освоены.

Работа со статическим и динамическим веб-контентом

Когда речь идет о динамическом веб-контенте, NGINX также придерживается иной стратегии, чем HTTP-сервер Apache.

В принципе: чтобы иметь возможность доставлять динамическое содержимое, веб-сервер должен иметь доступ к интерпретатору, способному обрабатывать требуемый язык программирования, такой как PHP, Perl, Python или Ruby. Apache имеет различные модули, включая mod_php, mod_perl, mod_python или mod_ruby, которые позволяют загрузить соответствующий интерпретатор непосредственно в веб-сервер. В результате Apache сам наделяется способностью обрабатывать динамический веб-контент, созданный с помощью соответствующего языка программирования. Функции подготовки статического контента уже реализованы с помощью вышеупомянутого модуля MPM.

NGINX, с другой стороны, предлагает только механизмы для доставки статического веб-контента. Подготовка динамического контента передается на аутсорсинг специализированному серверу приложений. В этом случае NGINX функционирует только как прокси между клиентской программой и сервером. Взаимодействие происходит по таким протоколам, как HTTP, FastCGI, SCGI, uWSGI и Memcached. Возможные серверы приложений для доставки динамического контента предлагаются WebSphere, JBoss или Tomcat. Для этой цели можно также использовать HTTP-сервер Apache.

Обе стратегии доставки статического и динамического контента имеют свои преимущества и недостатки. Такой модуль, как mod_php, позволяет веб-серверу самостоятельно выполнять код PHP. Отдельный сервер приложений не нужен. Это делает администрирование динамического сайта очень простым. Но модули интерпретаторов для динамических языков программирования должны быть загружены отдельно в каждый рабочий процесс, который отвечает за доставку контента. При большом количестве рабочих процессов это связано со значительными накладными расходами. NGINX снижает эти накладные расходы, поскольку сторонний интерпретатор вызывается только при необходимости.

Если NGINX настроен на взаимодействие с внешним интерпретатором, то пользователи Apache могут выбрать любую из этих двух стратегий. Apache также может быть установлен перед сервером приложений, который используется для интерпретации динамического веб-контента. Обычно для этого используется протокол FastCGI. Соответствующий интерфейс может быть загружен с помощью модуля mod_proxy_fcgi.

Резюме

Оба веб-сервера в нашем сравнении обеспечивают доставку динамического контента. Но если Apache сам интерпретирует и выполняет программный код с помощью модулей, то NGINX передает этот шаг внешнему серверу приложений.

Интерпретация клиентских запросов

Чтобы удовлетворительно отвечать на запросы клиентских программ (например, веб-браузеров или программ электронной почты), серверу необходимо определить, какой ресурс запрашивается и где он находится в зависимости от запроса.

HTTP-сервер Apache был разработан как веб-сервер. С другой стороны, NGINX предлагает функции как веб-, так и прокси-сервера. Эта разница в направленности отражается в том, как программное обеспечение интерпретирует запросы клиентов и распределяет ресурсы на сервере.

Примечание

HTTP-сервер Apache также может быть настроен как прокси-сервер с помощью модуля mod_proxy.

HTTP-сервер Apache и NGINX имеют механизмы, которые позволяют интерпретировать входящие запросы либо как физические ресурсы в файловой системе, либо как URI (Uniform Resource Indentifier). Но если Apache по умолчанию работает на основе файлов, то обработка запросов на основе URI более заметна в NGINX.

Если HTTP-сервер Apache получает запрос от клиента, он по умолчанию предполагает, что определенный ресурс должен быть получен из файловой системы сервера. Поскольку Apache использует виртуальные хосты для предоставления различного веб-контента на одном и том же сервере под разными именами хостов, IP-адресами или номерами портов, он должен сначала определить, к какому виртуальному хосту относится запрос. Для этого веб-сервер сопоставляет имя хоста, IP-адрес и номер порта в начале URI запроса с VirtualHosts, определенными в основном конфигурационном файле httpd.conf.

Следующий пример кода показывает конфигурацию Apache, в которой два домена ‘www.example.com’ и ‘www.other-example.com’ работают под одним IP-адресом:

NameVirtualHost *:80

<VirtualHost *:80>
ServerName www.example.com
ServerAlias example.com *.example.com
DocumentRoot /data/www/example
</VirtualHost>

<VirtualHost *:80>
ServerName www.other-example.com
DocumentRoot /data/www/other-example
</VirtualHost>

Звездочка (*) служит для обозначения IP-адреса. Apache решает, в каком DocumentRoot (начальный каталог веб-проекта) будет производиться поиск запрашиваемого ресурса, сравнивая имя хоста, содержащееся в запросе, с директивой ServerName.

Если Apache находит нужный сервер, то URI запроса по умолчанию отображается на файловую систему сервера. Для этого Apache использует спецификацию пути, содержащуюся в URI. В сочетании с DocumentRoot это равнозначно пути к ресурсу.

Для запроса с URI запроса «

www.example.org/public_html/images/logo.gif»

, Apache будет искать нужный ресурс по следующему пути к файлу (на основе приведенного выше примера):

/data/www/example/public_html/images/logo.gif
Примечание

Поскольку стандартным портом для HTTP является 80, эта спецификация обычно не указывается.

Apache также сопоставляет URI запроса с необязательными блоками файлов и каталогов в конфигурации. Это позволяет определить специальные инструкции для запросов, которые ведут к выбранным файлам или каталогам (включая подкаталоги).

В следующем примере специальные инструкции определены для каталога public_html/images и файла private.html:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com *.example.com
    DocumentRoot /data/www/example
      <Directory var/www/example.com/public_html/images>
          Order Allow,Deny
          Allow from all
     </Directory> 
      <Files public.html>
          Order Allow,Deny
          Deny from all
      </Files>
</VirtualHost>

В дополнение к этой стандартной процедуре интерпретации клиентских запросов Apache предлагает директиву alias, которая позволяет указать альтернативный каталог для поиска запрашиваемого ресурса вместо DocumentRoot. С помощью mod_rewrite HTTP-сервер Apache также предоставляет модуль, позволяющий пользователям переписывать или перенаправлять URL-адреса.

Совет

Узнайте больше о серверном модуле mod_rewrite в нашей базовой статье по теме rewrite engine.

Если вы хотите, чтобы Apache извлекал ресурсы, хранящиеся за пределами файловой системы сервера, используйте директиву location. Это позволяет определить инструкции для конкретных URI.

То, что представляет собой исключение для Apache, является стандартным случаем для NGINX. Сначала NGINX анализирует URI запроса и сопоставляет его с блоками server и location в конфигурации веб-сервера. Только после этого (при необходимости) происходит сопоставление с файловой системой и объединение с корнем (сравнимым с DocumentRoot сервера Apache).

Используя директиву server, NGINX определяет, какой хост отвечает за ответ на запрос клиента. Блок server соответствует VirtualHost в конфигурации Apache. Для этого имя хоста, IP-адрес и номер порта URI запроса сопоставляются со всеми серверными блоками, определенными в конфигурации веб-сервера. В следующем примере кода показаны три серверных блока в конфигурационном файле NGINX nginx.conf:

server {
    listen 80;
    server_name example.org www.example.org;
    ...
}

server {
    listen 80;
    server_name example.net www.example.net;
    ...
}

server {
    listen 80;
    server_name example.com www.example.com;
    ...
}
Примечание

Каждый серверный блок обычно содержит ряд блоков расположения. В данном примере они заменены на заполнитель (…).

URI запроса не сопоставляется с блоками расположения внутри серверного блока до тех пор, пока не будет найден запрашиваемый сервер. Для этого NGINX считывает указанные блоки расположения и ищет местоположение, которое наилучшим образом соответствует URI запроса. Каждый блок локации содержит определенные инструкции, которые указывают NGINX, как должен быть обработан соответствующий запрос.

Расположение может быть задано для интерпретации как префикс для пути, как точное соответствие или как регулярное выражение (RegEx). В синтаксисе конфигурации сервера используются следующие модификаторы:

Без модификатора

Местоположение интерпретируется как префикс.

Все запросы, URI которых имеют префикс, определенный в директиве location, считаются совпадающими с location.

Если конкретное местоположение не найдено, запрос обрабатывается в соответствии с информацией в блоке location.

=

Местоположение интерпретируется как точное совпадение.

Все запросы, URI которых точно совпадают со строкой, указанной в директиве location, обрабатываются в соответствии с информацией в блоке location.

 ~

Местоположение интерпретируется как регулярное выражение.

Все запросы, URI которых совпадают с регулярным выражением, обрабатываются в соответствии с информацией в блоке location.

Для поиска соответствия используются буквы верхнего и нижнего регистра (с учетом регистра).

~*

Местоположение интерпретируется как регулярное выражение.

Все запросы, URI которых соответствуют регулярному выражению, обрабатываются в соответствии с информацией в блоке location.

Буквы верхнего и нижнего регистра не оцениваются для соответствия (нечувствительно к регистру).

В следующем примере показаны три блока расположения, которые показывают, как должна обрабатываться информация для доменов ‘example.org’ и ‘www.example.org’:

server {
    listen 80;
    server_name example.org www.example.org;
    root /data/www;

    location / {
        index index.html index.php;
    }

    location ~* .(gif|jpg|png)$ {
        expires 30d;
    }
location ~ .php$ {
        fastcgi_pass localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

На основе запроса клиента с URI запроса ‘http://www.example.org:80/logo.gif’, NGINX будет действовать следующим образом, чтобы интерпретировать запросы и доставить желаемый ресурс:

http://www.example.org:80/logo.gif

http://www.example.org:80/index.php

Сначала NGINX определяет конкретное местоположение префикса. Для этого веб-сервер последовательно считывает все местоположения с модификаторами и останавливается на первом местоположении, соответствующем запросу. Затем считываются все местоположения, отмеченные модификатором RegEx (~). Здесь также используется первое совпадение. Если не найдено ни одного подходящего местоположения RegEx, то веб-сервер использует ранее определенное префиксное местоположение в качестве запасного варианта.

Например, URI запроса ‘http://www.example.org:80/logo.gif’ совпадает как с префиксным расположением /, так и с регулярным выражением .(gif|jpg|png)$. Поэтому NGINX сопоставит запрос в сочетании с корнем с путем к файлу /data/www/logo.gif и доставит соответствующий ресурс клиенту. Заголовок expired указывает, когда ответ считается устаревшим — в данном примере через 30 дней: expires 30d.

Запрос на PHP-страницу с URI ‘http://www.example.org:80/index.php’ также соответствует префиксу location / и RegEx location ~ .php$, который получает преимущественное обращение. NGINX перенаправляет запрос на сервер FastCGI, который прослушивает localhost:9000 и отвечает за обработку динамического веб-контента. Директива fastcgi_param устанавливает параметр FastCGI SCRIPT_FILENAME в /data/www/index.php. Затем этот файл запускается на сервере upstream. Переменная $document_root соответствует директиве root, а переменная $fastcgi_script_name — той части URI, которая следует за именем хоста и номером порта: /index.php.

Такая сложная на первый взгляд процедура интерпретации клиентских запросов обусловлена различными областями применения NGINX. В отличие от преимущественно файлового подхода HTTP-сервера Apache, интерпретация запросов на основе URI позволяет более гибко подходить к обработке различных шаблонов запросов. Это необходимо, например, когда NGINX используется не как веб-сервер, а как прокси-сервер или почтовый прокси-сервер.

Резюме

Apache в основном используется как веб-сервер и интерпретирует клиентские запросы преимущественно файловым методом. NGINX, с другой стороны, по умолчанию работает с URI и поэтому подходит и для других шаблонов запросов.

Конфигурация

Считается, что NGINX обладает огромным преимуществом в скорости по сравнению с HTTP-сервером Apache, когда речь идет о доставке статического веб-контента. Отчасти это объясняется различиями в конфигурации.

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

Обратите внимание, что это также может быть настроено централизованно в файле httpd.conf. Но .htaccess становится актуальным в таких моделях веб-хостинга, как виртуальный хостинг, где доступ к основному конфигурационному файлу зарезервирован за хостинг-провайдером. Децентрализованная конфигурация с помощью .htaccess позволяет разрешить пользователям администрирование определенных областей файловой системы сервера — например, выбранных каталогов проекта — без предоставления доступа к основной конфигурации. Изменения также вступают в силу немедленно, не требуя перезапуска.

NGINX, с другой стороны, предлагает только централизованные возможности конфигурирования. Все инструкции определяются в файле nginx.conf. Имея доступ к этому файлу, пользователь получает контроль над всем сервером. В отличие от apache, административный доступ не ограничен выбранными директориями. Это имеет как преимущества, так и недостатки. Централизованная конфигурация NGINX менее гибкая, чем концепция, используемая HTTP-сервером Apache, но она дает явное преимущество в плане безопасности: Изменения в конфигурацию веб-сервера могут вносить только пользователи с правами root.

Однако более важным, чем аргумент о безопасности, является недостаток производительности при использовании децентрализованной конфигурации через .htaccess. Разработчик уже рекомендовал в документации HTTP-сервера Apache воздерживаться от использования .htaccess, если возможен доступ к httpd.conf. Причина этого заключается в процедуре, которую использует Apache для чтения и интерпретации конфигурационных файлов.

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

Примечание

В принципе, администраторы Apache вольны выбирать, использовать ли децентрализованные возможности конфигурации веб-сервера, и принимать связанные с этим преимущества и недостатки. В документации разработчик подчеркивает, что все конфигурации .htaccess также могут быть выполнены в основной конфигурации httpd.conf с использованием блоков каталогов.

Пользователи, которые хотят отключить или ограничить децентрализованную конфигурацию на Apache, могут использовать директиву AllowOverride в блоках каталогов основного конфигурационного файла httpd.conf и установить для них значение None. Это позволит веб-серверу игнорировать все файлы .htaccess в соответствующих настроенных директориях.

<VirtualHost *:80>
    ServerName example.com;
    ...
    DocumentRoot /data/www/example
      <Directory /data/www/example>
        AllowOverride None
        ...
      </Directory>
    ...
</VirtualHost>

Пример конфигурации указывает веб-серверу, что все файлы .htaccess для хоста example.com должны быть проигнорированы.

Резюме

В отличие от NGINX, который конфигурируется только централизованно, Apache предлагает возможность децентрализованной конфигурации на основе каталогов с помощью .htaccess. Однако при использовании файлов .htaccess веб-сервер теряет в скорости.

Возможности расширения

Оба веб-сервера в нашем сравнении работают по модульной системе, в которой основная система может быть расширена дополнительными компонентами по мере необходимости. Однако до версии 1.9.10 NGINX придерживался принципиально иной стратегии работы с модулями, чем конкурирующий продукт.

HTTP-сервер Apache имеет два варианта расширения основного программного обеспечения. Модули могут либо компилироваться в двоичные файлы Apache во время разработки, либо загружаться динамически во время выполнения.

Существует три категории модулей Apache:

  • Базовые модули: Базовые модули Apache включают все компоненты, обеспечивающие основные функциональные возможности веб-сервера.
  • Модули расширений: Расширения — это модули Apache Foundation, которые входят в состав дистрибутива Apache. Обзор всех модулей, содержащихся в стандартной установке Apache 2.4, доступен в документации Apache.
  • Модули сторонних разработчиков: Эти модули не принадлежат Apache Foundation, а предоставляются внешними поставщиками услуг или независимыми программистами.

NGINX, с другой стороны, долгое время ограничивал модульность статическими компонентами расширения, которые должны были быть скомпилированы в двоичный файл программного ядра. Такой тип программного расширения значительно ограничивал гибкость веб-сервера, особенно для пользователей, которые не привыкли управлять собственными программными компонентами без менеджера пакетов соответствующего дистрибутива. Команда разработчиков внесла значительные улучшения в этом отношении: Начиная с версии 1.9.11 (релиз 09 февраля 2016 года), NGINX поддерживает механизмы, позволяющие преобразовывать статические модули в динамические, чтобы их можно было загружать через конфигурационный файл во время выполнения. В обоих случаях используется API модуля сервера.

Обратите внимание, что не все модули NGINX могут быть преобразованы в динамические. Модули, которые изменяют исходный код программного обеспечения сервера, не должны загружаться динамически. NGINX также по умолчанию ограничивает количество одновременно загружаемых динамических модулей до 128. Чтобы увеличить это ограничение, установите константу NGX_MAX_DYNAMIC_MODULES на желаемое значение в исходном коде NGINX.

В дополнение к официальным модулям документации NGINX, пользователям доступны различные модули сторонних производителей.

  • Модули расширения NGINX
  • Сторонние модули для NGINX
Резюме

Оба веб-сервера могут быть модульно расширены. Доступны как динамические модули, так и статические, которые могут быть загружены в запущенную программу по мере необходимости.

Документация и поддержка

Оба программных проекта хорошо документированы и предоставляют пользователям информацию из первых рук о вики и блогах.

  • HTTP-сервер Apache: Wiki
  • NGINX: Wiki

В то время как документация NGINX доступна только на английском и русском языках, проект Apache имеет информационные материалы на разных языках. Однако некоторые из них устарели, поэтому здесь также необходимо ознакомиться с документацией на английском языке.

Пользователи могут получить помощь в решении проблем для обоих проектов с открытым исходным кодом через сообщество. Для этого списки рассылки функционируют как дискуссионные форумы.

  • HTTP-сервер Apache: Списки рассылки
  • NGINX: списки рассылки

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

  • HTTP-сервер Apache: Отчет об ошибке
  • NGINX: отчет об ошибках

В дополнение к проекту NGINX с открытым исходным кодом компания Nginx, Inc. также предлагает коммерческий продукт NGINX Plus. За ежегодную плату за использование пользователи получают дополнительные функции, а также профессиональную поддержку от производителя. Сравнительную матрицу обеих программ можно найти на сайте NGINX.

Коммерческой версии HTTP-сервера Apache не существует. Однако платные услуги поддержки могут быть получены от различных сторонних компаний.

Резюме

И HTTP-сервер Apache, и NGINX достаточно документированы для профессионального использования в производственных системах.

Совместимость и экосистема

HTTP-сервер Apache доминирует во Всемирной паутине уже более двух десятилетий и, благодаря своей доле рынка, до сих пор считается стандартом де-факто для подготовки веб-контента. NGINX также имеет 15-летнюю историю успеха. Оба веб-сервера характеризуются широкой платформенной поддержкой. В то время как Apache рекомендуется для всех unix-подобных операционных систем, а также для Windows, в документации NGINX приводятся следующие протестированные системы: FreeBSD, Linux, Solaris, IBM AIX, HP-UX, macOS и Windows.

Как стандартный сервер, Apache отличается широкой совместимостью со сторонними проектами. Все соответствующие веб-стандарты могут быть интегрированы с помощью модулей. Большинство игроков в Интернете также знакомы с концепциями Apache. Администраторы и веб-разработчики обычно реализуют свои первые проекты на доступных платформах виртуального хостинга. Они, в свою очередь, в основном основаны на Apache и его возможности децентрализованной конфигурации с помощью .htaccess. HTTP-сервер Apache также входит в состав различных программных пакетов с открытым исходным кодом для разработки и тестирования программного обеспечения, таких как XAMPP или AMPPS.

Большая экосистема модулей также доступна пользователям NGINX. Кроме того, команда разработчиков развивает партнерские отношения с различными проектами программного обеспечения с открытым исходным кодом и проприетарными программами, а также с поставщиками инфраструктурных услуг, такими как Amazon Web Services, Windows Azure и HP.

Резюме

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

NGINX против Apache: обзор различий

Несмотря на значительные различия в архитектуре программного обеспечения, оба веб-сервера предлагают схожие функции. Apache и NGINX используются в сопоставимых сценариях, но используют собственные стратегии и концепции для удовлетворения требований. В следующей таблице приведено сравнение обоих программных проектов на основе их основных характеристик и показаны их сходства и различия.

Характеристика

Apache

NGINX

Функция

Веб-сервер

Прокси-сервер

Веб-сервер

Прокси-сервер

Прокси-сервер электронной почты

Балансировщик нагрузки

Язык программирования

C

C

Операционная система

Все unix-подобные платформы

Windows

FreeBSD

Linux

Solaris

IBM AIX

HP-UX

macOS

Windows

Релиз

1995

2002

Лицензия

Лицензия Apache v2.0

Лицензия BSD (Berkeley Software Distribution)

Разработчик

Apache Software Foundation

Nginx, Inc.

Архитектура программного обеспечения

Процессно/потоковая

Ориентированная на события

Конкуренция

Многопроцессорная

Многопоточность

Событийный цикл

Статический веб-контент

Да

Да

Динамический веб-контент

Да

Нет

Интерпретация клиентских запросов

Преимущественно на основе файлов

На основе URI

Конфигурация

Центральная конфигурация через httpd.conf

Децентрализованная конфигурация через .htaccess

 

Центральная конфигурация через nginx.conf

Возможности расширения

Статические модули

Динамические модули

Статические модули

Динамические модули

Документация

Немецкий

Английский

Датский

Испанский

Французский

Японский

Корейский

Португальский

Турецкий

Китайский

Немецкий

Английский

Поддержка разработчиков

Нет

Да (оплачивается через Nginx, Inc.)

Поддержка сообщества

Списки рассылки

Вики

Списки рассылки

Вики

Резюме

С Apache и NGINX пользователи имеют в своем распоряжении два стабильных, безопасных проекта с открытым исходным кодом. Но после сравнения ни один из веб-серверов не является явным победителем. Оба проекта основаны на принципиально разных проектных решениях, которые могут быть как преимуществом, так и недостатком, в зависимости от того, как используется программное обеспечение.

HTTP-сервер Apache предлагает огромный репертуар модулей, которые, вместе с гибкими возможностями конфигурации, открывают многочисленные области применения этого программного обеспечения. Веб-сервер также может стать стандартным программным обеспечением для сценариев виртуального хостинга и будет продолжать отстаивать свои позиции в своей области против легких веб-серверов, таких как NGINX. Возможность прямой интеграции интерпретаторов языков программирования, таких как PHP, Perl, Python или Ruby, в веб-сервер с помощью модулей позволяет предоставлять динамический веб-контент без использования отдельного сервера приложений. Это делает HTTP-сервер Apache удобным решением для малых и средних веб-сайтов, где контент создается динамически во время получения.

NGINX, с другой стороны, не предлагает никаких возможностей для нативной обработки динамического веб-контента или интеграции соответствующих интерпретаторов через модули. Всегда требуется отдельный сервер приложений. Это может показаться ненужным дополнительным усилием для малых и средних веб-сайтов. Однако для крупных веб-проектов и растущих объемов трафика такая архитектура показывает свою силу.

В целом, NGINX используется в качестве балансировщика нагрузки перед группой серверов приложений. Балансировщик нагрузки принимает входящие запросы и в зависимости от типа запроса решает, нужно ли его перенаправить на специализированный сервер в фоновом режиме. Статический веб-контент доставляется непосредственно NGINX. Если клиент запрашивает динамический контент, то балансировщик нагрузки передает запрос на специализированный сервер приложений. Он интерпретирует язык программирования, собирает запрашиваемый контент в веб-страницу и возвращает ее балансировщику нагрузки, который доставляет ее клиенту. Таким образом, можно эффективно управлять большими объемами трафика.

NGINX кэширует уже доставленный контент в течение определенного времени, так что вновь запрошенный динамический контент может быть доставлен непосредственно балансировщиком нагрузки без повторного обращения NGINX к серверу приложений.

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

Оцените статью
cdelat.ru
Добавить комментарий