Зачем понадобился ещё один протокол
Классическая связка веба состояла из HTTP, TLS и TCP. Каждый уровень вносил свои задержки: сначала рукопожатие TCP, затем рукопожатие TLS, и только после этого шли данные. К тому же потеря одного пакета в TCP задерживала все запросы в соединении, даже независимые, эффект называют head-of-line blocking, задержкой из-за потерянного пакета в начале очереди.
QUIC разработали, чтобы устранить эти недостатки. Он объединяет установку соединения и шифрование, а над ним работает HTTP/3, третья версия протокола веба. Стандартизован в RFC 9000.
Идея не нова: разработку начала компания Google, затем протокол был передан в IETF и доработан открытым сообществом. Стандартизованная версия отличается от ранней экспериментальной, и поддерживающие её браузеры и серверы используют именно её.
Основные отличия от TCP
Первое: транспорт построен поверх UDP, поэтому не зависит от реализации в ядре операционной системы и может обновляться вместе с приложением. Второе: шифрование обязательно и встроено, соединение устанавливается быстрее, обычно за один круг задержки, а при повторном подключении может стартовать без задержки установления вовсе.
Третье: внутри одного соединения независимые потоки данных. Потеря пакета мешает только тому потоку, которому он принадлежал, а остальные продолжают работать. Четвёртое: соединение привязано не к адресу и порту, а к идентификатору, поэтому при переходе телефона с Wi-Fi на мобильную сеть оно способно продолжиться.
Ещё одна особенность: заголовки пакетов QUIC частично шифруются, поэтому промежуточное оборудование видит намного меньше, чем при TCP. Это повышает приватность и защищает протокол от вмешательства посредников, но затрудняет диагностику: привычные инструменты анализа трафика показывают лишь общий поток UDP.
Где вы с ним сталкиваетесь
QUIC поддерживают современные браузеры и многие крупные сайты и сервисы. Вы можете этого не замечать: браузер сам договаривается, какую версию использовать, а при неудаче откатывается на прежнюю комбинацию. Чтобы увидеть протокол, откройте инструменты разработчика браузера, вкладку «Сеть», и включите столбец «Протокол»: у запросов будет значение h3.
Трафик QUIC идёт по UDP на порт 443. Из-за этого он выглядит иначе, чем обычный HTTPS по TCP, хотя порт тот же.
Если хотите проверить у себя, откройте страницу известного крупного сервиса, нажмите F12, перейдите на вкладку «Сеть» и обновите страницу. В столбце «Протокол» рядом с запросами будет h3, если использовался HTTP/3, h2 для HTTP/2 и http/1.1 для самого старого варианта. Значения могут смешиваться на одной странице, так как разные домены поддерживают разные версии.
Когда QUIC вызывает вопросы
Некоторые фаерволы, сетевые фильтры и корпоративные шлюзы не понимают QUIC или закрывают UDP на порту 443. Тогда браузер после недолгой паузы использует TCP, и вы можете заметить лишь небольшую задержку. Иногда антивирусы и системы контроля трафика рекомендуют отключить QUIC, чтобы иметь возможность проверять соединения привычным образом.
Если сайт зависает при первом открытии, но работает после нескольких секунд, стоит проверить, не блокируется ли UDP. В браузере функцию можно отключить в настройках, а на роутере убедиться, что UDP не режется.
Как убедиться, что проблема именно в QUIC: временно отключите его в настройках браузера (в некоторых браузерах для этого есть отдельный флаг в служебной странице настроек) и проверьте, стал ли сайт открываться стабильнее. Если да, причина в сети, которая плохо пропускает UDP на порту 443.
Мифы
QUIC не всегда быстрее. На хорошем канале с малой задержкой выигрыш небольшой, заметен он в сетях с потерями и при частой смене подключения. Он не «убирает надёжность»: подтверждения и повторы реализованы внутри протокола. И он не отменяет шифрование, а делает его неотъемлемой частью соединения, отключить которую нельзя.
Кроме того, не стоит ждать, что он ускорит всё подряд: тяжёлые загрузки упираются в пропускную способность, а не в задержки установления соединения. Реальный выигрыш заметен на мелких запросах и в нестабильных сетях, например в мобильных.