quickx protocol что это
HTTP по UDP — используем с пользой протокол QUIC
QUIC (Quick UDP Internet Connections) — это протокол поверх UDP, поддерживающий все возможности TCP, TLS и HTTP/2 и решающий большинство их проблем. Его часто называют новым или «экспериментальным» протоколом, но он уже давно пережил стадию эксперимента: разработка ведётся более 7 лет. За это время протокол не успел стать стандартом, но всё же получил широкое распространение. Например, QUIC используют для ускорения трафика и снижения задержек в мобильных сетях такие гиганты как Google и Facebook, а IETF объявила свой форк протокола основой для стандарта HTTP/3 (при том, что HTTP/2 использует только 44.8% сайтов).
Концепция
QUIC разрабатывался как замена устаревшего TCP, который изначально был заточен под проводные сети с низким процентом потерь. TCP доставляет пакеты по порядку, поэтому при потере одного пакета встаёт вся очередь (head-of-line blocking), что негативно сказывается на качестве и стабильности соединения. Чтобы избежать массовых потерь, сотовые сети прибегают к использованию больших буферов, что в свою очередь приводит к избыточности и false negative реакции протокола (bufferbloat). Кроме того, TCP тратит очень много времени на установление соединения: SYN/ACK и TLS запросы идут раздельно, требуя трёх roundtrip’ов вместо одного, как это делает QUIC.
Так как QUIC сочетает в себе замену TCP и реализацию TLS 1.3, все соединения всегда зашифрованы, расшифровать такой трафик не проще чем если бы он шёл по HTTPS. Кроме того, QUIC реализован на прикладном уровне, как как полная замена TCP стека заняла бы вечность.
Несмотря на поддержку мультиплексирования в HTTP/2, проблема head-of-line blocking там осталась из-за необходимости доставлять пакеты по порядку. QUIC реализован поверх UDP, поэтому у него блокировок не бывает в принципе, а чтобы пакеты не терялись безвозвратно, они нумеруются и могут содержать в себе части «соседей», обеспечивая избыточность. Кроме того, QUIC разбивает монолитную очередь на несколько потоков для разных типов запросов внутри одного соединения. Таким образом, при потере пакета проблемы могут возникнуть только у одной очереди (например, на передачу конкретного файла):
Использование
Изначально QUIC разрабатывался внутри Google и был во многом заточен под использование внутри компании. В 2013 году его передали в IETF для стандартизации (которая идёт до сих пор), и теперь каждый может поучаствовать в развитии протокола, предложив то, чего не хватает именно ему. Рабочая группа IETF ежегодно организует встречи, в рамках которых утверждается новый стандарт и ведётся обсуждение нововведений. Эта реализация QUIC считается основной и именно на её основе сертифицируется стандарт HTTP/3.
Пока что об включении HTTP/3 как основного протокола речь не идёт, потому что он ещё не закончен и почти не поддерживается:
Но QUIC можно реализовать как транспорт между приложением и сервером, что успешно проделали в Uber:
Комментарий Uber о внедрении QUIC
Чтобы успешно встроить QUIC и улучшить производительность приложения в условиях плохой связи, мы заменили старый стек (HTTP/2 поверх TLS/TCP) на протокол QUIC. Мы задействовали сетевую библиотеку Cronet из Chromium Projects, которая содержит оригинальную, гугловскую версию протокола – gQUIC. Эта реализация также постоянно совершенствуется, чтобы следовать последней спецификации IETF.
Сперва мы интегрировали Cronet в наши Android-приложения, чтобы добавить поддержку QUIC. Интеграция была осуществлена так, чтобы максимально снизить затраты на миграцию. Вместо того, чтобы полностью заменить старый сетевой стек, который использовал библиотеку OkHttp, мы интегрировали Cronet ПОД фреймворком OkHttp API. Выполнив интеграцию таким способом, мы избежали изменений в наших сетевых вызовах (который используют Retrofit) на уровне API.
Подобно подходу к Android-устройствам, мы внедрили Cronet в приложения Uber под iOS, перехватывая HTTP-трафик из сетевых API, используя NSURLProtocol. Эта абстракция, предоставленная iOS Foundation, обрабатывает протокол-специфичные URL-данные и гарантирует, что мы можем интегрировать Cronet в наши iOS-приложения без существенных миграционных затрат.
На бэкенде они ловили QUIC-соединения через Google Cloud lb, который поддерживает протокол с середины 2018 года.
Неудивительно, что Google Cloud прекрасно работает с протоколом, разработанным Google, но какие есть альтернативы?
Nginx
Здесь можно подключить свои модули при необходимости
Остаётся только включить поддержку HTTP/3
Другие технологии
Заключение
Интерес к QUIC нестабильно, но растёт, ведётся работа над его стандартизацией. Новые реализации протокола появляются уже чуть ли не каждый месяц, и с каждым годом всё больше разработчиков убеждаются, что будущее за QUIC. Допускается даже включение протокола в будущие версии TCP стека, а это означает, что рано или поздно весь интернет переедет на более устойчивые и быстрые соединения.
Уже сейчас вы можете настроить QUIC-взаимодействие для своей инфраструктуры или даже отдавать его браузерам — они все планируют добавить поддержку протокола, и печальная статистика с caniuse станет веселее.
Транспортный протокол QUIC приняли в качестве стандарта RFC 9000
QUIC — новый транспортный протокол связи, который отличается уменьшенным временем задержки, большей надёжностью и безопасностью, чем широко используемый сегодня TCP (RFC 793).
Уже много рассказывалось о преимуществах транспорта QUIC, который взят за основу будущего стандарта HTTP/3. В HTTP следующего поколения транспорт TCP меняется на QUIC, что означает автоматическое ускорение соединений и зашифровку всего интернет-трафика, который раньше шёл в открытом виде по TCP. Нешифрованный QUIC не предусмотрен вообще.
В мае 2021 года состоялось знаменательное событие: протокол QUIC принят в качестве официального стандарта RFC9000. Это великолепные новости для всей интернет-экосистемы.
Утверждением таких стандартов занимается Инженерный совет Интернета (IETF). Ранее были оформлены вспомогательные стандарты RFC 9001, RFC 9002 и RFC 8999.
Таким образом, QUIC версии 1 теперь официально принят и утверждён. Все участвующие стороны могут завершить эксперименты с черновиками протокола и перейти на первую официальную версию.
В последние годы QUIC был одним из главных приоритетов IETF. Появившись как эксперимент Google, вскоре разработка QUIC вышла на международный уровень. Она велась почти пять лет. Зафиксировано 26 очных собраний, 1749 задач в трекере и многие тысячи писем в почтовой рассылке.
QUIC — очень амбициозный проект, который принесёт большие изменения. «Транспортная экосистема интернета за несколько десятилетий закостенела, а QUIC оживит её», — пишут инженеры из компании Fastly, которые входят в рабочую группу по разработке протокола.
Окостенение означает, что система с каждым годом становится всё менее гибкой, менее подвижной. QUIC принесёт в транспортный уровень множество инноваций, включая обязательное шифрование, версионность, гораздо более богатый и более производительный набор сервисов, поверх которых будут строиться новые технологии. Предполагается, что QUIC приведёт к появлению нового поколения интернет-инноваций. Это уже начало происходит с расширениями, такими как ненадёжные датаграммы (Unreliable Datagram Extension). Ненадёжные датаграммы открывают двери перед новым классом медиа в реальном времени и другими приложениями, которым нужен более функциональный транспорт, чем обязательная доставка пакетов с обрывом канала при потере нескольких пикселей. Мы уже видим многообещающие технологии, такие как MASQUE и WebTransport.
HTTP/3
Стандарт HTTP/3 (это HTTP поверх QUIC) идёт с небольшим опозданием за QUIC и тоже будет официально принят в самое ближайшее время.
34-й (!) драфт HTTP/3
С момента принятия HTTP/2 прошло шесть лет: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 45,4% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Два с половиной года назад таких было 31,2%. Севсем недавно на HTTP/2 перешли сайты Amazon, Paypal, Telegram.org.
Cейчас практически готова третья версия HTTP/3, осталось совсем немного подождать.
QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали “HTTP/2-encrypted-over-UDP”.
Затем разработку QUIC передали в IETF для стандартизации. Здесь он разделилcя на две части: транспорт и HTTP. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в IETF.
Долгое время версия IETF называлась iQUIC, в то время как Google и другие продолжили работу над собственной реализацией gQUIC, но 7 ноября 2018 года один из ведущих разработчиков протокола Дмитрий Тихонов объявил, что стороны достигли совместимости протоколов, и теперь разработка продолжится в общем русле. QUIC в Chrome включается в настройках chrome://flags. Есть ещё расширение-индикатор, которое показывает, какие сайты поддерживают QUIC.
Встроенная безопасность и производительность
В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много. По словам руководителя рабочей группы Марка Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.
«Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».
Кроме перехода значительного объёма трафика с TCP на UDP, протокол QUIC требует обязательного шифрования: нешифрованного QUIC не существует вообще. QUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.
В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:
На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика.
Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.
Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи. Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей.
Одно из предложений для решения этой проблемы — введение спин-бита. Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.
Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что случилось «раздвоение» стандарта.
Тем не менее, прогресс неизбежен — и в ближайшие годы обязательно продолжится стандартизация и повсеместное внедрение различных протоколов нового поколения, в том числе HTTP/3 на транспорте QUIC.
Протокол QUIC: переход Web от TCP к UDP
Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — совершенно новый способ передачи информации в интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые люди называют его (в шутку) TCP/2. Переход к UDP — наиболее интересная и мощная особенность протокола, из которой следуют некоторые другие особенности.
Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.
Если вы захотите установить защищённое TLS-соединение, придётся переслать ещё больше пакетов.
Некоторые инновации, вроде TCP Fast Open, улучшат некоторые аспекты ситуации, но эта технология пока не очень широко распространена.
Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.
И здесь на сцену выходит QUIC от Google.
Протокол QUIC может открыть соединение и согласовать все параметры TLS (HTTPs) за 1 или 2 пакета (1 или 2 — зависит от того, открывается ли соединение к новому серверу или к уже знакомому).
Это невероятно ускоряет открытие соединения и начало загрузки данных.
Зачем нужен QUIC?
Планы команды разработчиков протокола QUIC выглядят очень амбициозно: протокол попытается совместить скорость UDP с надёжностью TCP.
Вот что об этом пишет Википедия:
Улучшение протокола TCP является долговременной целью для Google, а протокол QUIC создан как эквивалент независимого TCP-соединения, но с уменьшенными задержками и улучшенной в духе SPDY поддержкой мультиплексирования. Если QUIC покажет свою эффективность, то эти возможности могут войти в следующую версию протоколов TCP и TLS (разработка которых занимает больше времени).
В этой цитате есть важный момент: если QUIC докажет свою эффективность, то есть шанс, что опробованные в нём идеи станут частью следующей версии TCP.
Протокол TCP достаточно сильно формализован. Его реализации есть в ядрах Windows и Linux, в каждой мобильной OS, да и во многих более простых устройствах. Улучшение TCP является непростым делом, поскольку все эти реализации должны его поддерживать.
UDP же является относительно простым протоколом. Значительно быстрее разработать новый протокол поверх UDP чтобы иметь возможность проверить теоретические идеи, работу в перегруженных сетях, обработку заблокированных потерянным пакетом потоков и т.д. Как только эти моменты будут прояснены — можно будет начинать работу по переносу лучших частей QUIC в следующую версию TCP.
Где же сегодня место QUIC?
Если вы посмотрите на уровни, составляющие современное HTTPs-соединение, то увидите, что QUIC заменяет собой весь TLS-стек и часть HTTP/2.
Да, протокол QUIC реализует собственный крипто-слой, что позволяет избежать использования TLS 1.2.
Поверх QUIC работает небольшая прослойка HTTP/2 API, используемая для общения с удалёнными серверами. Она меньше полной реализации HTTP/2, поскольку мультиплексирование и установка соединения уже реализованы в QUIC. Остаётся лишь реализация протокола HTTP.
Блокировка начала очереди (Head-of-line blocking)
Протоколы SPDY и HTTP/2 используют одно TCP-соединение с сервером вместо отдельных соединений для каждой страницы. Это единое соединение может быть использовано для независимых запросов и получения отдельных ресурсов.
Поскольку весь обмен данными теперь построен на одном TCP-соединении, мы автоматически получаем один недостаток: блокировку начала очереди (Head-of-line blocking). В протоколе TCP требуется, чтобы пакеты приходили (точнее обрабатывались) в правильном порядке. Если пакет потерялся на пути к\от сервера — он должен быть отослан повторно. TCP-соединение в это время должно ожидать (блокироваться) и лишь после повторного получения потерянного пакета продолжается обработка всех пакетов в очереди — только так можно соблюсти условие корректного порядка обработки пакетов.
Протокол QUIC решает эту проблему фундаментально — отказом от протокола TCP в пользу UDP, который не требует соблюдения порядка обработки принимаемых пакетов. И, хотя потери пакетов, конечно, всё так же возможны, это будет влиять только на обработку тех ресурсов (индивидуальных HTML\CSS\JS-файлов), к которым относится потерянный пакет.
QUIC очень элегантно комбинирует лучшие части SPDY\HTTP2 (мультиплексирование) с неблокируемым транспортным протоколом.
Почему уменьшить количество пересылаемых пакетов так важно
Если у вас быстрое Интернет-соединение, то задержки передачи пакетов между вашим компьютером и удалённым сервером составляют около 10-50 мс. Каждый пересылаемый от вас по сети пакет будет получен сервером через этот промежуток времени. Для такого порядка величин преимущества QUIC могут быть не очень понятны. Но стоит нам рассмотреть вопрос обмена данными с сервером на другом континенте или использования мобильных сетей — и вот у нас уже появляются задержки порядка 100-150 мс.
В итоге на мобильном устройстве, при доступе к находящемуся далеко серверу, разница между 4 пакетами TCP+TLS и одним пакетом QUIC может составить около 300 мс, что уже является существенной величиной, наблюдаемой невооруженным глазом.
Превентивная коррекция ошибок
Изящной фичей протокола QUIC является превентивная коррекция ошибок (Forward Error Correction, FEC). Каждый пересылаемый пакет содержит в себе некоторое количество данных других пакетов, что позволяет реконструировать любой потерянный пакет по данным в его соседях, без необходимости запрашивать переотправку потерянного пакета и дожидаться его содержимого. Это, по сути, реализация RAID 5 на сетевом уровне.
Но вы уже и сами видите недостаток этого решения: каждый пакет становится немного больше. Текущая реализация устанавливает этот оверхед равным 10%, т.е. сделав каждый пересылаемый пакет на 10% больше мы тем самым получаем возможность восстановления данных без перезапроса в случае, если будет теряться не более каждого десятого пакета.
Эта избыточность — плата пропускной способностью сети за уменьшение задержек (что выглядит логично, ведь скорости соединения и пропускная способность каналов непрерывно растут, а вот тот факт, что передача данных на другой конец планеты занимает сотню миллисекунд — навряд ли удастся как-то изменить без фундаментального переворота в физике).
Возобновление сессии и параллельные загрузки
Ещё одной интересной особенностью использования протокола UDP является то, что вы больше не привязаны к IP сервера. В протоколе TCP соединение определяется четырьмя параметрам: IP-адресами сервера и клиента, портами сервера и клиента. В Linux вы можете увидеть эти параметры для каждого установленного соединения с помощью комманды netstat:
Если любой из этих четырёх параметров потребуется изменить — нам потребуется открывать новое TCP-соединение. Вот почему трудно поддерживать стабильную связь на мобильных устройствах при переключении между WiFi и 3G/LTE.
В QUIC, с его использованием UDP, данного набора параметров больше нет. QUIC вводит понятие идентификатора соединения, называемого Connection UUID. Появляется возможность перейти с WiFi на LTE с сохранением Connection UUID, таким образом избежав затрат на пересоздание соединения. Похожим образом работает Mosh Shell, сохраняя SSH-соединение активным при смене IP-адреса.
Также данный подход открывает двери возможности использования нескольких источников для запроса контента. Если Connection UUID может быть использовано для перехода от WiFi к мобильной сети, то мы можем, теоретически, использовать и их обе одновременно для получения данных параллельно. Больше каналов связи — больше пропускная способность.
Практические реализации QUIC
Браузер Chrome имеет экспериментальную поддержку QUIC с 2014-го года. Если вы хотите потестировать QUIC, то можете включить его поддержку в Chrome и попробовать поработать с сервисами Google, которые его поддерживают. Это сильное преимущество Google — возможность использовать комбинацию своего браузера и своих же веб-ресурсов. Включив QUIC в самом популяром в мире браузере (Chrome) и высоконагруженных сайтах (Youtube.com, Google.com), они смогут получить большую, наглядную статистику использования протокола, что позволит выявить все существенные проблемы практического использования QUIC.
Есть плагин для Chrome, который показывает в виде иконки поддержку сервером протоколов HTTP/2 и QUIC.
Вы также можете увидеть открытые QUIC-соединения открыв вкладку chrome://net-internals/#quic прямо сейчас (обратите внимание в таблице на параметр Connection UUID, упомянутый ранее)
Вы можете пойти ещё дальше и посмотреть все открытые соединения и все переданные по ним пакеты: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.
Как при этом всём работают файрволы?
Если вы — сисадмин или сетевой инженер, то, возможно, слегка дёрнулись, когда услышали о том, что QUIC использует UDP вместо TCP. Да, наверное, у вас есть на то свои причины. Возможно у вас (как, например, и у нас в компании), настройки доступа к веб-серверу выглядят как-то так:
Самое главное здесь, конечно же, столбик протокола, в котором явно написано «TCP». Подобные настройки используются тысячами веб-серверов по всему миру, поскольку они разумны. 80 и 443 порты, только TCP — и больше ничего на продакшн-вебсервере разрешено быть не должно. Никакого UDP.
Ну, если мы хотим использовать QUIC, придётся добавить и разрешение UDP-соединений на 443-ий порт. В больших энтерпрайз-сетях это может быть проблемой. Как показывает статистика Google, UDP кое-где блокируется:
Эти цифры были получены в ходе недавнего исследования в Швеции. Отметим несколько ключевых моментов:
Использование QUIC на серверной стороне
На данный момент QUIC поддерживается вебсервером Caddy (с версии 0.9). И клиентская, и серверная реализация QUIC ещё на стадии экспериментальной поддержки, так что будьте осторожны с практическим применением QUIC. Поскольку ни у кого по-умолчанию не включен QUIC, то, вероятно, будет безопасным включить его на своём сервере и экспериментировать со своим браузером (Обновление: с версии 52 QUIC включён по-умолчанию в Chrome).
Производительность QUIC
В 2015-ом году Google опубликовала некоторые результаты замеров производительности QUIC.
Как и ожидалось, QUIC затмевает классический TCP на плохих каналах связи, давая выигрыш в полсекунды на загрузке стартовой страницы www.google.com на 1% наиболее медленных соединений. Этот выигрыш ещё более заметен на видеосервисах вроде YouTube. Пользователи на 30% меньше жаловались на задержки из-за буферизации при просмотре видео при использовании QUIC.
Статистика Youtube особенно интересна. Если улучшения подобного масштаба действительно возможны, то мы увидим очень быструю адаптацию QUIC как-минимум в сфере видеосервисов вроде Vimeo, а также на рынке «видео для взрослых».
Выводы
Лично я нахожу протокол QUIC совершенно очаровательным! Огромный объём работы, проделанный его разработчиками, не пропал даром — один лишь факт того, что уже сегодня крупнейшие сайты в Интернете поддерживают QUIC, немного ошеломляет. Я жду не дождусь финальной спецификации QUIC, ну и дальнейшей её реализации всеми браузерами и веб-серверами.
Комментарий к статье от Jim Roskind, одного из разработчиков QUIC
Я потратил много лет на исследования, дизайн и разработку реализации протокола QUIC, и хотел бы добавить к статье кое-какие свои мысли. В тексте был верно подмечен момент о вероятной недоступности протокола QUIC у некоторых пользователей из-за строгих корпоративных политик в отношении протокола UDP. Это и было причиной того, что мы получили среднюю доступность протокола на уровне в 93%.
Если мы вернёмся немного в прошлое, то увидим что ещё совсем недавно корпоративные системы часто запрещали даже исходящий трафик к 80-му порту, с аргументацией «это уменьшит количество времени, которое работники тратят на серфинг в ущерб работе». Позже, как вы знаете, преимущества доступа к веб-сайтам (в том числе в производственных целях) вынудило большинство корпораций пересмотреть свои правила, разрешив выход в интернет с рабочего места рядового сотрудника. Я ожидаю чего-то аналогичного и с протоколом QUIC: как-только станет понятно, что с новым протоколом связь может быть быстрее, задачи выполняются оперативнее — он пробьёт себе путь и в энтерпрайз.
Я рассчитываю, что QUIC массово заместит собой TCP, и это даже помимо того, что он подарит следующей версии TCP ряд своих идей. Дело в том, что TCP реализуется в ядрах операционных систем, в железе, а значит адаптация к новой версии может занять 5-15 лет, в то время как внедрить QUIC поверх общедоступного и всеми поддерживаемого UDP можно в отдельно взятом продукте\сервисе буквально за несколько недель или месяцев.