Комментарии 29
Оно нужно гуглу и нескольким толстым компаниям. Свободному интернету этот протокол, с делегацией проблемы из ядра ОС в userspace, дался как собаке QUIC протокол. Сравнение с ipv6 совершенно ошибочно, потому что ipv6 решает проблемы большинства, а quic - толстой жирной it-прослойки нескольких монополистов.
А какие проблемы монополистов он решает?
Снижение огромного объёма трафика, может быть усложнение блокировки рекламы на промежуточных узлах.
Вряд ли. Насчёт трафика сложно сказать, на их объёмах любая копеечная экономия может быть заметна, но вот что до блокировки MITM то эту проблему решил https. А блокировать через /etc/hosts (как AdAway на телефонах) и через браузерные плагины QUIC не помешает.
Есть, например, AdGuard, который на сетевом уровне фильтрует всё внутри HTTPS. А для QUIC надо писать отдельный модуль. (Не в курсе, написали ли они его уже или нет).
Блокировка рекламы и систем слежения с помощью HOSTS или DNS-серверов не является полной. Сейчас на многих площадках реклама встроена в код страницы или просто грузится с того же домена, что и контент.
Браузерные расширения такое фильтруют пока хорошо. Но например в Chrome фильтрации контента скоро не станет, спасибо Manifest v3. Если хотите сохранить нормальную фильтрацию придётся переходить на Firefox.
Если хотите сохранить нормальную фильтрацию придётся переходить на Firefox.
Вы так говорите, как будто это что-то плохое. Плохо - это когда хром сожрал весь рынок, идя по стопам IE6. Так что если из-за фильтрации рекламы часть пользователей перейдёт на Firefox - это же хорошо.
Есть, например, AdGuard, который на сетевом уровне фильтрует всё внутри HTTPS.Вы говорите про MitM так, словно это что-то хорошее.
Туда им и дорога, всем этим перехватчикам HTTPS-трафика.
Рекламу можно блокировать и с quic. От Ютуб слышал на него перешёл. Моему адблокеру пофиг
Вы зря так, я очень надеюсь на его признание и повсеместное использование (не только в http) из-за одной важной фичи - connection id и самовосстановление при изменении IP. Что бывает весьма актуально в условиях мобильного интернета и переключением между ним и wifi хотспотами.
К сожалению, по факту "нормальных приложений" очень мало, и потеря коннектов - очень часто происходит. И да, я скорее про неHTTP-приложения говорю. Там я вижу гораздо больше потенциала для QUIC чем для HTTP стэка, как бы парадоксально это не звучало.
Хочу также уточнить, что проблема с реконнектами бывает даже не обязательно при смене IP, бывает просто разрыв недолгий - и коннект уже сбрасывается сервером, а для нового нужна реавторизация (в частности, касается игровых приложений - там из игры "выкидывает", приходится заново реавторизовываться для продолжения игровой сессии). В QUIC connection id способна решить такую проблему.
Для меня, как для оператора, quic выглядит чёрным ящиком. Если по tcp я вижу много метрик и могу понимать что происходит с сервером, то quic - целиком на откупе приложений. В https общепринята модель c https прокси поверх http на localhost, что даёт возможность быстро смотреть на проходящий трафик. quic это всё уничтожает.
Вместо богатого инструментария я получаю чёрный ящик, который "что-то там по сети шлёт", и пока программист (каждый из программистов каждого из приложения) не выставит метрики наружу, то про этот чёрный ящик ничего сказать нельзя.
Ну http3 это по сути http2 через UDP.
Wireshark его поддерживает, заголовки куки и все фичи http тоже есть. А для канального уровня что-то по любому есть для контроля.
Скажите, сколько у вас quic соединений в состоянии established? А сколько зависло в half-open? Сколько ретрансмитов было? Откуда вы это можете посмотреть в системе? В метриках udp? Удачи.
Состояние 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.
Есть такие документы как:
Т.е. существуют документы и по самому протоколу, по вспомогательным элементам протокола таким как QPACK, использование TLS вместо QUIC Crypto, балансировщикам. Есть документы для операторов Applicability & Manageability. Есть документы по расширениям, например тот же qlog, используемый для отладки. Нужна визуализация, не проблема - qvis.
Да QUIC получается более закрытым протоколом по отношению к посредникам, если вы не являетесь условно доверенным лицом одной из стороны обмена данными (а значит у вас вероятно нет доступа ни к qlog ни к другой внутренней и зашифрованной кухне протокола). Но это и к лучшему, а для посредников, обеспечивающих работоспособность соединений и т.д., а не внедрение и прослушивание потока - вся работа остаётся только в рамках IP/UDP.
Какая проблема монополистов? Я его использую в полностью бесплатном сервере, плата только за raspberry pi и интернет.
Я монополист по вашему?
На сайтах куча всяких фреймворков, библиотек, шрифтов, картинок. И при старом http приходилось извращаться, lazy loading, делать с картинок одну большую и потом резать и прочее.
Quic позволить это все безобразие загружать быстрее.
Во-первых http уже давно поддерживает мультиплексирование. HTTP/2, не?
Во-вторых, вы плохо прочитали. Я говорю, что этот протокол решает проблемы монополистов. Вы решили их решения пробовать тоже - ок, хотя я так и не понял что у вас за проблема (не решаемая http/2). В данной ситуации монополисты продавливают вынос кода из ядра ОС в userspace-приложения, что создат ситуацию, когда авторы приложения (хром?) и авторы сервера (гугль?) почему-то контролируют всё, происходящее на машине пользователя.
Во-первых http уже давно поддерживает мультиплексирование. HTTP/2, не?
Не, это такое же мультиплексирование как мультизадачность на одноядерном процессоре в один поток. И самое интересное, если у вас внезапно произойдёт потеря пакета все потоки будут пересылаться (мы же поверх 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. Тогда у нас не будет проблемы с глобальными просадками в случае потери одного пакета. Точнее проблема будет касаться только одного потока, но не всего соединения и не всех потоков в этом соединении.
Для всего можно найти и придумать применение, то что вы с этим не встречаетесь, не значит, что с этим не встречаются другие и тем более не значит, что с этим встречаются только "монополисты".
Во-первых http уже давно поддерживает мультиплексированиеHTTP pipelining, поддержка которого выключена по умолчанию в браузерах не просто так? (а из Firefox её с облегчением полностью выпилили аж 5 лет назад, констатировав «I tried so hard to make h1 pipelining a reality… The feature was never able to overcome the limitations of HoL blocking»)
Инженеры интернет-регистратора APNIC также отмечают, что QUIC работает хуже, если возникает необходимость повторной передачи потерянных пакетов.
...то есть всегда, потому что это UDP. Не говоря уже о том, что здесь, судя по всему, спрятано довольно-таки жирное допущение об окончательном уходе в прошлое сетей навроде dial-up — с нестабильностью и малой пропускной способностью.
Будто с TCP пакеты не теряются.
Восстановление после потерь есть у обоих.
У TCP абсолютная гарантия доставки, "ни один байт потока не должен быть потерян". У UDP же она отсутствует и обычно выполняется на уровне протоколов, реализованных поверх UDP, к которым относится и QUIC.
И моё опасение (не говоря уже о появлении лишнего протокольного слоя) заключается в том, является ли гарантия доставки в QUIC сопоставимой по эффективности с TCP, потому что её так-то можно и дубовой переотправкой вплоть до ack делать - только каналу от этого плоховато становится.
Соединение, установленное по TCP, имеет отдельный сокет. Его можно перебросить в другой тред или процесс.
Для UDP такого нет. Есть разделение нагрузки, но куда попадёт конкретная датаграмма — управлять нельзя. Значит, принимать в юзерленд должен один тред, дальше распределять нагрузку в пуле.
Как это предполагают решать? Вижу два варианта:
1. Добавка каким-нибудь setsockopt «общение с этими host:port перебрасывать вот на этот дескриптор» (и не забывать вычищать из таблиц по завершению соединения; на TCP эта вычистка происходит автоматом. Может, по аналогии со всякими eventfd, сделают владение таким управлением через дескриптор файла?)
2. На уровне протокола редирект «не реконнектиться, но переключиться на порт 54800» (может, даже другого IP).
Я ничего не смог найти про эту проблему и её решения. Может, кто-то что-то слышал?
QUIC стал RFC, но как дела с перспективами — обсуждаем мнения