Версии HTTP: 1.1, 2, 3 • Senior Go Interview Prep

Модуль: Сети и протоколы · Уровень: Middle+/Senior

TL;DR#

HTTP/1.1: текстовый, одно соединение = один запрос в момент времени; keep-alive переиспользует соединение; pipelining почти не работает (HoL blocking); параллелизм достигается множеством TCP-соединений (браузеры ~6 на хост).
HTTP/2: бинарный, мультиплексирование множества потоков по одному TCP, сжатие заголовков (HPACK), приоритеты, server push (по факту устарел). Решает HoL на уровне приложения, но НЕ на уровне TCP.
HTTP/3: HTTP поверх QUIC (UDP+TLS1.3). Убирает HoL на транспорте, быстрый handshake, миграция соединения.
Бэкендеру: gRPC требует HTTP/2; Go net/http сервер и клиент поддерживают h2 автоматически по TLS+ALPN; HTTP/3 — через quic-go/http3.

Теория#

HTTP/1.1#

Текстовый протокол, человекочитаемый, парсится построчно.
Persistent connections (keep-alive) — дефолт в 1.1: соединение не закрывается после ответа, переиспользуется. Управляется Connection: keep-alive/close и таймаутами.
Pipelining: можно отправить несколько запросов, не дожидаясь ответов, НО ответы должны прийти строго по порядку → head-of-line blocking: медленный первый ответ блокирует остальные. На практике pipelining отключён почти везде (баги прокси).
Параллелизм: реальная конкурентность достигается открытием нескольких TCP-соединений (браузеры ~6 на origin). Отсюда хаки вроде domain sharding.
Один запрос/ответ в момент времени на соединение → накладные расходы и затраты на handshake.

HTTP/2#

Бинарный протокол поверх одного TCP-соединения (обычно поверх TLS, ALPN h2):

Бинарное фреймирование: всё разбито на фреймы (HEADERS, DATA, SETTINGS, WINDOW_UPDATE, RST_STREAM, PING, GOAWAY…).
Мультиплексирование: множество streams в одном соединении, каждый со своим ID; запросы/ответы чередуются фреймами → нет HoL на уровне приложения, одно соединение вместо шести.
HPACK: сжатие заголовков — статическая + динамическая таблица + Huffman. Сильно экономит на повторяющихся заголовках (Cookie, User-Agent). Защищён от CRIME-атаки (в отличие от gzip-сжатия заголовков).
Flow control на уровне streams и соединения (WINDOW_UPDATE) — независимо от TCP-окна.
Приоритеты/зависимости streams (дерево приоритетов; в реальности реализовано непоследовательно, в RFC 9113 deprecated в пользу нового механизма).
Server push: сервер мог инициативно слать ресурсы. По факту выпилен (Chrome убрал поддержку) — плохо взаимодействовал с кэшем; вместо него 103 Early Hints.
Ограничение: TCP HoL blocking остаётся. Потеря одного TCP-сегмента блокирует ВСЕ streams, потому что TCP доставляет байты по порядку. Это и решает HTTP/3.

HTTP/3#

HTTP поверх QUIC (UDP + TLS 1.3):

Нет TCP HoL: streams в QUIC независимы; потеря пакета в одном stream не блокирует другие.
Быстрый handshake: TLS 1.3 встроен в QUIC, 1-RTT (или 0-RTT на повторных).
Connection migration: соединение живёт через Connection ID, переживает смену IP (Wi-Fi↔LTE).
QPACK вместо HPACK (адаптация сжатия заголовков под отсутствие гарантированного порядка между streams).
Деплой: обычно сервер анонсирует поддержку через заголовок Alt-Svc: h3=":443", клиент переключается на h3.

Сравнение#

	HTTP/1.1	HTTP/2	HTTP/3
Транспорт	TCP	TCP	QUIC/UDP
Формат	текст	бинарный	бинарный
Мультиплексирование	нет (только pipelining, HoL)	да (streams)	да (streams)
HoL приложения	да	нет	нет
HoL транспорта (TCP)	да	да	нет
Сжатие заголовков	нет	HPACK	QPACK
Handshake	TCP(+TLS)	TCP+TLS	QUIC (TLS1.3 встроен), 0/1-RTT
Connection migration	нет	нет	да
Server push	нет	да (устарел)	да (редко)
TLS обязателен	нет	де-факто да	да

Go и версии HTTP#

// HTTP/2 включается автоматически на TLS-сервере (ALPN h2),
// если используется http.Server с TLS и не отключён.
srv := &http.Server{Addr: ":443", Handler: mux}
srv.ListenAndServeTLS("cert.pem", "key.pem") // h2 + h1 через ALPN

// Клиент: http.Transport также сам согласует h2 по TLS+ALPN.
// h2c (HTTP/2 без TLS, cleartext) НЕ включается автоматически —
// нужен golang.org/x/net/http2 + http2.ConfigureServer/h2c.Handler.

// HTTP/3 (вне stdlib): github.com/quic-go/quic-go/http3
client := &http.Client{Transport: &http3.Transport{}}
resp, _ := client.Get("https://example.com")

gRPC всегда поверх HTTP/2 (нужны streams для bidi-стриминга).
Go-сервер автоматически отдаёт и h1, и h2 по одному TLS-листенеру (ALPN решает).

Подводные камни / gotchas#

HTTP/2 не убирает TCP HoL: при потерях на лоссистой сети один TCP-коннект с h2 может быть ХУЖЕ нескольких h1-соединений. Это контринтуитивно.
h2c (cleartext h2) требует явной настройки в Go — по plain TCP h2 сам не включится.
Server push мёртв — не предлагайте его как оптимизацию; правильный ответ 103 Early Hints / preload.
HPACK динамическая таблица — общее состояние соединения; неправильная реализация прокси может ломаться при больших заголовках; есть лимиты (SETTINGS_MAX_HEADER_LIST_SIZE).
Один h2-коннект и балансировка: L4-балансировщик “приклеивает” весь h2-трафик к одному бэкенду (одно соединение), что ломает балансировку. Для gRPC нужен L7-балансировщик или client-side LB.
GOAWAY при graceful shutdown: сервер шлёт GOAWAY, чтобы клиент не слал новые streams; неучтённый GOAWAY → ошибки на рестартах/деплоях.
Rapid Reset (CVE-2023-44487) — DoS через быстрое открытие/RST_STREAM множества h2-потоков; Go патчился, лимиты на конкурентные streams важны.
HTTP/3 и UDP в инфраструктуре: файрволлы/NAT/балансировщики могут не пропускать UDP/443 → нужен fallback на h2.

Вопросы на собеседовании#

В: Почему pipelining в HTTP/1.1 не прижился? О: Ответы обязаны идти в порядке запросов → head-of-line blocking, плюс множество багов в прокси/серверах. Браузеры его отключили, предпочитая несколько параллельных соединений.

В: HTTP/2 решает HoL blocking. Полностью? О: Только на уровне приложения (мультиплексирование streams). На уровне TCP HoL остаётся: потеря одного сегмента блокирует доставку всех streams, т.к. TCP — упорядоченный байт-поток. Полностью решает HTTP/3 поверх QUIC.

В: Что такое HPACK и зачем он? О: Сжатие HTTP-заголовков в h2: статическая таблица частых заголовков + динамическая (накапливается per-connection) + Huffman-кодирование. Экономит на повторяющихся заголовках. Спроектирован устойчивым к CRIME (в отличие от наивного gzip заголовков).

В: Почему один h2-коннект ломает балансировку нагрузки? О: Все запросы мультиплексируются в одно TCP-соединение. L4-балансировщик видит один коннект и шлёт его на один бэкенд → нагрузка не размазывается. Решение: L7-балансировка (видит отдельные streams) или client-side балансировка (gRPC).

В: В каком сценарии HTTP/1.1 может быть быстрее HTTP/2? О: На сильно лоссистой сети: h2 на одном TCP страдает от TCP HoL (потеря блокирует все streams), а несколько независимых h1-соединений изолируют потери. Отсюда мотивация HTTP/3.

В: Как в Go включается HTTP/2? О: Автоматически на TLS-сервере/клиенте через ALPN (h2). Для cleartext (h2c) нужна явная настройка через golang.org/x/net/http2. gRPC всегда использует h2.

В: Что такое Alt-Svc и зачем он для HTTP/3? О: Заголовок, которым сервер по h1/h2 анонсирует доступность h3 (Alt-Svc: h3=":443"). Клиент запоминает и при следующих запросах пробует QUIC, с fallback на TCP, если UDP заблокирован.

В: Почему server push в HTTP/2 фактически мёртв? О: Плохо взаимодействовал с клиентским кэшем (push того, что уже в кэше — трата трафика), сложен в настройке, выигрыш мал. Chrome убрал поддержку. Замена — 103 Early Hints с preload-подсказками.

На что копают на senior+#

Различие flow control: TCP-окно vs h2 stream/connection windows vs QUIC flow control — три независимых уровня.
Почему QPACK сложнее HPACK (отсутствие гарантированного порядка между QUIC-streams → риск HoL в самой таблице сжатия, решается dynamic table с подтверждениями).
Rapid Reset (CVE-2023-44487): механика атаки и почему лимит MaxConcurrentStreams сам по себе не спасает.
gRPC поверх h2: keepalive ping’и, MAX_CONCURRENT_STREAMS, почему нужен пул каналов или L7-LB.
Деплой HTTP/3 в реальной инфраструктуре: UDP buffer sizes, GSO, fallback-логика, проблемы с middleboxes.
GOAWAY-семантика и graceful drain при деплоях, как Go-сервер это обрабатывает в Shutdown.