Записки bаckend-разработчика
10 отличий Apache от Nginx
Доброго времени суток, backend/frontend/full-stack/devops/qa/.. да какая разница, добро пожаловать, мой друг!
Начнем с архитектурных и функциональных отличий.
1. Метод обработки соединений с клиентами
Nginx состоит из master-процесса и нескольких дочерних процессов. Мастер процесс обычно один — он создает дочерние процессы (воркеры, загрузчик кеша и кеш менеджер), считывает конфигурацию и открывает порты. Воркеров обычно несколько, разработчики nginx советуют количество воркеров определять равным числу ядер машины. Эти дочерние процессы буду обслуживать все соединения с клиентами в неблокирующей манере. В nginx используется бесконечный цикл, который бежит по всем соединениями и отвечает на запросы клиентов. Когда соединение закрывается, оно удаляется из event loop. Это решение идеально подходит для проектов, которые обслуживающих 10к+ соединений одновременно. При этом, загрузка CPU и использование памяти обычно равномерны, без видимых пиков.
2. Отдаваемый контент
Apache — может генерировать как статический контент, так и динамический. С этим никаких проблем нет. Прекрасно подойдет тем, кто не хочет заморачиваться с проксированием и настройкой дополнительного инструмента для генерации динамики, ведь Apache — это готовое работающее решение.
Nginx — отдает только статику и из коробки генерировать динамический контент не умеет. Если вы используете nginx и хотите генерировать динамический контент на своем сайте, то вам придется проксировать запросы тому, кто это делать умеет (apache, php-fpm и др.). Поэтому, разработчикам придется настраивать дополнительную связку, которая усложняет архитектуру, например nginx+apache (кстати в этой связке, Apache называют бекенд сервером, а Nginx — фронтендом), nginx + phpfpm, nginx + python и др.
3. Конфигурирование
Nginx не поддерживает конфигурирование на уровне каталогов. Существует один конфигурационный файл на весь проект, который обрабатывает master. Если вы хотите обновить конфигурацию, то необходимо отправить сигнал SIGHUP мастеру, который в свою очередь перезагружает конфигурацию и плавно завершает работу воркеров.
4. Работа с модулями
Apache за долгое время существования обзавелся около 60 официальными модулями, и еще большим числом неофициальных. Модули динамически подключаются, не требуют сборки и перезагрузки веб-сервера.
Nginx имеет около 130 официальных модулей. В отличие от Apache, модули Nginx не могут быть динамически загружены на лету и требуют сборки. Это гораздо сложнее, но считается безопаснее.
5. Интерпретация запросов
Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки.
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
6. Работа со скриптовыми языками
В Apache есть один модуль mod_php и все хосты вынуждены работать с одной и той же версией php и одним конфигурационным файлом.
В случае с nginx, каждый виртуалхост будет выполняться в отдельном процессе и, соответственно, может использовать разные версии php (python/ruby/perl и др.). Каждый процесс может иметь свою собственную независимую конфигурацию.
Вообще, в высоконагруженных проектах удобнее держать раздельно nginx и php. По отдельности их проще мониторить, ловить баги или узкие места. «Все-в-одном» Apache+mod_php в этом плане менее удобен.
От основных архитектурных и функциональных отличий переходим к показательным отличиям, отличиям инфрастктуры и всего того, что также является не менее важным при выборе веб-сервера.
7. Скорость работы
Скорость работы веб-сервера обычно измеряют для 2-х случаев отдачи контента: для статики и динамики. На основе тестов производительности, Nginx примерно в 2.5 раза быстрее отдает статику, чем Apache. Это довольно-таки большое превосходство. Если вам необходимо обслуживать большое количество статического контента, Nginx — лучший выбор. Во время тестирования отдачи динамического контента, Apache и Nginx показывают примерно одинаковые результаты. С точки зрения памяти, оба сервера используют один и тот же объем ресурсов. (Подробнее о тестах скорости отдачи контента можно почитать здесь)
8. Поддержка ОС
Apache прекрасно работает на Unix-подобных операционных системах, также разработчики этого веб-сервера полностью поддерживают линейку Microsoft Windows, включая последние версии этой ОС.
Nginx также поддерживает работу на множестве Unix-подобных ОС и имеет некоторую поддержку Windows, которая не является полной. Но разве кто-то в наше время размещает веб-сервер на Windows?
9. Сообщество и поддержка
Apache на рынке с 1995 года, что очень немалый срок, обеспечивший инструменту огромное сообщество и поддержку с его стороны. Практически на все вопросы на Stack Overflow уже есть исчерпывающие ответы. Коммерческой поддержки нет.
Nginx веб-сервер более молодой, на рынке он с 2004 года, что также не помешало большому сообществу сформироваться и поддерживать друг друга. Nginx, в отличие от Apache, имеет коммерческую версию Nginx Plus, которая дополнена инструментами балансировки нагрузки, мониторинга, потоковой передачи медиа и др.
10. Документация и обучение
И у Apache и у Nginx присутствует доступная официальная документация.
Nginx предлагает платное обучение, включающее в себя онлайн курсы, практические занятия и экзамен. По окончании курса все участники получают сертификаты. Например, сдать экзамен по основам nginx и получить официальный сертификат обойдется в 49$ (подробнее здесь).
От себя хотелось бы отметить, что оба решения очень стабильны, безопасны и поддерживаемы. Выбирайте то, что подходит именно вам. Пробуйте, экспериментируйте, ошибайтесь и снова пробуйте. Всем добра и будьте здоровы!
Apache против Nginx: плюсы и минусы для WordPress
Другое требование, которое само собой разумеется, производительность должна быть экономичной, поэтому у нас не может быть ресурсоемких решений. Решения должны быть скромными, средними и надежными и полностью максимизировать доход на вашем сайте, расходы на хостинг должны быть сведены к минимуму.
Если вы ожидаете получить большой трафик, конфигурация веб-сервера, в которой вы используете WordPress, напрямую влияет на производительность вашего сайта, что влияет на время загрузки и стабильность.
По оценкам, из всего Интернета в совокупности Apache Server и Nginx вместе составляют 50% всего веб-трафика.
Отличия
Основное различие заключается в том, как обрабатываются соединения.
Проще говоря, Apache использует разветвленное многопоточное решение или keep-alive, которое поддерживает соединение для каждого пользователя.
С другой стороны, Nginx использует неблокирующий цикл событий, который объединяет соединения, работающие асинхронно через рабочие процессы.

Из-за этой архитектуры результатом является однопоточный процесс nginx, и для обработки каждого нового соединения не создаются дополнительные процессы. Таким образом, даже при высокой нагрузке, CPU и оперативная память не очень сильно расходуются при таком подходе.
Помимо архитектуры, есть также некоторые незначительные различия и нюансы между ними в конфигурации, и мы рассмотрим их более подробно позже в этом руководстве.
Во-первых, давайте посмотрим на два проекта и сделаем четкий обзор.
Apache
Nginx
Будучи преемником Apache, Nginx имеет преимущество в понимании ошибок и проблем производительности параллелизма, которые могут произойти благодаря его очень быстрой асинхронной схеме цикла событий.
Для статического контента это работает очень быстро. Что касается динамического контента, например PHP, Nginx не имеет возможности обрабатывать это с помощью модуля, как это делает Apache. Но это не помеха, поскольку для достижения этого используется FastCGI. Это очень хорошо работает в сочетании с пулами соединений php fpm и memcache.
Требования WordPress
Оба Apache и Nginx поддерживают php fpm. Это менеджер FastCGI, forked process manager для PHP, который может использоваться для обеспечения очень быстрого времени отклика. Выполняясь как демон на сервере, он будет инициализировать процессы, как только они потребуются.
Настройка PHP FPM с помощью Apache
Пользователи Ubuntu и Debian могут устанавливать необходимые пакеты с помощью aptitude через:
Теперь включите модуль в apache:
Затем в файле конфигурации /etc/apache2/conf-available/php7.0-fpm.conf добавьте следующее:
Кроме того, в вашем VirtualHost для WordPress (путь по умолчанию /etc/apache2/sites-available/000-default.con f) добавьте следующее:
Теперь перезапустите apache, и готово
Создайте файл с содержимым вида и откройте его в своем браузере. Теперь PHP будет работать с FPM.
Теперь проверьте свой блог WordPress. Обратили внимание на разницу?
Настройка PHP FPM с Nginx
Пользователи Ubuntu и Debian могут установить пакет следующим образом:
Теперь в вашем файле конфигурации (по умолчанию /etc/nginx/sites-available/default) в блоке сервера вам необходимо добавить конфигурацию FastCGI следующим образом:
Здесь мы используем фрагмент из Nginx, чтобы установить параметры cgi и передать fastcgi соединение сокета.
Затем убедитесь, что вы установили cgi.fix_pathinfo = 0 в php ini, поскольку настройка по умолчанию нарушает конфигурацию. Измените /etc/php/7.0/fpm/php.ini и установите:
Теперь вы можете сохранить файл и перезагрузить PHP FPM. Сделайте это через:
Наконец, мы можем проверить в своем браузере, чтобы подтвердить, что сервер теперь использует PHP FPM с Nginx.
Выполнение mod_rewrite в Nginx
Чтобы ваш блог WordPress работал с Nginx, просто добавьте следующее к части try_files вашей конфигурации Nginx:
Если вы используете каталог для своего блога WordPress, задайте следующее:
Перезапустите Nginx, и у вас будет работать перезапись URL.
Оптимальные настройки
У вас есть много вариантов оптимизации WordPress посредством кеширования на сервере с помощью memcache, varnish, а также на уровне приложения WordPress с помощью плагинов, которые легко позволят вам получить доступ к этому.
Кэш статического содержимого
Nginx очень быстро работает в качестве кеша статического содержимого, и именно там его использование действительно впечатляет в WordPress и сообщениях в блогах с большим количеством изображений. Вы можете обслуживать свои CSS, JS и изображения через сервер Nginx, работающий именно для этих нужд.
Блок местоположения для этой конфигурации статических субдоменов будет выглядеть так:
Если вы хотите настроить кеширование по всему проекту, просто добавьте следующие четыре строки в свои конфигурации nginx.conf:
Важно: open_file_cache_errors будет кэшировать фактические ошибки 404, поэтому лучше отключить это, если вы используете балансировщик нагрузки.
Пулы подключения PHP-FPM
Вы можете настроить несколько конфигураций, например:
В каждом из следующих вариантов мы можем установить множество конфигураций:
С помощью этого вы можете указать параметры конфигурации PHP-FPM, такие как pm.max_children, и вы также можете указать переменные окружения и установить здесь параметры имени пользователя и группы.
Балансировщик нагрузки Nginx
Если вы собираетесь получать много трафика, то вам, вероятно, захочется настроить балансировщик нагрузки для использования с настройкой php-fpm.
Обычно мы хотим запустить несколько бэкенд серверов на верхнем уровне, все из которых работают с зеркалами вашего блога, а затем еще один сервер, на котором работает nginx, который действует как балансировщик нагрузки и будет направлять нагрузку между потоками трафика.
Это означает, что вы можете использовать много серверов для одновременного доступа к вашему блогу, а конфигурация для этого относительно проста.
Примерная конфигурация будет выглядеть так. Сначала мы начинаем с модуля upstream:
Здесь каждый backend1.example.com имеет собственную конфигурацию Nginx, зеркало того, как сайт был до того, как он имел балансировщик нагрузки. Nginx будет выбирать, какой сервер использовать для каждого запроса.
Если у одного из наших бэкендов есть более быстрый жесткий диск, например SSD, или географически ближе к вашей основной пользовательской базе, вы можете установить вес так:
Кроме того, если вы считаете, что сервер может стать медленнее или вы беспокоитесь о тайм-аутах, то для этого тоже есть варианты конфигурации:
Затем нам нужно передать это серверу через прокси-сервер, используя backend upstream, который мы только что определили ранее:
Наконец, по этой теме, также для вашей справки приведено руководство nginx по обслуживанию статического содержимого и наилучшим параметрам конфигурации. Обратите внимание на использование tcp_nopush и sendfile для Mp3, например.
Миграция Apache в Nginx
Помимо чтения руководства Nginx и самостоятельного внесения изменений, вы можете использовать инструмент apache2nginx с открытым исходным кодом для перевода вашей конфигурации с Apache на Nginx.
Следуйте инструкциям по установке apache2nginx README, и после установки вы сможете перенести файлы конфигурации, просто выполнив:
Теперь вы можете проверить конфигурацию и попробовать ее в установке Nginx. Вы можете обнаружить, что перевод не был совершенным, но он даст вам основание для начала.
Вывод
Для скорости и производительности Nginx является очевидным выбором вместо Apache, но это не означает, что Apache не может обрабатывать некоторый трафик. Если вы планируете перейти на первую страницу Reddit в ближайшее время, вероятно, вам стоит взглянуть на получение более эффективного решения с Nginx и PHP-FPM.
Миграция вашего WordPress в Nginx не очень сложна, и конфигурация для Nginx, очень проста и удобна в доступе по сравнению с Apache.
Хотя там и нет модулей, подобных Apache, и вначале это может быть незнакомо, вы сможете найти им замену в большинстве случаев. Если нет, то в качестве резервного решения вы всегда можете проксировать старый сервер через ваш nginx для этой цели, если это необходимо.
Существует множество способов настройки обоих серверов, поэтому хорошее решение можно найти почти всегда, независимо от требований. На данный момент кажется, что Apache всегда будет выбором по умолчанию для широко доступного хостинга cPanel, благодаря инструменту настройки EasyApache, который поставляется вместе с ним.
В будущем, возможно, больше хостов примет инструменты Nginx cPanel, такие как Engintron, которые также предоставляют Nginx для cPanel.
На данный момент, если вы хотите переключиться на WordPress с поддержкой Nginx, вам нужно будет настроить Linux VPN на DigitalOcean, AWS или на другом хостинг-провайдере.
NGINX vs Apache: Сравнение двух популярных веб-серверов
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и NGINX. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент NGINX (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины NGINX был создан для преодоления ограничений производительности веб-серверов Apache. NGINX, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут как автономный веб-сервер и как внешний прокси-сервер для Apache и других веб-серверов.
Обзор Apache
Модель «один сервер делает все» стала ключом к успеху Apache. Однако по мере увеличения уровней трафика и увеличения количества веб-страниц работа Apache стала усложняться.
Обзор NGINX
NGINX также имеет богатый набор функций и может выполнять различные роли сервера :
Apache против Nginx: сравнение наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
NGINX, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей NGINX должны быть очень осторожны, чтобы создавать эффективный и точный код, без каких-либо сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим.
Давайте рассмотрим эти два понятия:
Статический контент
Динамический контент
Результаты тестов Speedemy показали, что производительность динамического контента была одинаковой для серверов Apache и NGINX. Вероятная причина этого заключается в том, что почти все время обработки запросов тратится в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере без необходимости полагаться на внешние компоненты. Эти динамические процессы могут быть включены с помощью динамически загружаемых модулей.
NGINX изначально не имеет возможности обрабатывать динамический контент. Для обработки PHP и других запросов на динамический контент NGINX должен перейти на внешний процессор и дождаться отправки отрендеренного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его накладные расходы будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. NGINX также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и NGINX являются безопасными веб-серверами. Команда безопасности Apache существует, чтобы предоставлять помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках. Существует множество рекомендаций по обеспечению безопасности серверов для предотвращения атак безопасности.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долгое время имел динамическую загрузку модулей, поэтому все модули Apache поддерживают это.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживается обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был долгое время популярен, поддержка сервера довольно распространена повсеместно.
Наряду с документацией многие веб-проекты содержат инструменты для начальной загрузки в среде Apache. Оно может быть включено в сами проекты или в пакеты, поддерживаемые вашим дистрибутивом.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности его доступности.
Ngnix против Apache: Сравнение лицом к лицу
Apache
Ngnix
Совместное использование NGINX и Apache
Итак, что вы выберете? Apache или NGINX?
Как видно, Apache и NGINX являются мощными, гибкими и производительными веб-серверами. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше подходит для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Apache vs Nginx – сравнение и преимущества
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье
Краткий обзор Apache
Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась.
Краткий обзор Nginx
Nginx также имеет богатый набор функций и может выполнять различные роли сервера:
Apache против Nginx: сравнение их богатых наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу.
Статический контент
Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором.
Динамический контент
Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей.
Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя.
Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен.
В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц.
Ngnix против Apache: Сравнение лицом к лицу
Подводя итог, вот табличное представление наборов функций:
Итак, что выберите? Apache или Nginx?
Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps














