Производительность TLS: QUIC и HTTP/3

HTTP/2 мультиплексирует несколько потоков через одно соединение TCP, устраняя блокировку начала очереди для каждого соединения в HTTP/1.1. Однако сам TCP вызывает блокировку начала очереди на транспортном уровне: если теряется один сегмент TCP, все данные, находящиеся после него в очереди, ждут повторной передачи, одновременно блокируя все потоки HTTP/2. Потеря 1% пакетов может снизить производительность HTTP/2 ниже уровня HTTP/1.1 с несколькими соединениями. QUIC решает эту проблему, реализуя мультиплексированные потоки поверх UDP, где восстановление после потерь на уровне потока не блокирует другие потоки.

QUIC — транспортный протокол на базе UDP, разработанный Google (2012–2015) и стандартизированный IETF как RFC 9000 (2021). QUIC интегрирует TLS 1.3 на транспортном уровне — поверх QUIC нет отдельного рукопожатия TLS; TLS встроен в само рукопожатие QUIC. QUIC обеспечивает: мультиплексированные потоки без блокировки начала очереди, миграцию соединения (сохранение соединения при переключении сетей, например с WiFi на LTE), установление соединения за 0-RTT для повторных соединений, а также встроенное обнаружение потерь и управление перегрузкой. HTTP/3 (RFC 9114) реализует семантику HTTP поверх потоков QUIC.

Рукопожатие QUIC объединяет установление соединения и согласование TLS. На первом этапе обмена (0 RTT в терминологии QUIC) клиент отправляет начальные пакеты, содержащие TLS ClientHello. Сервер отвечает собственными начальными пакетами (ServerHello) и пакетами рукопожатия (зашифрованные расширения, сертификат, сообщение о завершении). Клиент отправляет сообщение о завершении рукопожатия и после этого готов передавать прикладные данные — это занимает 1-RTT. При соединении за 0-RTT клиент отправляет пакеты 0-RTT (прикладные данные) одновременно с ClientHello, используя ключ, производный от секрета возобновления предыдущего сеанса, и тем самым не тратит дополнительных циклов обмена для сеансов, данные о которых сохранены в кэше.

QUIC использует четыре различных уровня шифрования, соответствующих этапам расписания ключей TLS: начальный уровень (AEAD, производный от QUIC, с известным постоянным ключом — обеспечивает целостность, но не конфиденциальность от изощрённых атакующих), уровень рукопожатия (производный из TLS handshake_secret — обеспечивает конфиденциальность сообщений рукопожатия TLS), уровень 0-RTT (производный из early_secret предыдущего сеанса — шифрует прикладные данные 0-RTT) и уровень 1-RTT (производный из master_secret TLS — шифрует все прикладные данные). Заголовки QUIC шифруются частично: номер пакета и полезная нагрузка зашифрованы, но часть информации о маршрутизации (идентификатор соединения) остаётся видимой для балансировщиков нагрузки.

Соединения QUIC идентифицируются с помощью идентификатора соединения (CID), а не 4-кортежа (IP-адрес источника, порт источника, IP-адрес назначения, порт назначения). Благодаря этому соединения сохраняются при изменении сети: когда мобильный клиент переключается с WiFi на LTE, IP-адрес меняется, но CID остаётся прежним. Клиент отправляет кадр PATH_CHALLENGE по новому пути; сервер отвечает кадром PATH_RESPONSE, подтверждая новый адрес. Соединение продолжается без каких-либо заметных перерывов и повторного согласования. TCP не поддерживает такую возможность: соединение TCP привязано к своему 4-кортежу и при смене сети должно устанавливаться заново, что требует нового рукопожатия TLS. Миграция QUIC значительно улучшает воспринимаемую производительность для мобильных пользователей.

HTTP/3 отображает семантику HTTP на потоки QUIC. Каждая пара «запрос–ответ» HTTP занимает отдельный двунаправленный поток QUIC. Потоки QUIC независимы: потеря данных в потоке 3 не блокирует поток 7. HTTP/3 использует QPACK для сжатия заголовков, заменяя HPACK из HTTP/2; QPACK переработан так, чтобы не требовать доставки данных по порядку. Два выделенных однонаправленных управляющих потока передают настройки и инструкции декодеру и кодировщику. Серверная отправка в HTTP/3 использует потоки отправки, то есть однонаправленные потоки. В результате HTTP/3 особенно заметно превосходит HTTP/2 при потерях пакетов — в мобильных сетях и на перегруженных маршрутах, где блокировка начала очереди в TCP наносит наибольший вред.

Измерения производительности QUIC и HTTP/3 в реальных условиях дают неоднозначные результаты в зависимости от состояния сети. В сетях высокого качества — с малой задержкой и небольшим числом потерянных пакетов — HTTP/3 и HTTP/2 работают примерно одинаково; накладные расходы QUIC, включая более крупные заголовки и обработку UDP, могут даже сделать HTTP/3 немного медленнее. В сетях с потерями (более 1% пакетов, что часто встречается в мобильных и спутниковых сетях) HTTP/3 значительно превосходит HTTP/2. Google сообщил о сокращении повторной буферизации на 7–8% на YouTube при переходе на QUIC. Facebook (Meta) сообщил об улучшении задержки запросов на 7–15% для лент Instagram при использовании QUIC. Выигрыш особенно заметен в хвостовой задержке (p95, p99), где паузы из-за повторной передачи TCP оказывают наибольшее влияние.

Балансировка QUIC сложнее балансировки TCP, поскольку QUIC работает поверх UDP, а не сохраняющие состояние балансировщики UDP не могут обеспечить привязку соединения. Документ IETF draft-ietf-quic-load-balancers определяет такой подход: серверы кодируют информацию о маршрутизации в идентификаторе соединения, чтобы балансировщики могли направлять пакеты одного соединения на один и тот же сервер без отслеживания состояния каждого соединения. Идентификатор соединения содержит зашифрованный идентификатор сервера, созданный с помощью общего ключа балансировщика нагрузки и серверов. Cloudflare, Fastly и Nginx реализуют варианты этого подхода. Прохождение через NAT — ещё одна проблема: соединения QUIC должны сохраняться при переназначении NAT, что обеспечивается механизмом миграции соединения.

Крупнейшие CDN развернули QUIC и HTTP/3 в широких масштабах. Cloudflare обслуживает HTTP/3 с 2019 года и сообщает, что примерно 20% трафика использует QUIC, если он поддерживается и клиентом, и сервером. Fastly, Akamai и AWS CloudFront поддерживают HTTP/3 на своих периферийных узлах. Собственная инфраструктура Google (Поиск, YouTube, Gmail) использует QUIC внутри сети с 2013 года и предоставляет HTTP/3 внешним пользователям. Развёртывание в CDN выигрывает от возобновления соединения за 0-RTT в QUIC: постоянные посетители устанавливают соединения быстрее, а миграция соединения повышает производительность для мобильных пользователей, перемещающихся между точками доступа во время доставки контента.

Конструкция QUIC на базе UDP создаёт особые вопросы безопасности. Атаки усиления: злоумышленник может подделать IP-адрес источника и отправить небольшие начальные пакеты, заставив сервер отправить жертве большие ответы рукопожатия. QUIC смягчает эту угрозу, ограничивая ответы сервера объёмом, не превышающим трёхкратный объём полученных данных, до завершения проверки адреса с помощью механизма RETRY. При атаках массового открытия соединений серверы QUIC должны ограничивать частоту новых попыток соединения с одного IP-адреса. Атаки на согласование версии предотвращаются включением версии в криптографически защищённое рукопожатие. Встроенное шифрование QUIC означает, что средства инспекции трафика не могут анализировать полезную нагрузку QUIC без нахождения на пути между клиентом и сервером и доступа к сертификату сервера, что повышает конфиденциальность по сравнению с доступным для инспекции трафиком TCP.

Для развёртывания HTTP/3 требуются: (1) сервер с поддержкой QUIC — nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed или реализация на уровне приложения с помощью библиотек quic-go, aioquic и ngtcp2; (2) открытый на межсетевых экранах порт UDP 443 — многие корпоративные межсетевые экраны блокируют UDP 443, из-за чего QUIC переходит обратно на TCP/TLS; (3) объявление поддержки HTTP/3 с помощью заголовка ответа Alt-Svc: h3=":443"; ma=86400, предлагающего клиентам HTTP/2 перейти на новый протокол; (4) балансировщики нагрузки с поддержкой QUIC или сквозная передача UDP на уровне L4; (5) мониторинг показателей, специфичных для QUIC: событий миграции соединений, доли принятых соединений за 0-RTT и доли переходов на запасной протокол. Постепенное развёртывание с переходом на HTTPS происходит прозрачно для клиентов, не поддерживающих QUIC.

Как QUIC решает проблему блокировки начала очереди, которая возникает в HTTP/2 поверх TCP?

QUIC интегрирует TLS 1.3 на транспортном уровне поверх UDP, устраняя блокировку начала очереди в TCP благодаря независимому восстановлению после потерь для каждого потока. Идентификаторы соединений обеспечивают миграцию при изменении сети без повторного согласования. HTTP/3 отображает HTTP на потоки QUIC и использует QPACK для сжатия заголовков. Возобновление соединения за 0-RTT повторно использует секреты сеанса TLS. QUIC особенно значительно превосходит HTTP/2 при потерях пакетов — в мобильных и перегруженных сетях. Для балансировки QUIC требуется кодировать сведения о маршрутизации сервера в идентификаторах соединений. Для развёртывания нужны UDP 443, серверы с поддержкой QUIC и заголовки Alt-Svc для объявления протокола.