HTTP/2 vs HTTP/3 - эволюция протокола
HTTP/2 и HTTP/3 — современные версии протокола HTTP, решающие проблемы производительности HTTP/1.1. Понимание их отличий критически важно для оптимизации загрузки веб-приложений.
HTTP/1.1 → HTTP/2 → HTTP/3
Проблемы HTTP/1.1
Head-of-Line Blocking
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: ЖДУТ!
Overhead заголовков
GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0...
Accept: application/json
Cookie: session=abc123...
...
(~500-800 bytes заголовков каждый раз!)
HTTP/2 - Решение проблем
Multiplexing (Мультиплексирование)
Один 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...)
Header Compression (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% размера заголовков!
Server Push
<!-- Client запрашивает index.html -->
GET /index.html
<!-- Server push'ит style.css ДО запроса! -->
PUSH_PROMISE: /style.css
PUSH_PROMISE: /app.js
Stream Prioritization
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: TCP Head-of-Line Blocking
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 - QUIC решает проблему
QUIC = Quick UDP Internet Connections
Ключевое отличие: HTTP/3 использует UDP вместо TCP!
Преимущества QUIC
Независимые Streams
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 ждёт, остальные продолжают!
0-RTT Connection Establishment
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 при повторном подключении)
Connection Migration
// Пользователь переключился с 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 | Обязательно |
Performance в реальном мире
Идеальные условия (низкий packet loss)
HTTP/1.1: 5.0s
HTTP/2: 2.5s (2x быстрее)
HTTP/3: 2.3s (немного быстрее HTTP/2)
1% Packet Loss
HTTP/1.1: 6.0s
HTTP/2: 4.5s (TCP HOL blocking!)
HTTP/3: 2.8s (нет HOL blocking!)
3% Packet Loss (плохая мобильная сеть)
HTTP/1.1: 10.0s
HTTP/2: 8.5s
HTTP/3: 3.5s (2.4x быстрее HTTP/2!)
Adoption (Поддержка)
Браузеры:
- 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"
Best Practices для разработчиков
Используйте HTTP/3-совместимый CDN
Cloudflare, Fastly, AWS CloudFront автоматически используют HTTP/3.
Не используйте domain sharding
HTTP/2/3 не нуждаются в нескольких доменах. Один домен эффективнее.
Оптимизируйте для мобильных сетей
HTTP/3 особенно эффективен при высоком packet loss (3G/4G).
Server Push с осторожностью
Может привести к over-pushing. Используйте 103 Early Hints вместо Push.
Итог:
HTTP/3 + QUIC решают фундаментальную проблему TCP Head-of-Line Blocking, обеспечивая лучшую производительность особенно в условиях нестабильной сети. 0-RTT и Connection Migration делают HTTP/3 идеальным для мобильных приложений.