Кожного разу, коли ви вводите в адресну стрічку браузера умовну назву сайту і тиснете Enter, під капотом розгортається справжня драма. З пакетами даних, підтвердженнями, шифруванням та нескінченними очікуваннями. Втім, пересічний користувач цього не бачить. Йому просто треба, щоб картинка завантажилася за частку секунди.
За останні тридцять років протокол, який рухає весь інтернет, пройшов шлях від простої читалки статичних текстових файлів до складного монстра, що намагається витиснути максимум із законів фізики. Розберемося, як ми дісталися від дірявого HTTP до шифрованого HTTPS і чому Google змусив увесь світ перейти на HTTP/3. Без підручникового занудства і з повним розумінням того, що відбувається всередині ваших пристроїв.
HTTP/1.1: Дідівський метод і проблема «корок на дорозі»
Почнемо з витоків. HTTP у своєму початковому вигляді — це буквально текстовий діалог між браузером і сервером. Ви кажете серверу надати конкретну сторінку, а він відповідає і просто віддає її. Без заходів безпеки. Без шифрування. Усі дані летіли мережею у відкритому вигляді, і будь-який сусід по Wi-Fi у кав’ярні чи бібліотеці міг спокійно перехопити пароль.
Наприкінці дев’яностих з’явився специфікований HTTP/1.1. Він став стандартом на десятиліття, але мав один фундаментальний архітектурний фейл, який розробники називають блокуванням голови черги.
Уявити це простіше ніж здається. Ви прийшли в супермаркет з повним візком товарів. Перед вами в черзі стоїть людина, яка п’ять хвилин шукає дрібні гроші для оплати однієї пачки жувальної гумки. Поки вона не розплатиться, уся черга стоїть і чекає.
У HTTP/1.1 це працювало точно так само. Браузер створював з’єднання, запитував один файл, чекав на нього, і тільки після отримання міг попросити наступний стиль, скрипт чи картинку. Інженери згодом викрутилися: браузери навчилися відкривати до шести паралельних з’єднань на один сайт. Але це було схоже на латання старого паркану. Мережа перевантажувалася, а затримки залишалися жахливими.
HTTPS і TLS: Коли безпека стала обов’язковою
HTTPS — це той самий старий HTTP, але загорнутий у криптографічну броню протоколу TLS. Спочатку безпека нікого не хвилювала. Потім з’явилися інтернет-магазини, онлайн-банкінг та масове перехоплення даних. Потрібно було терміново вирішити дві задачі: шифрувати трафік та переконуватися, що сервер — це дійсно той, за кого себе видає.
Для цього вигадали так зване рукостискання. Браузер і сервер спочатку обмінюються вітаннями, узгоджують версії шифрів, сервер показує свій цифровий сертифікат, а потім вони обмінюються секретними ключами.
Це гарно і безпечно, але за таку броню довелося платити швидкістю.
Щоб просто розпочати передачу даних у HTTPS, браузеру та серверу потрібно зробити кілька холостих пробігів туди-сюди. Спочатку встановлюється базове з’єднання, потім узгоджуються ключі шифрування, і тільки після цього відправляється перший корисний запит. Якщо сидите на швидкісній оптиці, ви цього навіть не помітите. Але якщо ви в дорозі з мобільного інтернету, де кожен такий пробіг займає відчутний час, сторінка починає тупити ще до того, як завантажиться перший байт.
HTTP/2: Мультиплексування на одному кабелі
У 2015 році світ побачив HTTP/2. Його розробили на базі експериментального протоколу SPDY від Google, і головним нововведенням стало мультиплексування.
Замість того, щоб відкривати шість окремих з’єднань і ганяти запити по черзі, HTTP/2 почав використовувати одне-єдине з’єднання, але навчився розбивати всі дані на крихітні бінарні фрагменти. Тепер стилі, скрипти та сотні картинок летіли одночасно по різних віртуальних потоках всередині однієї труби. Текстовий формат замінили на бінарний, а заголовки запитів почали стискати, щоб не ганяти зайву інформацію.
Здавалося б, перемогла техніка. Веб став відчутно швидшим, а проблема черг нарешті вирішена.
Ні. Її просто перенесли на рівень нижче.
Пастка HTTP/2: Коли TCP починає заважати
HTTP/2 працює поверх базового транспортного протоколу TCP, а він створений з суворою гарантією доставки. Якщо хоча б один пакет даних із десяти втрачається десь на проміжному маршрутизаторі, TCP повністю зупиняє передачу всіх інших пакетів і чекає, поки втрачений шматочок буде відправлено повторно.
Це означає, що через один втрачений пакет, який відповідав за крихітну іконку на сторінці, ваш браузер не може розпарсити важливий програмний скрипт, хоча всі пакети для цього скрипта вже давно благополучно прилетели.
Це виявилося тим самим блокуванням черги, тільки тепер на рівні транспортного мережевого протоколу. На стабільному кабельному інтернеті це непомітно. Але на нестабільному Wi-Fi або мобільному зв’язку HTTP/2 іноді працював навіть повільніше за старий HTTP/1.1.
HTTP/3 та QUIC: Революція, яка викинула TCP
Розробники Google зрозуміли остаточно: ремонтувати TCP далі немає жодного сенсу. Він надто консервативний, зашитий глибоко в ядра операційних систем, і змінювати його на рівні всієї інфраструктури планети довелося б десятиліттями.
Рішення виявилося радикальним. Викинути TCP і перейти на UDP.
UDP — це протокол взагалі без гарантій і перевірок. Він просто кидає пакети в мережу на максимальній швидкості і без зайвих розмов. A вже поверх нього створили новий транспортний протокол QUIC, який і став основою для сучасного HTTP/3.
Головна зміна полягає в тому, що тепер всередині мережі нічого не блокується. Оскільки новий протокол керує потоками даних незалежно, втрата одного пакета в одному файлі взагалі не впливає на інші. Завис один елемент — решта сторінки спокійно рендериться далі.
Крім того, рукостискання стало практично миттєвим, бо встановлення з’єднання та узгодження шифрування об’єднали в один процес. Якщо ви вже відвідували сайт раніше, ви відправляєте корисні дані при першому ж запиті з нульовою затримкою.
А ще з’явилася стійкість до зміни мережі. Старий протокол прив’язувався до вашої IP-адреси. Якщо ви виходили з дому і телефон переключався з домашнього Wi-Fi на мобільну мережу, з’єднання рвалося, сесія скидалася, а завантаження файлів доводилося починати знову. Новий протокол використовує унікальний ідентифікатор з’єднання. Ви можете змінювати мережі, IP-адреси та провайдерів прямо на ходу — завантаження навіть не спіткнеться.
Чи потрібно бігти й вмикати HTTP/3 просто зараз?
Як завжди в інженерії — залежить від обставин.
Сьогодні HTTP/3 підтримується всіма сучасними браузерами та більшістю великих мереж доставки контенту. Якщо ви використовуєте популярні хмарні сервіси, швидше за все, новий протокол у вас уже працює за замовчуванням.
Проте є й зворотний бік. Обробка безперервного потоку UDP на високих швидкостях вимагає відчутно більше ресурсів процесора на боці сервера, ніж оптимізована десятиліттями робота зі старим протоколом. Крім того, деякі корпоративні фаєрволи або занадто консервативні провайдери досі підозріло ставляться до масового UDP-трафіку і можуть його просто блокувати. У такому разі браузер безболісно відкотиться назад на попередню версію.
HTTP/3 — це не проста чергова маркетингова цифра. Це перша за двадцять років масштабна перебудова фундаментальних принципів передачі даних у мережі. І поки ми просто гортаємо стрічки новин, цей протокол непомітно економить людству тисячі років очікування.