Модуль 6

Основи HTTP та HTTPS у контексті Nginx

Ось готовий урок, створений за твоїм майстер-промптом.

🎓 Урок: Основи HTTP та HTTPS у контексті Nginx

(Стиль CS50: Енергійно, зрозуміло, з "підкапотною" логікою)

1. 🔥 Вступ: Чому ваш браузер вам не довіряє?

Привіт, світе! 👋

Уявіть ситуацію. Ви написали свій перший веб-сайт, запустили його на сервері, надсилаєте посилання другу, а він замість вашого крутого дизайну бачить грізне червоне попередження в браузері: "Not Secure" (Небезпечно) або взагалі "Site can't be reached".

Розчарування, правда? Ви ж усе зробили правильно в коді!

Але чи замислювалися ви, як саме браузер вашого друга спілкується з вашим сервером? Як ці картинки та текст перелітають через океан кабелів?

Це не магія. Це — HTTP.

Уявіть, що інтернет — це величезний ресторан. * Ви (Клієнт/Браузер) — сидите за столиком і хочете замовити суп. * Кухня (Сервер) — має цей суп. * Але ви не йдете на кухню самі. Ви кличете офіціанта.

У нашому випадку офіціант — це Nginx. А мова, якою ви робите замовлення ("Дайте мені, будь ласка, головну сторінку"), називається HTTP.

Сьогодні ми розберемося, як навчити нашого офіціанта (Nginx) розуміти замовлення, чому іноді він "одягає бронежилет" (HTTPS) і як налаштувати все так, щоб браузер світився зеленим замочком, а не червоною тривогою.

Поїхали! 🚀

2. 🧠 Теоретична база: Листівки проти Сейфів

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

Що таке HTTP?

HTTP (HyperText Transfer Protocol) — це просто текст. Серйозно. Коли браузер звертається до сервера, він не надсилає якусь складну бінарну магію. Він надсилає текстову записку.

Уявіть, що ви пишете поштову листівку (не в конверті!) і передаєте її через весь клас своєму другу. На ній написано:

"Привіт, Nginx! Дай мені файл index.html."

Це і є HTTP. * Проблема: Будь-хто по дорозі (провайдер, хакер у кав'ярні з Wi-Fi) може прочитати вашу листівку. Якщо там пароль — його вкрадуть.

Що таке HTTPS?

Додаємо одну літеру S — Secure (Безпечний).

Тепер ви не просто пишете листівку. Ви кладете її в непробивний сталевий сейф, замикаєте його і відправляєте сейф. * Тільки у сервера (Nginx) є ключ, щоб відкрити цей сейф. * Ніхто по дорозі не бачить, що всередині.

Роль Nginx

Nginx — це програма, яка стоїть на вході вашого сервера і чекає на ці "листівки" або "сейфи". Він слухає певні порти (двері): * Порт 80: Звичайні двері для листівок (HTTP). * Порт 443: Броньовані двері для сейфів (HTTPS).

📌 Що треба запам’ятати залізно: 1. HTTP — це відкритий текст. Небезпечно для паролів. Працює на порту 80. 2. HTTPS — це шифрований канал. Потрібен SSL-сертифікат (цифровий паспорт), щоб довести, що ви — це ви. Працює на порту 443. 3. Nginx — це той, хто читає запит і віддає відповідь.

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

Давайте подивимося, як це виглядає в конфігурації Nginx.

Приклад 1: "Голий" HTTP

Уявіть: Ми хочемо, щоб Nginx просто віддав сторінку, коли хтось стукає у двері 80.

server {
    listen 80;                 # Слухаємо порт 80 (HTTP)
    server_name example.com;   # Наше ім'я (домен)

    location / {
        root /var/www/html;    # Де лежать файли
        index index.html;      # Який файл віддати
    }
}

❓ Питання до вас: Якби я змінив listen 80; на listen 8080;, чи відкрився б сайт, якщо ми просто введемо http://example.com у браузері? (Спойлер: Ні, бо браузер за замовчуванням стукає у 80-ті двері. Довелося б писати example.com:8080).

Приклад 2: Реальний світ (Redirect на HTTPS)

Сьогодні залишати сайт на HTTP — це поганий тон. Хороший офіціант (Nginx) повинен сказати клієнту: "Гей, тут небезпечно, переходь до захищеного столика!".

server {
    listen 80;
    server_name example.com;

    # Повертаємо код 301 (Переїхав назавжди)
    return 301 https://$host$request_uri;
}

Що тут відбувається? 1. Клієнт приходить на HTTP. 2. Nginx не віддає контент. Він каже: "301! Шукай мене за адресою https://...". 3. Браузер автоматично робить новий запит, вже захищений.

Приклад 3: "Броньований" HTTPS

Тепер, коли ми перенаправили клієнта, нам треба прийняти його на захищеному порту.

server {
    listen 443 ssl;             # Слухаємо 443 і вмикаємо SSL
    server_name example.com;

    # Шлях до ключів від "сейфу" (сертифікатів)
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Чому результат саме такий? Nginx використовує файли .crt (публічний паспорт) та .key (секретний ключ), щоб розшифрувати те, що надсилає браузер. Без цих файлів Nginx не зможе "відкрити сейф" і видасть помилку.

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

Час забруднити руки! Відкривайте термінал.

Завдання 1: "Hello World" на порту 80 Створіть простий конфіг у Nginx, який на запит http://localhost віддає сторінку з текстом "Я вивчив HTTP!". Перевірте через curl -I localhost (подивіться заголовки).

Завдання 2: Зміна порту Змініть у конфігу listen 80; на listen 8888;. Перезавантажте Nginx. Спробуйте відкрити в браузері. Що сталося? Як тепер треба ввести адресу?

Завдання 3: Симуляція помилки Приберіть крапку з комою ; після listen 80. Спробуйте перезапустити Nginx. Прочитайте, що пише команда nginx -t. Мета: Навчитись читати помилки синтаксису.

Завдання 4: Редирект Налаштуйте блок server так, щоб при заході на http://localhost вас перекидало на https://google.com. (Так, ми можемо перенаправляти користувачів куди завгодно!).

Завдання 5: Міні-кейс "Безпека" Уявіть, що ви налаштували HTTPS, але забули вказати шлях до ssl_certificate_key. Що скаже Nginx при перевірці конфігурації? Чому він не може працювати без ключа?

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

Як відрізнити новачка від профі в роботі з Nginx?

1. "Сліпий" перезапуск vs Перевірка * Новачок: Міняє конфіг і одразу пише systemctl restart nginx. Якщо там помилка — продакшн падає, клієнти панікують. 😱 * Профі: Завжди (чуєте, ЗАВЖДИ!) спочатку пише: sudo nginx -t Це тестовий прогін. Nginx скаже: "Синтаксис ок" або вкаже на конкретний рядок з помилкою. Тільки потім робимо reload.

2. HTTP коди — це ваші друзі Не ігноруйте їх. * 200 — Ок, все супер. * 301 — Йди туди (редирект). * 404 — Я не знайшов файл (перевір root шлях). * 500/502 — Проблема не в Nginx, а в тому, що "за ним" (наприклад, ваш Python/Node.js додаток впав).

3. Логи — це чорна скринька літака Якщо щось не працює, не гадайте. tail -f /var/log/nginx/error.log Там написано все. Nginx дуже балакучий, якщо знати, де слухати.

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? 1. Зрозуміли, що HTTP — це відкриті листівки, а HTTPS — це броньовані сейфи. 2. Навчилися налаштовувати Nginx як офіціанта, що приймає ці замовлення. 3. Побачили, як перенаправляти трафік з небезпечного каналу на безпечний.

Тепер ви не просто "копіюєте конфіги зі StackOverflow". Ви розумієте, чому там написано listen 443 і навіщо нам сертифікати.

🔮 Тизер наступного уроку: Зараз ми віддавали прості статичні файли (картинки, HTML). Але сучасний веб — це динаміка! Наступного разу ми дізнаємось, як перетворити Nginx на Reverse Proxy, щоб він став щитом і посередником для ваших потужних додатків на Python, Node.js або Go.

А поки — перевірте свої логи! 😉

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