llmdocsсправочник разработчика

QUIC

Материал из llmdocs — справочник разработчика
Портал: Сети и протоколы
QUIC
РазработкаGoogle (Джим Роскинд, 2012), затем IETF
СтандартRFC 9000 (май 2021), RFC 9001 (TLS), RFC 9002 (потери и перегрузка)
ПоверхUDP
ШифрованиеTLS 1.3, встроено и обязательно
Установление соединения1-RTT, при повторном — 0-RTT
Особенностинезависимые потоки, миграция соединения, шифрование заголовков
ПрименениеHTTP/3 (RFC 9114, 2022), DNS over QUIC, SMB, туннели

QUIC — транспортный протокол, работающий поверх UDP и объединяющий функции TCP (надёжная упорядоченная доставка, управление перегрузкой) и TLS (шифрование) в одном слое. Он устанавливает защищённое соединение за один круг «туда-обратно», передаёт много независимых потоков без взаимной блокировки и сохраняет соединение при смене сети — например, при переходе телефона с Wi-Fi на мобильный интернет. Название изначально расшифровывалось как Quick UDP Internet Connections, но в стандарте IETF это просто имя.[1]

QUIC — основа HTTP/3 (см. HTTP/2 и HTTP/3); его поддерживают все основные браузеры, Google, Cloudflare, Meta и крупные CDN, а значительная доля веб-трафика уже идёт через QUIC.

История

Инженер Google Джим Роскинд спроектировал QUIC в 2012 году; в 2013 году Google начала использовать его между Chrome и своими сервисами. Работа на масштабе интернета описана в статье на SIGCOMM 2017: QUIC заметно сократил задержки поиска и буферизацию видео YouTube, особенно в медленных сетях.[5] С 2016 года протокол стандартизировала IETF, существенно его переработав: IETF QUIC использует стандартный TLS 1.3 вместо собственной криптографии Google. Основные спецификации вышли в мае 2021 года (RFC 9000–9002), HTTP/3 — в июне 2022 года (RFC 9114).[4]

Зачем нужен новый транспорт

У связки TCP + TLS есть проблемы, которые трудно исправить:

  • Блокировка начала очереди. TCP — один упорядоченный поток. В HTTP/2 по одному соединению идут десятки запросов, и потеря одного пакета задерживает их все.
  • Медленное установление. Рукопожатие TCP плюс рукопожатие TLS — два круга «туда-обратно» до первых данных.
  • Окостенение протокола. TCP реализован в ядрах операционных систем и «понимается» множеством промежуточных устройств — файрволов, NAT, балансировщиков. Любое изменение TCP годами не может распространиться, потому что сетевое оборудование отбрасывает непривычные пакеты.

QUIC решает это, работая в пространстве пользователя поверх UDP (который пропускают почти все сети) и шифруя почти весь заголовок, чтобы промежуточные устройства не могли на него опираться.

Основные возможности

Возможность Как работает
Быстрое установление транспортное и криптографическое рукопожатие объединены: 1-RTT; при повторном подключении данные можно отправить сразу (0-RTT)
Потоки много независимых упорядоченных потоков в одном соединении; потеря пакета задерживает только свой поток
Встроенное шифрование TLS 1.3 обязателен; шифруются данные и большая часть заголовков[2]
Миграция соединения соединение определяется идентификатором, а не IP-адресом и портом, поэтому переживает смену сети
Управление перегрузкой как в TCP (по умолчанию алгоритм в духе NewReno, на практике CUBIC и BBR), но развивается в приложении[3]

Режим 0-RTT имеет оговорку: первые данные можно перехватить и воспроизвести повторно, поэтому в нём отправляют только идемпотентные запросы.

HTTP/3

HTTP/3 — это семантика HTTP поверх QUIC. Браузер узнаёт о поддержке HTTP/3 из заголовка Alt-Svc или DNS-записи HTTPS, после чего пробует подключиться по UDP на порт 443 и при неудаче возвращается к HTTP/2 поверх TCP.

curl --http3 -I https://cloudflare.com     # если curl собран с поддержкой HTTP/3

В инструментах разработчика браузера (вкладка «Сеть», столбец «Протокол») HTTP/3 отображается как h3.

Реализации

Поскольку QUIC работает в пространстве пользователя, реализаций много: quiche (Cloudflare, Rust), msquic (Microsoft), ngtcp2 (C), quic-go (Go), quinn (Rust), а также встроенные в Chromium, Firefox и серверы. nginx поддерживает HTTP/3 с версии 1.25, Caddy — по умолчанию. Помимо HTTP/3 QUIC используют DNS over QUIC (RFC 9250),[6] протокол SMB в Windows, туннели и VPN (MASQUE).

Недостатки и ограничения

  • Нагрузка на процессор. Обработка в пространстве пользователя и шифрование каждого пакета дороже, чем TCP с аппаратными оптимизациями ядра; разрыв сокращается.
  • Блокировка UDP. Некоторые корпоративные сети и провайдеры блокируют или ограничивают UDP, поэтому клиенты обязаны уметь откатываться на TCP.
  • Наблюдаемость. Зашифрованные заголовки затрудняют диагностику сети и работу систем, анализирующих трафик; отладка требует ключей TLS (SSLKEYLOGFILE) и поддержки QUIC в Wireshark.
  • Фильтрация. Поскольку QUIC шифрует почти всё, включая часть рукопожатия, системы фильтрации трафика нередко блокируют его целиком.

См. также

Источники

  1. RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
  2. RFC 9001 — Using TLS to Secure QUIC
  3. RFC 9002 — QUIC Loss Detection and Congestion Control
  4. RFC 9114 — HTTP/3
  5. A. Langley et al. — The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)
  6. RFC 9250 — DNS over Dedicated QUIC Connections
Категории: