TCP, подвинься. Почему протокол QUIC скоро станет основой интернет

Интернет держался на двух старых опорах почти полвека: TCP переносил данные, UDP помогал там, где важнее скорость, чем надежность. Теперь у сетевого стека появился третий серьезный претендент на роль базового протокола. QUIC уже давно работает под капотом веба, но по мере роста нагрузки и усложнения сервисов становится ясно: речь идет не просто о техническом улучшении HTTP, а о более глубокой перестройке логики сетевого обмена.

Авторы новой редакции Computer Networks: A Systems Approach решили заметно расширить раздел о QUIC. Причина проста: в ближайшие годы значение протокола может оказаться сопоставимым с ролью TCP. Ради такого обновления один из авторов, Брюс Дэви, заново прошелся по RFC, ранним спецификациям QUIC и публикациям о развитии SPDY и HTTP/2, чтобы собрать более полную и точную картину.

Одна из первых сложностей оказалась почти бытовой, но показательной. Спецификации QUIC занимают сотни страниц, однако почти не дают наглядных схем заголовков пакетов. Для сетевых инженеров и разработчиков, которые привыкли разбирать протоколы буквально по битам, такой подход усложняет чтение. QUIC активно использует поля переменной длины, многие из которых не выровнены по 32-битным границам, поэтому классические аккуратные схемы здесь рисовать неудобно. Именно поэтому автор решил подготовить собственные иллюстрации заголовков, чтобы упростить восприятие структуры пакета.

Такая архитектура отражает саму философию QUIC. Протокол старается одновременно решить две задачи: не тратить лишние байты и не упереться в старые ограничения, как раньше случалось с TCP и IP. В предыдущих поколениях сетевых протоколов разработчики не раз закладывали поля фиксированной длины, а спустя годы выяснялось, что размеров уже не хватает. QUIC уходит от ловушки за счет переменной длины полей. Например, идентификаторы соединения могут достигать 160 бит.

Экономия тоже играет важную роль. При передаче небольших объектов в HTTP заметную часть накладных расходов дают именно заголовки. Поэтому QUIC старается хранить поля короткими, когда в длинной записи нет необходимости. Для старого железа работа с невыравненными полями могла стать проблемой, но для современных систем такой компромисс уже выглядит разумным: лучше сэкономить байты в канале, чем любой ценой держаться за красивое выравнивание по 32 битам.

Отдельно QUIC меняет сам способ идентификации соединения. TCP привязывает сессию к исходному и конечному IP-адресам и номерам портов. QUIC использует единый идентификатор соединения, уникальный с точки зрения принимающей стороны. Такая схема помогает переживать смену IP-адреса без разрыва сессии, например при переходе устройства с одной сети на другую.

Но главная перемена происходит глубже, на уровне взаимодействия с TLS. В классической модели HTTP работал поверх TLS, а TLS, в свою очередь, опирался на TCP. Сначала устанавливалось TCP-соединение, затем строился защищенный канал, и только после начинался обмен прикладными данными. QUIC забирает часть функций TLS внутрь себя и перестраивает стек. TLS-рукопожатие по-прежнему создает защищенный канал, но HTTP работает уже напрямую поверх защищенного QUIC.

На практике такая интеграция сокращает число сетевых обменов, нужных для старта соединения. Там, где раньше приходилось тратить несколько RTT, QUIC может уложиться в один. В некоторых случаях прикладные данные удается передать уже в первом RTT. Даже без режима 0-RTT, который ускоряет старт ценой дополнительных рисков для безопасности, новая схема дает заметный выигрыш по задержкам.

Особенно важным авторы считают другой механизм QUIC: потоки внутри одного соединения. Именно здесь протокол, по их мнению, превращается в давно ожидаемый транспорт для систем, работающих по модели запрос-ответ. Разработчики учебника много лет утверждали, что надежный байтовый поток TCP плохо подходит для RPC и похожих задач. В таких системах важно не просто доставить байты по порядку, а быстро вернуть ответы на множество независимых запросов.

Для веба проблема выглядит знакомо. Когда браузер запрашивает несколько объектов, строгий порядок возврата не так важен, как общая скорость доставки. При работе HTTP поверх TCP приходится либо открывать несколько параллельных соединений, либо мириться с ограничениями одного канала. Первый вариант создает лишнюю конкуренцию между несколькими циклами контроля перегрузки. Второй приводит к известной проблеме head-of-line blocking: потеря одного пакета тормозит продвижение всех запросов, которые уже находятся в полете.

QUIC снимает часть таких ограничений. Один канал может содержать много независимых потоков, и каждый поток продолжает работу отдельно от остальных. Если теряется пакет, задержка затрагивает только те потоки, чьи данные попали внутрь потерянного пакета. При этом протокол все равно видит общую картину перегрузки и может корректно отреагировать на потерю. Новый поток создается легко: любая сторона выбирает новый идентификатор и отправляет кадр с первыми данными.

Механизм контроля перегрузки и восстановления потерь в QUIC описан в отдельном RFC 9002. Подход в целом напоминает TCP NewReno, но есть и важные отличия. Нумерация относится к пакетам, а не к байтам, и номера не переиспользуются даже при повторной передаче. Подтверждения доставки работают гибче и позволяют точнее описывать пропуски среди уже полученных пакетов.

Авторы текста признают, что уместить сотни страниц спецификаций в учебную главу без потерь почти невозможно. Но общий вывод у них вполне определенный. После десятилетий разговоров о третьем массовом транспортном протоколе, который не сводится ни к TCP, ни к UDP, интернет наконец получил реального кандидата на такую роль. Попытки расширить старую связку предпринимались и раньше, включая SCTP, но именно QUIC сумел совместить сильную техническую базу с реальными шансами на массовое внедрение.

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