Apache против Nginx: практические соображения

HTTP-сервер Apache был создан Робертом МакКулом в 1995 году и разрабатывается под руководством Apache Software Foundation с 1999 года. Поскольку веб-сервер HTTP является первоначальным проектом фонда и на сегодняшний день является их самым популярным программным обеспечением, его часто называют просто «Apache».

Веб-сервер Apache является самым популярным сервером в Интернете с 1996 года. Из-за этой популярности Apache извлекает выгоду из отличной документации и интегрированной поддержки со стороны других программных проектов.

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

В 2002 году Игорь Сысоев начал работу над Nginx в качестве ответа на проблему C10K, которая была проблемой для веб-серверов, чтобы начать обрабатывать десять тысяч одновременных подключений в качестве требования для современной сети. Первоначальный публичный выпуск был выпущен в 2004 году, и для достижения этой цели использовалась асинхронная архитектура, управляемая событиями.

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

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

Apache предоставляет множество модулей мультиобработки (Apache называет эти MPM), которые определяют, как обрабатываются клиентские запросы. По сути, это позволяет администраторам легко менять архитектуру обработки соединений. Это:

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

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

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

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

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

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

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

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

Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Затем результаты могут быть переданы клиенту.

Для администраторов это означает, что связь между Nginx и процессором должна быть настроена по одному из протоколов, которые Nginx знает, как говорить (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить ситуацию, особенно при попытке предвидеть количество разрешенных соединений, так как для каждого вызова процессора будет использоваться дополнительное соединение.

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

В Apache есть возможность разрешить дополнительную настройку для каждого каталога за счет проверки и интерпретации директив в скрытых файлах внутри самих каталогов содержимого. Эти файлы известны как + .htaccess + файлы.

Поскольку эти файлы находятся в самих каталогах содержимого, при обработке запроса Apache проверяет каждый компонент пути к запрашиваемому файлу на наличие файла «+ .htaccess +» и применяет директивы, найденные в нем. Это эффективно позволяет децентрализованную конфигурацию веб-сервера, которая часто используется для реализации перезаписи URL, ограничений доступа, авторизации и аутентификации, даже политики кэширования.

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

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

Nginx не интерпретирует файлы + .htaccess + и не предоставляет никакого механизма для оценки конфигурации для каждого каталога вне основного файла конфигурации. Это может быть менее гибким, чем модель Apache, но у нее есть свои преимущества.

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

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

Имейте в виду, что можно отключить интерпретацию + .htaccess + в Apache, если эти проблемы резонируют с вами.

Apache предоставляет возможность интерпретировать запрос как физический ресурс в файловой системе или как местоположение URI, которое может нуждаться в более абстрактной оценке. В целом, для первого Apache использует блоки + <Directory> + или + <Files> +, в то время как он использует блоки + <Location> + для более абстрактных ресурсов.

Поскольку Apache изначально разрабатывался как веб-сервер, по умолчанию обычно интерпретируют запросы как ресурсы файловой системы. Он начинается с получения корня документа и добавления части запроса после номера хоста и порта, чтобы попытаться найти фактический файл. По сути, иерархия файловой системы представлена ​​в сети как доступное дерево документов.

Apache предоставляет несколько альтернатив, когда запрос не соответствует базовой файловой системе. Например, директива + Alias ​​+ может использоваться для сопоставления с альтернативным местоположением. Использование блоков + <Location> + - это метод работы с самим URI вместо файловой системы. Существуют также варианты регулярных выражений, которые можно использовать для более гибкого применения конфигурации в файловой системе.

Хотя Apache имеет возможность работать как с базовой файловой системой, так и с веб-пространством, он сильно склоняется к методам файловой системы. Это можно увидеть в некоторых проектных решениях, включая использование файлов «+ .htaccess +» для конфигурации каждого каталога. Сами Apache docs предостерегают от использования блоков на основе URI для ограничения доступа, когда запрос отражает базовую файловую систему.

Nginx был создан как веб-сервер и прокси-сервер. Из-за архитектуры, требуемой для этих двух ролей, он работает в основном с URI, переводя в файловую систему при необходимости.

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

Например, первичными блоками конфигурации для Nginx являются блоки + server + и + location +. Блок + server + интерпретирует запрашиваемый хост, в то время как блоки + location + отвечают за совпадение частей URI, следующих за хостом и портом. На этом этапе запрос интерпретируется как URI, а не как местоположение в файловой системе.

Для статических файлов все запросы в конечном итоге должны быть сопоставлены с расположением в файловой системе. Сначала Nginx выбирает сервер и блоки местоположения, которые будут обрабатывать запрос, а затем объединяет корень документа с URI, адаптируя все необходимое в соответствии с указанной конфигурацией.

Это может показаться схожим, но синтаксический анализ запросов в основном в виде URI, а не местоположений файловой системы, позволяет Nginx более легко функционировать как в роли веб-узла, почты, так и в роли прокси-сервера. Nginx настраивается просто путем описания того, как реагировать на различные шаблоны запросов. Nginx не проверяет файловую систему, пока не будет готов обработать запрос, что объясняет, почему он не реализует форму файлов + .htaccess +.

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

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

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

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

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

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

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

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

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

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

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

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

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