Quick протокол что это
Транспортный протокол 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.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Знакомство с QUIC (Quick UDP Internet Connections)
В 2012 году Джим Роскинд разработал новый транспортный протокол, основной целью которого было увеличение скорости, с которой данные могут передаваться по относительно стабильным высокоскоростным сетям. В частности:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Уменьшение рукопожатия при запуске
Как только клиент получает STK, он включает его в будущие пакеты приветствия. Если STK совпадает с ранее использованным STK с этого IP-адреса, сервер примет приветствие.
Примечание: Эта пара IP-адрес / STK может быть украдена, и, следовательно, исходный IP-адрес может быть подменен злоумышленником с доступом к любой связи с этой парой. Это известная проблема в QUIC, которая рассматривается в документации QUIC.
Для сравнения, TCP требует, как минимум полтора rtts для создания нового сеанса:
SYN, SYN-ACK, а затем следующий ACK. Сколько времени экономит при переходе на одно соединение rtt? Конечно, это зависит от реализации клиентского и серверного приложений. Однако многие веб-страницы и приложения для мобильных устройств должны подключаться к множеству разных серверов (возможно, к сотням) для создания единой веб-страницы. Если каждое из этих подключений уменьшить с полутора до одного RTT, это может значительно снизить производительность.
Сокращение повторных передач
QUIC использует ряд различных механизмов для уменьшения количества повторно передаваемых пакетов:
Окно отправителя устанавливается на WMIN, а затем быстро увеличивается до размера окна посередине между WMIN и WMAX. Как только окно достигает этой средней точки, размер окна очень медленно увеличивается при так называемом зондировании, пока не встретится следующий сброс пакета. Этот процесс позволяет CUBIC находить максимальную скорость передачи чуть ниже точки, в которой сеть начинает довольно быстро отбрасывать пакеты.
Исключение блокировки начала строки
«Единая транзакция» в Интернете часто является не «отдельной транзакцией«, а скорее большим набором транзакций на нескольких разных серверах. Например, чтобы создать единую веб-страницу, сотни элементов, таких как изображения, скрипты, элементы каскадной таблицы стилей (CSS) и файлы языка гипертекстовой разметки (HTML), должны быть переданы с сервера на клиент. Эти файлы можно передавать двумя способами: последовательно или параллельно. Рисунок 1 иллюстрирует это.
На рисунке 1 показаны три варианта передачи нескольких элементов от сервера к клиенту:
Некоторые формы механизма мультиплексной передачи имеют тенденцию обеспечивать максимальную скорость передачи при наиболее эффективном использовании ресурсов, но как это мультиплексирование должно быть реализовано? Протокол передачи гипертекста версии 2 (HTTPv2) позволяет веб-серверу мультиплексировать несколько элементов в одном сеансе HTTP; поскольку HTTP работает поверх TCP, это означает, что один поток TCP может использоваться для параллельной передачи нескольких элементов веб-страницы. Однако один отброшенный пакет на уровне TCP означает, что каждая параллельная передача в потоке HTTP должна быть приостановлена на время восстановления TCP.
Обнаружение MTU пути
Одним из основных вопросов спора между асинхронным режимом передачи (ATM) и интернет-протоколом (IP) был фиксированный размер ячейки. В то время как IP-сети полагаются на пакеты переменной длины, ATM, чтобы обеспечить более высокую скорость коммутации и улучшить взаимодействие с множеством различных физических уровней Time Division Multiplexing (TDM), задал ячейки фиксированной длины. В частности, IPv4 обеспечивает не только пакет переменной длины, но и фрагментацию в процессе передачи. Рисунок 2 иллюстрирует это.
Первый заключается в том, что C фрагментирует пакет на два меньших пакета. Это возможно в IPv4; C может определить, что пакет не поместится на следующем канале, по которому пакет должен быть передан, и разбить пакет на два меньших пакета. Конечно, с этим решением есть ряд проблем. Например, процесс фрагментации пакета требует гораздо больше работы со стороны C, возможно, даже перемещение пакета из аппаратного пути коммутации в программный путь коммутации.
Во-вторых, A никогда не отправляет пакет, превышающий минимальный MTU, по всему пути к E. Для этого A должен определить минимальный MTU на пути, и он должен иметь возможность фрагментировать информацию, отправляемую из протоколов верхнего уровня на несколько пакетов перед передачей. IPv6 выбирает этот последний вариант, полагаясь на обнаружение Path MTU (PMTU), чтобы найти минимальный MTU на пути (при условии, что PMTU действительно работает), и позволяя процессу IPv6 в A фрагментировать информацию из протоколов верхнего уровня на несколько пакетов, которые затем повторно собираются в исходный блок данных верхнего уровня в приемнике.
Это решение, однако, также является проблемным. В недавней работе с системой доменных имен (DNS) исследователи обнаружили, что около 37% всех DNS- resolvers отбрасывают фрагментированные пакеты IPv6. Почему это происходит? Самый простой способ понять это-рассмотреть структуру фрагментированного пакета, а также природу DoS и DDoS атак.
При передаче пакета, в пакет помещается заголовок, указывающий принимающую услугу (номер сокета или протокола какого-либо рода), а также информацию о передаваемой услуге. Эта информация важна для фильтрации пакета на основе различных политик безопасности, особенно если политика безопасности гласит: «разрешать только пакеты инициации сеанса в сеть, если пакет не принадлежит существующему сеансу.» Другими словами, типичный фильтр с отслеживанием состояния, защищающий сервер, будет иметь некоторые основные правила, которым он следует:
Возможно подделать пакет, похожий на настоящий, но это очень сложно, т.к. используются различные nonce и другие методы, чтобы препятствовать подобному поведению. Но фрагментация пакета удаляет заголовок из второй половины пакета, что фактически означает, что второй пакет во фрагментированной паре может быть присоединен только к определенному сеансу или потоку, отслеживая часть пакета, которая имеет полный заголовок.
Как маршрутизатор или middlebox могут выполнить это? Он должен каким-то образом хранить копию каждого фрагмента пакета с заголовком где-нибудь в памяти, чтобы на пакет с заголовком можно было ссылаться для обработки любых будущих фрагментов. Как долго он должен хранить эти фрагменты с заголовками? На это нет ответа. Проще просто отбросить любые фрагменты, чем поддерживать состояние, необходимое для их обработки.
Каков результат? Похоже, что даже фрагментация на основе исходного кода не очень полезна на уровне IP.
Это должно напомнить об одном из основополагающих принципов пакета Интернет-протоколов: end-to-end принципе. End-to-end принцип гласит, что сеть не должна изменять трафик, передаваемый между двумя оконечными устройствами; или, скорее, сеть должна работать как черный ящик, соединяющий два устройства, никогда не изменяя данные, полученные от конечного хоста.
Означает ли это, что вся фильтрация трафика должна быть запрещена в общедоступном Интернете, всерьез навязывая end-to-end правило, оставляя всю безопасность конечным хостам?
Другая альтернатива-принять еще одну частицу реальности, часто забываемую в мире сетевой инженерии: утечку абстракций. Сквозной принцип описывает идеально абстрагированную систему, способную передавать трафик от одного хоста к другому, и идеально абстрагированный набор хостов, между которыми осуществляется трафик. Но все нетривиальные абстракции протекают; проблема MTU и фрагментации-это просто утечка состояния из сети в хост, и система на хосте пытается абстрагировать эту утечку в приложение, отправляющее трафик по сети. В такой ситуации, возможно, лучше всего просто признать утечку и официально продвинуть информацию вверх по стеку, чтобы приложение могло принять лучшее решение о том, как отправлять трафик.
Но это приводит к еще одному интересному вопросу для размышления: является ли описанная здесь фильтрация состояний предательством end-to-end принципа? Ответ зависит от того, считаете ли вы протокол верхнего уровня, отправляющий данные, конечной точкой, или систему, на которой работает приложение (следовательно, включая сам стек IP), конечной точкой. Так или иначе, эта двусмысленность преследовала Интернет с самых ранних дней, хотя мир сетевой инженерии не всегда серьезно задумывался о разнице между этими двумя точками зрения.
Ответ на слишком большой пакет можно использовать для определения максимального размера передаваемого блока (MTU) в сети; отправитель может передать большой пакет и дождаться, чтобы увидеть, не отправит ли какое-либо устройство в сети уведомление о слишком большом пакете через ICMP. Если такое уведомление приходит, отправитель может попробовать постепенно уменьшать пакеты, чтобы определить самый большой пакет, который может быть передан из конца в конец по сети.
Ответ с истекшим транзитом может использоваться для отслеживания маршрута от источника до пункта назначения в сети (это называется трассировкой маршрута). Отправитель может передать пакет в конкретное место назначения, используя любой протокол транспортного уровня (включая TCP, UDP или QUIC), но с TTL равным 1. Сетевое устройство первого перехода должно уменьшить TTL и отправить обратно ICMP-сообщение с истекшим сроком действия в транзитном уведомлении отправителю. Отправляя серию пакетов, каждый с TTL на один больше, чем предыдущий, каждое устройство на пути может быть вынуждено передать отправителю сообщение ICMP с истекшим сроком действия в транзитном уведомлении, открывая весь путь пакета.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Что такое сетевой протокол QUIC? Безупречен ли он?
Google является одним из ведущих пользователей QUIC. Он включен по умолчанию в Google Chrome и Opera 16, Google search, Gmail, Youtube и других службах Google. Chrome занимает 70% рынка браузеров, поэтому можно ожидать, что другие браузеры начнут использовать этот протокол очень скоро.
Безупречен ли QUIC?
У протокола QUIC мало недостатков. Он улучшает связь и уменьшает задержку, но все еще находится на стадии эксперимента. Он не получил широкого распространения на других сайтах или серверах, а также не поддерживается такими инструментами кибербезопасности, как брандмауэры. Из-за этого, экспериментальный протокол QUIC в настоящее время может открыть лазейку в системе безопасности.
Брандмауэры передают HTTP и HTTPS трафик через модуль web protection module, который выполняет сканирование на вредоносное ПО. Но что произойдет, если соединение будет осуществляться через QUIC? Браузер и поддерживающие серверы действительно распознают его как соединение QUIC, но устройство, на котором вы работаете, может и не распознать. Оно может рассматривает его как простой UDP-трафик, который не посылается на модуль защиты вашего брандмауэра.
Что можно сделать?
До тех пор, пока новый протокол не получит более широкое распространение и не будет признан большинством брандмауэров, рекомендуется блокировать или отключить QUIC:
На видео: Проблемы TCP и немного о QUIC — Илья Барбашов
По пути к QUIC: что лежит в основе HTTP/3
QUIC (Quick UDP Internet Connections) – это новый, шифрованный по умолчанию, протокол транспортного уровня, который имеет множество улучшений HTTP: как для ускорения трафика, так и для повышения уровня безопасности. Также QUIC имеет долгосрочную цель – в итоге заменить TCP и TLS. В этой статье мы рассмотрим как ключевые фишки QUIC и почему веб выиграет за счет них, так и проблемы поддержки этого абсолютно нового протокола.
По факту существует два протокола с таким именем: Google QUIC (gQUIC), изначальный протокол, который разработали инженеры Google несколько лет назад, который после ряда экспериментов был принят IETF (Internet Engineering Task Force) в целях стандартизации.
IETF QUIC (далее – просто QUIC) уже имеет настолько сильные расхождения с gQUIC, что может считаться отдельным протоколом. От формата пакетов до хендшейка и мэппинга HTTP – QUIC улучшил оригинальную архитектуру gQUIC благодаря сотрудничеству со многими организациями и разработчиками, которые преследуют единую цель: сделать Интернет быстрее и безопаснее.
Итак, какие улучшения предлагает QUIC?
Встроенная безопасность (и производительность)
Одно из самых заметных отличий QUIC от почтенного TCP – это изначально заявленная цель быть транспортным протоколом, который безопасен по умолчанию. QUIC добивается этого с помощью аутентификации и шифрования, которые обычно происходят на уровне выше (например, в TLS), а не в самом транспортном протоколе.
Первоначальный хендшейк в QUIC сочетает привычное трехстороннее общение по TCP с TLS 1.3 хендшейком, который обеспечивает аутентификацию участников, равно как и согласование криптографических параметров. Для тех, кто хорошо знаком с TLS: QUIC заменяет уровень записи TLS своим собственным форматом кадра, но при этом использует хендшейки TLS.
Это не только позволяет соединению быть всегда шифрованным и аутентифицированным, но также быстрее делать первоначальное соединение: рядовой QUIC-хендшейк делает обмен между клиентом и сервером за один проход, в то время как TCP + TLS 1.3 делают два прохода.
Однако QUIC идет дальше и также шифрует метаданные о соединении, которые могут быть легко скомпрометированы третьей стороной. Например, атакующие могут использовать номера пакетов, чтобы направлять пользователей по множеству сетевых путей, когда используется миграция соединения (см. ниже). QUIC шифрует номера пакетов, поэтому они не могут быть скорректированы никем, кроме настоящих участников соединения.
Шифрование также может быть эффективно против «косности» – феномена, которые не дает использовать гибкость протокола на практике из-за неверных предположений в реализациях (ossification – то, что из-за чего долго откладывали выкладку TLS 1.3. Выложили только после нескольких изменений, которые предотвратят нежелательные блоки для новых ревизий TLS).
Блокировка начала очереди (Head-of-line blocking)
Одним из главных улучшений, которое нам принес HTTP/2, это возможность объединять разные HTTP-запросы в одном TCP-соединении. Это позволяет приложениям на HTTP/2 параллельно обрабатывать запросы и лучше использовать сетевой канал.
Конечно, это было значительным шагом вперед. Потому что ранее приложениям нужно было инициировать множество TCP+TLS соединений, если они хотели одновременно обрабатывать несколько HTTP-запросов (например, когда браузеру нужно получить и CSS, и JavaScript чтобы отрисовать страницу). Создание новых соединений требует множественных хендшейков, а также инициализацию окна перегрузки: это означает замедление рендеринга страницы. Объединенные HTTP-запросы позволяют избежать этого.
Однако здесь есть недостаток: так как множественные запросы/ответы передаются по тому же TCP-соединению, они все одинаковы зависимы от потери пакетов, даже если потерянные данные касаются лишь одного из запросов. Это и называется «блокировкой начала очереди».
QUIC идет глубже и дает первоклассную поддержку для объединения запросов, например, разные HTTP-запросы могут быть расценены как разные транспортные QUIC-запросы, но при этом все они будут использовать одно и то же соединение QUIC – то есть дополнительные хендшейки не нужны, есть единое состояние перегрузки, запросы QUIC доставляются независимо – в итоге, в большинстве случаев потеря пакетов затрагивает только один запрос.
Таким образом можно существенно сократить время на, например, полный рендеринг веб-страницы (CSS, JavaScript, картинки и прочие ресурсы), особенно в случае перегруженной сети с высокой потерей пакетов.
Так просто, да?
Чтобы выполнить свои обещания, протокол QUIC должен преодолеть некоторые допущения, которые приняли во многих сетевых приложениях как нечто само собой разумеющееся. Это может затруднить имплементацию и внедрение QUIC.
QUIC спроектирован, чтобы доставляться поверх UDP-датаграмм, дабы облегчить разработку и избежать проблем с сетевыми устройствами, которые отбрасывают пакеты неизвестных протоколов (потому что большинство устройств поддерживают UDP). Также это позволяет QUIC жить в user-space, поэтому, например, браузеры смогут внедрять новые фишки протокола и доносить их до конечных пользователей, не дожидаясь обновлений ОС.
Тем не менее, благая цель – уменьшить сетевые проблемы – делает более трудным защиту пакетов и их правильный роутинг.
Один NAT чтобы всех воедино созвать и единою черною волей сковать
Обычно NAT-роутеры работают с TCP-соединениями, используя кортеж из 4 значений (исходные IP и порт плюс IP и порт назначения), а также отслеживая TCP SYN, ACK и FIN-пакеты, переданные по сети; роутеры могут определять, когда установилось новое соединение и когда закончилось. Поэтому возможно точное управление привязками NAT (связи между внутренними и внешними IP и портами).
В случае QUIC это пока невозможно, т.к. современные NAT-роутеры еще не знают про QUIC, поэтому они обычно делают даунгрейд к дефолтной и менее точной обработке UDP, что означает таймауты произвольной (иногда малой) длительности, которые могут влиять на длительные соединения.
Когда происходит перепривязка (например, из-за таймаута), устройство вне периметра NAT начинает получать пакеты из другого источника, из-за чего невозможно поддерживать соединение используя только лишь кортеж из 4 значений.
И дело не только в NAT! Одна из фишек QUIC называется connection migration и позволяет устройствам по их усмотрению переносить соединения на другие IP-адреса/пути. Например, мобильный клиент сможет перенести QUIC-соединение с мобильной сети на уже известную WiFi-сеть (пользователь зашел в любимую кофейню и т.п.).
QUIC пытается решить эту проблему с помощью концепции connection ID: кусок информации произвольной длины, передаваемый в пакетах QUIC и позволяющий идентифицировать соединение. Конечные устройства могут использовать этот ID, чтобы отслеживать свои соединения без сверки с кортежем. На практике тут должно быть множество ID, которые указывают на одно и то же соединение, к примеру, чтобы избежать соединения разных путей, когда происходит миграция соединения – потому что весь процесс контролируется только конечными устройствами, а не миддлбоксами.
Однако и здесь может быть проблема для операторов связи, которые используют anycast и ECMP-роутинг, где один IP потенциально может идентифицировать сотни или тысячи серверов. Так как пограничные маршрутизаторы в этих сетях еще не знают, как обрабатывать QUIC-трафик, то может случиться так, что UDP-пакеты из одного QUIC-соединения, но с разными кортежами будут отданы разным серверам, что означает разрыв соединения.
Чтобы избежать этого, операторам может понадобиться внедрить более умный балансировщик на 4 уровне. Этого можно добиться программно, не затрагивая сами пограничные роутеры (для примера см. проект Katran от Facebook).
QPACK
Другой полезной особенностью HTTP/2 было сжатие заголовков (HPACK), которое позволяет конечным устройствам уменьшать размер пересылаемых данных за счет отбрасывания ненужного в запросах и ответах.
В частности, помимо прочих техник, HPACK использует динамические таблицы с заголовками, которые уже были отправлены/получены от прошлых HTTP-запросов/ответов, что позволяет устройствам ссылаться в новых запросах/ответах на ранее встречавшиеся заголовки (вместо того, чтобы снова их передавать).
Таблицы HPACK должны быть синхронизированы между кодером (стороной, которая шлет запрос/ответ) и декодером (принимающая сторона), иначе декодер просто не сможет декодировать то, что получает.
В случае HTTP/2 поверх TCP эта синхронизация прозрачна, потому что транспортный уровень (TCP) обеспечивает доставку запросов/ответов в том же порядке, в каком они они были отправлены. То есть отправить декодеру инструкции по обновлению таблиц можно в простом запросе/ответе. Но в случае QUIC все намного сложнее.
QUIC может доставлять множественные HTTP-запросы/ответы по разным направлениям одновременно, что означает, что QUIC гарантирует порядок доставки в рамках одного направления, при это такой гарантии нет в случае множества направлений.
Например, если клиент отправляет HTTP-запрос А в QUIC-потоке А, а также запрос B в потоке B, то из-за перестановки пакетов или сетевых потерь, сервер получит запрос B до запроса А. И если запрос B был закодирован так, как было указано в заголовке запросе А, то сервер просто не сможет декодировать запрос B, так как он еще не видел запрос А.
В протоколе gQUIC эту проблему решили, просто сделав все заголовки (но не тела) HTTP-запросов/ответов последовательными в рамках одного gQUIC-потока. Это дало гарантию, что все заголовки придут в нужном порядке, что бы ни случилось. Это весьма простая схема, с ее помощью существующие решения могут продолжать использовать код, заточенный под HTTP/2; с другой стороны, это увеличивает вероятность блокировки начала очереди, снижать которую как раз и призван QUIC. Поэтому рабочая группа по QUIC из IETF разработала новый маппинг между HTTP и QUIC (HTTP/QUIC), а также новый принцип сжатия заголовков – QPACK.
В последнем драфте спецификаций HTTP/QUIC и QPACK каждый обмен HTTP-запросом/ответом использует свой собственный двунаправленный поток QUIC, так что блокировка начала очереди не возникает. Также, ради поддержки QPACK, каждый участник создает два дополнительных, однонаправленных потока QUIC, один для отправки обновлений таблиц, другой – для подтверждения их получения. Таким образом, кодер QPACK может использовать ссылку на динамическую таблицу только после того, как ее получение подтвердил декодер.
Преломляя отражение
Общая проблема основанных на UDP протоколов – их восприимчивость к атакам отражения, когда атакующий заставляет некий сервер отправлять огромное количество данных жертве. Атакующий подменяет свой IP, чтобы сервер думал, что запрос данных приходил с адреса жертвы.
Эта разновидность атаки может быть очень эффективна, когда ответ сервер несравнимо больше, чем запрос. В таком случае говорят об «усилении».
TCP обычно не используется для таких атак, потому что пакеты в изначальном хендшейке (SYN, SYN+ACK, …) имеют одинаковую длину, поэтому у них нет потенциала для «усиления».
С другой стороны, хендшейк QUIC очень ассиметричен: как и в TLS, сначала сервер QUIC отправляет свою цепочку сертификатов, которая может быть весьма большой, несмотря на то, что клиент должен отправить только несколько байт (сообщение от TLS-клиента ClientHello встроено в пакет QUIC). По этой причине, первоначальный пакет QUIC должен быть увеличен до определенной минимальный длины, даже если содержимое пакета значительно меньше. Как бы то ни было, эта мера все еще не очень эффективна, так как типичный ответ сервера содержит несколько пакетов и поэтому может быть больше чем увеличенный клиентский пакет.
Протокол QUIC также определяет явный механизм верификации источника: сервер, вместо того чтобы отдавать большой ответ, отправляет только retry-пакет с уникальным токеном, который клиент затем отправит серверу в новом пакете. Так у сервера есть бОльшая уверенность, что у клиента не подменный IP-адрес и можно завершить хендшейк. Минус решения – увеличивается время хендшейка, вместо одного прохода уже потребуется два.
Альтернативное решение заключается в уменьшении ответа сервера до размера, при котором атака отражения становится менее эффективной – например, с помощью сертификатов ECDSA (обычно они значительно меньше, чем RSA). Мы также экспериментировали с механизмом сжатия TLS-сертификатов, используя off-the-shelf алгоритмы сжатия вроде zlib и brotli; это фича, которая впервые появилась в gQUIC, но сейчас не поддерживается в TLS.
Производительность UDP
Одна из постоянных проблем QUIC – это ныне существующие железо и софт, которые не способны работать с QUIC. Мы уже рассматривали, как QUIC пытается справляться с сетевыми миддлбоксами вроде роутеров, однако другая потенциально проблемная зона это производительность отправки/получения данных между QUIC-устройствами по UDP. Долгие годы прикладывались усилия, чтобы оптимизировать реализации TCP насколько это возможно, включая встроенные возможности по разгрузке в софте (например, операционные системы) и в железе (сетевые интерфейсы), но ничто из этого не касается UDP.
Однако это лишь вопрос времени, пока реализации QUIC превзойдут эти улучшения и преимущества. Взгляните на недавние усилия внедрить разгрузку UDP на Linux, которая позволила бы приложениям объединять и передавать множественные UDP-сегменты между user-space и kernel-space сетевым стеком по затратам примерно одного сегмента; другой пример – поддержка zerocopy для сокетов в Linux, благодаря которой приложения смогли бы избегать затрат по копированию user-space памяти в kernel-space.