Компьютерные сети
HTTP/2 и HTTP/3
Каждый сайт загружает десятки ресурсов: HTML, CSS, JS, картинки, шрифты. HTTP/1.1 загружал их последовательно, HTTP/2 - параллельно, HTTP/3 делает это ещё и при нестабильном соединении. Понимание этих протоколов - ключ к производительности веба.
- **Производительность:** HTTP/2 ускоряет загрузку на 20-50%
- **Мобильные сети:** HTTP/3 + QUIC критичны для нестабильного LTE
- **CDN:** Cloudflare, Fastly, AWS уже на HTTP/3
Предварительные знания
HTTP/2: Streams и мультиплексирование
**HTTP/2** решает проблему HTTP/1.1 - head-of-line blocking. В HTTP/1.1 запросы идут последовательно в одном соединении. В HTTP/2 одно TCP-соединение делится на **streams** - параллельные потоки для независимых запросов.
**Stream ID:** нечётные - от клиента (1, 3, 5...), чётные - от сервера (2, 4, 6... для server push). Stream 0 - управляющие сообщения (SETTINGS, PING).
Какую проблему HTTP/1.1 решает HTTP/2?
HPACK: сжатие заголовков
**HPACK** - алгоритм сжатия заголовков в HTTP/2. В HTTP/1.1 заголовки передаются как текст, повторяются в каждом запросе. HPACK использует статическую таблицу, динамическую таблицу и Huffman-кодирование.
**QPACK в HTTP/3:** HPACK работает поверх порядкового TCP. В QUIC (UDP) порядок не гарантирован. QPACK - модификация HPACK для HTTP/3, которая справляется с out-of-order доставкой.
Как HPACK сжимает повторяющиеся заголовки?
Server Push
**Server Push** позволяет серверу отправить ресурсы до того, как клиент их запросит. Сервер знает: для HTML нужен CSS и JS - и отправляет их сразу. Экономит round-trip. На практике редко используется из-за сложностей с кешем.
**Почему Server Push не взлетел?** 1) Сложно понять, что уже в кеше браузера - можно отправить лишнее. 2) 103 Early Hints решает ту же задачу проще. 3) Chrome удалил поддержку Server Push в 2022. Вместо push используйте `<link rel="preload">`.
Почему Server Push редко используется?
QUIC: транспорт для HTTP/3
**QUIC** - транспортный протокол от Google, работает поверх UDP. Включает шифрование (TLS 1.3), мультиплексирование, контроль перегрузки. Решает проблему TCP: потеря одного пакета не блокирует все streams.
**Почему UDP?** TCP реализован в ядре ОС - обновить его на миллиардах устройств невозможно. QUIC работает в userspace поверх UDP. Можно обновлять вместе с браузером/сервером, не трогая ОС.
Почему QUIC работает поверх UDP, а не TCP?
HTTP/3
**HTTP/3** = HTTP-семантика поверх QUIC. Те же методы, заголовки, статус-коды. Отличие: вместо TCP+TLS используется QUIC. Сжатие заголовков через **QPACK** (адаптация HPACK для неупорядоченной доставки).
**Adoption:** ~30% веб-трафика уже HTTP/3 (2024). Cloudflare, Google, Facebook включили по умолчанию. Браузеры поддерживают. Узкое место - серверы и middleboxes, которые блокируют UDP:443.
HTTP/3 всегда быстрее HTTP/2
HTTP/3 быстрее при потерях пакетов и на мобильных сетях; на стабильных сетях разница минимальна
Главное преимущество - устранение HOL blocking и быстрый handshake. На стабильном соединении без потерь TCP работает отлично. HTTP/3 сияет на нестабильных мобильных сетях с частыми потерями.
Как браузер узнаёт, что сервер поддерживает HTTP/3?
Ключевые идеи
- **HTTP/2:** streams + мультиплексирование + HPACK (сжатие заголовков)
- **QUIC:** UDP + TLS 1.3 + streams без HOL blocking
- **HTTP/3:** HTTP поверх QUIC; 1-RTT handshake, 0-RTT для повторных
- **Alt-Svc:** заголовок для объявления поддержки HTTP/3
Связанные темы
HTTP-эволюция связана с другими технологиями:
Вопросы для размышления
- Почему HTTP/2 по TCP всё ещё имеет HOL blocking?
- Как Connection Migration в QUIC помогает мобильным приложениям?
- Зачем нужен fallback на HTTP/2 если есть HTTP/3?