QUIC (произносится как «быстрый») - это сетевой протокол общего назначения [1] транспортного уровня [2] , первоначально разработанный Джимом Роскинд в Google , [3] реализованный и развернутый в 2012 году [4], публично объявленный в 2013 году по мере расширения экспериментов. , [5] [6] [7] и описаны в IETF . [8] QUIC используется более чем половиной всех подключений браузера Chrome к серверам Google. [9] Microsoft Edge , [10] Firefox , [11] и Safari[12] поддерживают его, даже если он не включен по умолчанию.
Протокол связи | |
Цель | общее назначение |
---|---|
Разработчики) | IETF |
Введено | 27 мая 2021 г . |
Слой OSI | Транспортный уровень |
RFC (ы) | RFC 8999, RFC 9000 |
Веб-сайт | quicwg |
Хотя его название было первоначально предложено как аббревиатура от «Quick UDP Internet Connections», [3] [8] использование IETF слова QUIC не является аббревиатурой; это просто название протокола. [1] QUIC улучшает производительность ориентированных на соединение веб-приложений , которые в настоящее время используют TCP . [2] [9] Он делает это путем установления нескольких мультиплексных соединений между двумя конечными точками с использованием протокола пользовательских дейтаграмм (UDP) и предназначен для устаревания TCP на сетевом уровне для многих приложений, за счет чего протокол иногда получает прозвище «TCP». / 2 ". [13]
QUIC работает рука об руку с мультиплексированными соединениями HTTP / 2 , позволяя нескольким потокам данных достигать всех конечных точек независимо и, следовательно, независимо от потерь пакетов с участием других потоков. Напротив, HTTP / 2, размещенный на протоколе управления передачей (TCP), может испытывать задержки, связанные с блокировкой начала линии для всех мультиплексированных потоков, если какой-либо из пакетов TCP задерживается или теряется.
Вторичные цели QUIC включают уменьшение задержки соединения и транспорта , а также оценку пропускной способности в каждом направлении во избежание перегрузки . Он также перемещает алгоритмы управления перегрузкой в пользовательское пространство на обеих конечных точках, а не в пространство ядра , что, как утверждается, позволит этим алгоритмам быстрее улучшаться. Кроме того, протокол может быть расширен за счет прямого исправления ошибок (FEC) для дальнейшего повышения производительности, когда ожидаются ошибки, и это рассматривается как следующий шаг в развитии протокола.
В июне 2015 года Интернет-проект спецификации QUIC был представлен в IETF для стандартизации. [14] [15] В 2016 году была создана рабочая группа QUIC. [16] В октябре 2018 года рабочие группы IETF HTTP и QUIC совместно решили назвать отображение HTTP через QUIC « HTTP / 3 », прежде чем сделать его всемирным стандарт. [17] В мае 2021 года IETF окончательно стандартизировал QUIC в RFC 9000 , поддерживаемом RFC 8999 , RFC 9001 и RFC 9002 . [18]
Задний план
Протокол управления передачей , или TCP, предназначен для предоставления интерфейса для отправки потоков данных между двумя конечными точками. Данные передаются в систему TCP, которая гарантирует, что данные попадают на другой конец в точно такой же форме, или соединение укажет, что существует состояние ошибки. [19]
Для этого TCP разбивает данные на сетевые пакеты и добавляет небольшие объемы данных к каждому пакету. Эти дополнительные данные включают порядковый номер, который используется для обнаружения пакетов, которые потеряны или поступают не по порядку, и контрольную сумму, которая позволяет обнаруживать ошибки в пакетных данных. Когда возникает какая-либо проблема, TCP использует автоматический запрос на повторение (ARQ), чтобы сообщить отправителю, что нужно повторно отправить потерянный или поврежденный пакет. [19]
В большинстве реализаций TCP будет рассматривать любую ошибку в соединении как операцию блокировки, останавливая дальнейшие передачи до тех пор, пока ошибка не будет устранена или соединение не будет считаться неудачным. Если для отправки нескольких потоков данных используется одно соединение, как в случае с протоколом HTTP / 2 , все эти потоки блокируются, хотя только один из них может иметь проблемы. Например, если при загрузке изображения GIF, используемого для значка , возникает одна ошибка , вся остальная часть страницы будет ждать, пока эта проблема не будет решена. [19]
Поскольку система TCP спроектирована так, чтобы выглядеть как «канал данных» или поток, она намеренно содержит мало понимания передаваемых данных. Если к этим данным предъявляются дополнительные требования, такие как шифрование с использованием TLS , это должно быть настроено системами, работающими поверх TCP, с использованием TCP для связи с аналогичным программным обеспечением на другом конце соединения. Для каждого из этих видов задач настройки требуется собственный процесс подтверждения . Это часто требует нескольких циклов обработки запросов и ответов, пока соединение не будет установлено. Из-за задержки, свойственной междугородной связи, это может добавить значительные накладные расходы к общей передаче. [19]
Характеристики
QUIC стремится быть почти эквивалентным TCP-соединению, но с гораздо меньшей задержкой. Он делает это в основном за счет двух изменений, которые зависят от понимания поведения HTTP- трафика. [19]
Первое изменение заключается в значительном сокращении накладных расходов при настройке соединения. Поскольку для большинства HTTP-соединений требуется TLS , QUIC делает обмен ключами настройки и поддерживаемыми протоколами частью начального процесса установления связи. Когда клиент открывает соединение, ответный пакет включает данные, необходимые для использования шифрования в будущих пакетах. Это избавляет от необходимости устанавливать TCP-соединение, а затем согласовывать протокол безопасности с помощью дополнительных пакетов. Другие протоколы могут обслуживаться таким же образом, объединяя несколько шагов в один запрос-ответ. Затем эти данные можно использовать как для последующих запросов в начальной настройке, так и для будущих запросов, которые в противном случае согласовывались бы как отдельные соединения. [19]
Второе изменение заключается в использовании в качестве основы UDP, а не TCP, что не включает восстановление потерь. Вместо этого каждый поток QUIC управляется отдельно, и потерянные данные повторно передаются на уровне QUIC, а не UDP. Это означает, что если в одном потоке возникает ошибка, как в приведенном выше примере значка значка, стек протоколов может продолжить обслуживание других потоков независимо. Это может быть очень полезно для повышения производительности каналов, подверженных ошибкам, поскольку в большинстве случаев могут быть получены значительные дополнительные данные до того, как TCP заметит, что пакет отсутствует или поврежден, и все эти данные блокируются или даже сбрасываются, пока ошибка исправляется. В QUIC эти данные могут обрабатываться бесплатно, пока один мультиплексированный поток восстанавливается. [20]
QUIC включает ряд других, более приземленных изменений, которые также улучшают общую задержку и пропускную способность. Например, пакеты шифруются индивидуально, поэтому они не приводят к тому, что зашифрованные данные ожидают частичные пакеты. Обычно это невозможно в TCP, где записи шифрования находятся в байтовом потоке, а стек протоколов не знает границ более высокого уровня в этом потоке. Их можно согласовать с помощью уровней, работающих наверху, но QUIC стремится сделать все это за один процесс подтверждения. [8]
Другой целью системы QUIC было повышение производительности во время событий переключения сети, таких как то, что происходит, когда пользователь мобильного устройства перемещается из локальной точки доступа Wi-Fi в мобильную сеть . Когда это происходит по TCP, начинается длительный процесс, в котором время ожидания каждого существующего соединения одно за другим истекает, а затем восстанавливается по запросу. Чтобы решить эту проблему, QUIC включает идентификатор соединения, который однозначно определяет соединение с сервером независимо от источника. Это позволяет восстановить соединение, просто отправив пакет, который всегда содержит этот идентификатор, поскольку исходный идентификатор соединения будет по-прежнему действителен, даже если IP-адрес пользователя изменится. [21] [ нужен лучший источник ]
QUIC может быть реализован в пространстве приложения, а не в ядре операционной системы . Обычно это вызывает дополнительные накладные расходы из-за переключения контекста при перемещении данных между приложениями. Однако в случае QUIC стек протоколов предназначен для использования одним приложением, причем каждое приложение, использующее QUIC, имеет свои собственные соединения, размещенные на UDP. В конечном итоге разница может быть очень небольшой, потому что большая часть общего стека HTTP / 2 уже находится в приложениях (или их библиотеках, чаще). Размещение оставшихся частей в этих библиотеках, по сути, исправление ошибок, мало влияет на размер стека HTTP / 2 или общую сложность. [8]
Такая организация упрощает внесение будущих изменений, поскольку не требует изменений ядра для обновлений. Одна из долгосрочных целей QUIC - добавить новые системы упреждающего исправления ошибок (FEC) и улучшить контроль перегрузки. [21]
Одно из беспокойств по поводу перехода от TCP к UDP заключается в том, что TCP получил широкое распространение, и многие из «промежуточных ящиков» в инфраструктуре Интернета настроены на TCP и ограничивают скорость или даже блокируют UDP. Google провел ряд исследовательских экспериментов, чтобы охарактеризовать это, и обнаружил, что только небольшое количество соединений было заблокировано таким образом. [3] Это привело к использованию системы быстрого перехода на TCP; Сетевой стек Chromium одновременно открывает как QUIC, так и традиционное TCP-соединение, что позволяет ему откатиться с нулевой задержкой. [22]
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 года [4], и был анонсирован как часть Chromium версии 29 (выпущенной 20 августа 2013 года). [17] В настоящее время он включен в Chromium по умолчанию. В браузере Chrome экспериментальную поддержку QUIC можно включить в chrome: // flags. Существует также расширение браузера [23], указывающее, какие страницы обслуживаются QUIC.
Точно так же он был введен в Opera 16, его можно включить в opera: // flags / # enable-quic , а активные сеансы можно увидеть в opera: // net-internals / # quic .
Поддержка Firefox Nightly появилась в ноябре 2019 года. [24] [25]
Библиотека cronet для QUIC и других протоколов доступна для приложений Android в виде модуля, загружаемого через сервисы Google Play . [26]
cURL 7.66, выпущенный 11 сентября 2019 года, поддерживает HTTP / 3 (и, следовательно, QUIC). [27] [28]
В октябре 2020 года Facebook объявил [29], что он успешно перенес свои приложения и серверную инфраструктуру на QUIC, причем уже 75% своего интернет-трафика использует QUIC.
Поддержка сервера
По состоянию на 2017 год[Обновить], существует четыре активно поддерживаемых реализации. Серверы Google поддерживают QUIC, и Google опубликовал прототип сервера. [30] Akamai Technologies оказывает поддержку Quic с июля 2016 года [31] [32] Go реализация называется Quic-го [33] также доступны, и полномочия экспериментальная поддержка QUIC на сервере Caddy . [34] 11 июля 2017 года LiteSpeed Technologies официально начала поддерживать QUIC в своих продуктах балансировки нагрузки (WebADC) [35] и LiteSpeed Web Server . [36] По состоянию на октябрь 2019 г.[Обновить]88,6% веб-сайтов QUIC использовали LiteSpeed и 10,8% использовали Nginx . [37] Хотя сначала только серверы Google поддерживали соединения HTTP через QUIC, Facebook также запустил эту технологию в 2018 году [17], а Cloudflare предлагает поддержку QUIC на бета-версии с 2018 года. [38] По состоянию на март 2021 года.[Обновить], 5.0% всех веб-сайтов используют QUIC. [39]
Кроме того, существует несколько устаревших проектов сообщества: libquic [40] была создана путем извлечения реализации QUIC из Chromium и ее модификации для минимизации требований зависимостей, а goquic [41] предоставляет Go- привязки libquic. Наконец, quic-reverse-proxy [42] - это образ Docker, который действует как обратный прокси- сервер, переводя запросы QUIC в простой HTTP, который может быть понят исходным сервером.
.NET 5 представляет экспериментальную поддержку QUIC с использованием библиотеки MsQuic . [43]
Исходный код
Выполнение | Лицензия | Язык | Описание |
---|---|---|---|
Хром | Бесплатно | 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 . |
Смотрите также
- Протокол ограниченного приложения (CoAP) - протокол на основе UDP, использующий модель REST.
- Протокол управления перегрузкой дейтаграмм (DCCP)
- Безопасность на транспортном уровне дейтаграмм (DTLS)
- Быстрый и безопасный протокол
- HTTP / 3
- LEDBAT (фоновый транспорт с низкой дополнительной задержкой)
- Протокол микротранспорта (µTP)
- Протокол многоцелевых транзакций (MTP / IP) - альтернатива QUIC от Data Expedition, Inc.
- Протокол потока мультимедиа в реальном времени (RTMFP)
- Протокол надежных пользовательских дейтаграмм (RUDP)
- SPDY
- Протокол передачи управления потоком (инкапсуляция SCTP UDP; RFC 6951)
- Структурированный потоковый транспорт
- Протокол передачи данных на основе UDP (UDT) - транспортный протокол на основе UDP.
Рекомендации
- ^ а б QUIC: мультиплексированный и безопасный транспорт на основе UDP . IETF . сек. 1. ID draft-ietf-quic-transport-34.
- ^ а б Натан Уиллис. «Подключение к QUIC» . Еженедельные новости Linux . Проверено 16 июля 2013 .
- ^ а б в «QUIC: Проектная документация и обоснование спецификаций» . Джим Роскинд, автор проекта Chromium.
- ^ а б «Первая посадка кода Chromium: CL 11125002: добавьте QuicFramer и друзей» . Проверено 16 октября 2012 .
- ^ «Экспериментируем с QUIC» . Официальный блог Chromium . Проверено 16 июля 2013 .
- ^ «QUIC, Google хочет сделать Интернет быстрее» . Франсуа Бофор, евангелист хрома.
- ^ «QUIC: мультиплексированный транспорт нового поколения через UDP» . YouTube . Проверено 4 апреля 2014 .
- ^ а б в г «QUIC: IETF-88 TSV Area Presentation» (PDF) . Джим Роскинд, Google . Проверено 7 ноября 2013 .
- ^ а б Лардинуа, Фредерик. «Google хочет ускорить работу Интернета с помощью протокола QUIC» . TechCrunch . Проверено 25 октября 2016 .
- ^ Кристофер Фернандес (3 апреля 2018 г.). «Microsoft добавит поддержку быстрого интернет-протокола Google QUIC в Windows 10 Redstone 5» . Проверено 8 мая 2020 .
- ^ «Как включить HTTP3 в Chrome / Firefox / Safari» . bram.us . 8 апреля 2020.
- ^ «Состояние QUIC и HTTP / 3 2020» . www.fastly.com . Проверено 21 октября 2020 .
- ^ Тацухиро Цудзикава. "ngtcp2" . GitHub . Проверено 17 октября 2020 .
- ^ «Google предложит QUIC в качестве стандарта IETF» . InfoQ . Проверено 25 октября 2016 .
- ^ «Действие ID: draft-tsvwg-quic-protocol-00.txt» . id-announce (Список рассылки). 17 июн 2015.
- ^ «Рабочая группа QUIC - IETF» . datatracker.ietf.org . Проверено 25 октября 2016 .
- ^ а б в Чимпану, Каталин (12 ноября 2018 г.). «HTTP-over-QUIC будет переименован в HTTP / 3» . ZDNet .
- ^ «QUIC теперь RFC 9000» . www.fastly.com . 2021-05-27 . Проверено 28 мая 2021 .
- ^ а б в г д е Брайт, Питер (12 ноября 2018 г.). «Следующая версия HTTP не будет использовать TCP» . Арстехника .
- ^ Бер, Майкл; Светт, Ян. «Представляем QUIC поддержку балансировки нагрузки HTTPS» . Блог Google Cloud Platform . Проверено 16 июня 2018 .
- ^ а б «QUIC на высоте 10 000 футов» . Хром .
- ^ «Применимость транспортного протокола QUIC» . Сетевая рабочая группа IETF . 22 октября 2018 г.
- ^ «Индикатор HTTP / 2 и SPDY» . chrome.google.com . Проверено 7 августа 2020 года .
- ^ Даниэль, Стенберг. «Дэниел Стенберг объявляет о поддержке HTTP / 3 в Firefox Nightly» . Twitter . Дата обращения 5 ноября 2019 .
- ^ Чимпану, Каталин (26 сентября 2019 г.). «Cloudflare, Google Chrome и Firefox добавляют поддержку HTTP / 3» . ZDNet . Проверено 27 сентября 2019 года .
- ^ «Выполнять сетевые операции с помощью Cronet» . Разработчики Android . Проверено 20 июля 2019 .
- ^ «локон - Изменения» . curl.haxx.se . Проверено 30 сентября 2019 .
- ^ "curl 7.66.0 - параллельное будущее HTTP / 3 уже здесь | daniel.haxx.se" . Проверено 30 сентября 2019 .
- ^ «Как Facebook приносит QUIC миллиарды» . Facebook Engineering . 2020-10-21 . Проверено 23 октября 2020 .
- ^ https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.cc
- ^ Поддержка QUIC от Akamai , последнее посещение - 20 мая 2020 г.
- ^ QUIC in the Wild, Конференция по пассивным активным измерениям (PAM), 2018 г. , дата обращения 20 мая 2020 г.
- ^ "lucas-clemente / quic-go" . 7 августа 2020 . Получено 7 августа 2020 г. - через GitHub.
- ^ Поддержка QUIC в Caddy , последнее посещение - 13 июля 2016 г.
- ^ "LiteSpeed Web ADC - Load Balancer - LiteSpeed Technologies" . www.litespeedtech.com . Проверено 7 августа 2020 года .
- ^ Сообщение в блоге LiteSpeed Technologies QUIC, последнее посещение - 11 июля 2017 г.
- ^ «Распределение веб-серверов среди веб-сайтов, использующих QUIC» . w3techs.com . Проверено 7 августа 2020 года .
- ^ «Начните работу с QUIC» . 2018-09-25 . Проверено 16 июля 2019 .
- ^ «Статистика использования QUIC для веб-сайтов, март 2021 г.» . w3techs.com . Проверено 4 марта 2021 .
- ^ "devsisters / libquic" . 5 августа 2020 . Получено 7 августа 2020 г. - через GitHub.
- ^ "devsisters / goquic" . 5 августа 2020 . Получено 7 августа 2020 г. - через GitHub.
- ^ «Докер Хаб» . hub.docker.com . Проверено 7 августа 2020 года .
- ^ «Улучшения сети .NET 5» . Блог .NET . 2021-01-11 . Проверено 26 января 2021 .
Внешние ссылки
- RFC 8999 - Независимые от версии свойства QUIC
- RFC 9000 - QUIC: мультиплексированный и безопасный транспорт на основе UDP
- RFC 9001 - Использование TLS для защиты QUIC
- RFC 9002 - обнаружение потерь и контроль перегрузки QUIC
- Chromium : QUIC, мультиплексированная потоковая передача по UDP.
- QUIC: Design Document and Specification Rationale , оригинальный документ Джима Роскинда (2012/2013)
- Даниэль Стенберг : объяснение HTTP / 3
- Еженедельные новости Linux : Подключение к QUIC (2013)
- QUIC:, Презентация IETF-88 TSV Area (2013-11-07)
- Блог Chromium: эксперименты с QUIC (2013)
- QUIC: мультиплексированный транспорт нового поколения через UDP (разработчики Google, 2014 г.)
- HTTP через UDP: экспериментальное исследование QUIC
- Multipath QUIC (расширение QUIC)
- Инновации в транспорте с QUIC: подходы к проектированию и исследовательские задачи (2017)