QUIC - QUIC

QUIC
Протокол связи
Цель общее назначение
Разработчики) IETF
Введено 12 октября 2012 г . ; 9 лет назад ( 2012-10-12 )
Слой OSI Транспортный уровень
RFC (ы) RFC 8999, RFC 9000
Веб-сайт quicwg .org
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

QUIC (произносится как «быстрый») - это сетевой протокол общего назначения на транспортном уровне , первоначально разработанный Джимом Роскинд в Google , реализованный и развернутый в 2012 году, публично объявленный в 2013 году по мере расширения экспериментов и описанный на встрече IETF . QUIC используется более чем половиной всех подключений веб-браузера Chrome к серверам Google. Microsoft Edge (производная от Chrome) и Firefox поддерживают его. Safari реализует протокол, но по умолчанию он не включен.

Хотя его название было первоначально предложено как аббревиатура от «Quick UDP Internet Connections», использование IETF слова QUIC не является аббревиатурой; это просто название протокола. QUIC улучшает производительность ориентированных на соединение веб-приложений , которые в настоящее время используют TCP . Он делает это путем установления нескольких мультиплексных соединений между двумя конечными точками с использованием протокола пользовательских дейтаграмм (UDP) и предназначен для устаревания TCP на транспортном уровне для многих приложений, благодаря чему протокол иногда получает прозвище «TCP / 2».

QUIC работает рука об руку с мультиплексированными соединениями HTTP / 2 , позволяя нескольким потокам данных достигать всех конечных точек независимо и, следовательно, независимо от потерь пакетов с участием других потоков. Напротив, HTTP / 2, размещенный на протоколе управления передачей (TCP), может страдать от задержек, связанных с блокировкой начала линии для всех мультиплексированных потоков, если какой-либо из пакетов TCP задерживается или теряется.

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

В июне 2015 года Интернет-проект спецификации QUIC был представлен в IETF для стандартизации. В 2016 году была создана рабочая группа QUIC. В октябре 2018 года рабочие группы IETF HTTP и QUIC совместно решили назвать отображение HTTP через QUIC « HTTP / 3 », прежде чем сделать его всемирным стандартом. В мае 2021 года IETF стандартизировал QUIC в RFC  9000 , поддерживаемом RFC  8999 , RFC  9001 и RFC  9002 .

Фон

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

Для этого TCP разбивает данные на сетевые пакеты и добавляет к каждому пакету небольшие объемы данных. Эти дополнительные данные включают порядковый номер, который используется для обнаружения пакетов, которые потеряны или поступают не по порядку, и контрольную сумму, которая позволяет обнаруживать ошибки в пакетных данных. Когда возникает какая-либо проблема, TCP использует автоматический запрос на повторение (ARQ), чтобы сообщить отправителю, чтобы он повторно отправил потерянный или поврежденный пакет.

В большинстве реализаций TCP будет рассматривать любую ошибку в соединении как операцию блокировки, останавливая дальнейшие передачи до тех пор, пока ошибка не будет устранена или соединение не будет считаться неудачным. Если для отправки нескольких потоков данных используется одно соединение, как в случае с протоколом HTTP / 2 , все эти потоки блокируются, хотя только один из них может иметь проблемы. Например, если при загрузке изображения GIF, используемого для значка , возникает единственная ошибка , вся остальная часть страницы будет ждать, пока эта проблема не будет решена.

Поскольку система TCP спроектирована так, чтобы выглядеть как «канал данных» или поток, она намеренно содержит мало понимания передаваемых данных. Если к этим данным предъявляются дополнительные требования, такие как шифрование с использованием TLS , это должно быть настроено системами, работающими поверх TCP, с использованием TCP для связи с аналогичным программным обеспечением на другом конце соединения. Для каждого из этих видов задач настройки требуется собственный процесс подтверждения . Это часто требует нескольких циклов обработки запросов и ответов, пока соединение не будет установлено. Из-за задержки, свойственной междугородной связи, это может добавить значительные накладные расходы к общей передаче.

Характеристики

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

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

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

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

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

QUIC может быть реализован в пространстве приложения, а не в ядре операционной системы . Обычно это вызывает дополнительные накладные расходы из-за переключения контекста при перемещении данных между приложениями. Однако в случае QUIC стек протоколов предназначен для использования одним приложением, причем каждое приложение, использующее QUIC, имеет свои собственные соединения, размещенные на UDP. В конечном итоге разница может быть очень небольшой, потому что большая часть общего стека HTTP / 2 уже находится в приложениях (или их библиотеках, чаще). Размещение оставшихся частей в этих библиотеках, по сути, исправление ошибок, мало влияет на размер стека HTTP / 2 или общую сложность.

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

Одной из проблем, связанных с переходом от TCP к UDP, является то, что TCP получил широкое распространение, и многие из «промежуточных ящиков» в инфраструктуре Интернета настроены на TCP и ограничивают скорость или даже блокируют UDP. Google провел ряд исследовательских экспериментов, чтобы охарактеризовать это, и обнаружил, что только небольшое количество соединений было заблокировано таким образом. Это привело к использованию системы быстрого возврата к TCP; Сетевой стек Chromium одновременно открывает как QUIC, так и традиционное TCP-соединение, что позволяет ему откатиться с незначительной задержкой.

Google QUIC (gQUIC)

Протокол, который был создан Google и передан в IETF под названием QUIC (уже в 2012 году около QUIC версии 20), сильно отличается от QUIC, который продолжал развиваться и совершенствоваться в IETF. Первоначальный Google QUIC был разработан как протокол общего назначения, хотя изначально он был развернут как протокол для поддержки HTTP (S) в Chromium. Текущая эволюция протокола IETF QUIC - это транспортный протокол общего назначения. Разработчики Chromium продолжали отслеживать эволюцию усилий IETF QUIC по стандартизации для принятия и полного соответствия самым последним интернет-стандартам для QUIC в Chromium.

Принятие

Поддержка браузера

Код QUIC был экспериментально разработан в Google Chrome, начиная с 2012 года, и был анонсирован как часть Chromium версии 29 (выпущенной 20 августа 2013 года). В настоящее время он включен по умолчанию в Chromium и Chrome.

Поддержка Firefox прибыла в мае 2021 года.

Apple добавила экспериментальную поддержку в движок WebKit через Safari Technology Preview 104 в апреле 2020 года. Официальная поддержка была добавлена ​​в Safari 14, включенном в macOS Big Sur и iOS 14 , но эту функцию необходимо включать вручную.

Служба поддержки клиентов

Библиотека cronet для QUIC и других протоколов доступна для приложений Android в виде модуля, загружаемого через сервисы Google Play .

cURL 7.66, выпущенный 11 сентября 2019 года, поддерживает HTTP / 3 (и, следовательно, QUIC).

В октябре 2020 года Facebook объявил об успешном переносе своих приложений, в том числе Instagram , и серверной инфраструктуры на QUIC, при этом уже 75% своего интернет-трафика использует QUIC. Все мобильные приложения от Google поддерживают QUIC, включая YouTube и Gmail . Мобильное приложение Uber также использует QUIC.

Поддержка сервера

По состоянию на 2017 год существует несколько активно поддерживаемых реализаций. Серверы Google поддерживают QUIC, и Google опубликовал прототип сервера. Akamai Technologies поддерживает QUIC с июля 2016 года. Также доступна реализация Go под названием quic-go, которая обеспечивает экспериментальную поддержку QUIC на сервере Caddy . 11 июля 2017 года LiteSpeed ​​Technologies официально начала поддерживать QUIC в своих продуктах балансировки нагрузки (WebADC) и LiteSpeed ​​Web Server . По состоянию на октябрь 2019 года 88,6% веб-сайтов QUIC использовали LiteSpeed ​​и 10,8% использовали Nginx . Хотя сначала только серверы Google поддерживали соединения HTTP-over-QUIC, Facebook также запустил эту технологию в 2018 году, а Cloudflare предлагает поддержку QUIC на бета-версии с 2018 года. По состоянию на март 2021 года, 5,0% всех веб-сайтов используют QUIC. Microsoft Windows Server 2022 поддерживает как HTTP / 3, так и SMB по протоколам QUIC через MsQuic .

Кроме того, существует несколько устаревших проектов сообщества: libquic была создана путем извлечения Chromium-реализации QUIC и ее модификации для минимизации требований зависимостей, а goquic предоставляет Go- привязки libquic. Наконец, quic-reverse-proxy - это образ Docker, который действует как обратный прокси- сервер, переводя запросы QUIC в простой HTTP, который может быть понят исходным сервером.

.NET 5 представляет экспериментальную поддержку QUIC с использованием библиотеки MsQuic .

Исходный код

Следующие реализации QUIC или gQUIC доступны в исходной форме:
Реализация Лицензия Язык Описание
Хром Бесплатно C ++ Это исходный код веб-браузера Chrome и эталонная реализация gQUIC. Он содержит автономные клиентские и серверные программы gQUIC и QUIC, которые можно использовать для тестирования. Доступный для просмотра исходный код . Эта версия также является основой ЛИНИЮ «s стеллита и cronet Google.
Библиотека QUIC (mvfst) Лицензия MIT C ++ mvfst (произносится как «двигаться быстро») - это клиентская и серверная реализация протокола IETF QUIC на C ++ от Facebook.
Библиотека LiteSpeed ​​QUIC (lsquic) Лицензия MIT C Это реализация QUIC и HTTP / 3, используемая LiteSpeed ​​Web Server и OpenLiteSpeed .
ngtcp2 Лицензия MIT C Это библиотека QUIC, которая не зависит от криптографических библиотек и работает с OpenSSL или GnuTLS. Для HTTP / 3 нужна отдельная библиотека, например nghttp3 .
Пирог с заварным кремом Лицензия BSD-2-Clause Ржавчина Независимость от сокетов и предоставляет C API для использования в приложениях C / C ++.
быстро Лицензия MIT C Эта библиотека является реализацией QUIC для веб-сервера H2O .
быстрый ход Лицензия MIT Идти Эта библиотека обеспечивает поддержку QUIC на веб-сервере Caddy . Также доступна клиентская функциональность.
Куинн Лицензия Apache 2.0 Ржавчина
Neqo Лицензия Apache 2.0 Ржавчина Эта реализация от Mozilla планируется интегрировать в Necko, сетевую библиотеку, используемую в веб-браузере Firefox.
aioquic Лицензия BSD-3-Clause Python В этой библиотеке есть API без ввода-вывода, подходящий для встраивания как в клиенты, так и в серверы.
пикокик Лицензия BSD-3-Clause C Минимальная реализация QUIC в соответствии со спецификациями IETF
pquic Лицензия MIT C Расширяемая реализация QUIC, которая включает виртуальную машину eBPF, которая может динамически загружать расширения как плагины.
MsQuic Лицензия MIT C Кроссплатформенная реализация QUIC от Microsoft, разработанная как универсальная библиотека QUIC.
КОЛИЧЕСТВО Лицензия BSD-2-Clause C Quant поддерживает традиционные платформы POSIX (Linux, MacOS, FreeBSD и т. Д.), А также встроенные системы.
быстро Лицензия BSD-3-Clause Haskell Этот пакет реализует QUIC на основе облегченных потоков Haskell.
netty-инкубатор-кодек-quic Лицензия Apache 2.0 Джава Этот пакет реализует QUIC в netty на основе реализации Quiche .

Смотрите также

использованная литература

внешние ссылки