Мир веб-серверов: Apache против Nginx

Введение в Apache и Nginx

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

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

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

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

Общий обзор

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

Apache

Apache появился в 1995 году. Роберт Маккул разработал этот HTTP-сервер в рамках the Apache Software Foundation, отсюда и название. С момента его выпуска сотни тысяч людей по всему миру используют Apache.

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

Nginx

Nginx — это относительно новый веб-сервер, выпущенный в 2004 году. Он стал результатом усилий Игоря Сысоева по решению проблемы, известной сегодня как проблема C10K. Эта проблема возникла, когда серверам стало трудно справляться с большим объемами трафика. По мере того как все больше и больше людей начинали пользоваться Интернетом, серверы веб-сайтов начали перегружаться. Неспособность этих серверов обрабатывать несколько тысяч одновременных подключений приводила к сбоям в работе сайтов.

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

Возможности обработки трафика

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

Apache

Apache использует так называемые MPM — мультипроцессорные модули (Multi-Processing Modules). Администраторы используют различные MPM для манипулирования и изменения архитектуры обработки соединений. Частью привлекательности веб-сервера Apache является гибкость, которую предлагает его архитектура. Такая модульная инфраструктура, разделяющая обработку на отдельные потоки и группы потоков, облегчает масштабирование и адаптацию к различным типам соединений.

Давайте взглянем на некоторые из отдельных модулей, используемых в Apache:

• mpm_prefork

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

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

• mpm_worker

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

• mpm_event

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

Nginx

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

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

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

Обработка статического и динамического контента

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

Apache

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

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

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

Nginx

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

Поскольку информация должна передаваться между двумя компонентами, вам нужно будет координировать связь между ними. Вам придется определить, сколько соединений вы хотите разрешить, и настроить протокол. Вам придется использовать протокол, который может быть прочитан и понят Nginx, например, HTTP, FastCGI, SCGI, uWSGI или memcache, среди прочих.

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

Каталоги контента: распределенная и централизованная конфигурация

У каждого веб-сервера есть свой каталог контента. Один из наиболее важных параметров для оценки Apache и Nginx — позволяют ли они выполнять настройку на уровне каталогов.

Apache

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

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

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

При желании вы можете отключить интерпретацию .htaccess в Apache.

Nginx

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

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

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

Еще один способ отличить эти два сервера — то, как они интерпретируют запросы.

Apache

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

При интерпретации в качестве физического ресурса используются блоки <Directory> или <Files>. Это метод интерпретации по умолчанию для сервера. Он берет корень документа. Затем он следует за хостом и номером порта в запросе, чтобы найти соответствующий файл в дереве документов.

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

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

Nginx

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

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

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

Системы модулей

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

Apache

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

Фактически, вы даже можете изменить работу ядра сервера, используя такие модули, как mod_php. Как мы уже упоминали ранее, этот модуль позволяет встроить интерпретатор PHP в отдельные рабочие процессы. Это полезно, когда вам нужно обрабатывать динамический контент.

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

Nginx

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

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

Экосистема и поддержка

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

Apache

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

Nginx

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

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

Совместное решение?

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

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

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

Вот несколько ресурсов, которые вы можете найти в нашем блоге, которые помогут вам начать работу с обоими веб-серверами:

Apache

• Установка сервера Apache на Ubuntu 18.04: пошаговое руководство
• Настройка виртуальных хостов Apache на Ubuntu 20.04
• Как установить стек Linux, Apache, MySQL, PHP (LAMP) на CentOS 7
• Защита Apache с помощью Let’s Encrypt на Ubuntu 18.04

Nginx

• Установка Nginx на Ubuntu 18.04
• Автоматизация продления SSL-сертификатов LetsEncrypt для Nginx
• Как защитить Nginx с помощью Let’s Encrypt на Ubuntu 20.04
• Как установить стек LEMP (Linux, Nginx, MySQL PHP) на Ubuntu 20.04

Заключение

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

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

Приятной работы!