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

Часть 1: Сравнительная таблица. Nginx vs Apache

Давайте сведем все, что мы узнали, в одну простую таблицу.

Критерий Nginx Apache
Архитектура Асинхронная, событийно-ориентированная. Один процесс обрабатывает множество соединений. Процессная/потоковая. Новый процесс или поток на каждое соединение/группу.
Производительность (статика) Очень высокая. Идеален для отдачи HTML, CSS, JS, картинок. Потребляет мало памяти. Хорошая, но ниже, чем у Nginx при высоких нагрузках. Потребляет больше памяти.
Конфигурация Централизованная. Все правила в .conf файлах на сервере. Просто, логично, быстро. Децентрализованная. Поддерживает .htaccess файлы прямо в папках сайта.
.htaccess Не поддерживается. Все правила (например, для ЧПУ) нужно прописывать в основном конфиге. Поддерживается. Главное преимущество для виртуального хостинга и CMS.
Гибкость и модульность Хорошая. Много встроенных модулей, но добавление сторонних требует пересборки. Очень высокая. Огромное количество динамически подключаемых модулей (.so файлы).
Основная роль Отдача статики и обратный прокси (reverse proxy). Идеален как "фасад" для приложений. Универсальный веб-сервер. Хорошо справляется с динамическим контентом (PHP, Perl).

Простой вывод:

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

  • Если вы предоставляете услуги виртуального хостинга, где клиентам нужна гибкость .htaccess, или используете старую CMS, которая сильно на него завязана, Apache может быть проще в настройке.

Часть 2: Лучшее из двух миров. Гибридная схема: Nginx + Apache

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

Как это работает:

  1. Nginx ставится "на входе" (на "ресепшн"). Он слушает порты 80 и 443 и принимает все запросы от посетителей.

  2. Apache "прячется" за Nginx и слушает какой-нибудь внутренний порт, например, 8080, недоступный из интернета.

  3. Правила распределения: Nginx настраивается как обратный прокси (Урок 43).

    • Если приходит запрос на статический файл (картинку .jpg, стиль .css), Nginx, как самый быстрый, отдает его сам, не беспокоя Apache.

    • Если приходит запрос на динамическую страницу (например, PHP-скрипт), Nginx перенаправляет (проксирует) этот запрос на Apache (на порт 8080).

  4. Обработка: Apache получает запрос, обрабатывает его (например, с помощью своего модуля mod_php), генерирует HTML-страницу и отдает ее обратно Nginx.

  5. Ответ клиенту: Nginx получает готовый HTML от Apache и отправляет его посетителю.

Визуальная схема:

[ Посетитель ] <---> [ Интернет ] <---> [ :80/:443 NGINX ] ---> [ Статика (.jpg, .css) ]
                                             |
                                             |
                                             v
                             [ :8080 APACHE + mod_php ] ---> [ Динамика (.php) ]

Зачем нужна такая сложность?

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

  • Гибкость Apache: Вся сложная логика обработки динамики и правила .htaccess работают на стороне Apache, где их проще настраивать.

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

Эта связка (nginx как reverse proxy для apache) была золотым стандартом для многих хостинг-провайдеров и веб-студий на протяжении многих лет.

Часть 3: Практика. Настройка связки Nginx + Apache

Давайте реализуем эту схему на нашем сервере.

Шаг 1: Подготовка. Устанавливаем и настраиваем Apache

Мы предполагаем, что у вас уже установлен apache2 из прошлого урока.

  1. Изменим порт Apache. Нам нужно, чтобы он перестал слушать порт 80 и начал слушать внутренний порт 8080.

    nano /etc/apache2/ports.conf

    Найдите строку Listen 80 и измените ее на Listen 8080.
    Сохраните и закройте файл.

  2. Изменим конфиг виртуального хоста Apache.

    nano /etc/apache2/sites-available/project-one.local.conf

    Найдите строку <VirtualHost *:80> и измените ее на <VirtualHost *:8080>.
    Сохраните и закройте файл.

  3. Перезапустим Apache.

    systemctl restart apache2
  4. Проверим порты. Убедимся, что Apache теперь слушает только порт 8080.

    ss -tulpn | grep apache

    Вы должны увидеть ...:8080.

Шаг 2: Включаем Nginx и настраиваем как прокси

  1. Включаем Nginx обратно.

    systemctl start nginx
    systemctl enable nginx
  2. Редактируем конфиг сайта для Nginx.
    Откроем наш конфиг для project-one.local в Nginx.

    nano /etc/nginx/sites-available/project-one.local

    Полностью замените его содержимое на это:

    server {
        listen 80;
        server_name project-one.local www.project-one.local;
    
        # Сначала обрабатываем статику
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            root /var/www/project-one.local/html;
        }
    
        # Все остальные запросы отправляем на Apache
        location / {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

Разбор нового конфига:

  • location ~* \.(jpg|...)$: Это новый, более сложный блок location~* означает "регулярное выражение без учета регистра". \. - это экранированная точка. (jpg|jpeg|...) - логическое "ИЛИ". Вся строка означает: "Если URL запроса заканчивается на .jpg или .jpeg или ...".

  • root ...;Только для этого location мы указываем Nginx, где искать файлы, и он отдает их сам.

  • location / { ... }: Этот блок теперь ловит все остальные запросы (которые не попали в первый location). И здесь мы используем уже знакомую нам конструкцию proxy_pass, чтобы отправить запрос на Apache.

Шаг 3: Проверка и перезагрузка Nginx

nginx -t
systemctl reload nginx

Шаг 4: Финальный тест

Откройте в браузере http://project-one.local. Вы должны увидеть вашу страницу "Добро пожаловать на Project One!". Но теперь запрос прошел по всей цепочке: браузер -> Nginx -> Apache -> Nginx -> браузер.

Часть 4: Заключение

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

  • Сравнивать Nginx и Apache по ключевым параметрам: архитектуре, производительности и конфигурации.

  • Понимать сильные стороны каждого: Nginx - для статики и проксирования, Apache - для гибкости с .htaccess.

  • Освоили концепцию гибридной архитектуры, где Nginx выступает в роли быстрого "фасада", а Apache - в роли гибкого "бэкенда".

  • Реализовали эту связку на практике, настроив proxy_pass в Nginx для перенаправления запросов на Apache.

Это знание дает вам свободу выбора и возможность строить более сложные и производительные веб-архитектуры.

На следующем, 46-м уроке, мы сделаем наши сайты безопасными. Мы установим SSL-сертификат от бесплатного центра сертификации Let's Encrypt, чтобы наши сайты работали по протоколу HTTPS.

Перейти к просмотру - УРОК №46.

подарок Промо-код: PROMO15 - скидка 15%! огонь

Введите при оформлении первого заказа на сайте: Hosting-VDS.com

авторское право цифровые решения

Помог ли вам данный ответ? 0 Пользователи считают это полезным (0 голосов)