QUIC вскоре станет таким же важным протоколом, как TCP, но при этом будет совершенно другим.

16.04.2026 Расшифровка четырех RFC третьего транспортного протокола — задача, сравнимая с попыткой слепого понять слона.Мы ожидаем, что в ближайшие годы роль QUIC станет примерно такой же важной, как и роль TCP, а это значит, что ей требуется более подробное освещение, чем мы представили в прошлом издании. Поэтому я углубился в изучение QUIC, чем раньше, с целью довести уровень освещения до уровня нашего обзора TCP. Помимо изучения RFC, я нашел много полезной информации в оригинальной спецификации QUIC, а также в некоторых публикациях конференций по проектированию и оценке SPDY (предшественника HTTP/2) и QUIC.Одна довольно незначительная вещь, которая затрудняет мне понимание QUIC, — это отсутствие в его RFC (четырех документах, занимающих сотни страниц) изображений заголовков пакетов. Причина, как я полагаю, в том, что QUIC широко использует поля переменной длины, часто не выровненные по 32-битным границам, что делает изображения заголовков пакетов несколько сложными и менее аккуратными. Я решил попробовать нарисовать свои собственные — вот один пример, который я привожу здесь в надежде, что другие найдут его полезным или непонятным.В протоколе повсеместно используются поля переменной длины, что позволяет найти баланс между эффективностью и перспективностью.Как в TCP, так и в IP-протоколе существовала практика определения 32-битных полей, которые оказывались недостаточными; QUIC, как правило, избегает этой проблемы, позволяя использовать очень большие поля, например, 160-битные идентификаторы соединений в заголовке пакета, приведенном выше.В то же время, эффективность была важным фактором на протяжении всего процесса проектирования QUIC и HTTP/2, поскольку время передачи небольших объектов в HTTP значительно зависит от объема накладных расходов заголовка. Поэтому используются кодировки переменной длины, которые позволяют сохранять поля небольшими, когда дополнительная длина не требуется.Вероятно, справедливо будет также сказать, что обработка невыровненных полей в программном обеспечении сейчас представляет гораздо меньшую проблему, чем это было на вычислительных машинах 1970-х годов, поэтому экономия байтов при передаче по сети теперь имеет приоритет над 32-битным выравниванием.Эти длинные идентификаторы соединений заменяют способ идентификации TCP-соединений (IP-адреса источника и назначения, а также номера TCP-портов) одним уникальным идентификатором с точки зрения принимающего хоста. Это обеспечивает удобную отправную точку для обеспечения возможности сохранения QUIC-соединений при изменении IP-адреса, например, при переключении хоста из одной сети в другую.Поскольку QUIC во многом отличается от TCP, как в больших, так и в малых аспектах, и охватывает четыре RFC, попытка описать его наиболее важные особенности немного напоминает притчу о слепом и слоне. Один аспект, который привлекает мое внимание, — это то, как в QUIC была переработана многоуровневая архитектура с использованием TLS.