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

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

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

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

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

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

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

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

Также довольно часто возникает проблема блокировки началом очереди. Простыми словами её можно определить так: когда потеря одного объекта мешает передаваться следующим. Тут проблема возникает из-за самой работы TCP, она построена по принципу FIVO – 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

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