Хабрахабр

На замену TCP: протокол QUIC готов для внедрения [но не готов стать RFC]

Представители Инженерного совета интернета (IETF) объявили, что протокол QUIC для передачи данных на транспортном уровне готов для широкомасштабных тестов. Но из-за ряда недостатков, его пока нельзя представить в виде RFC. Подробности — в нашем сегодняшнем материале.


/ Pixabay / www_slon_pics / PD

Почему появился QUIC

Работу над QUIC начала Google в 2013 году. Он тестировался в браузерах Chrome и Chromium. Позже технологию начали поддерживать сайты компании, в том числе YouTube. Через пару лет ИТ-гигант объявил, что тестирование протокола прошло успешно, и его представят в IETF.

Как отметили представители IETF, в будущем QUIC должен будет заменить TCP, так как последний исчерпал свои возможности в условиях современных сетей (в основном мобильных). Совет интернета начал работать над QUIC в марте 2016 года.

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

Помимо этого тесты, проведенные Google, показывают снижение числа ребуферизаций при просмотре видео на YouTube на 30%. Задача QUIC — сделать процесс переключения между беспроводными сетями (в том числе Wi-Fi) более «гладким».

Особенности работы протокола

Работа QUIC строится на протоколе UDP, который позволяет обмениваться данными без проверки готовности получателя к их приему. В отличие от TCP, который использует принцип «тройного рукопожатия», в QUIC рукопожатие происходит в один этап с уже знакомым сервером и в два этапа с сервером, с которым клиент раньше не работал. Второй этап нужен, чтобы открыть защищенный канал связи и обменяться криптографическими ключами. В итоге QUIC имеет более низкую задержку соединения и передачи, чем TCP. При трансляции данных на большое расстояние (например, с одного континента на другой) посредством мобильного устройства разница в скорости установления подключения между TCP с TLS и пакетом QUIC может достигать 300 мс.

Вместо них протокол работает с идентификатором соединения UUID. В QUIC больше нет набора параметров, связанных с IP-адресами и портами сервера и клиента. Механизм работы похож на утилиту Mosh, которая сохраняет сессии при переключении между беспроводными сетями. Это позволяет переключаться между Wi-Fi и мобильной сетью, каждый раз не пересоздавая соединение (UUID сохраняется). Информацию о ней можно найти в официальном репозитории проекта.

Каждый пакет, который передается через QUIC, имеет информацию о соседях. QUIC дополнительно включает метод контроля целостности данных — прямую коррекцию ошибок, или Forward Error Correction (FEC). Поэтому если он теряется, содержимое пакета можно восстановить.

Критика технологии

Пока что у технологии есть определенные недостатки. Например, уязвимость перед DDoS-атаками. По словам ИБ-специалистов, популярные наборы для организации DDoS-атак обладают встроенной поддержкой UDP, что представляет большую угрозу. По этой причине при внедрении QUIC важно убедиться в корректности работы механизма рукопожатия — он должен быть оптимизирован и реализован как можно ближе к железу. В противном случае те атаки, с которыми раньше могло справиться ядро, придётся обрабатывать сторонними решениями (например, nginx).


/ Wikimedia / Sagor Kumar sr / CC

Они работают с TCP-соединениями и не смогут распознавать и регулировать QUIC-трафик. Второй недостаток — несовместимость протокола с сетями, в которых используются технологии NAT, Anycast или ECMP. Такая несовместимость сужает возможности для применения.

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

Протокол шифрует не только данные, но и заголовок пакета, в котором они передаются. Ещё один недостаток QUIC — затрудненный поиск неисправностей. Это мешает системным администраторам оценивать работу сети и быстро устранять неполадки.

Перспективы

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

Протокол уже поддерживают крупные организации. С QUIC начали работать CDN-сервисы — Cloudflare и Verizon Digital Media Services (VDMS). В Cloudflare функция соединения через QUIC находится в бета-тестировании. Команда VDMS работала над реализацией протокола с 2016 года, и сейчас QUIC могут использовать все клиенты сервиса. Версии протокола QUIC также тестируют Apple, Pandora, Facebook. Полный список компаний доступен на GitHub.

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

S. P. О чем еще мы пишем в корпоративном блоге VAS Experts:

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть