Quick 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-соединения через Google Cloud lb, который поддерживает протокол с середины 2018 года.

Неудивительно, что Google Cloud прекрасно работает с протоколом, разработанным Google, но какие есть альтернативы?

Nginx

Здесь можно подключить свои модули при необходимости

Остаётся только включить поддержку HTTP/3

Другие технологии

Заключение

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

Уже сейчас вы можете настроить QUIC-взаимодействие для своей инфраструктуры или даже отдавать его браузерам — они все планируют добавить поддержку протокола, и печальная статистика с caniuse станет веселее.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

На смену TCP пришел Quic — протокол, который может стать главной интернет-новацией следующего десятилетия

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

Соответственно, нужен новый, более совершенный протокол. И им может стать протокол Quic, разработанный несколько лет назад. Более того, протокол уже прошел исчерпывающее тестирование в части веб-браузеров и онлайн-сервисов и уже доказал свою состоятельность и надежность. Недавно он был опубликован рабочей группой IETF, занимающейся разработкой и тестированием сетевых протоколов, как стандарт с лучшими возможностями, чем это наблюдается сейчас у TCP.

Задача улучшения интернета на базовом уровне установления соединения кажется невероятно трудной. Она усложняется тем, что огромное количество сервисов, программ и устройств настроены и работают на инфраструктуре, созданной несколько десятилетий назад. В то же время есть четкое понимание того, что интернет должен эволюционировать, несмотря на затраты и неудобства. Таким образом, внедрение протокола Quic в той же степени является необходимостью, как и внедрение IPv6, HTTPS и пост квантовой криптографии. Протокол Quic может стать главной интернет-новацией следующего десятилетия.

Что такое протокол Quic для обычного пользователя?

На этот вопрос отвечает исследование, проведенное Google несколько лет назад. Специалисты пришли к выводу, что Quic ускоряет поиск на 8% и 4% на компьютерах и смартфонах, соответственно. А время буферизации при просмотре видео сократилось для этих же групп устройств на 18% и 15%. Стандарт Quic решает те же задачи, что и TCP, но справляется с ними существенно лучше. Это проявляется не только в большей устойчивости, но и в большей скорости отработки запросов. Его преимущества могут в полной мере проявиться, например, когда пользователь покидает зону домашнего Wi-Fi и начинает пользоваться сетью мобильного оператора.

Источник

Протокол QUIC в деле: как его внедрял Uber, чтобы оптимизировать производительность

Картинки кликабельны. Приятного чтения!

Uber – это мировой масштаб, а именно 600 городов присутствия, в каждом из которых приложение полностью полагается на беспроводной интернет от более чем 4500 сотовых операторов. Пользователи ожидают, что приложение будет работать не просто быстро, а в реальном времени – чтобы обеспечить это, приложению Uber нужны низкие задержки и очень надежное соединение. Увы, но стек HTTP/2 плохо себя чувствует в динамичных и склонных к потерям беспроводных сетях. Мы уяснили, что в данном случае низкая производительность напрямую связана с реализациями TCP в ядрах операционных систем.

Чтобы решить проблему, мы применили QUIC, современный протокол с мультиплексированием каналов, который дает нам больше контроля над производительностью транспортного протокола. В данный момент рабочая группа IETF стандартизирует QUIC как HTTP/3.

После подробных тестов, мы пришли к выводу, что внедрение QUIC в наше приложение сделает «хвостовые» задержки меньше по сравнению с TCP. Мы наблюдали снижение в диапазоне 10-30% для HTTPS-трафика на примере водительского и пассажирского приложений. Также QUIC дал нам сквозной контроль над пользовательскими пакетами.

В этой статье мы делимся опытом по оптимизации TCP для приложений Uber с помощью стека, который поддерживает QUIC.

Последнее слово техники: TCP

Сегодня TCP – самый используемый транспортный протокол для доставки HTTPS-трафика в сети Интернет. TCP обеспечивает надежный поток байтов, тем самым справляясь с перегрузкой сети и потерями канального уровня. Широкое применение TCP для HTTPS-трафика объясняется вездесущностью первого (почти каждая ОС содержит TCP), доступностью на бОльшей части инфраструктуры (например, на балансировщиках нагрузки, HTTPS-прокси и CDN) и функциональностью «из коробки», которая доступна почти в большинстве платформ и сетей.

Большинство пользователей используют наше приложение на ходу, и «хвостовые» задержки TCP были далеки от требований нашего HTTPS-трафика в реальном времени. Проще говоря, с этим сталкивались пользователи по всему миру – на Рисунке 1 отражены задержки в крупных городах:

Рисунок 1. Величина «хвостовых» задержек варьируется в основных городах присутствия Uber.

Несмотря на то, что задержки в индийских и бразильских сетях были больше, чем в США и Великобритании, хвостовые задержки значительно больше чем задержки в среднем. И это так даже для США и Великобритании.

Производительность TCP по воздуху

TCP был создан для проводных сетей, то есть с упором на хорошо предсказуемые ссылки. Однако у беспроводных сетей свои особенности и трудности. Во-первых, беспроводные сети чувствительны к потерям из-за помех и затухания сигнала. Например, сети Wi-Fi чувствительны к микроволнам, bluetooth и прочим радиоволнам. Сотовые сети страдают от потери сигнала (потери пути) из-за отражения/поглощения сигнала предметами и строениями, а также от помех от соседних сотовых вышек. Это приводит к более значительным (в 4-10 раз) и разнообразным круговым задержкам (RTT) и потерям пакетов по сравнению с проводным соединением.

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

Наконец, производительность сотовой сети меняется в зависимости от оператора связи, региона и времени. На Рисунке 2 мы собрали медианные задержки HTTPS-трафика по сотам в диапазоне 2 километров. Данные собраны для двух крупнейших операторов сотовой связи в Дели, Индия. Как можно заметить, производительность меняется от соты к соте. Также производительность одного оператора отличается от производительности второго. На это влияют такие факторы как паттерны входа в сеть с учетом времени и локации, подвижность пользователей, а также сетевая инфраструктура с учетом плотности вышек и соотношения типов сети (LTE, 3G и т.д.).

Рисунок 2. Задержки на примере 2-километрового радиуса. Дели, Индия.

Также производительность сотовых сетей меняется во времени. На Рисунке 3 показана медианная задержка по дням недели. Мы также наблюдали разницу в более маленьком масштабе – в рамках одного дня и часа.

Рисунок 3. Хвостовые задержки могут значительно меняться в разные дни, но у того же оператора.

Анализ производительности TCP

Чтобы понять, как мы анализировали производительность TCP, давайте коротко вспомним, как TCP передает данные от отправителя получателю. Вначале отправитель устанавливает TCP-соединение, выполняя трехсторонний хендшейк: отправитель отправляет SYN-пакет, ждет SYN-ACK-пакет от получателя, затем шлет ACK-пакет. Дополнительные второй и третий проходы уходят на создание TCP-соединения. Получатель подтверждает получение каждого пакета (ACK), чтобы обеспечить надежную доставку.

Если потерян пакет или ACK, отправитель делает ретрансмит после таймаута (RTO, retransmission timeout). RTO рассчитывается динамически, на основании разных факторов, например, на ожидаемой задержке RTT между отправителем и получателем.

Рисунок 4. Обмен пакетами по TCP/TLS включает механизма ретрансмита.

Чтобы определить, как TCP работал в наших приложениях, мы отслеживали TCP-пакеты с помощью tcpdump в течение недели на боевом трафике, идущем с индийских пограничных серверов. Затем мы проанализировали TCP-соединения с помощью tcptrace. Дополнительно мы создали Android-приложение, которое шлет эмулированный трафик на тестовый сервер, максимально подражая реальному трафику. Смартфоны с этим приложением были розданы нескольким сотрудникам, кто собирал логи на протяжении нескольких дней.

Результаты обоих экспериментов были сообразны друг другу. Мы увидели высокие RTT-задержки; хвостовые значения были почти в 6 раз выше медианного значения; среднее арифметическое значение задержек – более 1 секунды. Многие соединения были с потерями, что заставляло TCP ретрансмитить 3,5% всех пакетов. В районах с перегрузкой, например, аэропорты и вокзалы, мы наблюдали 7%-ные потери. Такие результаты ставят под сомнение расхожее мнение, что используемые в сотовых сетях продвинутые схемы ретрансмиссии значительно снижают потери на транспортном уровне. Ниже – результаты тестов из приложения-«симулянта»:

1,2 сПотеря пакетов в неустойчивых соединенияхВ среднем

3.5% (7% в районах с перегрузкой)

Почти в половине этих соединений была как минимум одна потеря пакетов, по большей части это были SYN и SYN-ACK-пакеты. Большинство реализаций TCP используют значение RTO в 1 секунду для SYN-пакетов, которое увеличивается экспоненциально для последующих потерь. Время загрузки приложения может увеличиться за счет того, что TCP потребуется больше времени на установку соединений.

В случае пакетов данных, высокие значения RTO эффективно снижают нагрузку на сеть при наличии временных потерь в беспроводных сетях. Мы выяснили, что среднее время ретрансмита – примерно 1 секунда с хвостовой задержкой почти в 30 секунд. Такие высокие задержки на уровне TCP вызывали HTTPS-таймауты и повторные запросы, что еще больше увеличивало задержку и неэффективность сети.

В то время как 75-й процентиль измеренных RTT был в районе 425 мс, 75-й процентиль для TCP был почти 3 секунды. Это намекает на то, что потери заставляли TCP делать 7-10 проходов чтобы успешно передать данные. Это может быть следствием неэффективного расчета RTO, невозможности TCP быстро реагировать на потерю последних пакетов в окне и неэффективности алгоритма управления перегрузкой, который не различает беспроводные потери и потери из-за сетевой перегрузки. Ниже – результаты тестов потерь TCP:

Применение QUIC

Изначально спроектированный компанией Google, QUIC – это мультипоточный современный транспортный протокол, который работает поверх UDP. На данный момент QUIC в процессе стандартизации (мы уже писали, что существует как бы две версии QUIC, любознательные могут пройти по ссылке – прим. переводчика). Как показано на Рисунке 5, QUIC разместился под HTTP/3 (собственно, HTTP/2 поверх QUIC – это и есть HTTP/3, который сейчас усиленно стандартизируют). Он частично заменяет уровни HTTPS и TCP, используя UDP для формирования пакетов. QUIC поддерживает только безопасную передачу данных, так как TLS полностью встроен в QUIC.

Рисунок 5: QUIC работает под HTTP/3, заменяя TLS, который раньше работал под HTTP/2.

Альтернативы QUIC

Мы рассматривали альтернативные подходы к решению проблемы до того, как выбрать QUIC.

Первым делом мы попробовали развернуть TPC PoPs (Points of Presence), чтобы закрывать TCP-соединения ближе к пользователям. По сути, PoPs прерывает TCP-соединение с мобильным устройством ближе к сотовой сети и проксирует трафик до изначальной инфраструктуры. Завершая TCP ближе, мы потенциально можем уменьшить RTT и быть уверенными, что TCP будет более активно реагировать на динамичное беспроводное окружение. Однако наши эксперименты показали, что по большей части RTT и потери приходят из сотовых сетей и использование PoPs не обеспечивает значительного улучшения производительности.

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

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

Наши изыскания показали, что QUIC – едва ли не единственный протокол, который может помочь с проблемой Интернет-трафика, при этом учитывая как безопасность, так и производительность.

Интеграция 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

На стороне бэкенда прерывание QUIC обеспечено инфраструктурой Google Cloud Load balancing, которая использует alt-svc заголовки в ответах, чтобы поддерживать QUIC. В общем случае, к каждому HTTP-запросу балансировщик добавляет заголовок alt-svc и уже он валидирует поддержку QUIC для домена. Когда клиент Cronet получает HTTP-ответ с таким заголовком, он использует QUIC для последующих HTTP-запросов к этому домену. Как только балансировщик прерывает QUIC, наша инфраструктура явно отправляет это действие по HTTP2/TCP в наши дата-центры.

Производительность: результаты

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

Эксперимент 1

Эксперимент 2

Когда Google сделал QUIC доступным с помощью Google Cloud Load Balancing, мы использовали тот же инвентарь, но с одной модификацией: вместо NGINX, мы взяли гугловские балансировщики для завершения TCP и QUIC-соединений от устройств, а также для направления HTTPS-трафика в сервер эмуляции. Балансировщики распределены по всему миру, но используют ближайший к устройству PoP-сервер (спасибо геолокации).

Рисунок 7. Во втором эксперименте мы хотел сравнить задержку завершения TCP и QUIC: с помощью Google Cloud и с помощью нашего облачного прокси.

Боевой трафик

Вдохновленные экспериментами, мы внедрили поддержку QUIC в наши Android и iOS-приложения. Мы провели A/B тестирование, чтобы определить влияние QUIC в городах присутствия Uber. В целом, мы увидели значимое снижение хвостовых задержек в разрезе как регионов, так и операторов связи и типа сети.

На графиках ниже показаны процентные улучшения хвостов (95 и 99 процентили) по макрорегионам и разным типам сети – LTE, 3G, 2G.

Рисунок 9. В боевых тестах QUIC превзошел TCP по задержкам.

Только вперед

Пожалуй, это только начало – выкатка QUIC в продакшн дала потрясающие возможности улучшить производительность приложений как в стабильных, так и нестабильных сетях, а именно:

Увеличение покрытия

Проанализировав производительность протокола на реальном трафике, мы увидели, что примерно 80% сессий успешно использовали QUIC для всех запросов, в то время как 15% сессий использовали сочетание QUIC и TCP. Мы предполагаем, что сочетание появилось из-за того, что библиотека Cronet переключается обратно на TCP по таймауту, так как она не может различать реальные UDP-сбои и плохие условия сети. Сейчас мы ищем решение этой проблемы, так как мы работаем над последующим внедрением QUIC.

Оптимизация QUIC

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

С этими и некоторыми другими улучшениями мы планируем улучшить пользовательский опыт вне зависимости от сети и региона, сделав удобный и бесшовный транспорт пакетов более доступным по всему миру.

Источник

Протокол HTTP-over-QUIC официально становится HTTP/3

С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 31,2% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Из самых популярных сайтов на него перешли Google, Youtube, Wikipedia, Twitter, Vk.com и другие.

Тем не менее, прогресс не стоит на месте — и уже идёт работа над следующей версией HTTP/3. Как сейчас стало известно, разработчики двух альтернативных вариантов достигли совместимости, а протокол HTTP-over-QUIC теперь меняет название и официально именуется HTTP/3. Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.

Путаница с разными вариантами QUIC

QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали “HTTP/2-encrypted-over-UDP”.

Затем разработку QUIC передали в IETF для стандартизации. Здесь он разделилcя на две части: транспорт и HTTP. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).

В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome. Хотя тесты показывают, что реализация QUIC от Google работает существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов.

Разница в производительности между QUIC с TCP (в процентах) в сети с RTT 112 мс и джиттером 10 мс, источник

Разница в производительности между QUIC с TCP (в процентах) в сети с RTT 112 мс и джиттером 10 мс, который меняет порядок пакетов, источник

Некоторые разработчики вообще любые версии QUIC на UDP называют «дичайшим экспериментом».

Разноголосицу в версиях и именованиях QUIC объясняет Дэниель Стенберг, ведущий разработчик curl, работающий в Mozilla, который давно следит за этой историей.

По его словам, в кругу разработчиков получили распространения неформальные названия двух версий QUIC, поскольку варианты от IETF и Google значительно различаются в деталях реализации:

В общем, устоявшегося названия для разных версий не было. На семинаре рабочей группы QUIC Майк Бишоп напугал всех собравшихся таким слайдом, как будто это логотип.

Слайд из презентации Майка Бишопа

Тем не менее, 7 ноября 2018 года один из ведущих разработчиков протокола Дмитрий Тихонов объявил, что LiteSpeed Tech и Facebook достигли совместимости протоколов, и теперь разработка продолжится в общем русле.

Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов. По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP.

Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.

Транспорт QUIC

В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много, и по словам самого Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.

«Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».

Кроме перехода значительного объёма трафика с TCP на UDP, и Google QUIC (gQUIC), и IETF QUIC (iQUIC) требуют обязательного шифрования: нешифрованного QUIC не существует вообще. iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.

В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:

На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика.

Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.

Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи. Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей.

Одно из предложений для решения этой проблемы — введение спин-бита. Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.

Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что сейчас на проприетарную версию iQUIC приходится более 7% трафика в интернете.

Тем не менее, прогресс неизбежен — и в ближайшие годы обязательно продолжится стандартизация и повсеместное внедрение различных протоколов нового поколения, в том числе HTTP/3 на транспорте QUIC.

Источник