Nginx или apache как проверить

Как проверить, является ли apache бэкэндом для nginx?

Есть сервер на Ubuntu 14.04.3, и к нему есть доступ по SSH. На сервере установлен nginx/1.4.6 и Apache/2.4.7 Но вот в чем вопрос. Работают ли в паре Nginx+Apache? То есть, является ли nginx «фронтэндом», а apache «бэкэндом»? Есть ли какая нибудь ssh-команда, которая бы показала это?

Отслеживать
68k 218 218 золотых знаков 79 79 серебряных знаков 221 221 бронзовый знак
задан 6 окт 2015 в 15:42
151 2 2 серебряных знака 12 12 бронзовых знаков
А вы уверены, что именно apache бэкенд для nginx, а не наоборот?
6 окт 2015 в 16:32
@Foxtrot, посмотри глазами в конфигах nginx (/etc/nginx/nginx.conf и дальше в инклюды)
6 окт 2015 в 16:43

@norbornen, я слишком долго смотрел в вопрос и не так его понял. Естественно, nginx не может быть бэкендом. По крайней мере мне об этом ничего не известно.

6 окт 2015 в 16:52
@norbornen, бэкендом для nginx много что может быть.
6 окт 2015 в 17:03

@ВикторРэд, Естественно, nginx не может быть бэкендом — запросто, ведь nginx — полноценный http-сервер. при желании можно использовать даже связку apache+nginx «наоборот» — чтобы apache проксировал запросы к nginx-у. только так вряд ли кто-то делает.

6 окт 2015 в 18:38

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

можно воспользоваться такой командой:

$ sudo lsof -Pn -iTCP -sTCP:LISTEN -c nginx -c apache -c httpd -a

и проанализировать её вывод. пример (реальный сервер, часть строк опущена для наглядности):

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME apache2 2206 root 3u IPv4 58834967 0t0 TCP 127.0.0.1:8080 (LISTEN) apache2 13377 www-data 3u IPv4 58834967 0t0 TCP 127.0.0.1:8080 (LISTEN) nginx 13289 root 6u IPv4 58829785 0t0 TCP *:80 (LISTEN) nginx 13289 root 7u IPv4 58829786 0t0 TCP *:443 (LISTEN) nginx 13624 www-data 6u IPv4 58829785 0t0 TCP *:80 (LISTEN) nginx 13627 www-data 7u IPv4 58829786 0t0 TCP *:443 (LISTEN)

из него видно, что nginx слушает 80-й и 443-й порты на всех адресах ( *:80 и *:443 ), а apache — лишь порт 8080 и только на адресе 127.0.0.1 ( 127.0.0.1:8080 ).

откуда вытекает вполне логичный вывод: nginx слушает внешние обращения и (возможно) передаёт (некоторые из них) apache-у.

«расшифровка» использованных опций программы lsof :

-P — отображать номера портов, а не имена, взятые из файла /etc/services
-n — отображать ip-адреса, не пытаясь преобразовать их в доменные имена
-iTCP -sTCP:LISTEN — отобразить процессы, слушающие tcp-порты
-c nginx -c apache -c httpd — отобразить процессы, начинающиеся с этих строк
-a — логическое and для параметров (правда, не для всех: в данном случае применяется для «связывания» -iTCP и -c имя ). если его опустить, то будут выведены ещё и открытые указанными (с помощью опций -c ) процессами файлы (вообще программа lsof в первую очередь для отображения открытых файлов и писалась).

Как узнать какой сервер на хостинге Apache или Nginx

Существует несколько простых способов выяснить, какой веб-сервер установлен на вашем хостинге. В их основе лежит просмотр заголовков HTTP-запроса посредством различных сервисов или вручную. Чаще всего поиски данной информации заканчиваются тем, что пользователь сталкивается с такими вариантами ответа: Nginx или Apache – одни из самых популярных и хорошо зарекомендовавших себя проектов, предоставляющих в совокупности до 50% веб-трафика, который гонится на сайт. Следовательно, в этом материале мы разберем упомянутые веб-сервера. Данное руководство будет полезно всем пользователям, которые сталкиваются с этим вопросом впервые.

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

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

Определяем руками, просмотр HTTP заголовков

В этом варианте будем использовать сам браузер и инструменты разработчика CTRL+ SHIFT +I. В качестве браузере, рассмотрим на примере Google Chrome. Шаг 1. В браузере Google Chrome открываем сайт, у которого требуется узнать веб-сервер. Веб-сайт Шаг 2. Открываем инструменты разработчика. Меню (три тоски) —> Дополнительные инструменты —> Инструменты разработчика. Меню разработчика Шаг 3. Заходим на вкладку network (сеть), затем перезагружаем сайт. Network Шаг 4. В столбце «Name» находим название сайта, в моем случае это vseprolinux.ru. Кликаем левой кнопкой мыши. В появившемся окне справа в headers ищем слово «server». Это и есть веб-сервер, который используется на сайте. Headers

Bertal

http
https
ftp

bertal

Чтобы произвести успешную проверку http-заголовка, пользователю потребуется заполнить поля формы на странице сайта. Если пользователь предпочтет заполнить одно поле (URL сайта), то он получит лишь основную информацию о своём хостинге. Для получения развернутой информации все же рекомендуется заполнять все имеющиеся поля на странице сайта.

Примечательно, что запрос информации происходит несколькими способами:

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

Несколько интересных фактов о популярных веб-серверах

Разработка проекта стартовала в 1995 году. Сервер улучшали вплоть до 1999-го года. И уже через год после этого продукт начал широко применяться в сети Интернет.
Имеет множество модулей, гибкий.

Разработка сервера стартовала в 2002 году. Готовый продукт был представлен широкой публике в 2004 году.
Обладает высокой чувствительностью при мощных нагрузках.

Заключение

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

Linux получить список пользователей
Как создать tar архив Linux
..
Ограничение подключения ssh по IP

Веб-серверы Apache и Nginx

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

Взаимодействие клиента и сервера

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

Упрощенное представление процесса обработки соединения на примере браузера и веб-сервера для получения HTML-страницы. Веб-сервер запускает PHP процесс для динамической генерации страницы с захватом информации из базы данных

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

Веб-серверы

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

Apache

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

Балансировка нагрузки — разделение трафика между серверами внутренней сети, чтобы распределить задачи и обеспечить отказоустойчивость системы. Примерами таких модулей в Apache являются mod_status и mod_proxy_balancer; ;
Кэширование информации — хранение ответов заданное время, чтобы при повторном обращении сократить количество запросов на бэкенд. Примером такого модуля в Apache является pagespeed , он используется для сжатия и кэширования данных;
Поддержка разных протоколов и видов запросов: не только HTTP, но также протокол передачи файлов FTP (модуль mod_ftp), протоколы электронной почты и другие;
Поддержка разных операционных систем и языков программирования.

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

Nginx

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

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

Асинхронная архитектура Nginx делает нагрузку более предсказуемой с точки зрения использования ресурсов и задержек, и в результате сам сервер легко масштабируется на самом простом «железе». По всем тестам производительности Nginx либо сопоставим, либо работает быстрее и потребляет меньше памяти, чем Apache. Nginx также чаще выбирают для сайтов с поддержкой современных веб-технологий: HTTP/2 и IPv6.

Apache vs Nginx

Главное различие между двумя веб-серверами состоит в механике обслуживания множества соединений. Apache реализует несколько решений с помощью трёх Multi-Processing модулей (MPM). Разработчик сам решает, какой модуль использовать в зависимости от задачи:

mpm_prefork запускает под каждый запрос один процесс, а в нем единственный поток обработки, так что в один момент времени процесс обслуживает только одно соединение;
mpm_worker запускает в каждом процессе несколько потоков обработки данных. Переключение между потоками требует меньше программных ресурсов и, чем между процессами. Освободившийся поток сразу берётся за новое соединение;
mpm_event работает аналогично mpm_worker , но оптимизирован под keep-alive соединения. В рамках такого типа соединений отправляется множество пар запрос-ответ без открытия новых соединений. Модуль выделяет разные потоки под разные типы соединений, так что сервер не увязает в обработке keep-alive.

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

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

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

Apache + Nginx

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

Пример стандартной архитектуры сервера с веб-приложением: клиент взаимодействует с прокси-сервером (Nginx) и тот может выдавать статические файлы (например, изображения или pdf-файлы), а для динамического контента опрашивать указанные в настройках веб-серверы на базе Apache

Пара альтернатив

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

IIS — веб-сервер, разработанный Microsoft для своих операционных систем. По умолчанию он выключен в Windows, но его можно активировать специально. IIS используется для проектов на базе Windows Server и веб-приложений с использованием технологии ASP.NET.
LiteSpeed является современной альтернативой Apache и совместим с его файлами настроек, но дает более высокую производительность, задействует меньше ресурсов и умеет эффективно кэшировать данные. Сервер является проприетарным, но у него есть и open-source версия под названием OpenLiteSpeed.

Как попробовать работу с веб-сервером

Самый простой способ попробовать работу с веб-сервером — панель ispmanager. В панели можно установить любой из популярных веб-серверов с открытым исходным кодом: Apache, Nginx или OpenLiteSpeed. Далее запустить на их базе приложение и проверить результат работы в реальном времени.

Нас читает уже более 35 000 человек

Подпишитесь и получите скидку 10% на ispmanager!

Выбирайте интересное вам: новости ispmanager, подборка статей для начинающих веб-специалистов, всё для матёрых разработчиков или предложите свой вариант рассылки

Благодарим за интерес к рассылке от ispmanager!

На ваш почтовый адрес: отправлено письмо с просьбой подтвердить свой email.

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

*Если вы не получили письмо, пожалуйста, проверьте правильно ли был указан почтовый адрес и попробуйте заполнить форму еще раз.

Apache и nginx

Nginx – это дополнительный высокопроизводительный веб-сервер, который обычно используется как обратный прокси и позволяет улучшить работу основного веб-сервера (Apache), отвечающего за хостинг клиентских сайтов. Этот веб-сервер был разработан специально для передачи больших объемов статического контента (изображений, видео, css, xml и так далее). Nginx намного эффективнее справляется с большим количеством одновременных подключений, чем Apache. А также потребляет гораздо меньше памяти в расчете на одно подключение.

Для наиболее оптимального использования nginx Plesk настраивает его как обратный прокси-сервер между Интернетом и Apache (см. схему ниже). Это означает, что nginx работает как внешний веб-сервер, который принимает все входящие запросы от посетителей сайтов. Эти запросы отправляются Apache, который в свою очередь разделяет их в зависимости от того, какой тип контента запрашивается – статический или динамический. Если запрашивается статический файл (jpg, css, html и т.д.), Apache пропускает запрос через все имеющиеся обработчики (применяет конфигурацию .htaccess , перезаписывает URL и т.д.) и возвращает nginx ответ, содержащий только расположение запрошенного файла в файловой системе. Nginx находит этот файл и отправляет его клиенту. Если запрашивается динамический файл (например, скрипт PHP), Apache исполняет этот файл и отправляет ответ nginx, который доставляет его клиенту.

Такая комбинация из nginx и Apache обеспечивает следующие преимущества:

Увеличивается максимальное количество одновременных подключений к одному сайту.
Сокращается потребление процессорного времени и памяти на сервере. Этот эффект будет наиболее ощутим для сайтов с большим объемом статического контента (фотогалереи, видеохостинги и так далее).
Оптимизируется обслуживание посетителей с низкой скоростью соединения (GPRS, EDGE, 3G и т.д.). Например, допустим, что клиент со скоростью подключения 10 KБ/с запрашивает некий сценарий PHP, который генерирует ответ размером 100 KБ. Если на сервере не установлен nginx, то этот ответ доставляется веб-сервером Apache. В течение всех 10 секунд, необходимых для доставки ответа, Apache и PHP продолжают потреблять полный объем системных ресурсов для поддержания этого открытого подключения. Если же nginx установлен, Apache перенаправляет этот ответ ему (соединение между nginx и Apache очень быстрое, так как оба находятся на одном сервере) и высвобождает системные ресурсы. Благодаря тому, что nginx потребляет меньше памяти, общая нагрузка на систему сокращается. Если у вас много таких медленных подключений, использование nginx позволит вам значительно повысить производительность сайтов.

Технические подробности того, как Plesk обрабатывает HTTP-запросы с помощью nginx, приведены далее в этом разделе. Информацию о том, как включить поддержку nginx в Plesk, смотрите в разделе Установка nginx . Если вы не хотите использовать веб-сервер nginx, вы можете отключить его, как описано в разделе Отключение nginx . Если вы хотите, чтобы nginx обслуживал все HTTP-запросы к веб-контенту, смотрите Изменение настроек веб-сервера Apache.

Как обрабатываются HTTP-запросы в Plesk с nginx

Чтобы обеспечить интеграцию между nginx и Apache, Plesk использует два дополнительных модуля Apache:

mod_aclr2. Этот модуль устанавливает обработчик, который запускается после обработчиков всех остальных модулей Apache (mod_rewrite; модулей, связанных с .htaccess ; mod_php и т.д.). Таким образом, в случае запроса динамического контента модуль mod_aclr2 никогда его не получит, так как этот запрос будет выполнен вышестоящими обработчиками соответствующих модулей Apache (mod_php, mod_perl, mod_cgi и т.д.). Единственным исключением являются запросы SSI: как только они доходят до модуля mod_aclr2, он перенаправляет их соответствующим обработчикам. Если запрашивается статический файл, mod_aclr2 находит точное расположение файла в файловой системе и сообщает его nginx.
mod_rpaf или mod_remoteip С точки зрения Apache все клиенты имеют один и тот же IP-адрес – адрес сервера nginx (см. схему выше). Это создает проблемы для сайтов и веб-приложений, использующих IP-адреса клиентов для идентификации, сбора статистики и так далее. Модуль mod_rpaf (в Apache 2.2) или mod_remoteip (в Apache 2.4) решает эту проблему, заменяя IP-адрес сервера nginx на IP-адреса клиентов во всех запросах. Если подробнее, то этот модуль использует специальный заголовок X-Forwarded-For, в который nginx помещает IP-адрес клиента.

Давайте более подробно рассмотрим, как Plesk обрабатывает запросы статического и динамического контента с помощью этих модулей.

Обработка HTTP-запроса статического файла происходит следующим образом (см. схему):

Клиент отправляет запрос веб-серверу.
Nginx добавляет в этот запрос заголовки X-Accel-Internal (используется модулем mod_aclr2) и X-Forwarded-For (содержит IP-адрес клиента) и отправляет его Apache.
Apache получает запрос и пропускает его через зарегистрированные обработчики (применяет конфигурацию .htaccess , перезаписывает URL и т.д.). На этом этапе модуль mod_rpaf заменяет IP-адрес сервера nginx в переменной Apache REMOTE_ADDR на адрес клиента из заголовка X-Forwarded-For.
После прохождения через все зарегистрированные обработчики запрос попадает в модуль mod_aclr2. Обработчик проверяет наличие заголовка X-Accel-Internal. Если он есть, модуль отправляет серверу nginx ответ с заголовком X-Accel-Redirect и пустым содержимым. Этот заголовок содержит точное расположение файла, определенное модулем mod_aclr2.
Получив ответ, сервер nginx находит соответствующий файл и передает его клиенту.

На расположенной ниже схеме приведен пример обработки запроса файла GIF размером 2 КБ.

В случае с динамическим контентом шаги с первого по третий будут такими же. Затем запрос передается обработчику соответствующего модуля Apache (mod_php, mod_perl, mod_cgi и т.д.). Запрос никогда не доходит до модуля mod_aclr2 (за исключением запросов SSI). Обработчик формирует ответ и отправляет его nginx, который в свою очередь доставляет его клиенту. На следующей схеме приведен пример обработки запроса файла PHP.

Установка nginx

В случае установки Plesk с нуля сервер nginx включен по умолчанию. В случае обновления с более ранней версии вы всегда можете добавить компонент nginx на странице Инструменты и настройки > Обновления > Установить/удалить компоненты. После установки компонента запустите службу Обратный прокси-сервер (nginx) на странице Инструменты и настройки > Управление службами.

Номер установленной у вас версии nginx можно посмотреть на странице Инструменты и настройки > Серверные компоненты.

Выключение nginx

Чтобы вернуться к конфигурации с одним веб-сервером (Apache), остановите службу Обратный прокси-сервер (nginx) на странице Инструменты и настройки > Управление службами.

Чтобы снова включить nginx, запустите службу Обратный прокси-сервер (nginx).

Примечание: Запуская и останавливая службу Обратный прокси-сервер (nginx), вы не только включаете и отключаете nginx, но и меняете конфигурацию веб-сервера (при одной внешним веб-сервером является комбинация из nginx и Apache, при другой ― только Apache). Перезапуск работает так же, как со всеми остальными службами: служба nginx просто перезапускается.