HTTP/HTTPS: що це, протоколи передачі даних та TLS шифрування

Що таке HTTP та HTTPS?

HTTP (HyperText Transfer Protocol) — це протокол прикладного рівня моделі OSI, призначений для передачі гіпертекстових документів та інших даних у World Wide Web. Розроблений Тімом Бернерсом-Лі у 1989 році, HTTP пройшов кілька версій: від HTTP/0.9 (лише GET-запити та HTML-відповіді) до сучасних HTTP/2 та HTTP/3. Протокол працює за схемою запит-відповідь: клієнт надсилає запит на сервер, сервер обробляє його та повертає відповідь.

HTTPS (HTTP Secure) — це розширення протоколу HTTP, що додає рівень шифрування через TLS (Transport Layer Security). HTTPS не є окремим протоколом — це комбінація HTTP та TLS. Дані, що передаються через HTTPS, шифруються на стороні клієнта та розшифровуються на сервері, що робить їх недоступними для перехоплення та підробки. HTTPS також забезпечує автентифікацію сервера через SSL/TLS-сертифікати, гарантуючи, що клієнт підключається до справжнього сервера, а не до зловмисника.

Ключова відмінність між HTTP та HTTPS — безпека. HTTP передає дані у відкритому вигляді: будь-який вузол мережі між клієнтом та сервером може прочитати вміст запиту або відповіді. HTTPS шифрує весь вміст, включаючи URL, заголовки та тіло запиту, залишаючи видимим лише IP-адресу сервера та порт підключення. Для мобільних додатків, що працюють через публічні Wi-Fi мережі, HTTPS є обов'язковою вимогою безпеки.

Як працює HTTP

HTTP — це протокол без збереження стану (stateless), що працює поверх TCP/IP. Клієнт встановлює TCP-з'єднання з сервером (зазвичай на порт 80 для HTTP або 443 для HTTPS), надсилає HTTP-запит, отримує HTTP-відповідь та закриває з'єднання (в HTTP/1.1 з'єднання може бути перевикористано). Кожна взаємодія між клієнтом та сервером складається із запиту та відповіді. Відсутність стану означає, що сервер не зберігає інформацію про попередні запити клієнта — кожен запит обробляється незалежно.

Процес HTTP-взаємодії включає наступні кроки:

• DNS-резолв — браузер або клієнт перетворює доменне ім'я в IP-адресу через DNS
• TCP-рукопотискання — встановлюється TCP-з'єднання через триетапне рукопотискання (SYN, SYN-ACK, ACK)
• TLS-рукопотискання — для HTTPS додатково встановлюється зашифроване з'єднання (обмін сертифікатами та ключами)
• HTTP-запит — клієнт надсилає метод, URL, заголовки та опціонально тіло запиту
• HTTP-відповідь — сервер повертає статус-код, заголовки та тіло відповіді

Важлива характеристика HTTP — ідемпотентність методів. GET, HEAD, PUT, DELETE та OPTIONS є ідемпотентними: багаторазове виконання одного й того ж запиту не змінює стан сервера після першого виконання. POST, PATCH та CONNECT не ідемпотентні — кожен виклик може створювати новий ресурс або змінювати стан. Для мобільної розробки розуміння ідемпотентності критичне: при повторному надсиланні запиту через помилку мережі клієнт повинен знати, чи безпечно повторити запит.

HTTPS та TLS шифрування

HTTPS використовує криптографічний протокол TLS (Transport Layer Security) для захисту даних, що передаються. TLS — спадкоємець SSL (Secure Sockets Layer), який був розроблений компанією Netscape у 1995 році. Версії SSL 2.0 та 3.0 вважаються застарілими та небезпечними; сучасні версії TLS 1.2 (випущений у 2008) та TLS 1.3 (випущений у 2018) використовуються повсюдно. TLS 1.3, зокрема, скорочує час встановлення з'єднання з 2 round-trips до 1, що значно прискорює завантаження на мобільних пристроях.

Процес TLS-рукопотискання (handshake) включає наступні етапи:

• Client Hello — клієнт надсилає список підтримуваних версій TLS та наборів шифрів
• Server Hello — сервер вибирає версію TLS та набір шифрів, надсилає свій SSL/TLS-сертифікат
• Перевірка сертифіката — клієнт перевіряє сертифікат сервера через ланцюжок довіри до кореневого CA
• Обмін ключами — клієнт та сервер генерують спільний секретний ключ (сеансовий ключ)
• Switch Cipher — обидві сторони підтверджують перехід на зашифроване з'єднання

Перевірка SSL/TLS-сертифіката — критичний етап для безпеки. Клієнт перевіряє, що сертифікат: не прострочений, підписаний довіреним центром сертифікації (CA), відповідає домену в URL та не відкликаний (через CRL або OCSP). У мобільних додатках рекомендується використовувати Certificate Pinning — прив'язку до конкретного сертифіката або публічного ключа сервера. Це запобігає MITM-атакам навіть у разі компрометації CA. Однак pinning вимагає обережності: при зміні сертифіката додаток має бути заздалегідь оновлений.

Структура HTTP запиту та відповіді

HTTP-запит складається з трьох частин: стартового рядка (request line), заголовків (headers) та опціонального тіла (body). Стартовий рядок містить HTTP метод, URL запиту та версію HTTP. Заголовки передають мета-інформацію: тип контенту, автентифікаційні токени, налаштування кешування. Тіло присутнє лише в методах, що передають дані (POST, PUT, PATCH), та відсутнє в GET та DELETE.

Приклад HTTP-запиту до REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Анна",
    "email": "anna@example.com"
}

HTTP-відповідь має аналогічну структуру: стартовий рядок з версією HTTP та статус-кодом, заголовки та тіло. Статус-код — тризначне число, що визначає результат обробки запиту. Заголовки відповіді включають Content-Type, Content-Length, Cache-Control, Set-Cookie та інші. Тіло відповіді містить запитані дані у форматі, зазначеному в Content-Type (зазвичай JSON для API, HTML для веб-сторінок, зображення для медіа-контенту).

Заголовки відіграють критичну роль у роботі HTTP. Content-Type та Accept керують форматом даних. Authorization передає токени доступу. Cache-Control керує кешуванням. CORS-заголовки (Access-Control-Allow-Origin) контролюють доступ з інших доменів у браузерах. User-Agent ідентифікує клієнтський додаток. Для мобільних додатків особливо важливі заголовки керування кешуванням — вони дозволяють скоротити обсяг даних, що передаються, та покращити роботу при слабкому сигналі.

Коди стану HTTP

Коди стану HTTP групуються за п'ятьма класами, що позначаються першою цифрою: 1xx (інформаційні), 2xx (успіх), 3xx (перенаправлення), 4xx (помилка клієнта), 5xx (помилка сервера). Розуміння цих кодів необхідне для коректної обробки відповідей у мобільному додатку: 2xx означає успіх і дані можна відображати, 4xx вказує на проблему в запиті (потрібно показати помилку користувачеві), 5xx — на проблему на сервері (потрібно повторити запит пізніше).

Для мобільних додатків особливе значення має обробка коду 401 Unauthorized. При отриманні цього коду клієнт повинен спробувати оновити токен доступу через Refresh Token та повторити оригінальний запит. Якщо оновлення токена також повертає 401, користувача необхідно перенаправити на екран входу. Ця логіка зазвичай реалізується в Interceptor (OkHttp) або в middleware шарі мережевого клієнта.

HTTP/1.1, HTTP/2 та HTTP/3

HTTP/1.1, опублікований у 1999 році, досі залишається широко використовуваною версією протоколу. Його головний недолік — head-of-line blocking: запити до одного сервера виконуються послідовно, кожен наступний чекає завершення попереднього. Для обходу цього обмеження браузери відкривають 6-8 паралельних TCP-з'єднань до одного домену, що збільшує навантаження на сервер та споживання пам'яті. HTTP/1.1 також передає заголовки в незашифрованому вигляді та не підтримує серверний push.

HTTP/2 (2015) вирішує проблему блокування через мультиплексування — безліч потоків даних передаються по одному TCP-з'єднанню одночасно. Сервер може надсилати ресурси клієнту до того, як клієнт їх запитає (server push). HTTP/2 також стискає заголовки через HPACK, що зменшує обсяг даних, що передаються. Для мобільних додатків HTTP/2 особливо корисний: одне з'єднання замінює кілька, скорочуючи час TLS-рукопотискання та споживання батареї.

HTTP/3 (2022) — остання версія протоколу, яка використовує QUIC (Quick UDP Internet Connections) замість TCP. QUIC працює поверх UDP, усуваючи проблему head-of-line blocking на рівні транспортного протоколу. HTTP/3 скорочує час встановлення з'єднання до 0 round-trips у кращому випадку (на повторних підключеннях) та до 1 round-trip при першому підключенні, що значно швидше HTTP/2 з його 2-3 round-trips. Для мобільних пристроїв HTTP/3 особливо ефективний при перемиканні між Wi-Fi та мобільною мережею — з'єднання не розривається, оскільки QUIC використовує ідентифікатор з'єднання, а не IP-адресу.

HTTPS у мобільній розробці

Використання HTTPS у мобільних додатках — не рекомендація, а обов'язкова вимога. Починаючи з Android 9 (API 28) та iOS 9 (ATS — App Transport Security), всі мережеві запити за замовчуванням повинні використовувати HTTPS. HTTP-запити блокуються системою, і для їх дозволу потрібен явний виняток у конфігурації додатка. Google Play Store та App Store відхиляють додатки, що передають конфіденційні дані по HTTP, включаючи паролі, токени та персональні дані.

Конфігурація HTTPS у мобільному додатку на Android включає:

<!-- AndroidManifest.xml — дозвіл на мережеві запити -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — налаштування HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

На iOS аналогічне налаштування виконується через Info.plist з ключем NSAppTransportSecurity. Для налагодження HTTPS-трафіку в мобільних додатках використовуються проксі-інструменти: Charles Proxy, Proxyman або mitmproxy. Вони вимагають встановлення довіреного SSL-сертифіката на пристрій. У продакшн-збірках необхідно відключати можливість налагодження та перевіряти, що Certificate Pinning налаштовано коректно. Використання OkHttp на Android з його CertificatePinner або TrustManager на iOS з SecTrustEvaluate — стандартні підходи для реалізації pinning.

Важливий аспект безпеки HTTPS у мобільній розробці — SSL Pinning. Без pinning додаток довіряє будь-якому сертифікату, підписаному відомим CA. Якщо CA буде скомпрометовано, зловмисник зможе перехоплювати трафік додатка. Pinning прив'язує додаток до конкретного сертифіката або публічного ключа сервера. При зміні сертифіката на сервері необхідно випустити оновлення додатка, тому pinning планують із запасом — прив'язуються до сертифіката вищестоящого CA або використовують кілька запасних ключів.