QUIC против TCP: чем HTTP/3 реально отличается на практике

TCP — главный транспорт интернета на протяжении сорока пяти лет. Он надёжен, изучен и отлично работает на стабильных линиях. Парадоксально, именно его известность стала тормозом: сетевое оборудование настолько привыкло к TCP-флагам, опциям и поведению, что любая попытка добавить что-то новое ломает соединения посередине. Это называется network ossification, и QUIC проектировали как ответ на эту проблему.

QUIC берёт транспорт целиком в userspace, маскируется под зашифрованный UDP и тем самым делает невозможным вмешательство в логику соединения. На бумаге это звучит абстрактно. На практике — даёт измеримый прирост на мобильных сетях, при потере пакетов и на дальних маршрутах.

HTTP/2 стек                    HTTP/3 стек
─────────────                  ─────────────
HTTP/2 фреймы                  HTTP/3 фреймы
    │                              │
TLS 1.3                        QUIC (TLS встроен)
    │                              │
TCP                            UDP
    │                              │
IP                             IP

Потеря 1 пакета TCP            Потеря 1 пакета QUIC
блокирует ВСЕ HTTP-потоки      блокирует только ОДИН поток
до retransmission              остальные продолжают доставку

Что было не так с TCP в современном вебе

Четыре главных боли TCP в 2020-х годах:

1. Head-of-line blocking. TCP — это байтовый поток с гарантированным порядком. Если один пакет потерян, всё, что пришло после него, лежит в буфере приёмника, пока retransmit не доедет. HTTP/2 пытался решить это мультиплексированием поверх TCP, но проблему лишь сместил — потеря одного пакета по-прежнему блокирует все потоки.
2. Латентность handshake. Полное TCP+TLS-соединение — это 3 RTT (1 для TCP SYN/ACK + 2 для TLS 1.2). На дальних маршрутах в 200 мс это полсекунды до первого байта.
3. Mobility. TCP-соединение жёстко привязано к четвёрке IP+порт обеих сторон. Меняется IP клиента — соединение разорвано. Для мобильного устройства, которое переключается между Wi-Fi и LTE, это означает полный рестарт.
4. Ossification. Промежуточные NAT и middleboxes так привыкли к стандартному TCP, что любые новые поля или опции просто фильтруются. Расширения вроде MPTCP и TCP Fast Open десятилетиями приживаются с трудом.

Что меняет QUIC

Архитектурное решение — не «улучшить TCP», а перенести всю надёжность в userspace и заодно зашифровать всё, что только можно. Конкретно:

• UDP как транспорт. Сетевое оборудование видит просто UDP-пакеты на порт 443. Внутри — зашифрованные QUIC-фреймы, в которые промежуточный узел не может вмешаться технически.
• Connection ID. Соединение идентифицируется не парой IP+порт, а 8-байтовым ID, который путешествует вместе с пакетом. Меняется IP клиента — соединение продолжает жить.
• Stream-level reliability. Внутри QUIC живут независимые потоки. Потеря пакета влияет только на тот поток, к которому он относился.
• Встроенный TLS 1.3. Handshake QUIC и TLS — это одно сообщение. Полное соединение строится за 1 RTT, а с PSK — за 0 RTT.
• Современная loss recovery. Раздельные number spaces для initial/handshake/application data, ACK ranges с явными gap'ами, packet pacing вместо burst-ретрансмитов.

Это не косметика, а смена парадигмы: транспорт перестал быть «частью ОС, которую все знают», и стал «частью приложения, которую сеть не трогает».

Connection migration на практике

Самый ощутимый эффект QUIC проявляется на мобильных. Сценарий: вы заходите в метро и Chrome загружает большой ютуб-ролик через Wi-Fi. На входе в туннель Wi-Fi пропадает, телефон переключается на LTE — IP меняется. С TCP это означает реконнект, новый TLS handshake, потенциально потерянный буфер видео и спиннер на 1–2 секунды. С QUIC браузер просто продолжает посылать пакеты с тем же Connection ID, сервер видит новый source-IP, проверяет пакет и принимает его — пользователь не заметил вообще ничего.

Это работает не на каждом маршруте: некоторые corporate-NAT не любят UDP-сессии и закрывают их раньше времени. Но в публичном интернете эффект стабилен.

Как QUIC переживает потери

В TCP loss recovery работает по простой схеме: если ACK не пришёл за RTO, пакет посылается заново. У QUIC механика тоньше:

• Каждый пакет имеет уникальный packet number — даже ретрансмит. Это убирает неоднозначность «это новый пакет или повтор?», которая мешала TCP.
• ACK содержит явные диапазоны полученных номеров (до 256 штук), а не один кумулятивный. Сервер точно знает, что у клиента есть, и шлёт только нужные данные.
• Encrypted ACKs нельзя подделать со стороны: посредник не сможет «обмануть» сторону якобы полученным пакетом, как это иногда делалось с TCP.
• Loss-detection работает по таймингу: если приходит более новый пакет, а старый ещё не подтверждён, RACK помечает его как потерянный быстрее RTO.

За что приходится платить

QUIC не бесплатен. Минусы, о которых редко говорят в маркетинге:

• CPU. Userspace-транспорт без kernel-acceleration требует в 2–4 раза больше CPU на сервере, чем TCP+kTLS. Поэтому крупные CDN ставят AES-NI, AF_XDP и собственные оптимизации.
• UDP не везде проходит. Старые корпоративные файрволлы, гостевые Wi-Fi-сети и часть мобильных тарифов режут UDP/443. Браузеры умеют делать fallback на HTTP/2, но это лишний RTT.
• Сложнее debug. Wireshark показывает зашифрованный QUIC. Чтобы видеть содержимое, нужны ключи (SSLKEYLOGFILE) и свежий dissector. Привычный tcpdump | grep уже не работает.
• Реализаций мало, версионирование нетривиально. QUIC v1 (RFC 9000) — стандарт, но v2 (RFC 9369) уже на подходе. Каждый клиент должен поддерживать version negotiation.

Реальные цифры с продакшена

Несколько публичных бенчмарков, которые стоит держать в голове:

• Cloudflare в отчётах 2024-го: ~30% трафика по HTTP/3, медианное ускорение page load 5–8% против HTTP/2, на p95 (плохие сети) — до 25%.
• Google на YouTube: -10% rebuffering на мобильных при включении QUIC, -15% time-to-first-byte для start-of-stream.
• Meta (Facebook): на нестабильных сетях QUIC уменьшает количество failed requests почти вдвое.
• Discord перевёл голос на QUIC и получил снижение jitter на 20% в среднем.

На стабильном домашнем оптике с RTT 5–10 мс разница HTTP/2 и HTTP/3 чаще всего в пределах погрешности. Чем хуже сеть — тем заметнее преимущество.

Что меняется для сетевой инфраструктуры и DevOps

Для NetOps и DevOps это означает переучивание привычек. Старые скрипты на iptables/conntrack хуже работают с UDP-сессиями. NAT-таймауты для UDP по умолчанию короче (30–120 секунд против часов у TCP) — нужно настраивать. Балансировщики уровня L4 (HAProxy, nginx-stream) обычно не понимают Connection ID и распределяют пакеты по 5-tuple — это ломает migration. Современные балансеры (HAProxy 2.6+, nginx-quic, envoy) уже умеют hash по CID. Метрики Prometheus и Grafana требуют отдельных экспортеров для QUIC.

Стандарты и где читать дальше

QUIC v1 описан в RFC 9000 (transport), 9001 (TLS integration), 9002 (loss detection и congestion control). HTTP/3 — RFC 9114. QPACK (header compression для H3) — RFC 9204. Datagram extension для realtime — RFC 9221. Базовый разбор стека есть в статье про QUIC и HTTP/3, а пользовательский ракурс — в материале HTTP/3 простыми словами.

Итого

QUIC — не «магически быстрее всегда». На идеальной сети он сравним с TCP+TLS, иногда чуть медленнее по чистой пропускной способности из-за userspace-CPU. Но он радикально лучше там, где TCP давно упирался: при потерях, на мобильности, при коротких сессиях и на дальних маршрутах. И это не временное преимущество — это новая архитектура, которая уйдёт от ossification ещё на ближайшие 20 лет.