Загрузка...
Загрузка...
HTTP/2 и HTTP/3 — современные версии протокола HTTP, решающие проблемы производительности 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 bytes заголовков каждый раз!)
Один TCP connection для всех запросов:
TCP Connection (ONE)
├── Stream 1: style.css (frames: 1,2,3...)
├── Stream 2: app.js (frames: 1,2,3...)
└── Stream 3: image.png (frames: 1,2,3...)
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% размера заголовков!
<!-- Client запрашивает index.html -->
GET /index.html
<!-- Server push'ит style.css ДО запроса! -->
PUSH_PROMISE: /style.css
PUSH_PROMISE: /app.js
Stream Priority:
style.css (weight: 256, critical)
app.js (weight: 256, critical)
image1.jpg (weight: 16, low priority)
image2.jpg (weight: 16, low priority)
HTTP/2 мультиплексирует streams, но TCP всё ещё линейный:
TCP Packet Loss:
Packet 1: Stream 1, 2, 3
Packet 2: LOST! (блокирует!)
Packet 3: WAITING (есть, но не может быть обработан)
Packet 4: WAITING
// Все streams ждут Packet 2!
TCP гарантирует порядок → если пакет потерян, все streams блокируются.
Ключевое отличие: HTTP/3 использует UDP вместо TCP!
QUIC (UDP):
Packet 1: Stream 1, 2, 3
Packet 2: LOST! (только Stream 2 блокируется)
Packet 3: Stream 1, 3 продолжают!
Packet 4: Stream 1, 3 работают!
// Только Stream 2 ждёт, остальные продолжают!
TCP + TLS 1.3:
Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK + ClientHello
Server → Client: ServerHello + Certificate
Client → Server: Finished
// 2-3 RTT до первых данных!
QUIC:
Client → Server: Initial Packet + TLS ClientHello + HTTP Request
Server → Client: Response!
// 1 RTT! (0-RTT при повторном подключении)
// Пользователь переключился с WiFi на 4G
// HTTP/2 (TCP): новое соединение
// HTTP/3 (QUIC): продолжает то же соединение!
// QUIC использует Connection ID вместо IP+Port
Connection ID: abc123
WiFi: 192.168.1.5:443 → Connection: abc123
4G: 10.0.0.15:443 → Connection: abc123 (тот же!)
QUIC: TLS 1.3 встроен в протокол → всегда зашифрован!
| Характеристика | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Транспорт | TCP | TCP | QUIC/UDP |
| Connections per domain | 6 | 1 | 1 |
| Multiplexing | Нет | Да | Да |
| HOL Blocking | Полное | TCP level | Нет |
| Header Compression | Нет | HPACK | QPACK |
| Server Push | Нет | Да | Да |
| 0-RTT | Нет | Нет | Да |
| Connection Migration | Нет | Нет | Да |
| Encryption | Optional | Optional | Обязательно |
HTTP/1.1: 5.0s
HTTP/2: 2.5s (2x быстрее)
HTTP/3: 2.3s (немного быстрее HTTP/2)
HTTP/1.1: 6.0s
HTTP/2: 4.5s (TCP HOL blocking!)
HTTP/3: 2.8s (нет HOL blocking!)
HTTP/1.1: 10.0s
HTTP/2: 8.5s
HTTP/3: 3.5s (2.4x быстрее HTTP/2!)
Браузеры:
CDN:
Проверка:
# Chrome DevTools → Network → Protocol
# Ищем "h3" или "http/3"
Cloudflare, Fastly, AWS CloudFront автоматически используют HTTP/3.
HTTP/2/3 не нуждаются в нескольких доменах. Один домен эффективнее.
HTTP/3 особенно эффективен при высоком packet loss (3G/4G).
Может привести к over-pushing. Используйте 103 Early Hints вместо Push.
Итог:
HTTP/3 + QUIC решают фундаментальную проблему TCP Head-of-Line Blocking, обеспечивая лучшую производительность особенно в условиях нестабильной сети. 0-RTT и Connection Migration делают HTTP/3 идеальным для мобильных приложений.