HTTP/3 – третя основна версія протоколу HTTP, стандартизована Інженерною радою інтернету у червні 2022 року як RFC 9114. На відміну від HTTP/1.1 і HTTP/2, він працює не поверх TCP, а поверх QUIC, транспортного протоколу на базі UDP із вбудованим шифруванням TLS 1.3.
Станом на липень 2026 року частка HTTP/3 у фактичних вебзапитах вперше опустилася нижче 20 відсотків: 19,84% за даними аналітики Cloudflare Radar. Водночас частка сайтів, що заявляють підтримку протоколу через заголовок alt-svc чи DNS-записи HTTPS, за квітень 2026 становить 38,8% за оцінкою W3Techs. Різниця у 18,96 відсоткового пункту пояснюється не помилкою вимірювання. Обидва показники рахують різні речі: перший рахує сайти, які повідомляють про підтримку, другий рахує реальні браузерні з’єднання. Розбір різниці нижче.
Як влаштований QUIC і чим він відрізняється від TCP
HTTP/1.1 і HTTP/2 передають дані через TCP, де встановлення з’єднання займає окремий раунд для рукостискання TCP і ще один чи два для TLS. QUIC об’єднує транспортне і криптографічне рукостискання в один раунд, а для клієнтів, що вже підключалися раніше, підтримує відновлення сесії за нуль додаткових раундів. Головна структурна відмінність від TCP полягає в тому, що блокування черги вирішується на рівні транспорту. Втрата одного пакета в одному потоці QUIC не зупиняє інші потоки того самого з’єднання, як це відбувається в TCP. QUIC ідентифікує з’єднання за унікальним ідентифікатором, а не за парою IP-адреса і порт. Тому воно переживає зміну мережі, наприклад перехід з Wi-Fi на мобільний інтернет, без повторного рукостискання.
Стиснення заголовків у HTTP/3 працює через QPACK. HTTP/2 натомість використовує HPACK, який покладається на суворий порядок пакетів: якщо один заголовок губиться, декодер зупиняється, поки пакет не прийде повторно. Це відтворює те саме блокування черги, від якого QUIC мав позбавити протокол. QPACK виносить динамічний словник заголовків в окремий потік і дозволяє декодувати заголовки, що вже прийшли, навіть коли частина попередніх ще в дорозі. Плата за це, помітно складніша реалізація на сервері і в клієнті. Тому перші версії багатьох HTTP-бібліотек підтримували транспорт QUIC раніше, ніж повноцінний QPACK. У проміжний період деякі з’єднання через це працювали повільніше очікуваного.
Скільки сайтів насправді використовують HTTP/3
Три джерела вимірюють три різні речі. Жодне з них не помиляється, кожне описує свій зріз.
| Джерело | Що рахує | Показник | Дата |
|---|---|---|---|
| W3Techs | сайти, що заявляють підтримку через alt-svc або DNS HTTPS | 38,8% сайтів | квітень 2026 |
| HTTP Archive Web Almanac | чисті переходи браузером без кешу, лише перше з’єднання | приблизно 7-9% запитів напряму по HTTP/3 | видання 2024 року |
| Cloudflare Radar | усі запити через мережу Cloudflare, включно з ботами і серверним трафіком | 19,84% запитів | липень 2026 |
Розрахунок за наведеними цифрами: рік до року, з липня 2025 по липень 2026, частка HTTP/3 у запитах Cloudflare Radar впала з 21,64% до 19,84%. Це приблизно 8,3% відносно попереднього рівня і перше падіння нижче позначки 20% за весь час публікації цих даних. Розрив між заявленою підтримкою і фактичним використанням існує тому, що alt-svc вимагає попереднього виявлення. Браузер дізнається про підтримку HTTP/3 лише після першого підключення по HTTP/2. Значна частина першого візиту на сайт так і не переходить на новий протокол.
Чому частка HTTP/3 впала саме у 2026 році
Пояснення підтверджене доповіддю Чжана та співавторів на конференції ACM Web Conference 2024. На швидкості 1 Гбіт/с у Chrome QUIC передає до 45,2% менше даних, ніж HTTP/2, а поріг, де HTTP/2 випереджає HTTP/3, знаходиться в діапазоні 500-600 Мбіт/с. Причина в двох інженерних деталях, а не в бездіяльності адміністраторів серверів. У ядрі Linux для TCP існує функція групового отримання пакетів, яка об’єднує вхідні пакети перед тим, як їх побачить застосунок. Для QUIC на момент дослідження ця функція не була розгорнута повсюдно, тому кожен UDP-датаграм оброблявся окремо. При передачі тестового файлу QUIC у Chrome генерував близько 744 тисяч читань пакетів проти приблизно 58 тисяч у TCP.
Друга причина стосується підтверджень отримання пакетів. У TCP вони формуються в ядрі системи з умонтованою логікою затримки. У QUIC ті самі підтвердження формуються в просторі користувача. На тому самому тестовому передаванні це забирає близько трьох секунд процесорного часу проти незначної частки секунди в TCP. Обидві проблеми інженерно вирішувані, але станом на початок 2026 року виправлення розгорнуті не повсюдно.
Звідси випливає практичний висновок, який спростовує поширене уявлення, що новіший протокол автоматично швидший за старий. HTTP/3 виграє там, де мережа повільна або втрачає пакети: мобільний зв’язок, ринки, що розвиваються, з’єднання з високою затримкою. Італія (28,07% запитів у липні 2026), Індія (27,92%) і Бразилія (26,64%) очолюють список саме тому, що це мобільні ринки із середньою пропускною здатністю нижче порогового значення. HTTP/3 програє там, де мережа швидка і стабільна. На швидкому дротовому широкосмуговому зв’язку в розвинених країнах HTTP/2 через фізику обробки пакетів часто виявляється не повільнішим, а іноді й швидшим.
Окремий випадок, який плутають із занепадом якості мереж, це так званий парадокс дата-центрів. Сінгапур і Нідерланди мають одні з найвищих часток HTTP/1.x у світі (55,56% і 54,45% відповідно в липні 2026 року), хоча обидві країни мають сучасну інфраструктуру. Пояснення в тому, що через ці країни проходить величезний обсяг серверного і ботового трафіку. Це не трафік звичайних сайтів. Перевірка через частку TLS 1.3 (83,94% у Сінгапурі, одна з найвищих у світі) показує, що інфраструктура сучасна. Клієнти, які роблять ці запити, це здебільшого старі бібліотеки автоматизації. Браузери людей серед них радше виняток.
Підтримка в браузерах
| Браузер | Версія з повною підтримкою за замовчуванням |
|---|---|
| Chrome і Chrome для Android | 87 і новіші |
| Edge | 87 і новіші |
| Firefox | 88 і новіші (104 для Android) |
| Opera і Opera Mobile | 74 і новіші (80 для мобільної версії) |
| Safari (macOS, iOS, iPadOS) | 16 і новіші |
| Samsung Internet | 14 і новіші |
| Internet Explorer | підтримка не додавалася ніколи |
Safari довше за інших залишався винятком: до версії 16 підтримка існувала лише як експериментальна функція, яку користувач мав вмикати вручну в налаштуваннях розробника. Це затримало практичне охоплення HTTP/3 на iOS приблизно на два роки порівняно з Chrome і Firefox.
Як увімкнути HTTP/3 на власному сервері
Nginx підтримує HTTP/3 нативно починаючи з версії 1.25.0, без патчів і збірки зі сторонніх модулів, які були потрібні раніше. Мінімальна конфігурація для домену з уже налаштованим TLS-сертифікатом:
listen 443 quic reuseport;
listen 443 ssl;
http2 on;
http3 on;
quic_gso on;
ssl_protocols TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400';
LiteSpeed підтримує QUIC і HTTP/3 без додаткових модулів починаючи з версій, орієнтованих на цей стандарт. Перед увімкненням потрібно відкрити порт UDP/443 у фаєрволі: правило лише для TCP/443, яке лишилося з часів HTTP/2, HTTP/3 просто не запустить. Частина українських хостинг-провайдерів надає HTTP/3 за замовчуванням через власні CDN або збірки Nginx, частина ще ні. Конкретну підтримку варто перевіряти в документації провайдера. Назва тарифного плану про це нічого не каже.
Обмеження, які варто врахувати
Деякі корпоративні мережі та мобільні оператори блокують або обмежують трафік по UDP на порту 443. У такому разі браузер автоматично повертається до HTTP/2 без помилки для користувача, тому HTTP/3 не можна вважати єдиною точкою відмови сайту.
Виграш у швидкості помітний насамперед на мобільних і нестабільних з’єднаннях. На швидкому фіксованому широкосмуговому зв’язку різниця з HTTP/2 часто не відчувається або йде не на користь HTTP/3, як показано вище.
Прискорення 0-RTT має зворотний бік. Перший пакет даних у такому з’єднанні можна перехопити і повторно надіслати на сервер, а сервер не завжди здатен відрізнити повторне надсилання від нового запиту від того самого клієнта. Специфікація QUIC тому обмежує застосування 0-RTT ідемпотентними запитами на кшталт GET і виключає з нього операції, що змінюють стан, наприклад оплату чи зміну пароля. Сервер, який приймає через 0-RTT будь-які запити без цього обмеження, залишає відкритою можливість атаки повторного відтворення. Це причина, чому увімкнення HTTP/3 вимагає перевірки конфігурації, а встановлення самого пакета цю перевірку не замінює.
HTTP/3 не замінює HTTP/2 повністю. Більшість сучасних серверів і CDN пропонують обидва протоколи одночасно, а клієнт сам обирає найкращий спільний варіант під час встановлення з’єднання.