HTTP/3: работа поверх QUIC и отказ от TCP

Главное отличие HTTP/3 не в новых методах и заголовках, они остались прежними, а в транспорте. Первые две версии ездили поверх TCP. HTTP/3 использует QUIC, протокол, построенный на UDP, и переносит в него то, что раньше делали отдельно TCP и TLS: надёжную доставку, контроль перегрузки и шифрование. Стандарт был опубликован в 2022 году.

Выбор UDP объясняется практикой. Протоколы TCP реализованы в ядрах операционных систем и в сетевом оборудовании, поэтому менять их поведение медленно и трудно. UDP оставляет приложению свободу, и QUIC живёт в пользовательском пространстве, обновляясь вместе с браузером и сервером.

В HTTP/2 все потоки делили одно TCP-соединение, и потеря одного сегмента задерживала все потоки. В QUIC потоки независимы прямо на транспортном уровне. Если потерялся пакет с данными одной картинки, остальные ответы продолжают собираться и передаваться, а повтор требуется только для затронутого потока.

Для пользователя это заметно на нестабильных каналах: мобильной сети с переменным качеством, слабом Wi-Fi, в поездке. На стабильной проводной сети разница может быть небольшой. Механизм контроля перегрузки в QUIC не привязан к ядру системы, но по духу близок к тем, что используются в TCP.

При TCP с TLS перед первым запросом требовалось несколько обменов сообщениями: сначала трёхстороннее рукопожатие, затем согласование шифрования. QUIC совмещает установление соединения и криптографию, а сам TLS 1.3 встроен в протокол. Новое соединение обычно готово после одного круга обмена, а при повторном обращении к знакомому серверу возможен вариант 0-RTT, когда данные отправляются уже в первом пакете.

У 0-RTT есть оговорка: такие данные могут быть повторно воспроизведены злоумышленником, поэтому их разрешают в основном для безопасных запросов на чтение. Ещё одно полезное свойство — идентификатор соединения. Он не привязан к паре адресов и портов, поэтому при переходе телефона с Wi-Fi на мобильную сеть соединение теоретически можно сохранить, не начиная заново.

Рядом с этим стоит упомянуть управление потоком. QUIC ограничивает объём данных, который отправитель вправе выдать, и на уровне отдельного потока, и на уровне всего соединения, чтобы медленный получатель не был засыпан данными. Это тоже защита от того, что один поток займёт весь канал.

Поддержку HTTP/3 включили основные браузеры и многие сети доставки контента. Клиент сначала узнаёт о ней из заголовка Alt-Svc в ответе по HTTP/2 или из записи DNS, и уже потом пробует подключиться по UDP, обычно на порт 443. Если попытка не удалась, браузер незаметно возвращается к TCP.

Этот запасной вариант нужен потому, что в некоторых корпоративных и общественных сетях UDP на 443 фильтруется или ограничивается. Кроме того, шифрование заголовков пакетов QUIC затрудняет анализ трафика привычными для администраторов средствами, а обработка UDP на серверах пока требует в среднем больше процессорного времени.

Часто считают, что UDP ненадёжен, значит и HTTP/3 ненадёжен. Это не так: надёжность доставки реализована внутри QUIC, просто на уровень выше. Другое заблуждение — что HTTP/3 всегда быстрее. Выигрыш зависит от потерь и задержки, а на хорошем канале он может быть почти незаметен. Про сам транспорт подробнее написано на странице про QUIC.

Чтобы увидеть версию, откройте инструменты разработчика, вкладку «Сеть», включите столбец «Протокол» и загрузите страницу крупного сайта: обозначение h3 говорит об использовании HTTP/3, h2 — о втором поколении. Иногда первая загрузка идёт по h2, а h3 появляется только при повторной, потому что браузер сначала должен узнать о поддержке.

Для администратора включение обычно сводится к открытию UDP на порту 443 на файрволе и выбору сервера или сети доставки с поддержкой QUIC. Если после включения часть посетителей не замечает улучшений, это нормально: клиенты за строгими сетями продолжают работать по HTTP/2. Поэтому обе версии обычно поддерживают одновременно, а выбор оставляют за браузером.