Представители Инженерного совета интернета (IETF) объявили, что протокол QUIC для передачи данных на транспортном уровне готов для широкомасштабных тестов. Но из-за ряда недостатков, его пока нельзя представить в виде RFC. Подробности — в нашем сегодняшнем материале.
/ Pixabay / www_slon_pics / PD
Работу над QUIC начала Google в 2013 году. Он тестировался в браузерах Chrome и Chromium. Позже технологию начали поддерживать сайты компании, в том числе YouTube. Через пару лет ИТ-гигант объявил, что тестирование протокола прошло успешно, и его представят в IETF.
Совет интернета начал работать над QUIC в марте 2016 года. Как отметили представители IETF, в будущем QUIC должен будет заменить TCP, так как последний исчерпал свои возможности в условиях современных сетей (в основном мобильных).
В протоколе TCP-соединение определяется IP-адресами и портами сервера и клиента. Если по какой-то причине один из этих параметров изменяется, приходится пересоздавать подключение. Отсюда вытекают сложности со стабильностью связи в мобильных сетях. Пользователь перемещается между разными сотовыми вышками и постоянно меняет IP-адрес.
Работа QUIC строится на протоколе UDP, который позволяет обмениваться данными без проверки готовности получателя к их приему. В отличие от TCP, который использует принцип «тройного рукопожатия», в QUIC рукопожатие происходит в один этап с уже знакомым сервером и в два этапа с сервером, с которым клиент раньше не работал. Второй этап нужен, чтобы открыть защищенный канал связи и обменяться криптографическими ключами. В итоге QUIC имеет более низкую задержку соединения и передачи, чем TCP. При трансляции данных на большое расстояние (например, с одного континента на другой) посредством мобильного устройства разница в скорости установления подключения между TCP с TLS и пакетом QUIC может достигать 300 мс.
В QUIC больше нет набора параметров, связанных с IP-адресами и портами сервера и клиента. Вместо них протокол работает с идентификатором соединения UUID. Это позволяет переключаться между Wi-Fi и мобильной сетью, каждый раз не пересоздавая соединение (UUID сохраняется). Механизм работы похож на утилиту Mosh, которая сохраняет сессии при переключении между беспроводными сетями. Информацию о ней можно найти в официальном репозитории проекта.
QUIC дополнительно включает метод контроля целостности данных — прямую коррекцию ошибок, или Forward Error Correction (FEC). Каждый пакет, который передается через QUIC, имеет информацию о соседях. Поэтому если он теряется, содержимое пакета можно восстановить.
Пока что у технологии есть определенные недостатки. Например, уязвимость перед DDoS-атаками. По словам ИБ-специалистов, популярные наборы для организации DDoS-атак обладают встроенной поддержкой UDP, что представляет большую угрозу. По этой причине при внедрении QUIC важно убедиться в корректности работы механизма рукопожатия — он должен быть оптимизирован и реализован как можно ближе к железу. В противном случае те атаки, с которыми раньше могло справиться ядро, придётся обрабатывать сторонними решениями (например, nginx).
/ Wikimedia / Sagor Kumar sr / CC
Второй недостаток — несовместимость протокола с сетями, в которых используются технологии NAT, Anycast или ECMP. Они работают с TCP-соединениями и не смогут распознавать и регулировать QUIC-трафик. Такая несовместимость сужает возможности для применения.
Более того, результаты тестирования QUIC показали, что протокол не так хорошо работает на мобильных устройствах, как это обещают создатели технологии. Согласно экспериментам, при увеличении пропускной способности сети и объема передаваемых данных время загрузки страницы для TCP и QUIC выравнивается. Это происходит потому, что QUIC работает в пользовательском пространстве, а не в пространстве ядра.
Ещё один недостаток QUIC — затрудненный поиск неисправностей. Протокол шифрует не только данные, но и заголовок пакета, в котором они передаются. Это мешает системным администраторам оценивать работу сети и быстро устранять неполадки.
Хотя пока QUIC остается экспериментальной технологией, количество сайтов с поддержкой этого протокола растет — это показывают данные исследовательской организации W3Techs. Эксперты оценивают, что с принятием стандарта протокол будут использовать чаще — хотя пока неясно, когда именно IETF представит финальную версию QUIC.
P.S. О чем еще мы пишем в корпоративном блоге VAS Experts:
/ Pixabay / www_slon_pics / PD
Почему появился QUIC
Работу над QUIC начала Google в 2013 году. Он тестировался в браузерах Chrome и Chromium. Позже технологию начали поддерживать сайты компании, в том числе YouTube. Через пару лет ИТ-гигант объявил, что тестирование протокола прошло успешно, и его представят в IETF.
Совет интернета начал работать над QUIC в марте 2016 года. Как отметили представители IETF, в будущем QUIC должен будет заменить TCP, так как последний исчерпал свои возможности в условиях современных сетей (в основном мобильных).
В протоколе TCP-соединение определяется IP-адресами и портами сервера и клиента. Если по какой-то причине один из этих параметров изменяется, приходится пересоздавать подключение. Отсюда вытекают сложности со стабильностью связи в мобильных сетях. Пользователь перемещается между разными сотовыми вышками и постоянно меняет IP-адрес.
Задача QUIC — сделать процесс переключения между беспроводными сетями (в том числе Wi-Fi) более «гладким». Помимо этого тесты, проведенные Google, показывают снижение числа ребуферизаций при просмотре видео на YouTube на 30%.
Особенности работы протокола
Работа QUIC строится на протоколе UDP, который позволяет обмениваться данными без проверки готовности получателя к их приему. В отличие от TCP, который использует принцип «тройного рукопожатия», в QUIC рукопожатие происходит в один этап с уже знакомым сервером и в два этапа с сервером, с которым клиент раньше не работал. Второй этап нужен, чтобы открыть защищенный канал связи и обменяться криптографическими ключами. В итоге QUIC имеет более низкую задержку соединения и передачи, чем TCP. При трансляции данных на большое расстояние (например, с одного континента на другой) посредством мобильного устройства разница в скорости установления подключения между TCP с TLS и пакетом QUIC может достигать 300 мс.
В QUIC больше нет набора параметров, связанных с IP-адресами и портами сервера и клиента. Вместо них протокол работает с идентификатором соединения UUID. Это позволяет переключаться между Wi-Fi и мобильной сетью, каждый раз не пересоздавая соединение (UUID сохраняется). Механизм работы похож на утилиту Mosh, которая сохраняет сессии при переключении между беспроводными сетями. Информацию о ней можно найти в официальном репозитории проекта.
QUIC дополнительно включает метод контроля целостности данных — прямую коррекцию ошибок, или Forward Error Correction (FEC). Каждый пакет, который передается через QUIC, имеет информацию о соседях. Поэтому если он теряется, содержимое пакета можно восстановить.
Критика технологии
Пока что у технологии есть определенные недостатки. Например, уязвимость перед DDoS-атаками. По словам ИБ-специалистов, популярные наборы для организации DDoS-атак обладают встроенной поддержкой UDP, что представляет большую угрозу. По этой причине при внедрении QUIC важно убедиться в корректности работы механизма рукопожатия — он должен быть оптимизирован и реализован как можно ближе к железу. В противном случае те атаки, с которыми раньше могло справиться ядро, придётся обрабатывать сторонними решениями (например, nginx).
/ Wikimedia / Sagor Kumar sr / CC
Второй недостаток — несовместимость протокола с сетями, в которых используются технологии NAT, Anycast или ECMP. Они работают с TCP-соединениями и не смогут распознавать и регулировать QUIC-трафик. Такая несовместимость сужает возможности для применения.
Более того, результаты тестирования QUIC показали, что протокол не так хорошо работает на мобильных устройствах, как это обещают создатели технологии. Согласно экспериментам, при увеличении пропускной способности сети и объема передаваемых данных время загрузки страницы для TCP и QUIC выравнивается. Это происходит потому, что QUIC работает в пользовательском пространстве, а не в пространстве ядра.
Ещё один недостаток QUIC — затрудненный поиск неисправностей. Протокол шифрует не только данные, но и заголовок пакета, в котором они передаются. Это мешает системным администраторам оценивать работу сети и быстро устранять неполадки.
Перспективы
Из-за существующих уязвимостей защищать систему, спроектированную поверх QUIC, может быть сложно. Чтобы устранить недостатки протокола, разработчикам нужны данные о его работе в реальных условиях. Для этого IETF привлекает к тестированию IT-компании.Протокол уже поддерживают крупные организации. С QUIC начали работать CDN-сервисы — Cloudflare и Verizon Digital Media Services (VDMS). В Cloudflare функция соединения через QUIC находится в бета-тестировании. Команда VDMS работала над реализацией протокола с 2016 года, и сейчас QUIC могут использовать все клиенты сервиса. Версии протокола QUIC также тестируют Apple, Pandora, Facebook. Полный список компаний доступен на GitHub.
Хотя пока QUIC остается экспериментальной технологией, количество сайтов с поддержкой этого протокола растет — это показывают данные исследовательской организации W3Techs. Эксперты оценивают, что с принятием стандарта протокол будут использовать чаще — хотя пока неясно, когда именно IETF представит финальную версию QUIC.
P.S. О чем еще мы пишем в корпоративном блоге VAS Experts:
