Протокол передачі гіпертексту (HTTP) є наріжним каменем Інтернету, який допомагає завантажувати веб-сторінки, транслювати відео та отримувати дані для ваших улюблених програм.
Минулого року була стандартизована нова версія протоколу, HTTP/3, організацією Internet Engineering Task Force (IETF), яка відповідає за визначення інтернет-технологій. Відтоді HTTP/3 і пов'язаний з ним протокол QUIC стали швидко поширюватися у всесвітній павутині. Точні цифри залежать від джерела та методології вимірювання, але HTTP/3 підтримують від 19% до 50+% веб-серверів та мереж по всьому світу.
Оскільки ці нові протоколи активно використовуються великими компаніями, такими як Google і Meta, можна з упевненістю сказати, що велика частина поточного інтернет-трафіку вже сьогодні використовує HTTP/3.
У цій статті я розповім про те, які проблеми вирішує HTTP/3, як він працює, чому його так швидко прийняли, і які обмеження він все ще намагається подолати.
Навіщо потрібен HTTP/3?
Мережевий протокол описує, як відбувається обмін даними між двома пристроями в мережі, як правило, пристроєм користувача і веб-сервером. Оскільки багато різних компаній створюють програмне забезпечення для Інтернету, протокол має бути стандартизованим, щоб усе це програмне забезпечення було "сумісним", тобто могло розуміти одне одного, оскільки воно працює за однаковими правилами.
На практиці ми використовуємо не один протокол, а комбінацію декількох одночасно, кожен з яких має свої обов'язки та правила (рис. 1). Це робиться для того, щоб зробити речі гнучкими та придатними для багаторазового використання - ви все одно можете використовувати ту саму логіку HTTP, незалежно від того, чи використовуєте ви Wi-Fi, кабель або 4G/5G.
Рисунок 1 - Стек протоколів для HTTP/2 і HTTP/3, що показує, як кілька протоколів об'єднуються для забезпечення повної функціональності Інтернету.
Багато первинних протоколів для Інтернету були стандартизовані у 80-х і 90-х роках, а це означає, що вони були створені з урахуванням цілей і обмежень тих десятиліть. Хоча деякі з цих протоколів витримали випробування часом, інші вже почали давати про себе знати. Більшість проблем було вирішено за допомогою обхідних шляхів і хитрих трюків. Однак було зрозуміло, що щось потрібно змінювати. Особливо це стосується протоколу управління транспортом (TCP), який забезпечує надійну передачу ваших даних через Інтернет.
Чому TCP не є оптимальним для сучасного Інтернету
HTTP/1.1 і HTTP/2 покладаються на TCP для успішної роботи. Перш ніж клієнт і сервер зможуть обмінятися HTTP-запитом/відповіддю, вони повинні встановити TCP-з'єднання.
З часом було докладено багато зусиль, щоб оновити TCP і усунути деякі його недоліки - TCP все ще завантажує веб-сторінки так, ніби вони є окремими файлами, а не колекцією з сотень окремих файлів. Деякі з цих оновлень були успішними, але більшість з найбільш впливових (наприклад, TCP multipath і TCP Fast Open) зайняли майже десятиліття, щоб стати практично придатними для використання в загальнодоступному Інтернеті.
Основною проблемою при впровадженні змін до TCP є те, що тисячі пристроїв в Інтернеті мають власну реалізацію протоколу TCP. До них відносяться телефони, ноутбуки та сервери, а також маршрутизатори, фаєрволи, балансувальники навантаження та інші типи проміжних пристроїв. Таким чином, якщо ми хочемо оновити TCP, нам доведеться почекати, поки значна частина всіх цих пристроїв оновить свою реалізацію, що на практиці може зайняти роки.
Рішення QUIC
Ця проблема стала настільки серйозною, що найбільш практичним рішенням було замінити TCP чимось абсолютно новим. Цією заміною став протокол QUIC, хоча багато хто все ще (жартома) називає його TCP 2.0. Це прізвисько є доречним, оскільки QUIC включає багато з тих самих високорівневих функцій TCP, але з кількома важливими змінами.
Основна зміна полягає в тому, що QUIC тісно інтегрується з протоколом безпеки транспортного рівня (TLS). TLS відповідає за шифрування конфіденційних даних в Інтернеті - це те, що забезпечує S (secure) в HTTPS. У випадку з TCP, TLS шифрує лише власне HTTP-дані (Рисунок 2). У випадку з QUIC, TLS також шифрує значну частину самого протоколу QUIC. Це означає, що метадані, такі як номери пакетів і сигнали закриття з'єднання, які в TCP були видимі (і могли змінюватися) усіма проміжними блоками, тепер доступні тільки клієнту і серверу в QUIC.
Рисунок 2 - Відмінності в шифруванні між TCP+TLS і QUIC. QUIC шифрує набагато більше, ніж просто дані HTTP.
Крім того, оскільки QUIC шифрується ширше, змінити його або додати нові функції буде набагато простіше, ніж TCP - нам потрібно буде лише оновити клієнти та сервери, оскільки проміжні блоки все одно не можуть розшифрувати метадані. Це робить QUIC перспективним протоколом, який дозволить нам швидше вирішувати нові завдання.
Звичайно, це додаткове шифрування також добре для загальної безпеки та конфіденційності нового протоколу. Хоча TCP + TLS ідеально підходять для захисту конфіденційних персональних даних, таких як кредитні картки або вміст електронної пошти, вони все ще можуть бути вразливими до складних атак на конфіденційність, які стають все більш практичними у виконанні завдяки останнім досягненням в області штучного інтелекту. Завдяки додатковому шифруванню цього типу метаданих QUIC є більш стійким до складних атак зловмисників.
QUIC також має багато інших функцій, пов'язаних з безпекою, включаючи захист від розподілених атак на відмову в обслуговуванні (DDoS), з такими функціями, як запобігання ампліфікації та RETRY-пакети.
Нарешті, QUIC також містить велику кількість покращень ефективності та продуктивності порівняно з TCP, включаючи швидке встановлення з'єднання (див. Рисунок 3), усунення проблеми "блокування головної лінії", краще виявлення/відновлення втрачених пакетів та способи роботи з користувачами, які перемикаються з однієї мережі на іншу.
Рисунок 3 - QUIC швидше встановлює з'єднання, оскільки поєднує "транспортне" тристороннє рукостискання з криптографічним встановленням сеансу TLS, що в TCP+TLS є двома окремими процесами.
Нам не потрібен був HTTP/3, нам потрібен був QUIC
Спочатку були спроби зберегти HTTP/2 і внести в нього мінімальні зміни, щоб ми могли використовувати QUIC на нижніх рівнях (зрештою, в цьому і полягає весь сенс наявності цих протоколів, що взаємодіють і можуть використовуватися повторно). Однак, стало зрозуміло, що QUIC досить сильно відрізняється від TCP, що робить його несумісним з HTTP/2. Таким чином, було прийнято рішення створити нову версію HTTP спеціально для QUIC, яка зрештою стала HTTP/3.
HTTP/3 майже ідентичний HTTP/2. Вони в основному відрізняються технічною реалізацією функцій над QUIC або TCP. Однак, оскільки HTTP/3 може використовувати всі нові функції QUIC, очікується, що він буде продуктивнішим при завантаженні веб-сторінок і потокового відео. На практиці саме цей аспект призвів до швидкого впровадження HTTP/3.
Коментарі (1)