Протокол quic что это
Перейти к содержимому

Протокол quic что это

  • автор:

Quic от Google

Основной обязанностью любого транспортного протокола является поддержка связи и коммуникации между двумя конечными сущностями. Таким сущностями могут выступать хосты и устройства, как, к примеру, роутеры. Транспортный протокол предоставляет механизм виртуального зацикленного пути между двумя конечными устройствам. Есть два типа транспортных протоколов: ориентирующиеся на соединения и не ориентирующиеся. Из названий становится понятно, что в первом типе происходит некоторое количество дополнительной работы на то, чтобы создать соединение и только после этого появляется возможность передачи информации. В свою очередь протоколы, работающие без заранее созданного соединения, нацелены на то, чтобы доставлять информацию, не волнуясь о том была ли она принята или нет, но в таком случае работа по приёму ложится на самих отправителей и адресатов, которые связаны протоколом. В пример можно привести два самых распространённых протокола – это TCP и UDP, соответственно, первый ориентирован на связь, а второй – нет.

Протокол QUIC – новый транспортный протокол, предназначенный для обеспечения соединения с низкой задержкой через Интернет. Новая технология построена на основе протокола UDP (что напрямую отражено в названии — Quick UDP Internet Connections), поэтому с её помощью можно передавать данных без необходимости в выделенном сквозном соединении.

QUIC был разработан компанией Google для решения проблем основного транспортного протокола TCP (Transmission Control Protocol), который широко используется в интернете, однако имеет недостатки среди которых – высокий уровень задержек и проблемы с контролем перегрузок, который могут привести к проблемам с производительностью.

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

Основная часть

Предпосылки появления нового протокола

В самом распространённом на сегодняшний день протоколе TCP сокрыты некоторые недостатки, приносящие проблемы во время работы интернет-инфраструктуры, от которых хотелось бы избавиться.

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

Также довольно часто возникает проблема блокировки началом очереди. Простыми словами её можно определить так: когда потеря одного объекта мешает передаваться следующим. Тут проблема возникает из-за самой работы TCP, она построена по принципу FIFO – first in first out, то есть данные передаются последовательно и не пакет из конца очереди не может попасть в начало. В TCP эта проблема решается так: пакет, находящийся после потерянного, сохраняется в буфер и хранится там до тех пор, пока ему не придёт копия потерянного пакета.

История QUIC

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

За годы с момента появления QUIC был широко внедрён компанией Google. Создатели протокола активно переводили свои сервисы на новую технологию и уже к сегодняшнему дню мы видим, что все подконтрольные им сервисы используют новый протокол как основной. Помимо этого, Google также заявили, что на сегодняшний день уже более половины запросов их браузер Chrome обрабатывает по новым стандартам. QUIC также получил распространение за пределами Google и поддерживается рядом других компаний и организаций, включая Mozilla, Cloudflare и Инженерный совет Интернета (IETF).

Ключевым для протокола событием стало его принятие в качестве стандарта сообществом IETF, поскольку именно IETF занимается стандартизацией протокола для повсеместного внедрения. И впоследствии Инженерный совет Интернета назначил крайний срок для принятия комментариев на ноябрь 2021 года в теме обсуждения будущего протокола HTTP3, в котором QUIC стал основным транспортным протоколом. После окончания обсуждений третья версия трансферного протокола может быть использована.

Устройство QUIC

QUIC в модели OSI находится на уровне приложений, что очень отличает его от других протоколов, которые находятся на транспортном уровне. Такое нестандартное положение протокола позволяет ему быть высоко-совместимым с конечными сущностями. QUIC очень похож на стек из TCP + TLS + HTTP2, но поскольку он построен на UDP, который не ориентирован на связь, все обязанности в стабильности выполняются на уровне приложений.

Решение проблем TCP в QUIC

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

  • Миграция соединения В QUIC соединения идентифицируются с помощью 64-битного ID, который можно продолжать использовать даже после смены IP адреса пользователем. Из-за этого при смене IP адреса пользователя не возникает разрыва соединения, которое случается при смене на TCP. Также важно отметить, что на практике это довольно часто возникающая ситуация, особенно для смартфонов.
  • Оптимизированный ACK В QUIC каждый пакет имеет свой уникальный последовательный номер, поэтому не возникает проблемы различия пакетов при их ретрансмите. В QUIC поддерживается до 256 диапазонов NACK, помогая отправителю быть более устойчивым к перестановке пакетов и использовать меньше байтов в процессе. В TCP используется выборочный SACK, который решает проблему не во всех случаях.
  • Восполнение потерь В QUIC вызывается два TLP до того, как сработает Retransmission TimeOut (RTO), что отличается от реализации в TCP. Это позволяет быстрее обрабатывать восполнение хвостовых задержек, особенно для коротких и чувствительных к задержкам передач.
  • Управление перегрузкой QUIC находится в модели OSI на уровне приложений, позволяя проще обновлять главный алгоритм транспорта, который управляет отправкой, основываясь на параметрах сети. Большинство TCP-реализаций используют алгоритм CUBIC, который не оптимален для трафика, чувствительного к задержкам. Недавно разработанные алгоритмы вроде BBR, более точно моделируют сеть и оптимизируют задержки. QUIC позволяет использовать BBR и обновлять этот алгоритм по мере его совершенствования.
  • Многопоточность QUIC позволяет передавать несколько потоков данных через одно соединение, снижая расходы на создание и поддержание отдельных связей для каждого потока. В свою очередь TCP ничего подобного не имеет, поэтому для передачи данных несколькими потоками при работе с ним приходится открывать несколько различных соединений.
  • Приоритезация потоков QUIC позволяет устанавливать приоритеты потоков в зависимости от важности передаваемых данных, что позволяет ускорять процесс.
  • Шифрование QUIC по умолчанию обеспечивает сквозное шифрование, помогая защитить передачу данных. Для шифрования в QUIC используется TLS 1.3, который устанавливает ключи сессии, а после этого шифрует каждый пакет информации. В TCP также используется TLS, но из-за этого появляется необходимость в дополнительном рукопожатии между клиентом и сервером. В QUIC же этого не происходит, поскольку он соединяет собственное рукопожатие с RTT от TLS. Также в QUIC заменён записывающий слой TLS на собственный формат, но при этом сохраняется полная совместимость, и при этом ещё передаются дополнительный метаданные с целью защиты от манипуляций соединением через firewall и proxy.

Дополнительно в QUIC

  • QPACK В HTTP второй версии были представлены сжатые заголовки — HPACK, которые позволяет конечным хостам сокращать количество передаваемой информации. В частности, HPACK имеют динамические таблицы, заполненные предыдущими HTTP запросами и ответами. Это позволяет хостами обращаться к прошлой информации без необходимости запрашивать её снова. Используя TCP, HTTP запросы и ответы отправляются по порядку их пришествия, последовательно. А QUIC при помощи мультипоточности может отправлять их во множественном количестве одновременно, но тогда не гарантируется последовательность отправки пакетов.
  • QUIC заголовки Заголовки в QUIC бывают двух типов: длинные и короткие. Различают их по объёму передаваемой информации, в длинных её хранится больше. Длинные заголовки хранят в себе информацию о версии, ID адресата и отправителя и различные флаги, как например, форма заголовка. В самом частом сценарии длинные заголовки используются для первичного рукопожатия, но как только соединение установлено, отправитель начинает отправлять короткие пакеты, которые являются наиболее часто используемой опцией в трафике QUIC. В коротких пакетах хранится информации об ID адресата, номере самого пакета и зашифрованная информация пакета.
  • ID связи В QUIC существует Connection ID или CID. У каждой связи есть свой набор CID, каждый из которых может быть использован для выделения связи. CID независимо выбирается конечными приложениями, между которыми происходит отправка. Целью CID является доставка информации до получателя независимо от смены его UDP или IP адреса в сети
  • Stream Frame Поскольку QUIC подключается клиент и сервер одним соединением, появляется необходимость создания нескольких потоков внутри этого соединения для передачи данных в режиме мультиплекс. Этим и занимается Stream Frame, он создает несколько внутренних потоков, доставляющих информацию. В каждом таком потоке есть механизм контроля данных и отслеживание потерь, если потеря происходит, то это не влияет на другие потоки. В каждом потоке содержится информация о его порядковом номере, смещение, которое позволяет определить откуда потоку начинать передавать пакет, длину передаваемой информации и само содержимое.
  • Нумерация пакетов Нумерация представлена числом в диапазоне от 0 до . Это используется для определение криптографического одноразового номера защиты. Каждая конечная точка поддерживает отдельный номер пакета для отправки и получения. Номера пакетов ограничены, потому что им необходимо быть представленными целиком в поле ACK. Номера пакетов могут быть сокращены и кодироваться в от 1 до 4 байт.

Сравнение TCP и QIUC

QUIC основан на UDP и был разработан для решения проблем TCP, который является доминирующим транспортным протоколом, используемым в Интернете.

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

Чтобы сравнить скорость работы протоколов хорошо подойдёт следующая иллюстрация:

На ней мы видим большой прирост скорости QUIC даже в сравнении с TCP без шифрования. Поскольку QUIC основан на UDP, для передачи информации нет необходимости в том, чтобы отправлять RTT в таком же количестве, как это делает TCP. Если связь между клиентом и сервером уже была установлена, QUIC не будет отправлять никаких RTT, но, если связь первичная, один RTT всё же будет отправлен. Это положительно сказывается на скорости передачи данных.

Проблемы нового протокола

Несмотря на то, что QUIC оказался вполне успешным и был широко принят компаниями и организациями, при его использовании могут возникать сложности и проблемы.

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

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

Не обошлось и без проблем с памятью. Поскольку QUIC находится на уровне приложений в модели OSI, он использует больше оперативной памяти, чем обычно это делает TCP. Также в QUIC существует ограничение на максимальный размер передачи (Maximum Transmission Unit) в 1392 байта, что пока не позволяет ему задействовать фрагментацию.

Выводы

QUIC точно привнесёт что-то новое в IoT отрасль. Поскольку траффик там немного отличается от обычного пользовательского интернет-трафика и работают устройства умного дома в сетях с высокими потерями, использование TCP в качестве основного протокола – ошибка. В свою же очередь QUIC может легко работать внутри таких сетей и эффективно справляться со своими задачами благодаря Connection ID.

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

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

Список используемой литературы

  1. Google. (2021). QUIC: Overview. Источник: https://peering.google.com/#/learn-more/quic
  2. Habr. (2015). Google успешно использует новый интернет-протокол QUIC в работе браузера Chrome. Источник: https://habr.com/ru/post/378543/
  3. Habr (2016). Протокол QUIC: переход Web от TCP к UDP. Источник: https://habr.com/ru/company/infopulse/blog/315172/
  4. Habr. (2021). Транспортный протокол QUIC приняли в качестве стандарта RFC 9000 Источник: https://habr.com/ru/company/globalsign/blog/560342/
  5. Habr. (2018). Протокол HTTP-over-QUIC официально становится HTTP/3. Источник: https://habr.com/ru/company/globalsign/blog/429820/
  6. Habr. (2019). TCP против UDP или будущее сетевых протоколов. https://habr.com/ru/company/oleg-bunin/blog/461829/
  7. Habr. (2020). Head-of-Line Blocking в QUIC и HTTP/3: Подробности. https://habr.com/ru/company/selectel/blog/532868/
  8. TProger. (2020). Протоколы передачи данных: что это, какие бывают и в чём отличия? https://tproger.ru/explain/protokoly-peredachi-dannyh-chto-jeto-kakie-byvajut-i-v-chjom-razlichija/
  9. QUIC – A Quick Study. (2020). https://arxiv.org/pdf/2010.03059.pdf

Это мой первый пост, рад любой критике.

HTTP/3 и QUIC: будущее интернета

На момент этой публикации последняя стандартизированная версия протокола HTTP — HTTP/2. Но уже очень скоро будет официально выпущена его замена — HTTP/3, протокол, работающий через QUIC, более быстрый и безопасный. Многие браузеры и IT-сервисы уже его поддерживают.

Мы в EdgeЦентр тоже уже запустили поддержку нового протокола на нашей CDN в режиме бета-тестирования. Новый протокол позволит доставлять контент наших клиентов ещё быстрее.

Давайте разбираться, что такое HTTP/3 и QUIC, и как он помогает ускорять доставку контента.

  • Что такое HTTP/3
  • Что такое QUIC
  • Как HTTP/3 использует QUIC
  • Почему бы просто не встроить QUIC в HTTP/2?
  • Преимущества HTTP/3 над HTTP/2
  • Сложности, связанные с HTTP/3
  • Когда интернет перейдёт на новый протокол
  • HTTP/3 в сервисах EdgeЦентр
  • Подведём итоги

Что такое HTTP/3

HTTP/3 — готовящаяся к стандартизации версия протокола HTTP (HyperText Transfer Protocol). Напомним, что HTTP — это протокол прикладного уровня, основной протокол передачи данных в интернете, используется для получения данных с веб-ресурсов.

Первоначальное название HTTP/3 — HTTP-over-QUIC. И главное его отличие от предыдущих версий в том, что он использует новый транспортный протокол QUIC, и за счёт этого передаёт данные быстрее.

Что такое QUIC

QUIC (Quick UDP Internet Connection) — транспортный протокол, основанный на UDP. Был разработан Google в 2012 году.

Чтобы лучше понять, что такое QUIC, давайте сначала поговорим о двух других транспортных протоколах — TCP и UDP.

Во всех предыдущих версиях HTTP на транспортном уровне использовался TCP. Он считается более надёжным, потому что проверяет получение информации. На каждый полученный пакет принимающая сторона должна послать отправителю сообщение с подтверждением. Если через определённое время подтверждение на какой-то пакет не пришло, он отправляется повторно.

Для установки TCP-соединения требуется «тройное рукопожатие».

1. Отправитель посылает запрос на установку соединения — сообщение SYN и порядковый номер переданного байта.

2. Получатель отвечает сообщением SYN, подтверждает получение данных сообщением ACK и отправляет номер байта, который должен быть получен следующим.

3. Отправитель тоже подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта.

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

UDP отличается от TCP тем, что не проверяет правильный порядок и целостность пакетов. Он просто отправляет данные и не требует подтверждать их получение. За счёт этого информация передаётся быстрее, чем по TCP.

Никакой установки соединения UDP не требует. Пакеты передаются сразу, что тоже ускоряет процесс.

Вот поэтому UDP считается более быстрым. Но всё это ведёт к проблемам с надёжностью. Часть пакетов при передаче может потеряться, и нет никакого механизма восстановления.

QUIC решает проблемы обоих протоколов:

  • Сокращает время на установку соединения.
  • Берёт от UDP высокую скорость передачи, но при этом контролирует целостность пакетов.
  • Может передавать несколько пакетов параллельно, что тоже ускоряет их доставку.

Давайте разберём его основные особенности.

Быстрая установка соединения

Мы уже рассказали про «тройное рукопожатие» в TCP. К этому надо добавить, что многие сайты работают через HTTPS. Это значит, что поверх TCP-соединения надо установить ещё и TLS-соединение для безопасной передачи данных.

И для этого клиенту и серверу надо обменяться ещё большим количеством сообщений.

Всё это значительно замедляет процесс доставки данных.

QUIC включает в себя TLS 1.3, обеспечивает безопасное зашифрованное соединение, но при этом не требует такого количества «рукопожатий».

Зашифрованное соединение устанавливается сразу. «Рукопожатие» проходит за 3 шага. А если это повторное соединение, то первые данные отправляются одновременно с «рукопожатием».

Всё это позволяет QUIC передавать данные в несколько раз быстрее TCP и при этом обеспечивать высокий уровень безопасности.

Быстрая доставка и контроль за целостностью пакетов

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

За счёт чего тогда данные передаются быстрее?

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

Переключение сессий

В QUIC нет привязки к конкретному IP.

Для сравнения, в TCP-соединении участвуют IP клиента и сервера и порты клиента и сервера. И если один из этих параметров меняется, нам нужно открывать новое соединение.

Если пользователь подключается к ресурсу через Wi-Fi, а потом переходит на мобильную сеть, у него меняется IP, и соединение нужно устанавливать заново.

С QUIC такой проблемы нет. В этом протоколе вместо адресов и портов используется идентификатор соединения — Connection UUID. И он не меняется при переходе от Wi-Fi на мобильную сеть. А значит, соединение остаётся, и ничего не нужно открывать заново.

Кроме того, если QUIC может очень легко перейти от Wi-Fi к мобильному интернету, то в теории он может использовать их оба. В передаче данных будет задействовано 2 канала, и пакеты дойдут быстрее.

Транспортный протокол 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.

  • «HTTP/3: от корней до кончиков»
  • «Будущее интернет-протоколов», Марк Ноттингем

QUIC (протокол)

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

Для этого он устанавливает несколько мультиплексированных соединений между двумя конечными точками по протоколу User Datagram Protocol (UDP), а не Transmission Control Protocol (TCP).

QUIC против TCP: сравнительный анализ

Чтобы оценить преимущества QUIC, необходимо сравнить его с TCP, традиционным протоколом для интернет-коммуникаций. Хотя TCP обеспечивает надежную доставку данных, он страдает от проблемы, известной как «блокировка в голове линии», когда потеря одного пакета задерживает доставку последующих пакетов.

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

Преимущества QUIC

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

Кроме того, в QUIC интегрирован протокол TLS (Transport Layer Security) для обеспечения безопасности связи, что делает его более надежным выбором для передачи конфиденциальных данных. Представьте себе QUIC как безопасную, высокоскоростную курьерскую службу, которая не только быстро доставляет ваши посылки, но и обеспечивает их сохранность во время транспортировки.

Будущее QUIC

QUIC – это протокол не только настоящего, но и будущего. Он является основой для HTTP/3, будущей версии протокола HTTP. Благодаря своей способности снижать задержки, справляться с потерями пакетов и обеспечивать безопасную передачу данных, QUIC призван сыграть ключевую роль в будущем интернет-коммуникаций.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *