Коротко про HTTP

Процес відкриття сайту браузером виглядає наступним чином:

Браузер в залежності від системних налаштувань звертається до вибраного DNS серверу, отримуючи ІР адресу серверу з сайтом.

[Браузер] — foobar.com —> [ОС] — foobar.com —> DNS (1.1.1.1, 1.0.0.1)

[Браузер] <— 168.154.13.42 — [ОС] <— 168.154.13.42 — DNS (1.1.1.1, 1.0.0.1)

Отримавши ІР адресу браузер може почати відкриття сайту. Браузер відправляє HTTP запит до необхідного серверу. Протокол HTTP має текстовий вигляд, тому всі дані відправляються у вигляді звичайного ASCII тексту. Якщо ми намагаємося зайти по адресу http://foobar.com/, браузер відкриє TCP з’єднання по отриманому IP адресу 168.154.13.42 на 80 порт і відправить просте текстове повідомлення наступного вигляду

GET / HTTP/1.1
Host: foobar.com

Перший рядок вкаже дію яку хоче виконати клієнт, об’єкт щодо якого відбувається дія і версія протоколу. Після чого в запиті будуть вказані хедери запиту. В справжньому запиті хедерів буде куди більше, проте в нашому випадку показаний базовий приклад, який без проблем буде працювати. Браузери зазвичай передають хедер Host який вказує домен відносно якого відбувався запит. Це дозволяє одному фізичному серверу приймати запити по різним доменам. Зазвичай для організації такого використовується Reverse Proxy який слухає на цільовому порту (80/443) і відносно значення Host і своїх налаштування перенаправляє запит на інший локальний порт. Тому при розгортці веб сервісу який має працювати по HTTP рідко коли напряму сервіс піднімають на порту 80 чи 443. Більше того ймовірно що написаний розробником сервіс не вмітиме працювати з SSL який необхідний для роботи HTTPS, а сам розробник не захоче в придачу до розгортки займатися ще й випуском і перевипуском SSL сертифікатів і перепис сервісу для того аби він міг працювати з ними. Зазвичай вся робота пов’язана з SSL передається на вхідний веб сервер (Nginx, Apache, Caddy) який налаштовується для роботи в режимі Reverse Proxy. Веб сервер займається правильною обробкою запиту, фільтруванням спаму і тому подібне і вже готовий запит перенаправляє на необхідний локальний сервіс. Завдяки чому сервіс можна запустити і заблокувати будь який зовнішній трафік. Також для сервісу всі запити будуть виглядати так наче вони прийшли з локальної машини (127.0.0.1). Власне так і є оскільки всі запити будуть надсилатися вхідним веб сервером, проте навіть так можна передавати ІР клієнта напряму в сервіс для цього зазвичай веб сервер налаштовується аби передавати в запиті новий хедер X-Real-IP або X-Forwarded-For де вказується ІР адрес клієнта.

Щодо HTTPS, зазвичай всі сайти використовують саме його для роботи. По своїй суті це той же протокол HTTP, проте працює по стандарту на порту 443 і використовується додатково шифрування всіх запитів за допомогою симетричного шифрування з попереднім обміном ключами по алгоритму Деффі-Хелмана . Також веб сервер надає певний сертифікат який підтверджує право володіння доменом, що дозволяє впевнитись в тому що сервер до якого ви підключаєтесь дійсно є власником доменного імені (foobar.com). Насправді ця система не працює і є вкрай ненадійною в разі якщо атакуюча сторона контролює мережу жертви, проте в цілому варто вірити що це працює :). Сертифікат являє собою звичайний підписаний третьою стороною (яка називається валідатор, або ЦС - центр сертифікації), за допомогою асиметричного шифрування, файл. Ця система вважається надійною тому що припускається що обидві сторони (клієнт і сервер) довіряють ЦС, сертифікат якого також підписаний декількома вищестоящими по іерархії ЦС. Звісно при контролі мережі клієнта для прикладу у випадку підключення до відкритої мережі WiFi зловмисник без проблем може підминити трафік до ЦС і видати себе за нього і так само без проблем видати сертифікат на свій фіктивний сайт і при вході на google.com ви відправити свої логіни і паролі атакуючій стороні, навіть не помітивши цього. Проте повертаючись до теми HTTPS нам це треба щоб клієнтам не висвічувалось попередження в браузері. Для цього нам треба отримати сертифікат підписаний ЦС і займатися всіх вищеописаним алгоритмом при обробці запитів. Цим зазвичай займається вхідний веб сервер, крім сертифікату, його необхідно зазвичай купувати в ЦС. Проте існують безкоштовні ЦС як от Let’s Encrypt (LE), проте їхні сертифікати видаються максимум на 2 місяці і їх необхідно постійно оновлювати. Щоб не морочитись з цим можна використовувати веб сервер Caddy який автоматично отримує і оновлює сертифікати LE.

Відповідь від сервера по протоколу HTTP це такий же текстовий документ який зазвичай являє собою або html сторінку, або json дані. Тип даний визначається хедером відповіді Content-Type.