Skip to main content
Практика завдань

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: ЧЕКАЄ!

Надмірність заголовків

http
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% розміру заголовків!

Серверний пуш

html
<!-- Клієнт запитує 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 при повторному з'єднанні)

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

javascript
// Користувач переключився з 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.1HTTP/2HTTP/3
ТранспортTCPTCPQUIC/UDP
З'єднання на домен611
МультиплексуванняНіТакТак
Блокування HOLПовнеРівень TCPНі
Стиснення заголовківНіHPACKQPACK
Серверний пушНіТакТак
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%

Перевірка:

bash
# 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% втрата пакетів (погана мобільна мережа)ПрийняттяНайкращі практики для розробниківСхожі статті

Коротка відповідь

Для співбесіди
Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Дочитали статтю?
Практика завдань