Развёртывание и стоимость CPU

CDN выкатывает HTTP/3. Утилизация CPU на граничных серверах вырастает на 25%, пропускная способность на гигабитных каналах падает почти вдвое, а 4% клиентов незаметно откатываются на HTTP/2 — без единой ошибки в логах. QUIC действительно лучше по задержке. И действительно дороже в эксплуатации.

Стоимость CPU: почему транспорт в пользовательском пространстве дорог

QUIC работает в пользовательском пространстве — каждый пакет проходит через код приложения, а не по быстрому пути ядра от NIC до сокета. Составляющие стоимости:

1. Шифрование AES-GCM на пакет — ~15–20 тактов на байт на современных CPU. Ядерный TCP выгружает это на NIC (TLS offload, kTLS). QUIC не может — NIC пока не понимает QUIC.
2. Декодирование целых переменной длины — номера пакетов, идентификаторы потоков и длины фреймов используют кодировку VarInt из QUIC. Каждое декодирование — условный переход в пользовательском пространстве.
3. Фреймирование нагрузки — фреймы STREAM, CRYPTO и ACK сериализуются/десериализуются на пакет в пользовательском пространстве. Повторно передаваемые фреймы должны быть пересериализованы с новыми номерами пакетов.
4. Накладные расходы системных вызовов — без батчинга каждый sendmsg() по UDP — это системный вызов. На 1 Гбит/с с пакетами по 1500 байт это ~83 тыс. syscall/с на ядро.

Измеренный эффект: На гигабитном LAN-канале при полной нагрузке QUIC насыщает ядро CPU раньше, чем канал заполняется. Пропускная способность падает до ~45% по сравнению с HTTP/2 на TCP. На медленных или нестабильных каналах (типичный мобильный) узким местом является сеть, а не CPU, поэтому накладные расходы незаметны.

Оптимизации: UDP GSO, NIC offload, привязка к ядрам

UDP Generic Segmentation Offload (UDP GSO): Вместо одного sendmsg() на пакет 1500 байт — батчинг до 64 КБ нагрузки QUIC в одном системном вызове с подсказкой GSO. Ядро разбивает на отдельные UDP-датаграммы перед DMA на NIC. Результат: ~3–4 syscall на 64 КБ вместо 43. Cloudflare сообщает о ~20% снижении CPU только от GSO.

NIC QUIC offload (Intel E810 и новее): Разбор заголовков QUIC long/short в кремнии, маршрутизация пакетов к нужному потоку QUIC без участия демультиплексора в пользовательском пространстве. Снижает накладные расходы на прерывание на пакет. По состоянию на 2026 год всё ещё экспериментально, но доступно на оптимизированных для облака NIC.

Привязка к ядрам: Держите процесс QUIC на одном физическом ядре. Состояние QUIC (таблица соединений, окна CC, ключевой материал) помещается в кэш L3. Миграция между ядрами сбрасывает кэш-линии, добавляя ~50 нс на пакет.

С GSO + привязкой к ядрам стоимость CPU на байт снижается с 30% до 15–20% накладных расходов по сравнению с ядерным TCP.

Блокировка UDP и обязательный фолбэк на HTTP/2

~3–5% сетей блокируют UDP — корпоративные прокси, определённые ISP-шлюзы, некоторые LTE-контексты. Когда QUIC молча дропается (нет ICMP-ошибки, просто потерянные пакеты), единственный сигнал для клиента — таймаут, обычно 1–3 секунды до фолбэка на TCP.

Гонка браузера: Современные браузеры запускают и QUIC (UDP 443), и TCP (443) одновременно. Выигрывает то рукопожатие, которое завершится первым. Это ограничивает потери UX от блокировки UDP нулём — TCP побеждает, а QUIC изящно проигрывает гонку. Обратная сторона: при систематической блокировке UDP на пути — лишние усилия на каждом соединении.

Обнаружение Alt-Svc: HTTP/3 анонсируется через Alt-Svc: h3=":443"; ma=3600 в ответе HTTP/2. Браузер кэширует это и пытается использовать QUIC на следующем соединении. Первичные соединения всегда откатываются на TCP, обнаруживают заголовок и переходят на QUIC при следующих запросах.

Требование RFC 9000: Реализации ДОЛЖНЫ поддерживать фолбэк на HTTP/2 over TCP. Деплой без этого нарушает спецификацию и сломается в заблокированных сетях.

Реальность развёртывания в 2026 году

~21% веб-трафика идёт через HTTP/3. ~35–40% крупных сайтов анонсируют его через Alt-Svc. Принятие бимодально:

• Мобильные браузеры включают HTTP/3 по умолчанию — задержка и устранение HoL-блокировки важны в сотовых сетях.
• Десктоп/LAN всё ещё устраивает гонку QUIC vs TCP; TCP часто выигрывает, потому что RTT короткие и HoL-блокировка редка на быстрых путях.

Крупные CDN (Cloudflare, Google, Akamai, Fastly) включают HTTP/3 по умолчанию. Браузеры (Chrome, Safari, Firefox) его поддерживают. Кривая принятия будет расти по мере того, как блокировка UDP станет редкостью, аппаратный offload снизит стоимость CPU, а гонка фолбэков станет универсальной.

$ quictrace capture.pcapng | head -20
timestamp=0.000 dcid=12345678 type=Initial pkt_num=0 frames=[Crypto[0..120], Padding]
timestamp=0.045 dcid=12345678 type=Initial pkt_num=1 frames=[Crypto[120..240], Padding] # Повторная передача (нет ACK вовремя)
timestamp=0.051 scid=87654321 dcid=12345678 type=Initial pkt_num=0 frames=[Crypto[0..200], Ack[0], Padding]
timestamp=0.052 dcid=87654321 type=Handshake pkt_num=0 frames=[Crypto[200..350]]
timestamp=0.100 scid=87654321 dcid=12345678 type=Handshake pkt_num=0 frames=[Crypto[350..400], Finished]
timestamp=0.101 dcid=87654321 type=1RTT pkt_num=0 frames=[Stream(0, fin, 4096 bytes)]
timestamp=0.151 scid=87654321 dcid=12345678 type=1RTT pkt_num=0 frames=[Stream(0, fin, [все байты 0..4095], Ack[0])]

Пробелы в наблюдаемости

Шифрование QUIC предотвращает инспекцию пакетов — tcpdump показывает только непрозрачные блобы. Традиционный мониторинг сети (счётчики HTTP-запросов на endpoint, обнаружение медленных клиентов, нарушения на уровне потока) ломается.

Адаптация стека:

• Приложения экспортируют трассировки QUIC через JSON (формат qlog по RFC 9312) — жизненный цикл соединения, номера пакетов, события CC.
• Браузеры сообщают PerformanceResourceTiming.nextHopProtocol = "h3" для HTTP/3-соединений.
• Облачные провайдеры (AWS, GCP) добавляют QUIC-aware метрики потоков.
• eBPF-пробы на пользовательских QUIC-сокетах могут восстанавливать тайминг пакетов без расшифровки.

Это компромисс по сути: шифрование даёт конфиденциальность и безопасность за счёт операционной непрозрачности.