Модуль 37

Порівняння Nginx та Apache

Ось готовий урок, створений спеціально за твоїм запитом у стилі David Malan (CS50).

🎓 CS50: Nginx vs Apache — Битва Титанів

Привіт, світе! 👋 Радий бачити вас на занятті.

Сьогодні ми розберемо одну з наріжних тем веб-розробки. Ви вже вмієте писати код — HTML, CSS, можливо, трохи Python чи PHP. Але ось питання: як ваш код потрапляє з вашого ноутбука на екран користувача десь у Бразилії чи Японії?

Ваш код — це лише рецепт. Але вам потрібен офіціант, який візьме страву з кухні та принесе її клієнту. Цей офіціант — Веб-сервер.

І тут починається справжня "священна війна" (holy war) інтернету: Nginx проти Apache.

1. 🔥 Вступ: Проблема та мотивація

Уявіть, що ви відкрили піцерію 🍕.

Ситуація А: У вас працює Apache. Це старий, досвідчений офіціант. Він дуже розумний. Коли приходить клієнт, Apache виділяє йому окремого працівника, який стоїть біля столика весь час, поки клієнт їсть. * Плюс: Клієнт відчуває персональний підхід (можна налаштувати все під себе). * Мінус: А що, як прийде 10 000 клієнтів одночасно? Вам потрібно 10 000 працівників. Ваша піцерія (сервер) просто лусне від тісноти.

Ситуація Б: У вас працює Nginx. Це супер-швидкий робот 🤖. Він один стоїть на касі. Прийшов клієнт -> прийняв замовлення -> дав пейджер -> "Наступний!". Він не чекає, поки кухар приготує піцу. Він просто перемикається між клієнтами з шаленою швидкістю. * Плюс: Один робот може обслугувати тисячі людей. * Мінус: Він не такий гнучкий у спілкуванні, як живий офіціант.

Чому це важливо? Ви запустили стартап. У вас 10 користувачів — все працює. Раптом про вас написали у Twitter, і на сайт зайшло 50 000 людей. Якщо ви обрали неправильну архітектуру — ваш сервер "впаде", бізнес втратить гроші, а ви — нервові клітини.

Тож, кого наймемо: дідуся Apache чи робота Nginx? А може... обох? 🤔

2. 🧠 Теоретична база (Що під капотом)

Давайте заглянемо під капот, але без нудних схем.

Apache HTTP Server (Стара гвардія)

Apache з'явився у 1995 році. Він побудований на процесній моделі (або потоковій). * Як це працює: На кожного користувача створюється окремий потік (thread) або процес. * Аналогія: Телефонна станція, де кожному абоненту потрібен окремий оператор. Немає вільних операторів — лінія зайнята. * Фішка: .htaccess. Це магічний файл у кожній папці сайту, який дозволяє змінювати налаштування сервера "на льоту", не перезавантажуючи головний сервер. Це обожнюють хостинги.

Nginx (Engine X - Нова хвиля)

Створений у 2004 році Ігорем Сисоєвим спеціально, щоб вирішити "проблему C10k" (як обробити 10 000 з'єднань одночасно). * Як це працює: Подієва модель (Event-driven & Asynchronous). Один процес (Worker) обробляє тисячі з'єднань у циклі. * Аналогія: Гросмейстер, який грає сеанс одночасної гри на 50 дошках. Він робить хід тут, переходить туди, робить хід там. Він нікого не чекає. * Важливо: Nginx НЕ вміє виконувати PHP/Python код сам. Він вміє тільки швидко віддавати файли (картинки, HTML). Для коду він кличе помічників (наприклад, PHP-FPM).

📌 Що треба запам'ятати:

  1. Apache = Сила і гнучкість, але їсть багато пам'яті (RAM).
  2. Nginx = Швидкість і масштабованість, їсть мало ресурсів.
  3. Статичний контент (картинки, CSS) — Nginx перемагає "всуху".
  4. Динамічний контент (PHP) — Apache робить це простіше, Nginx потребує налаштування.

3. 🧪 Приклади (Від простого до реального)

Приклад 1: Простий конфіг (Virtual Host)

Як ми скажемо серверу: "Якщо хтось стукає на сайт mysite.com, покажи йому папку /var/www/site"?

Apache:

<VirtualHost *:80>
    ServerName mysite.com
    DocumentRoot /var/www/site
    # Зверніть увагу: XML-подібний синтаксис
</VirtualHost>

Nginx:

server {
    listen 80;
    server_name mysite.com;
    root /var/www/site;
    # Зверніть увагу: C-подібний синтаксис з фігурними дужками
}

Риторичне питання: Що виглядає чистішим? Для багатьох розробників Nginx читається легше, як JSON або код на C.

Приклад 2: Реальна архітектура "Reverse Proxy" (Найкраща практика)

У великих проєктах ми часто робимо хитро. Ми ставимо Nginx спереду, а Apache позаду.

Сценарій: Користувач просить картинку logo.png і сторінку profile.php.

  1. Запит приходить на Nginx (він стоїть на вході, порт 80).
  2. Nginx дивиться: "Ага, logo.png — це просто файл. Я віддам його сам за 0.001 секунди".
  3. Nginx дивиться: "Ого, profile.php. Я не вмію це читати. Гей, Apache (на порті 8080), розберись!".
  4. Apache повільно, але надійно генерує HTML і віддає його Nginx.
  5. Nginx віддає результат користувачу.

Чому це геніально? Ми знімаємо навантаження з Apache (важку статику віддає легкий Nginx) і залишаємо зручність .htaccess для розробників.

4. 🛠 Практична частина

Час забруднити руки! Уявіть, що ви адмін сервера.

Завдання 1: Розвідка Дізнайтеся, що зараз працює на вашому комп'ютері (або в Docker-контейнері). * Виконайте: curl -I google.com (або свій локалхост). * Знайдіть рядок Server:. Що ви там бачите? gws? nginx? apache?

Завдання 2: Знайди відмінність У вас є файл конфігурації. В ньому пропущена одна деталь, через яку Nginx не запуститься. Знайдіть її.

server {
    listen 80
    server_name example.com;
    location / {
        root /usr/share/nginx/html;
    }
}

(Підказка: Nginx дуже суворий до пунктуації, як вчителька мови. Де крапка з комою?)

Завдання 3: Міні-кейс Ви робите сайт-візитку для фотографа. Там 5 HTML сторінок і 5000 фотографій у високій якості. Очікується багато трафіку. * Який сервер ви оберете основним? Чому? (Очікувана відповідь: Nginx, бо він ідеальний для віддачі статики/картинок).

Завдання 4: А що, якщо... Ваш клієнт хоче заблокувати доступ до адмінки (/admin) для всіх, крім його домашнього IP (наприклад, 192.168.1.5). Напишіть шматочок конфігу для Nginx. (Підказка: використовуйте директиви allow та deny).

5. 💡 Мислення як у розробника

Ось що відрізняє новачка (Junior) від профі (Senior) у цій темі:

Помилка новачка: Думати, що "Apache — це старе лайно, треба скрізь ставити Nginx". Або намагатися змусити Nginx читати .htaccess файли (спойлер: він їх не бачить і ігнорує).

Думка професіонала: "Який інструмент вирішує мою задачу?" * Якщо це простий хостинг, де клієнти хочуть самі міняти конфіги -> Apache. * Якщо це високонавантажений API або віддача медіа -> Nginx. * Якщо це складний додаток -> Nginx як Reverse Proxy.

Порада Девіда: Ніколи не оптимізуйте передчасно. Але завжди знайте, де "вузьке місце" вашої системи. У 90% випадків повільний сайт — це поганий код або база даних, а не вибір між Apache та Nginx. Але коли настане "Чорна п'ятниця" — Nginx врятує вашу дупу. 😉

6. 🧩 Підсумок

Отже, що ми сьогодні зрозуміли?

  1. Apache — це універсальний солдат. Потужний, сумісний, але важкий.
  2. Nginx — це швидкісний болід F1. Асинхронний, легкий, король статики.
  3. Ми навчилися розрізняти їхні архітектури (Процеси vs Події).
  4. Ми зрозуміли, що їх можна комбінувати.

Ви тепер вмієте: Свідомо обирати веб-сервер під задачу, а не просто ставити те, що було в туторіалі на YouTube.

🔎 Тизер наступного уроку: Добре, сервер віддає файли. Але зараз вони летять інтернетом відкритим текстом. Будь-хто в кав'ярні з Wi-Fi може перехопити ваші паролі. Як захистити дані і що це за зелений замочок у браузері? Наступного разу говоримо про HTTPS та SSL сертифікати.

А поки що... це був CS50! 🚀

← До списку уроків Наступний урок →