Apache против Nginx: практические соображения
Введение
Apache и Nginx — два самых распространенных в мире веб-сервера с открытым исходным кодом. Вместе они отвечают за обслуживание более 50% трафика в Интернете. Оба решения способны справляться с разнообразными рабочими нагрузками и работать с другим программным обеспечением, обеспечивая полный веб-стек.
Хотя Apache и Nginx имеют много общего, их не следует считать полностью взаимозаменяемыми. Каждый превосходен по-своему, и в этой статье будут рассмотрены сильные и слабые стороны каждого из них.
Общий обзор
Прежде чем мы углубимся в различия между Apache и Nginx, давайте кратко рассмотрим предысторию этих двух проектов и их общие характеристики.
Апачи
HTTP-сервер Apache был создан Робертом МакКулом в 1995 г. и с 1999 г. разрабатывается под руководством Apache Software Foundation. именуется просто «Апач».
Веб-сервер Apache был самым популярным сервером в Интернете по крайней мере с 1996 по 2016 год. Из-за этой популярности Apache пользуется отличной документацией и интегрированной поддержкой других программных проектов.
Apache часто выбирают администраторы за его гибкость, мощность и почти универсальную поддержку. Он расширяется за счет динамически загружаемой модульной системы и может напрямую обслуживать многие языки сценариев, такие как PHP, без необходимости в дополнительном программном обеспечении.
Nginx
В 2002 году Игорь Сысоев начал работу над Nginx как ответом на проблему C10K, которая представляла собой серьезную проблему для веб-серверов, способных обрабатывать десять тысяч одновременных подключений. Nginx был публично выпущен в 2004 году и достиг этой цели, полагаясь на асинхронную архитектуру, управляемую событиями.
С тех пор Nginx превзошел Apache по популярности из-за своего легкого размера и способности легко масштабироваться на минимальном оборудовании. Nginx отлично справляется с быстрой обработкой статического контента, имеет собственную надежную модульную систему и может при необходимости передавать динамические запросы другому программному обеспечению.
Администраторы часто выбирают Nginx за эффективность использования ресурсов и быстродействие под нагрузкой, а также за простой синтаксис конфигурации.
Архитектура обработки соединений
Одним из различий между Apache и Nginx является особый способ обработки соединений и сетевого трафика. Это, пожалуй, самая существенная разница в том, как они реагируют на нагрузку.
Апачи
Apache предоставляет множество многопроцессорных модулей (Apache называет их MPM), которые определяют, как обрабатываются клиентские запросы. Это позволяет администраторам настраивать архитектуру обработки соединений. Это:
- mpm_prefork: этот модуль обработки порождает процессы с одним потоком, каждый из которых обрабатывает запросы. Каждый дочерний элемент может одновременно обрабатывать одно соединение. Пока количество запросов меньше количества процессов, этот MPM работает очень быстро. Однако производительность быстро снижается после того, как запросы превышают количество процессов, поэтому во многих сценариях это не лучший выбор. Каждый процесс оказывает значительное влияние на потребление оперативной памяти, поэтому этот MPM сложно эффективно масштабировать. Тем не менее, это может быть хорошим выбором, если используется в сочетании с другими компонентами, которые не созданы с учетом потоков. Например, PHP не всегда потокобезопасен, поэтому этот MPM рекомендуется как безопасный способ работы с
mod_php, модулем Apache для обработки этих файлов. - mpm_worker: этот модуль порождает процессы, каждый из которых может управлять несколькими потоками. Каждый из этих потоков может обрабатывать одно соединение. Потоки гораздо более эффективны, чем процессы, а это означает, что этот MPM лучше масштабируется, чем MPM prefork. Поскольку потоков больше, чем процессов, это также означает, что новые соединения могут сразу занять свободный поток вместо того, чтобы ждать освобождения процесса.
- mpm_event: этот модуль в большинстве случаев похож на рабочий модуль, но оптимизирован для обработки соединений проверки активности. При использовании рабочего MPM соединение будет удерживать поток независимо от того, выполняется ли запрос активно, до тех пор, пока соединение остается активным. Событие MPM обрабатывает поддерживающие соединения, выделяя выделенные потоки для обработки поддерживающих соединений и передавая активные запросы другим потокам. Это не позволяет модулю увязнуть в запросах поддержки активности, обеспечивая более быстрое выполнение.
Apache предоставляет гибкую архитектуру для выбора различных алгоритмов подключения и обработки запросов. Предоставленные варианты в основном зависят от эволюции сервера и растущей потребности в параллелизме по мере изменения интернет-ландшафта.
Nginx
Nginx появился на сцене после Apache, с большей осведомленностью о проблемах параллелизма, с которыми сталкиваются сайты при масштабировании. В результате Nginx был разработан с нуля для использования асинхронного, неблокирующего алгоритма обработки соединений, управляемого событиями.
Nginx порождает рабочие процессы, каждый из которых может обрабатывать тысячи подключений. Рабочие процессы достигают этого за счет реализации механизма быстрого цикла, который постоянно проверяет и обрабатывает события. Отделение фактической работы от соединений позволяет каждому работнику заниматься соединением только тогда, когда инициировано новое событие.
Каждое из соединений, обрабатываемых рабочим потоком, помещается в цикл обработки событий. В цикле события обрабатываются асинхронно, что позволяет выполнять работу неблокирующим образом. Когда соединение закрывается, оно удаляется из цикла.
Этот стиль обработки соединений позволяет Nginx масштабироваться с ограниченными ресурсами. Поскольку сервер является однопоточным, а процессы не создаются для обработки каждого нового подключения, использование памяти и ЦП имеет тенденцию оставаться относительно стабильным даже во время большой нагрузки.
Статический и динамический контент
С точки зрения реальных вариантов использования, одним из наиболее распространенных сравнений между Apache и Nginx является способ, которым каждый сервер обрабатывает запросы на статический и динамический контент.
Апачи
Серверы Apache могут обрабатывать статический контент, используя обычные файловые методы. Выполнение этих операций в основном зависит от методов MPM, описанных выше.
Apache также может обрабатывать динамический контент, встраивая процессор соответствующего языка в каждый из своих рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры можно активировать с помощью динамически загружаемых модулей.
Способность Apache обрабатывать динамический контент внутри компании напрямую способствовала популярности архитектур LAMP (Linux-Apache-MySQL-PHP), поскольку PHP-код может выполняться нативным образом самим веб-сервером.
Nginx
Nginx не имеет возможности обрабатывать динамический контент. Чтобы обрабатывать PHP и другие запросы динамического контента, Nginx должен передать запрос внешней библиотеке для выполнения и дождаться возврата вывода. Затем результаты могут быть переданы клиенту.
Этими запросами должен обмениваться Nginx и внешняя библиотека, используя один из протоколов, которые Nginx умеет говорить (http, FastCGI, SCGI, uWSGI, memcache). На практике PHP-FPM, реализация FastCGI, обычно является вспомогательным решением, но на практике Nginx не так тесно связан с каким-либо конкретным языком.
Однако у этого метода есть и некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его накладные расходы будут присутствовать только для динамического содержимого. Статический контент можно обслуживать прямолинейно, и с переводчиком можно будет связаться только при необходимости.
Распределенная и централизованная конфигурация
Apache и Nginx значительно различаются в своем подходе к разрешению переопределений для каждого каталога.
Апачи
Apache включает возможность разрешить дополнительную настройку для каждого каталога путем проверки и интерпретации директив в скрытых файлах в самих каталогах содержимого. Эти файлы известны как файлы .htaccess.
Поскольку эти файлы находятся в самих каталогах контента, при обработке запроса Apache проверяет каждый компонент пути к запрошенному файлу на наличие файла .htaccess и применяет найденные в нем директивы. Это эффективно обеспечивает децентрализованную настройку веб-сервера, который часто используется для реализации перезаписи URL-адресов, ограничения доступа, авторизации и аутентификации и даже политик кэширования.
Хотя все приведенные выше примеры можно настроить в основном файле конфигурации Apache, файлы .htaccess имеют ряд важных преимуществ. Во-первых, поскольку они интерпретируются каждый раз, когда они обнаруживаются на пути запроса, они реализуются немедленно, без перезагрузки сервера. Во-вторых, это позволяет непривилегированным пользователям управлять определенными аспектами их собственного веб-контента, не предоставляя им контроль над всем файлом конфигурации.
Это обеспечивает простой способ для определенного веб-программного обеспечения, такого как системы управления контентом, настраивать свою среду без предоставления доступа к центральному файлу конфигурации. Это также используется провайдерами виртуального хостинга, чтобы сохранить контроль над основной конфигурацией, предоставляя клиентам контроль над своими конкретными каталогами.
Nginx
Nginx не интерпретирует файлы .htaccess и не предоставляет никакого механизма для оценки конфигурации каждого каталога вне основного файла конфигурации. Первоначально Apache был разработан в то время, когда было выгодно запускать множество разнородных веб-развертываний параллельно на одном сервере, и делегирование разрешений имело смысл. Nginx был разработан в то время, когда отдельные развертывания с большей вероятностью были контейнеризированы и поставлялись с собственными сетевыми конфигурациями, что сводило к минимуму эту потребность. В некоторых случаях она может быть менее гибкой, чем модель Apache, но у нее есть свои преимущества.
Наиболее заметным улучшением по сравнению с системой конфигурации на уровне каталогов .htaccess является повышение производительности. Для типичной установки Apache, которая может разрешить .htaccess в любом каталоге, сервер будет проверять эти файлы в каждом из родительских каталогов, ведущих к запрошенному файлу, для каждого запроса. Если во время этого поиска будет найден один или несколько файлов .htaccess, их необходимо прочитать и интерпретировать. Не допуская переопределения каталогов, Nginx может быстрее обслуживать запросы за счет
Еще одно преимущество связано с безопасностью. Распределение доступа к конфигурации на уровне каталога также распределяет ответственность за безопасность между отдельными пользователями, которым нельзя доверять выполнение этой задачи должным образом. Имейте в виду, что интерпретацию .htaccess в Apache можно отключить, если вас это беспокоит.
Файл против интерпретации на основе URI
То, как веб-сервер интерпретирует запросы и сопоставляет их с реальными ресурсами в системе, — это еще одна область, в которой эти два сервера различаются.
Апачи
Apache предоставляет возможность интерпретировать запрос как физический ресурс в файловой системе или как местоположение URI, для которого может потребоваться более абстрактная оценка. В общем, для первого Apache использует блоки
Поскольку Apache изначально разрабатывался как веб-сервер, по умолчанию запросы обычно интерпретируются как ресурсы файловой системы. Он начинается с того, что берет корень документа и добавляет часть запроса, следующую за номером хоста и порта, чтобы попытаться найти фактический файл. По сути, иерархия файловой системы представлена в сети как доступное дерево документов.
Apache предоставляет ряд альтернатив, когда запрос не соответствует базовой файловой системе. Например, директиву Alias можно использовать для сопоставления с альтернативным местоположением. Использование блоков
Хотя Apache может работать как с базовой файловой системой, так и с другими веб-URI, он в значительной степени опирается на методы файловой системы. Это можно увидеть в некоторых проектных решениях, включая использование файлов .htaccess для конфигурации для каждого каталога. Сами документы Apache предостерегают от использования блоков на основе URI для ограничения доступа, когда запрос отражает базовую файловую систему.
Nginx
Nginx был создан как веб-сервер и прокси-сервер. Из-за архитектуры, необходимой для этих двух ролей, он работает в основном с URI, транслируя их в файловую систему, когда это необходимо.
Это видно по тому, как создаются и интерпретируются файлы конфигурации Nginx. Nginx не предоставляет механизма для указания конфигурации каталога файловой системы, а вместо этого анализирует сам URI.
Например, основными блоками конфигурации для Nginx являются блоки server и location. Блок server интерпретирует запрашиваемый хост, а блоки location отвечают за сопоставление частей URI, которые идут после хоста и порта. На данный момент запрос интерпретируется как URI, а не как местоположение в файловой системе.
Для статических файлов все запросы в конечном итоге должны быть сопоставлены с местоположением в файловой системе. Сначала Nginx выбирает сервер и блоки местоположения, которые будут обрабатывать запрос, а затем объединяет корень документа с URI, адаптируя все необходимое в соответствии с указанной конфигурацией.
Это может показаться похожим, но синтаксический анализ запросов в первую очередь как URI, а не местоположения файловой системы, позволяет Nginx более легко работать как в веб-ролях, так и в роли почтового сервера и прокси-сервера. Nginx настраивается путем определения того, как отвечать на различные шаблоны запросов. Nginx не проверяет файловую систему, пока не будет готов обслужить запрос, что объясняет, почему он не реализует форму файлов .htaccess.
Совместное использование Apache и Nginx
Изучив преимущества и ограничения как Apache, так и Nginx, вы можете лучше понять, какой сервер больше подходит для ваших нужд. В некоторых случаях можно использовать сильные стороны каждого сервера, используя их вместе.
Обычная конфигурация для этого партнерства заключается в размещении Nginx перед Apache в качестве обратного прокси-сервера. Это позволит Nginx обрабатывать все запросы клиентов. Это использует преимущества высокой скорости обработки Nginx и способности одновременно обрабатывать большое количество подключений.
Для статического контента, в котором Nginx преуспевает, файлы или другие директивы будут доставлены клиенту быстро и напрямую. Для динамического контента, например файлов PHP, Nginx передает запрос Apache, который затем может обрабатывать результаты и возвращать обработанную страницу. Затем Nginx может передать содержимое обратно клиенту.
Эта настройка хорошо работает для многих людей, поскольку позволяет Nginx функционировать как сортировочная машина. Он будет обрабатывать все запросы, которые он может, и передавать те, которые он не может обслуживать. Сократив количество запросов, которые серверу Apache предлагается обработать, мы можем облегчить некоторые блокировки, возникающие, когда процесс или поток Apache занят.
Эта конфигурация также облегчает горизонтальное масштабирование за счет добавления дополнительных внутренних серверов по мере необходимости. Nginx можно настроить для передачи запросов на несколько серверов, что повышает производительность этой конфигурации.
Заключение
И Apache, и Nginx мощные, гибкие и функциональные. Решение о том, какой сервер лучше для вас, в значительной степени зависит от оценки ваших конкретных требований и тестирования шаблонов, которые вы ожидаете увидеть.
Между этими проектами есть различия, которые очень сильно влияют на исходную производительность, возможности и время реализации, необходимое для использования любого решения в производственной среде. Используйте решение, которое лучше всего соответствует вашим целям.