как узнать на чем работает сайт apache или nginx
Узнать WEB сервер одного сайта
Зарегистрирован: 14.11.2015
Пользователь #: 159,013
Сообщения: 108
Windows guru
Windows guru » title=» Windows guru » border=»0″ />
Зарегистрирован: 08.09.2015
Пользователь #: 158,190
Сообщения: 1846
Зарегистрирован: 28.01.2012
Пользователь #: 136,928
Сообщения: 1194
Зарегистрирован: 28.01.2012
Пользователь #: 136,928
Сообщения: 1194
Зарегистрирован: 28.01.2012
Пользователь #: 136,928
Сообщения: 1194
Nginx, Apache, Cloudflare — статистика и обзор популярных веб-серверов
Разрабатывая сайт, рано или поздно придется столкнуться с необходимостью выбора веб-сервера. На какие параметры при этом опираться? Самый простой вариант — выбрать один из популярнейших в рунете (и мировой сети) серверов. Их и рассмотрим.
Статистика веб-серверов
На конец 2019 года рейтинг самых популярных веб-серверов в рунете возглавлял Nginx («Энджинкс»). Он шел впереди с огромным отрывом, держа в своих руках более 66% сайтов. После него шел Cloudflare, а тройку лидеров замыкал Apache. В 2020 году тенденция не изменилась.
Отмечу интересную деталь — в мире Nginx тоже оказался самым востребованным веб-сервером, поддерживающим более 479 миллионов сайтов. Но по доле активных сайтов его обгоняет Apache. Поэтому в статистике использования веб-серверов Apache находится на первом месте, а Nginx — на втором.
В десятке самых популярных серверов также оказались:
Рейтинг популярности составлялся на базе данных Яндекс.Радара. Некоторые сайты поддерживались более чем одним сервером. В этом случае в результаты статистики попадал тот веб-сервер, который ответил первым, так что статистика не учитывала резервные варианты.
В мире ситуация несколько иная. На 2020 год в глобальной сети наибольшей популярностью пользуются серверы:
Читайте также
Обзор популярных веб-серверов
Как говорит статистика, в рунете наибольшим спросом пользуются три сервера: Nginx, Cloudflare и Apache. Поэтому если вы путаетесь в обилии веб-серверов, ограничьте свой выбор этими тремя — не ошибетесь.
Nginx
Nginx — это веб-сервер с открытым исходным кодом. Если вам нужно что-то в нем подправить, вы всегда можете бесплатно скачать исходный код и подогнать его под себя. Но в большинстве случаев это не требуется — у Nginx и без того широкий функционал, способный удовлетворить потребности не только простеньких проектов, но и сложных сайтов с огромной посещаемостью.
Nginx относится к легковесным серверам. При его разработке старались учесть все недостатки более старого Apache, и разработчикам это удалось. Код сервера подразумевает более эффективное масштабирование — с увеличением потока подключений скорость работы почти не падает. Каждый рабочий процесс Nginx способен обрабатывать по тысячам HTTP-подключений сразу. Если предсказуемость нагрузки является для вас приоритетом, смело устанавливайте Nginx.
Широкий арсенал функций позволяет Nginx работать в качестве:
Главный минус Nginx — малая гибкость по сравнению с конкурентами. Этот сервер лучше всего справляется со статическим содержимым, но динамические сайты лучше развернуть на Apache или другом подобном сервере, более приспособленном к таким нагрузкам.
Cloudflare
Несмотря на то, что Cloudflare — это американская компания, в России она пользуется немалой популярностью. Широко разрекламированный веб-сервер предлагает пользователям элементарную установку и настройку, низкий прайс на услуги и особую защиту от DDoS-атак. Возможно, именно это и привлекает веб-разработчиков. В статистике популярных веб-серверов рунета Cloudfare оказался именно по причине своей простоты и разрекламированности.
Разобраться с Cloudflare сможет даже новичок. Установка сервера у большинства пользователей идет без проблем, а если таковые намечаются — всегда можно обратиться в техподдержку, которая работает в чате на сайте. Услугами Cloudflare пользуются не только разработчики-новички, но и крупные современные платформы: Twitch, Reddit, Discord и многие другие.
У Cloudflare есть существенная проблема — географическая удаленность. Поскольку при использовании CDN контент перебрасывается через Америку, время ожидания на сайте возрастает. Большой пинг в России — однозначный минус этого веб-сервера. Если ваша аудитория находится в Западной Европе или США, спокойно забывайте об этом недостатке и ставьте Cloudflare с CDN. Если же вы планируете развернуть русскоязычный сайт, лучше выбрать другой сервер.
Еще один минус Cloudflare относится скорее к этическим. Поскольку эта компания поставляет веб-услуги для огромного количества пользователей (включая крупные корпорации), даже небольшие неполадки в ее работе существенно сказываются на интернет-индустрии в целом. За примером далеко идти не надо — в 2019 году Cloudflare не работала буквально несколько часов, и из-за этого прекратили работу все сервисы, так или иначе использующие ее продукты. Суммарные убытки оказались огромными. Так что Cloudflare можно назвать компанией, которая способствует централизации интернета — а это, по мнению абсолютного большинства пользователей и разработчиков, нехорошая тенденция.
Apache
Веб-сервер Apache стоял у истоков развития мирового интернета — хотя бы поэтому на него стоит обратить внимание! А еще он лидирует в мировом рейтинге популярности. За свою долгую жизнь (а «Апач» ведет свою историю с 1995 года) свободный веб-сервер оброс массой модулей, научился разворачиваться на всевозможных платформах (легко встанет и на Windows, и на Unix) и прочно засел на первом месте по использованию. До 2005 года Apache широко использовался как единый сервер для всех задач — он выполнял роли и веб-сервера, и прокси, и резервного, и был балансировщиком нагрузки. Впрочем, сейчас его позиции пошатнулись — по мере увеличения трафика, количества подключений и объемов данных на страницах Apache перестал справляться с такой многозадачностью.
Но это не значит, что Apache уже вышел из игры. Главное его преимущество — огромное количество подключаемых модулей. Здесь можно найти библиотеки для любых задач, поэтому «Апач» с большой вероятностью идеально подойдет для разработки необычного сайта. Кроме того, ненужные модули всегда можно отключить, чтобы повысить быстродействие.
Архитектура Apache — это ядро и модули. Теоретически, ядро может работать и без модулей, но в этом случае его функциональность будет весьма ограничена, так что такие эксперименты подходят лишь для ознакомления с архитектурой сервера. Стандартная установка Apache предполагает подключение пакета модулей безопасности, управления динамическим контентом и базовой обработки HTTP-запросов.
Как узнать какой сервер на хостинге Apache или Nginx
Существует несколько простых способов выяснить, какой веб-сервер установлен на вашем хостинге. В их основе лежит просмотр заголовков HTTP-запроса посредством различных сервисов или вручную. Чаще всего поиски данной информации заканчиваются тем, что пользователь сталкивается с такими вариантами ответа: Nginx или Apache – одни из самых популярных и хорошо зарекомендовавших себя проектов, предоставляющих в совокупности до 50% веб-трафика, который гонится на сайт.
Следовательно, в этом материале мы разберем упомянутые веб-сервера. Данное руководство будет полезно всем пользователям, которые сталкиваются с этим вопросом впервые.
Важно! Радикальных различий между Nginx и Apache не существует, но все-таки приходится говорить об отличительной обработке соединений.
Вернемся к тому, как узнать тип веб-сервера на хостинге, и какие сервисы станут наилучшими помощниками для этих целей.
Определяем руками, просмотр HTTP заголовков
В этом варианте будем использовать сам браузер и инструменты разработчика CTRL+ SHIFT +I.
В качестве браузере, рассмотрим на примере Google Chrome.
Шаг 1. В браузере Google Chrome открываем сайт, у которого требуется узнать веб-сервер.
Шаг 3. Заходим на вкладку network (сеть), затем перезагружаем сайт.
В столбце «Name» находим название сайта, в моем случае это vseprolinux.ru.
Кликаем левой кнопкой мыши.
В появившемся окне справа в headers ищем слово «server».
Это и есть веб-сервер, который используется на сайте.
Bertal
Предлагаем вашему вниманию еще один надежный сервис, посредством которого можно посмотреть HTTP-заголовки веб-файлов различных форматов. Чтобы воспользоваться инструментов, пользователю необходимо перейти по ссылке. Если размер интернет-страницы Несколько интересных фактов о популярных веб-серверах
Заключение
У пользователя может возникнуть срочная необходимость выявить тип веб-сервера на своём хостинге. В этой статье мы рассказали, как получить нужную информацию самостоятельно, без обращения в саппорт. Просто используйте для этих целей один из упомянутых способов.
Nginx, Php-Fpm и что это вообще?
FPM
SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:
Во вторую очередь, FPM действительно умный менеджер процессов. Он контролирует количество работающих PHP-процессов, частоту их перезапуска для борьбы с утечками памяти (да, модули php как и всегда текут) и прочие простые вещи, необходимые для контроля сервера.
Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.
Количество процессов определяет, сколько одновременно может «висеть» запросов в обработке.
NGINX
Благодаря этой архитектуре nginx на порядки быстрее обрабатывает запросы, чем любой другой сервер и благодаря ей же потребляет при этом сильно меньше ресурсов. Как это происходит?
В эту схему отлично вписалась асинхронная работа со статическими файлами. Благодаря тому, что в современном мире с файлами можно работать почти так же асинхронно, как и с backend, Nginx отлично разделяет работу на две части: статику отдает с диска, динамику обрабатывает в PHP-FPM.
В чем выигрыш?
У вас на странице 100 картинок+js+css-ок? Значит, большая их часть будет висеть в очереди внутри сервера Apache и ждать, когда пользователь получит предыдущие 35 ответов.
В случае с Nginx + PHP-FPM важнее всего количество процессов PHP-FPM. Мы можем поставить его таким же равным тридцати пяти. Что это значит? Это значит, что мы можем одновременно обрабатывать 35 запросов к динамике, запросы же к статике nginx разгребет своими силами в количестве 3000+ одновременных почти на любой слабой VPS.
Расход оперативной памяти при использовании Nginx+PHP-FPM меньше, чем на «голом» Apache, при равном количестве процессов (FPM и Apache). Скорость обработки запросов выше.
На расход CPU внутри PHP замена Apache на FPM никак не скажется. CPU в первую очередь кушает Ваш PHP-код, а пока его никто не оптимизирует, работать быстрее и экономичнее он не начнет.
Итог
Все проблемы PHP (процесс на запрос, не оптимальный код самого проекта) никуда не деваются.
Появляется возможность перелопачивать тонны запросов за статикой, которой нет в Apache.
Вы экономите оперативную память, что сказывается на цене оборудования или VPS.
Появляется море приятного функционала самого Nginx.
Пропадает возможность использовать htaccess, но честно скажу, конфигурация nginx куда более простая и понятная, чем htaccess.
Установка PHP и модулей на Ubuntu/Debian
В Debian/Ubuntu это делается легко и просто, зачастую не требуется ничего собирать
Капризы WebSocket и при чём здесь костыли
Протокол WebSocket имеет свои преимущества и свои недостатки: детальный разбор
Curl в PHP
Почему timeout для curl в php необходим
IoT Highload: особенности и подводные камни
Особенности серверных приложений, работающих с сетью IoT-устройств на практике и в теории
Установка PHP и модулей на Ubuntu/Debian
В Debian/Ubuntu это делается легко и просто, зачастую не требуется ничего собирать
Капризы WebSocket и при чём здесь костыли
Протокол WebSocket имеет свои преимущества и свои недостатки: детальный разбор
Curl в PHP
Почему timeout для curl в php необходим
IoT Highload: особенности и подводные камни
Особенности серверных приложений, работающих с сетью IoT-устройств на практике и в теории
О безопасности, рисках и вложениях
Как сделать так, чтобы Ваш IT-отдел не стал местом утечки информации, за которую Вы отвечаете?
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настраиваем веб-сервер. Nginx как front-end к Apache
Начнем с теории
В формировании современного динамического контента принимают участие три основных службы: веб-сервер, сервер приложений и сервер СУБД. Если у вас проблемы с БД или не хватает производительности PHP, то никакая замена Apachе на Nginx вам не поможет. Но для чего тогда все продолжают ставить Nginx перед Apache? Давайте разбираться.
Начнем с Apache, с его сильных сторон. Это прежде всего отличная производительность сервера приложений (чаще всего PHP), который является модулем веб-сервера и работает в общем с ним адресном пространстве, снижая потери на взаимодействие между процессами. Затем следует простота настройки и администрирования. Пользователь может сам настраивать веб-сервер для своего сайта через инструкции htaccess, причем в случае какой-либо серьезной ошибки перестанет работать только его сайт или его часть, не затрагивая остальные, которые обслуживаются данным сервером.
Рассмотрим следующую схему:
В верхней ее части показан Apache, работающий в качестве самостоятельного сервера. Давайте посмотрим, что происходит, когда пользователь запрашивает веб-страницу. Прежде всего генерируется динамическое содержимое: запускается экземпляр Apache, его модуль mod_php собирает страницу и отдает пользователю. Но это только начало, каждая страница содержит ссылки на статическое содержимое: скрипты, стили, изображения и т.д. и т.п.
А теперь вспомним немного об особенностях протокола HTTP/1.1: для каждого получаемого от веб-сервера ресурса создается отдельное HTTP-соединение, т.е. запускается отдельный процесс веб-сервера. Это серьезно упрощенная модель, но вполне достаточная для понимания происходящих процессов. Проще говоря, для того, чтобы отдать пользователю картинку мы вынуждены каждый раз запускать достаточно ресурсоемкий Apache со всеми его модулями, которые в данный момент не нужны.
В реальности процесс обработки запросов Apache гораздо более сложен, но смысл от этого не меняется: для того чтобы отдать статическое содержимое мы запускаем весьма ресурсоемкий процесс, большинство возможностей которого при этом избыточно.
К чему это приводит? К тому что при некотором количестве активных клиентов у веб-сервера закончатся ресурсы, и он начнет тормозить или вообще перестанет отвечать на запросы. Это актуально для недорогих VPS c ограниченными ресурсами, особенно когда бюджет проекта не позволяет перейти на более дорогой тариф.
Nginx разрабатывался позже Apache, и его разработчик имел возможность учесть все проблемы связанные с эффективностью обработки запросов, что в итоге стало одной из сильных сторон данного веб-сервера. Действительно Nginx в пределах одного рабочего процесса может обрабатывать большое количество запросов, включая запросы от медленных клиентов, причем делать это предельно эффективно, с небольшим расходом ресурсов.
Однако Nginx не поддерживает динамическую генерацию контента и несовместим с директивами htaccess, поэтому в тех случаях, когда от Apache отказываться нежелательно, Nginx устанавливают перед Apache в качестве front-end.
Нижняя часть схемы как раз отражает такую ситуацию. Apache по-прежнему генерирует динамический контент, остаются рабочими директивы htaccess, но теперь его клиентом выступает не браузер, а Nginx, причем очень быстрым клиентом, это позволяет оперативно забрать у Apache результат его работы и освободить занимаемые им ресурсы. Браузер посетителя получает созданное Apachе содержимое уже у Nginx, как и всю статику.
Если ваш сервер до этого уже работал на пределе своих возможностей, то установив Nginx перед Apache вы скорее всего увидите увеличение производительности. Если же ресурсов хватало, то «на глаз» ничего не изменится, но производительность вашего сервера вырастет, что позволит отсрочить, иногда существенно, переход на более дорогой тариф и более производительный сервер.
Перейдем к практике
Здесь и далее мы будем подразумевать, что веб-сервер настроен по нашей статье Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server, в иных случаях, возможно, вам потребуется уточнить некоторые детали.
Начнем с Apache, откройте /etc/apache2/ports.conf и измените порты на которых принимает соединения веб-сервер, для этого
Теперь перейдите в /etc/apache2/sites-available и в настройках каждого виртуального хоста приведите директиву VirtualHost к виду:
Причем это нужно сделать и для отключенных сайтов, чтобы потом, подключив данный хост не получить неработающий сервер, так как Apache откажется перезагружаться из-за конфликта портов.
Проверяем правильность конфигурации командой:
Если ошибок нет, то переходим к следующему этапу, на котором мы установим и настроим Nginx.
Nginx можно установить из двух источников: репозиториев дистрибутива и репозиториев разработчиков, мы рекомендуем последний вариант, так вы получите последнюю версию веб-сервера с поддержкой всех современных технологий, в то время как версии из репозиториев дистрибутива могут существенно отставать.
Подключим репозитории разработчиков, для этого создадим в папке /etc/apt/sources.list.d файл nginx.list:
и внесем в него следующие записи.
Затем скачаем и установим PGP-ключ для проверки подлинности пакетов:
Затем обновим список пакетов и установим Nginx:
В процессе установки получим вполне закономерную ошибку: Nginx не сможет запуститься, так как 80-й порт продолжает занимать работающий Apache.
Конфигурацию Nginx в файле /etc/nginx/nginx.conf приведем к следующему виду:
Мы не будем подробно комментировать все перечисленные опции, так как подробно останавливались на них в статье: Настраиваем веб-сервер на базе Nginx + PHP-FPM в Debian / Ubuntu Server. Отметим лишь новую секцию upstream apache24.
Директива upstream позволяет описывать сервер (группу серверов), которым Nginx может передавать свои запросы, такая конструкция удобна прежде всего тем, что в конфигурациях виртуальных хостов не фигурирует адрес и порт вышестоящего сервера, в нашем случае Apache, а только его символьное имя. В опции server, как вы уже догадались, указываем адрес и порт, на котором работает Apache.
На первый взгляд конфиг Nginx может показаться излишне сложным, но на самом деле это не так и если вы настраиваете данный сервер в первый раз, то мы советуем вам пройти по ссылке выше и ознакомиться с той частью статьи, которая описывает настройки Nginx.
Чтобы не писать из конфигурации в конфигурацию хостов одно и то-же создадим шаблон apache24.conf в котором укажем все основные опции подключения к вышестоящему серверу и работы со статическим содержимым. Создадим файл:
И внесем в него параметры соединения с вышестоящим сервером:
Опция proxy_pass перенаправляет все запросы вышестоящему серверу, proxy_set_header нужным образом изменяют HTTP-заголовки страниц, последние три опции задают тайм-ауты соединения.
Ниже добавим секцию для работы со статическим содержимым:
Первая строка содержит список расширений, которые Nginx будет отдавать самостоятельно, список примерный и вы можете откорректировать его под свои потребности. Опция access_log off выключает логи доступа к статике, служит для уменьшения размера файлов лога, однако если ваш сайт находится в стадии разработки, то данная опция будет лишней, так как сделает отладку невозможной. Время кэширования на стороне браузера задается опцией expires, единого мнения на счет его значения нет, в любом случае стоит делать его достаточно большим, но без фанатизма.
Следующая секция задает правила работы со скриптами и стилями:
Ее содержимое аналогично предыдущей, кроме времени кэширования, оно установлено в 180 мин (3 часа), как разумный компромисс между снижением нагрузки на сервер и возможным изменением их содержимого.
Наконец запретим доступ к ht-файлам, в которых содержатся конфигурационные директивы Apache:
Если вы используете phpMyAdmin, то создайте еще один шаблон:
Внесите в него следующее содержимое:
Теперь, когда шаблоны готовы, можно перейти к описанию виртуальных хостов, для этого в папке /etc/nginx/sites-available создадим для каждого сайта свой конфигурационный файл, для примера мы используем домен example.com:
Внутри разместите следующий текст:
И в самом конце подключим шаблоны для работы с вышестоящим Apache и phpMyAdmin.
Обратите внимание, что приведенная настройка хоста будет обслуживать запросы как с www, так и без, если вы хотите использовать вариант только без www или наоборот, например, в целях SEO, то оставьте в директиве server_name только один хост:
А в конфигурационный файл сайта добавьте еще одну секцию server:
Данная конструкция осуществит редирект всех запросов с www, на страницы без www.
Сохраним и подключим файл конфигурации:
Проверим его правильность командой:
И, если все хорошо, перезапустим оба веб-сервера:
Как видим, мы установили Nginx в качестве front-end к Apache на работающем сервере без простоя последнего, спокойно все настроив и проверив правильность настройки. Остается последний вопрос: как проверить, что статическое содержимое отдает действительно Nginx?
Очень просто, если ваш движок принудительно не перехватывает страницы ошибок, то просто запросите несуществующий статический контент, скажем, изображение.
Как видим, установить Nginx перед Apache достаточно просто, несмотря на большой объем данной статьи. А имея некоторый опыт и готовые шаблоны данная операция вообще занимает несколько минут, в тоже время позволяя существенно повысить нагрузочную способность вашего сервера и в полной мере воспользоваться преимуществами каждого из веб-серверов.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 