HTTP/3 у 2026: що це, як працює та як увімкнути на Nginx

HTTP/3: коли старий протокол перестає справлятись

Користувач відкриває інтернет-магазин з мобільного у метро. Сигнал нестабільний, пакети губляться. На HTTP/2 втрата одного пакету заморожує всю сторінку — TCP чекає ретрансмісії і блокує все інше. Користувач бачить білий екран і закриває вкладку. На HTTP/3 та ж сторінка довантажиться — протокол не блокує інші ресурси через один загублений пакет. Для магазину на Magento з 70% мобільного трафіку це різниця між -12% відмов і тим же bounce rate що й раніше.

За даними досліджень, 40% користувачів покидають сайт який не завантажується за 3 секунди. Для eCommerce це пряма втрата грошей, для медіа — втрата аудиторії, для SaaS — втрата клієнтів. HTTP/3 — це не просто "нова версія старого протоколу". Це фундаментальна зміна того як дані передаються по мережі, і вона вирішує реальні проблеми які HTTP/2 виправити не міг.

Можна заперечити: "у мене і так все швидко, навіщо ще один протокол?". Справедливо — якщо ваша аудиторія це десктоп-користувачі з дротовим інтернетом у тому ж місті де ваш сервер, різниця справді невелика. Але більшість сайтів зараз обслуговують мобільну аудиторію: користувачі з нестабільним 4G, з роумінгом, з поганим Wi-Fi у кафе, з перемиканнями між мережами. Саме тут HTTP/3 дає 20-40% приросту швидкості.

Далі — що таке HTTP/3 технічно, які числа показують наші внутрішні тести, як налаштувати протокол на Nginx за 15 хвилин, і де він дає максимальний ефект.

Коротко про еволюцію HTTP

Щоб зрозуміти чим HTTP/3 краще за попередників, корисно подивитись на проблеми які вирішувала кожна версія. Кожна наступна версія не просто додавала нові функції — вона виправляла принципові обмеження попередньої.

Проблема HTTP/2 була в тому, що він побудований поверх TCP. TCP гарантує доставку пакетів у правильному порядку — і якщо один пакет загубився, всі наступні чекають. Навіть якщо браузер вже отримав дані для іншого запиту на тій самій сторінці, він не може їх обробити поки не прийде загублений пакет. Це називається "head-of-line blocking" — блокування на рівні транспорту. HTTP/2 вирішив цю проблему на рівні додатку (кілька запитів в одному з'єднанні), але TCP проблема залишилась.

Уявіть собі аналогію з автомобільною дорогою. HTTP/1.1 — це одна вузька дорога, де машини їдуть одна за одною, і якщо перша гальмує — всі гальмують. HTTP/2 додав кілька смуг на тій же дорозі — машини можуть їхати паралельно. Але якщо посередині дороги ДТП (загублений пакет TCP), усі смуги зупиняються. HTTP/3 — це окремі дороги для кожного потоку, тому ДТП на одній дорозі не впливає на рух по інших.

HTTP/3 вирішує це радикально: відмовляється від TCP на користь QUIC — нового транспортного протоколу поверх UDP. UDP не гарантує доставку на рівні транспорту, і тому QUIC може сам вирішувати як обробляти втрати пакетів — незалежно для кожного потоку.

Що таке QUIC і чому UDP замість TCP

QUIC (Quick UDP Internet Connections) — це транспортний протокол, розроблений у Google у 2012 році, стандартизований IETF у 2021. Він працює поверх UDP, але забезпечує надійну доставку даних як TCP — тільки без його недоліків.

Незалежні потоки (streams)

Головна перевага QUIC — кожен запит (наприклад, зображення, CSS, JavaScript) передається через окремий потік. Якщо пакет одного потоку загубився, інші продовжують обробку без затримки. У HTTP/2 поверх TCP це було неможливо — втрата одного пакета блокувала всі потоки одразу.

0-RTT: з'єднання без рукостискань

Класичне з'єднання HTTPS вимагає кілька раундів обміну пакетами: TCP handshake (1 RTT), потім TLS handshake (ще 1-2 RTT). На мобільному з пінгом 100 мс це вже 200-300 мс тільки на встановлення з'єднання — до того як прийшов перший байт контенту. А користувач уже дивиться на білий екран і починає нервувати.

QUIC об'єднує транспортний та криптографічний handshake в один крок. Перший раз — 1 RTT замість 3. А при повторному підключенні до того ж сервера використовує 0-RTT — перший запит відправляється одразу разом з handshake-пакетом, без жодних додаткових раундів. Це дає економію 100-300 мс на кожне нове з'єднання.

Для API-запитів з мобільного це критично. Типова мобільна сесія — це не один запит, а десятки коротких підключень (кожне відкриття екрана, кожен refresh списку). Економія 200 мс на кожному — це секунди відчутної різниці для користувача протягом однієї сесії.

Міграція з'єднань

Це фіча якої немає у HTTP/2. Коли користувач у транспорті перемикається з Wi-Fi на мобільну мережу, IP-адреса змінюється — і TCP-з'єднання обривається. Браузер мусить встановлювати нове з'єднання з нуля: заново TCP handshake, TLS handshake, повторний запит. Це 500-1000 мс простою, під час якого завантаження зупиняється.

QUIC ідентифікує з'єднання не за IP-адресою, а за connection ID — унікальним ідентифікатором, який передається у кожному QUIC-пакеті. Коли IP змінюється, сервер впізнає клієнта за connection ID і продовжує з'єднання як ні в чому не бувало. Для користувача це виглядає як безперервне завантаження — жодного розриву, жодної паузи. Особливо помітно при стрімінгу відео або великих файлів: завантаження не переривається на перемиканні між мережами.

Чому не просто виправити TCP?

Логічне питання: навіщо вигадувати новий протокол, якщо можна було б просто виправити TCP? Відповідь у двох словах — це неможливо. TCP реалізований у ядрі операційної системи і на рівні мережевого обладнання (роутерів, файрволів, middleboxes). Будь-яка зміна TCP вимагає оновлення мільярдів пристроїв по всьому світу. Це займає десятиліття.

QUIC реалізований у user-space — прямо в коді браузера та веб-сервера. Оновити Chrome чи Nginx — це тижні, а не роки. І мережеве обладнання не треба чіпати взагалі: UDP-пакети проходять через все, що пропускає інтернет-трафік, без жодних модифікацій. Саме тому Google пішов шляхом нового протоколу — це дозволило ітерувати швидко і випустити HTTP/3 у продакшн за роки, а не десятиліття.

Що показують реальні заміри

Загальні бенчмарки з інтернету — це одне, а внутрішні тести на реальному стеку — інше. Ось дані з наших замірів на стандартній конфігурації Nginx + PHP-FPM у мережі 1 Gbps:

8% прискорення TTFB на чистому з'єднанні виглядає скромно. Але handshake — це де ховається справжня різниця. На мобільній мережі з пінгом 80 мс два-три додаткових round-trip це 160-240 мс затримки ще до початку передачі контенту. QUIC прибирає ці round-trip, і перший байт приходить відчутно швидше.

А рядок "втрата пакетів 5%" — це ключ до розуміння чому HTTP/3 змінює гру саме на мобільних. 5% втрат — типова ситуація для 4G у рухомому транспорті. При HTTP/2 це катастрофа: TCP зупиняє всі потоки і чекає ретрансмісії. При QUIC потоки незалежні — загублений пакет одного зображення не блокує CSS, JavaScript та інші ресурси.

Коли HTTP/3 дає найбільший ефект

Не кожен сайт отримає ті ж 40% прискорення. Чим більше ваша аудиторія на мобільних, у поганих мережах, далеко від сервера — тим більший виграш. Перелік ситуацій де HTTP/3 реально змінює картину:

• Мобільні додатки та PWA — користувачі у транспорті, з нестабільним сигналом, з перемиканням між Wi-Fi та мобільними мережами
• Стрімінг — відео, аудіо, live-трансляції де кожна буферизація дратує і знижує час перегляду
• eCommerce з міжнародною аудиторією — високий пінг з віддалених регіонів, де 0-RTT особливо помітний
• Real-time застосунки — чати, нотифікації, колаборативні інструменти, онлайн-ігри
• API з мобільних клієнтів — 0-RTT економить помітний час на кожному запиті, а мобільний додаток робить десятки запитів за сесію
• Сайти з великою кількістю ресурсів — багато зображень, скриптів, CSS-файлів (мультиплексування без head-of-line blocking)

Коли різниця непомітна

Невеликий блог на WordPress з аудиторією з одного регіону, яка заходить переважно з десктопу — HTTP/3 дасть 2-5% прискорення у кращому випадку. Не поганий результат, але й не той WOW-ефект про який пишуть заголовки. Для таких проєктів HTTP/3 — це бонус, а не пріоритет.

HTTP/3 + CDN: синергія

Окремо варто згадати комбінацію HTTP/3 з CDN. Коли ви використовуєте CDN (Cloudflare, Fastly, BunnyCDN тощо), користувач підключається не до вашого origin-сервера, а до найближчого edge-вузла CDN. Пінг стає мінімальним — 10-20 мс замість 150-200 мс до далекого серверу. HTTP/3 поверх такого з'єднання дає ще більший ефект: 0-RTT handshake плюс короткий фізичний шлях плюс стійкість до втрат — все разом дає справді швидкі сайти навіть з найгірших мережевих умов.

Більшість сучасних CDN увімкнули HTTP/3 за замовчуванням. Cloudflare зробив це одним з перших — ще у 2019 році, задовго до офіційного стандарту. Fastly, Akamai, BunnyCDN, KeyCDN — усі підтримують HTTP/3 для edge-трафіку без будь-яких додаткових налаштувань з вашого боку. Ви просто вмикаєте CDN — і ваші користувачі автоматично отримують HTTP/3 там, де він працює.

Безпека: TLS 1.3 як обов'язкова вимога

HTTP/3 не існує без шифрування. На відміну від HTTP/2, де TLS був опціональним (хоча й використовувався майже завжди), HTTP/3 вимагає TLS 1.3 обов'язково. Це не опція — це частина специфікації QUIC. Не можна зробити "незашифрований HTTP/3" — протокол просто не передбачає такої конфігурації.

Це спрощує життя адміністраторам і підвищує загальний рівень безпеки інтернету. Більше не треба перевіряти "а чи увімкнутий TLS на цьому домені" — якщо HTTP/3 працює, значить TLS 1.3 працює. Якщо TLS не налаштований — HTTP/3 взагалі не запуститься.

Що це дає на практиці:

• Швидше handshake — TLS 1.3 замінив 2-RTT handshake з TLS 1.2 на 1-RTT (або 0-RTT при повторному з'єднанні)
• Сучасні cipher suites — TLS 1.3 викинув застарілі та вразливі алгоритми (RC4, SHA-1, MD5, статичний RSA)
• Захист від downgrade-атак — браузер не може бути примушений використовувати старіший протокол
• Шифрування метаданих — QUIC шифрує більше полів заголовків ніж TLS over TCP, ускладнюючи аналіз трафіку

Як увімкнути HTTP/3 на Nginx

На наших VPS за замовчуванням стоять останні стабільні версії Nginx — 1.24+ або 1.26+. Починаючи з 1.25.x, Nginx має офіційну підтримку QUIC через модуль ngx_http_v3_module.

HTTP/3 не активований за замовчуванням — і на це є причини. Протокол вимагає обов'язкового TLS 1.3 з OpenSSL 3.0+ (або BoringSSL), а для активації потрібно додати заголовок Alt-Svc, щоб браузер побачив можливість переходу на UDP. Без цього заголовка браузер навіть не спробує HTTP/3 — він просто не знає що сервер його підтримує.

Ось конфіг який додає HTTP/3 до існуючого HTTPS-сервера:

server {
    # HTTP/2 — залишається як fallback
    listen 443 ssl;
    http2 on;
    # HTTP/3 (QUIC) — новий протокол
    listen 443 quic reuseport;
    http3 on;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # TLS 1.3 обов'язковий для HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    # Заголовок Alt-Svc повідомляє браузер що доступний HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    # ... решта конфігу (root, location тощо)
}

Технічна вимога яку часто пропускають: для QUIC потрібен OpenSSL 3.0+ або BoringSSL. На Ubuntu 22.04+ та Debian 12+ це стоїть за замовчуванням. На старіших системах — ні, і Nginx просто проігнорує директиву listen 443 quic без помилки у логах. Перевірте: openssl version — якщо бачите 1.x, потрібне оновлення ОС або ручна збірка Nginx з BoringSSL.

Ключовий момент — директива listen 443 quic та заголовок Alt-Svc. Браузер спершу з'єднується по HTTP/2, бачить заголовок Alt-Svc, і при наступних запитах пробує HTTP/3. Якщо HTTP/3 працює — всі подальші запити йдуть через нього. Якщо ні — залишається HTTP/2. Це називається "happy eyeballs" — браузер сам обирає найкращий варіант.

Значення ma=86400 у заголовку Alt-Svc означає "max age" — скільки секунд браузеру пам'ятати, що цей сервер підтримує HTTP/3. 86400 секунд = 24 години. Тобто після першого відвідування, наступна доба браузер одразу пробує HTTP/3 без попереднього HTTP/2-запиту. Після цього — повторна перевірка. Для сайтів з частими відвідуваннями це працює практично непомітно.

Відкрийте UDP 443 у firewall

Найчастіша причина чому HTTP/3 не злітає після налаштування конфігу — закритий порт. На наших серверах стоїть UFW або iptables/nftables залежно від ОС. За замовчуванням UDP 443 закритий — QUIC працює виключно через UDP, і його потрібно відкрити явно:

sudo ufw allow 443/tcp    # HTTPS (HTTP/2 fallback)
sudo ufw allow 443/udp    # QUIC (HTTP/3)

На хмарних провайдерах (AWS, GCP, DigitalOcean, Hetzner) UDP 443 теж потрібно відкрити окремим правилом у security groups або VPC Firewall Rules.

Як перевірити що HTTP/3 справді працює

Після налаштування обов'язково перевірте що все працює. Увімкнення в конфігу не гарантує що протокол реально використовується — можуть бути проблеми з firewall, версією Nginx, або TLS-налаштуваннями.

Через curl

Найшвидший спосіб з командного рядка (потрібен curl з підтримкою HTTP/3):

curl --http3 -I https://example.com

У відповіді має бути HTTP/3 200. Якщо бачите HTTP/2 — HTTP/3 не працює, хоча заголовок Alt-Svc може бути присутній.

Через браузер

У Chrome або Firefox відкрийте Developer Tools → вкладка Network → завантажте сторінку. У колонці Protocol повинно бути h3 для запитів до вашого домену. Якщо колонки Protocol не видно — клікніть правою кнопкою на заголовку колонок і увімкніть її.

Важливий нюанс: перший запит до домену зазвичай йде через HTTP/2. Браузер отримує Alt-Svc і пробує HTTP/3 для наступних запитів. Тому перезавантажте сторінку (Ctrl+F5) — і тоді побачите h3. Якщо після перезавантаження все одно HTTP/2 — перевірте в консолі браузера чи немає помилок QUIC, та перевірте чи справді заголовок Alt-Svc приходить від сервера (у вкладці Headers → Response Headers).

Онлайн-сервіси

Є безкоштовні сервіси для швидкої перевірки: http3check.net, https.hardenize.com, ssllabs.com/ssltest. Вони перевіряють не тільки факт підтримки HTTP/3, але й конфігурацію TLS, наявність Alt-Svc, та інші параметри.

Типові проблеми та рішення

Більшість проблем з HTTP/3 пов'язані не з самим протоколом, а з інфраструктурою навколо нього — файрволами, застарілими версіями софту, неправильно налаштованими хмарними security groups. Ось найчастіші сценарії які ми бачимо у клієнтів Hostiserver, та способи їх виправлення.

Остання ситуація важлива — деякі корпоративні мережі та старі роутери досі блокують або throttlять UDP-трафік. Це не ваша проблема — браузер автоматично відкотиться на HTTP/2 і сайт працюватиме як раніше. Головне що для більшості користувачів HTTP/3 працюватиме і дасть приріст швидкості.

Адопція HTTP/3 у 2026 році

HTTP/3 у 2026 — вже не експеримент. Це стандарт, який підтримують всі основні гравці:

• Браузери: Chrome, Firefox, Edge, Safari, Opera — усі підтримують HTTP/3 за замовчуванням з 2022-2023 років
• Веб-сервери: Nginx (з 1.25), LiteSpeed (нативно), Caddy (з коробки), Cloudflare (глобально), HAProxy (з 2.6)
• CDN: Cloudflare, Fastly, Akamai, BunnyCDN — усі основні CDN підтримують HTTP/3 для edge-з'єднань
• Мобільні OS: iOS, Android використовують HTTP/3 у нативних мережевих бібліотеках

За даними W3Techs, станом на початок 2026 року HTTP/3 використовує близько 30% з Топ-10 мільйонів сайтів. Для порівняння: HTTP/2 використовує близько 80% — більшість ще не перейшла, але активно рухається в цьому напрямку. Apache HTTP Server досі не має production-ready HTTP/3 — це одна з причин чому багато WordPress-сайтів на Apache залишаються на HTTP/2.

Цікава статистика: серед сайтів з Топ-1000 за трафіком — адопція HTTP/3 уже понад 50%. Тобто великі гравці (Google, Facebook, Netflix, Cloudflare, Amazon) давно на HTTP/3. Адопція нерівномірна — що більший сайт, то більше інвестує в оптимізацію швидкості, то швидше переходить на новий протокол. Малий та середній бізнес зазвичай наслідує з запізненням 2-3 роки.

Окрема категорія — мобільні API та backend-сервіси для смартфон-додатків. Там адопція HTTP/3 ще вища — практично всі великі мобільні застосунки вже використовують HTTP/3 для зв'язку зі своїми серверами. Причина зрозуміла: мобільний трафік — саме той сегмент де HTTP/3 дає найбільший приріст.

Часті питання