Разработка протокола велась на протяжении восьми лет, и в этом году его, наконец, оформили в RFC 9000. Представители ИТ-индустрии по большей части тепло приняли технологию, но энтузиазм разделяют не все. Рассмотрим аргументы скептиков.
Настроения вокруг QUIC
QUIC — это транспортный протокол, построенный на базе UDP. Его представили инженеры из Google и IETF. Еще до оформления в RFC 9000 технологии пророчили светлое будущее в качестве замены TCP, главным образом из-за сокращения задержек при соединении. QUIC позволяет установить подключение за меньшее число рукопожатий — всего одно для знакомого и два для незнакомого сервера (TCP реализует «трёхэтапное рукопожатие»).
Согласно последним отчетам W3Techs, работу с QUIC поддерживает 6% сайтов в интернете — его внедряют крупные телекомы, облачные провайдеры и соцсети. Некоторые предлагают свои реализации протокола на разных языках программирования. По мнению экспертов, стандартизация QUIC ускорит его внедрение и подстегнёт развитие таких технологий, как WebTransport (для обмена данными между браузером и сервером) и MASQUE (проксирование соединений).
Однако не все представители ИТ-индустрии настроены оптимистично. Есть мнение, что новая технология пройдет по стопам IPv6 и попадет в своеобразный лимб, когда её внедрение растянется на десятки лет. И есть несколько причин так думать.
Неоднозначная ситуация
Согласно бенчмаркам, опубликованным компанией Google, QUIC более производителен, чем TCP. Во время тестов он сократил время загрузки веб-страниц на 3%, а число операций буферизации при просмотре YouTube-видео — на 18%.
Однако в начале месяца инженеры из Брауновского университета в США отметили, что разработчики анализировали работу протокола на неоптимизированных open source серверах. Исследователи установили, что в «боевых условиях» прирост пропускной способности по отношению к TCP получается не таким большим. Более того, аналогичного результата вполне можно добиться за счет тонкой настройки механизмов контроля перегрузки TCP и наборов шифров (стр.11).
К аналогичным выводам пришли специалисты из Вустерского политехнического института (стр.41). По их данным, разница в пропускной способности двух протоколов на ряде задач не превышает 0,1%. Инженеры интернет-регистратора APNIC также отмечают, что QUIC работает хуже, если возникает необходимость повторной передачи потерянных пакетов.
В том числе в беспроводных каналах
Неоднозначная ситуация сложилась и в беспроводных меш-сетях — они чувствительны к потерям из-за помех и затухания сигнала, их производительность может меняться. Инженеры из университетов Каталонии, Лювена и Турина установили (стр.20), что пропускная способность QUIC в таких условиях может быть хуже, чем у TCP. Специалисты говорят, что QUIC интерпретирует изменяющиеся параметры задержки как перегрузку, что мешает подобрать оптимальный объем передаваемых данных. В то же время механизм packet pacing не позволяет эффективно использовать функцию frame aggregation из семейства стандартов 802.11.
Справедливости ради стоит заметить, что инженерам удалось улучшить некоторые аспекты протокола и увеличить его пропускную способность на 28%. При этом практика отдельных компаний показывает, что QUIC может комфортно работать «по беспроводу». Еще пару лет назад на него перешли в Uber, а их приложение чаще всего используют в мобильных сетях. Там QUIC обошел TCP в плане снижения хвостовых задержек на 10–30%. Подробнее этот кейс разбирали на Хабре.
Вопросы безопасности
У специалистов также есть вопросы к безопасности — в начале года группа китайских инженеров обратила внимание, что QUIC более уязвим к «фингерпринтингу», чем HTTPS. Так, если у злоумышленника получится прослушать трафик, ему будет проще определить, какие сайты посещает пользователь — точность превышает 95% по 40 пакетам данных (стр.2). Хотя китайские коллеги проводили эксперименты в лабораторных условиях, и результаты в реальных сетях могут отличаться.
В одном из обсуждений QUIC на Хабре также «всплывала» тема нестабильности некоторых его реализаций, в частности в отношении ошибок обработки запросов. Необходимость в исправлении подобных вещей может помешать распространению технологии. К слову, затормозить процесс в корпоративной среде могут и строгие политики в отношении UDP, поверх которого работает QUIC.
Нет сомнений, что протокол будет внедрять все больше сайтов и ИТ-компаний (уже сейчас на графике W3Techs виден восходящий тренд), а ситуация с безопасностью и стабильностью станет лучше. Вопрос лишь в том, как быстро это произойдет, и не успеет ли угаснуть энтузиазм сообщества — как в случае с IPv6.
О чем еще мы пишем в корпоративном блоге VAS Experts:
Комментарии (29)
cher-nov
19.09.2021 21:01-2Инженеры интернет-регистратора APNIC также отмечают, что QUIC работает хуже, если возникает необходимость повторной передачи потерянных пакетов.
...то есть всегда, потому что это UDP. Не говоря уже о том, что здесь, судя по всему, спрятано довольно-таки жирное допущение об окончательном уходе в прошлое сетей навроде dial-up — с нестабильностью и малой пропускной способностью.
netch80
20.09.2021 22:18>… то есть всегда, потому что это UDP.
Будто с TCP пакеты не теряются.
Восстановление после потерь есть у обоих.cher-nov
20.09.2021 23:01-1У TCP абсолютная гарантия доставки, "ни один байт потока не должен быть потерян". У UDP же она отсутствует и обычно выполняется на уровне протоколов, реализованных поверх UDP, к которым относится и QUIC.
И моё опасение (не говоря уже о появлении лишнего протокольного слоя) заключается в том, является ли гарантия доставки в QUIC сопоставимой по эффективности с TCP, потому что её так-то можно и дубовой переотправкой вплоть до ack делать - только каналу от этого плоховато становится.
netch80
20.09.2021 22:23По поводу QUIC интересен один момент уровня IP стека.
Соединение, установленное по TCP, имеет отдельный сокет. Его можно перебросить в другой тред или процесс.
Для UDP такого нет. Есть разделение нагрузки, но куда попадёт конкретная датаграмма — управлять нельзя. Значит, принимать в юзерленд должен один тред, дальше распределять нагрузку в пуле.
Как это предполагают решать? Вижу два варианта:
1. Добавка каким-нибудь setsockopt «общение с этими host:port перебрасывать вот на этот дескриптор» (и не забывать вычищать из таблиц по завершению соединения; на TCP эта вычистка происходит автоматом. Может, по аналогии со всякими eventfd, сделают владение таким управлением через дескриптор файла?)
2. На уровне протокола редирект «не реконнектиться, но переключиться на порт 54800» (может, даже другого IP).
Я ничего не смог найти про эту проблему и её решения. Может, кто-то что-то слышал?
amarao
Оно нужно гуглу и нескольким толстым компаниям. Свободному интернету этот протокол, с делегацией проблемы из ядра ОС в userspace, дался как собаке QUIC протокол. Сравнение с ipv6 совершенно ошибочно, потому что ipv6 решает проблемы большинства, а quic - толстой жирной it-прослойки нескольких монополистов.
Alex_ME
А какие проблемы монополистов он решает?
Revertis
Снижение огромного объёма трафика, может быть усложнение блокировки рекламы на промежуточных узлах.
powerman
Вряд ли. Насчёт трафика сложно сказать, на их объёмах любая копеечная экономия может быть заметна, но вот что до блокировки MITM то эту проблему решил https. А блокировать через /etc/hosts (как AdAway на телефонах) и через браузерные плагины QUIC не помешает.
Revertis
Есть, например, AdGuard, который на сетевом уровне фильтрует всё внутри HTTPS. А для QUIC надо писать отдельный модуль. (Не в курсе, написали ли они его уже или нет).
Блокировка рекламы и систем слежения с помощью HOSTS или DNS-серверов не является полной. Сейчас на многих площадках реклама встроена в код страницы или просто грузится с того же домена, что и контент.
Браузерные расширения такое фильтруют пока хорошо. Но например в Chrome фильтрации контента скоро не станет, спасибо Manifest v3. Если хотите сохранить нормальную фильтрацию придётся переходить на Firefox.
powerman
Вы так говорите, как будто это что-то плохое. Плохо - это когда хром сожрал весь рынок, идя по стопам IE6. Так что если из-за фильтрации рекламы часть пользователей перейдёт на Firefox - это же хорошо.
Revertis
Я-то много последних лет только Firefox и пользуюсь. Но для многих это будет "чем-то плохим", они ведь привыкли к Хромому.
dartraiden
Туда им и дорога, всем этим перехватчикам HTTPS-трафика.
Revertis
Когда настраиваешь сам для себя это хорошее.
dartraiden
Антивирусное ПО тоже ставят и настраивают для себя. Но оно выходит вон как.
gameplayer55055
Рекламу можно блокировать и с quic. От Ютуб слышал на него перешёл. Моему адблокеру пофиг
Revertis
Расширениям в браузере, понятное дело, пофиг. Я писал о другом.
Evengard
Вы зря так, я очень надеюсь на его признание и повсеместное использование (не только в http) из-за одной важной фичи - connection id и самовосстановление при изменении IP. Что бывает весьма актуально в условиях мобильного интернета и переключением между ним и wifi хотспотами.
uhf
Какая может быть необходимость держать непрерывной TCP-сессию с мобильного устройства? Задержка в передаче данных на время переключения все равно будет.
Нормальные приложения умеют прозрачно реконнектиться, либо используют UDP. Видео буферизуется, и т.д.
Разве что если качать огромный файл в один поток с файлообменника бесплатно без СМС, или по где-то ssh сидеть. Ну в этой ситуации OpenVPN решит проблему.
Для меня гораздо актуальнее падение производительности TCP при больших потерях пакетов.
Evengard
К сожалению, по факту "нормальных приложений" очень мало, и потеря коннектов - очень часто происходит. И да, я скорее про неHTTP-приложения говорю. Там я вижу гораздо больше потенциала для QUIC чем для HTTP стэка, как бы парадоксально это не звучало.
Evengard
Хочу также уточнить, что проблема с реконнектами бывает даже не обязательно при смене IP, бывает просто разрыв недолгий - и коннект уже сбрасывается сервером, а для нового нужна реавторизация (в частности, касается игровых приложений - там из игры "выкидывает", приходится заново реавторизовываться для продолжения игровой сессии). В QUIC connection id способна решить такую проблему.
amarao
Для меня, как для оператора, quic выглядит чёрным ящиком. Если по tcp я вижу много метрик и могу понимать что происходит с сервером, то quic - целиком на откупе приложений. В https общепринята модель c https прокси поверх http на localhost, что даёт возможность быстро смотреть на проходящий трафик. quic это всё уничтожает.
Вместо богатого инструментария я получаю чёрный ящик, который "что-то там по сети шлёт", и пока программист (каждый из программистов каждого из приложения) не выставит метрики наружу, то про этот чёрный ящик ничего сказать нельзя.
gameplayer55055
Ну http3 это по сути http2 через UDP.
Wireshark его поддерживает, заголовки куки и все фичи http тоже есть. А для канального уровня что-то по любому есть для контроля.
amarao
Скажите, сколько у вас quic соединений в состоянии established? А сколько зависло в half-open? Сколько ретрансмитов было? Откуда вы это можете посмотреть в системе? В метриках udp? Удачи.
Myateznik
Состояние half-open относится к TCP, в UDP соединениями в состоянии "half-open" можно считаться те, у которых нет обратного трафика. Опять таки в самом UDP нет такого понятия как half-open. QUIC построен поверх UDP, соответственно весь базовый мониторинг должен касаться именно UDP.
Далее у QUIC тоже нет понятия "half-open", есть только "half-closed" и то это относится к потокам в QUIC. Причём потоки в QUIC работают внутри уже установленного соединения (сессии QUIC).
Ок, вам как оператору нужны метрики по QUIC, используйте существующий формат логирования для QUIC и HTTP/3 - qlog. Не поверите, но инструменты мониторинга и отладки уже придуманы или прорабатываются.
Лежит это всё рядом с RFC 9000 в рабочих черновиках и не только. Нужно всего лишь как минимум посмотреть документы рабочей группы QUICWG.
Есть такие документы как:
RFC 8999 - Version-Independent Properties of QUIC
RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
RFC 9001 - Using TLS to Secure QUIC
RFC 9002 - QUIC Loss Detection and Congestion Control
HTTP/3
QPACK
Load Balancers
Applicability
Manageability
Datagram
Version Negotiation
Greasing the QUIC bit
Acknowledgement Frequency
Main logging Schema
QUIC event definitions
HTTP/3 and QPACK event definitions
Т.е. существуют документы и по самому протоколу, по вспомогательным элементам протокола таким как QPACK, использование TLS вместо QUIC Crypto, балансировщикам. Есть документы для операторов Applicability & Manageability. Есть документы по расширениям, например тот же qlog, используемый для отладки. Нужна визуализация, не проблема - qvis.
Да QUIC получается более закрытым протоколом по отношению к посредникам, если вы не являетесь условно доверенным лицом одной из стороны обмена данными (а значит у вас вероятно нет доступа ни к qlog ни к другой внутренней и зашифрованной кухне протокола). Но это и к лучшему, а для посредников, обеспечивающих работоспособность соединений и т.д., а не внедрение и прослушивание потока - вся работа остаётся только в рамках IP/UDP.
gameplayer55055
Какая проблема монополистов? Я его использую в полностью бесплатном сервере, плата только за raspberry pi и интернет.
Я монополист по вашему?
На сайтах куча всяких фреймворков, библиотек, шрифтов, картинок. И при старом http приходилось извращаться, lazy loading, делать с картинок одну большую и потом резать и прочее.
Quic позволить это все безобразие загружать быстрее.
amarao
Во-первых http уже давно поддерживает мультиплексирование. HTTP/2, не?
Во-вторых, вы плохо прочитали. Я говорю, что этот протокол решает проблемы монополистов. Вы решили их решения пробовать тоже - ок, хотя я так и не понял что у вас за проблема (не решаемая http/2). В данной ситуации монополисты продавливают вынос кода из ядра ОС в userspace-приложения, что создат ситуацию, когда авторы приложения (хром?) и авторы сервера (гугль?) почему-то контролируют всё, происходящее на машине пользователя.
Myateznik
Не, это такое же мультиплексирование как мультизадачность на одноядерном процессоре в один поток. И самое интересное, если у вас внезапно произойдёт потеря пакета все потоки будут пересылаться (мы же поверх TCP) с самого начала, что будет хуже чем если бы у нас было классическое одно TCP соединение на один поток, как это было всегда в HTTP/1.x.
Собственно HTTP/3 это своего рода переезд HTTP/2 с TCP на UDP. QUIC тут изначально был как прослойка, добавляющая много чего из мира TCP (мы же хоть и махнули в сторону мультиплекса, по прежнему опираемся на ряд механизмов из TCP) с рядом улучшений и приправ на будущее. Уже ближе к тому времени как QUIC попал под крыло IETF он стал восприниматься как более универсальный и самостоятельный уровень.
H/3 зависит от QUIC, но QUIC от H/3 не зависит. А соответственно есть возможность поверх QUIC применять любые другие протоколы, хоть DNS пакеты гонять, хоть RDP, хоть игровые, хоть MPEG потоки. Собственно протокол WebTransport по своей сути просто идентификатор "протокола", по факту весь WebTransport это и есть весь QUIC.
Про решение проблем только монополистов классика конечно же... Я например, решил тоже попробовать и даже знаю какую проблему QUIC решит, которую HTTP/2 не решит. Например, для стриминговых сервисов (это может быть аудио/видео/стриминг игр/приложение да чего угодно - не важно). Я могу в рамках одного соединения QUIC получать медиаконтент (например будем гонять MPEG-DASH совместимое видео) и одновременно контролировать со своей стороны битрейт (не переключаясь, не открывая новые соединения и т.д.), а ещё могу в третьем потоке сразу получать какие-то данные по интерактиву (в случае игр состояние и т.д., в случае потокового вещания например голосование на экране).
Как разработчик игры, я могу использовать соединение QUIC и уже сразу скинуть с себя задачу по шифрованию / базовому контролю соединения. Я буду думать только о формате пакетов и возможно о синхронизации какого-то состояния.
Ок, а может я хочу в одном соединении сразу проксировать и DNS трафик например и HTTP/1 или другой не шифрованный трафик и чтобы это всё ещё дополнительно шифровалось. Я просто поднимаю соединение QUIC и в разных потоках оперирую разными протоколами. Для меня в данном случае поток QUIC всё равно, что обычный UDP, разве что ещё сразу зашифрованный.
Или например будущий потенциальный этап развития gRPC, сейчас он основан на HTTP/2. Вероятно его переведут на HTTP/3 или ещё лучше на чистый QUIC. Тогда у нас не будет проблемы с глобальными просадками в случае потери одного пакета. Точнее проблема будет касаться только одного потока, но не всего соединения и не всех потоков в этом соединении.
Для всего можно найти и придумать применение, то что вы с этим не встречаетесь, не значит, что с этим не встречаются другие и тем более не значит, что с этим встречаются только "монополисты".
dartraiden
amarao
Нет.
https://en.wikipedia.org/wiki/HTTP/2