HTTP/2 проти HTTP/3: еволюція протоколу
HTTP/2 та HTTP/3 — це сучасні версії протоколу HTTP, які вирішують проблеми продуктивності HTTP/1.1. Розуміння їхніх відмінностей є критично важливим для оптимізації завантаження веб-додатків.
HTTP/1.1 → HTTP/2 → HTTP/3
6 з'єднань на домен
Мультиплексування 1 з'єднання
QUIC/UDP Без блокування HOL
HTTP/1.1 1997
HTTP/2 2015
HTTP/3 2022
Майбутнє
Проблеми HTTP/1.1
Блокування на початку рядка
Client → Server
Request 1: style.css (50KB, завантажується повільно)
Request 2: app.js (10KB, швидко, але ЧЕКАЄ!)
Request 3: image.png (30KB, також чекає...)Обмеження з'єднань
Браузер відкриває максимум 6 з'єднань на домен:
Connection 1: style.css
Connection 2: app.js
Connection 3: image1.jpg
Connection 4: image2.jpg
Connection 5: image3.jpg
Connection 6: font.woff
Request 7-100: ЧЕКАЄ!Надмірність заголовків
GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0...
Accept: application/json
Cookie: session=abc123...
...
(~500-800 байтів заголовків щоразу!)HTTP/2 - Вирішення проблем
Мультиплексування
Одне TCP з'єднання для всіх запитів:
ServerClientServerClientУсе паралельно в одному з'єднанні!Stream 1: style.cssStream 2: app.jsStream 3: image.pngStream 2: app.js (швидко!)Stream 3: image.pngStream 1: style.css (повільно)
TCP Connection (ОДНЕ)
├── Stream 1: style.css (frames: 1,2,3...)
├── Stream 2: app.js (frames: 1,2,3...)
└── Stream 3: image.png (frames: 1,2,3...)Стиснення заголовків (HPACK)
Request 1:
:method: GET
:path: /api/users
:authority: example.com
cookie: session=abc123
Request 2:
:method: GET
:path: /api/posts
:authority: example.com
cookie: session=abc123
↑
(стиснуто! вже надіслано)Економія: ~80-90% розміру заголовків!
Серверний пуш
<!-- Клієнт запитує index.html -->
GET /index.html
<!-- Сервер пушить style.css ДО запиту! -->
PUSH_PROMISE: /style.css
PUSH_PROMISE: /app.jsПріоритезація потоків
Stream Priority:
style.css (вага: 256, критично)
app.js (вага: 256, критично)
image1.jpg (вага: 16, низький пріоритет)
image2.jpg (вага: 16, низький пріоритет)Проблема HTTP/2: Блокування на початку рядка TCP
HTTP/2 мультиплексує потоки, але TCP все ще лінійний:
TCP Втрата пакета:
Packet 1: Stream 1, 2, 3
Packet 2: ВТРАТА! (блокує!)
Packet 3: ЧЕКАЄ (доступний, але не може бути оброблений)
Packet 4: ЧЕКАЄ
// Усі потоки чекають на Packet 2!TCP гарантує порядок → якщо пакет втрачається, всі потоки блокуються.
HTTP/3 - QUIC вирішує проблему
QUIC = Швидкі UDP Інтернет З'єднання
Ключова відмінність: HTTP/3 використовує UDP замість TCP!
HTTP/2
HTTP/3
TCP рівень Блокування HOL
TLS 1.3
QUIC рівень UDP + вбудований TLS
Переваги QUIC
Незалежні потоки
QUIC (UDP):
Packet 1: Stream 1, 2, 3
Packet 2: ВТРАТА! (тільки Stream 2 заблоковано)
Packet 3: Stream 1, 3 продовжують!
Packet 4: Stream 1, 3 працюють!
// Тільки Stream 2 чекає, інші продовжують!0-RTT встановлення з'єднання
TCP + TLS 1.3:
Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK + ClientHello
Server → Client: ServerHello + Сертифікат
Client → Server: Завершено
// 2-3 RTT перед першим даними!QUIC:
Client → Server: Початковий пакет + TLS ClientHello + HTTP запит
Server → Client: Відповідь!
// 1 RTT! (0-RTT при повторному з'єднанні)Міграція з'єднання
// Користувач переключився з WiFi на 4G
// HTTP/2 (TCP): нове з'єднання
// HTTP/3 (QUIC): продовжує те ж з'єднання!
// QUIC використовує ID з'єднання замість IP+Port
Connection ID: abc123
WiFi: 192.168.1.5:443 → З'єднання: abc123
4G: 10.0.0.15:443 → З'єднання: abc123 (те ж саме!)Вбудоване шифрування
QUIC: TLS 1.3 вбудовано в протокол → завжди зашифровано!
Таблиця порівняння
| Характеристика | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Транспорт | TCP | TCP | QUIC/UDP |
| З'єднання на домен | 6 | 1 | 1 |
| Мультиплексування | Ні | Так | Так |
| Блокування HOL | Повне | Рівень TCP | Ні |
| Стиснення заголовків | Ні | HPACK | QPACK |
| Серверний пуш | Ні | Так | Так |
| 0-RTT | Ні | Ні | Так |
| Міграція з'єднання | Ні | Ні | Так |
| Шифрування | Додаткове | Додаткове | Обов'язкове |
Продуктивність у реальному світі
Ідеальні умови (низька втрата пакетів)
HTTP/1.1: 5.0s
HTTP/2: 2.5s (в 2 рази швидше)
HTTP/3: 2.3s (трохи швидше за HTTP/2)1% втрата пакетів
HTTP/1.1: 6.0s
HTTP/2: 4.5s (блокування HOL TCP!)
HTTP/3: 2.8s (без блокування HOL!)3% втрата пакетів (погана мобільна мережа)
HTTP/1.1: 10.0s
HTTP/2: 8.5s
HTTP/3: 3.5s (в 2.4 рази швидше за HTTP/2!)Прийняття
Браузери:
- Chrome/Edge: 100%
- Firefox: 100%
- Safari: 100%
- Opera: 100%
CDN:
- Cloudflare: 100%
- Fastly: 100%
- Google Cloud CDN: 100%
- AWS CloudFront: 100%
Перевірка:
# Chrome DevTools → Network → Protocol
# Шукайте "h3" або "http/3"Найкращі практики для розробників
Використовуйте CDN, сумісний з HTTP/3
Cloudflare, Fastly, AWS CloudFront автоматично використовують HTTP/3.2
Не використовуйте шардінг доменів
HTTP/2/3 не потребують кількох доменів. Один домен є більш ефективним.
Оптимізуйте для мобільних мереж
HTTP/3 особливо ефективний при високій втраті пакетів (3G/4G)
Серверний пуш з обережністю
Може призвести до надмірного пушу. Використовуйте 103 Early Hints замість Push.
Резюме:
HTTP/3 + QUIC вирішують фундаментальну проблему блокування на початку рядка TCP, забезпечуючи кращу продуктивність, особливо в нестабільних мережах. 0-RTT та міграція з'єднання роблять HTTP/3 ідеальним для мобільних додатків.
Зміст
HTTP/1.1 → HTTP/2 → HTTP/3Проблеми HTTP/1.1Блокування на початку рядкаОбмеження з'єднаньНадмірність заголовківHTTP/2 - Вирішення проблемМультиплексуванняСтиснення заголовків (HPACK)Серверний пушПріоритезація потоківПроблема HTTP/2: Блокування на початку рядка TCPHTTP/3 - QUIC вирішує проблемуQUIC = Швидкі UDP Інтернет З'єднанняПереваги QUICНезалежні потоки0-RTT встановлення з'єднанняМіграція з'єднанняВбудоване шифруванняТаблиця порівнянняПродуктивність у реальному світіІдеальні умови (низька втрата пакетів)1% втрата пакетів3% втрата пакетів (погана мобільна мережа)ПрийняттяНайкращі практики для розробниківСхожі статті
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.