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

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

^[1]
/ Pixabay / www_slon_pics ^[2] / PD

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

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

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

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

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

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

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

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

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

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

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

/ Wikimedia / Sagor Kumar sr ^[14] / CC ^[15]

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

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

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

Перспективы

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

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

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

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

Автор: VAS Experts

Источник ^[29]