“Классику” тоже дропают?
quic_vk.bin (1.2 KB)
дропают
похоже, наши власти обьявили QUIC полную негласную войну
анализ QUIC сопряжен с алгоритмической и нагрузочной сложностью. проще рубануть.
любой внутрироссийский сервис будет вынужден отказываться от деплоймента QUIC
на мегафоне спб смотрел. Опять появились подвисания, непонятно по какому алгоритму. Пробивка short header первым пакетом уже не надежна. Где-то норм, но ютубе скатывается на http2 после небольших тормозов. Полной стателесс блокировки нет
внедрение блокиратора на магистрале - предполагаю это вынужденная антисанкционная мера в условиях острой нехватки оборудования. не все провайдеры еще с ТСПУ, а где есть, часто бывает лоад балансинг, где не все пути оборудованы этим ДПИ. Пробный шар как прокатит, тестирование на высокой нагрузке, включение щадящих CPU режимов фильтрации (stateless)
http, кстати, тоже фильтруется stateless. Надо сечь все пакеты внутри keep alive. Обычный режим rdp.ru предполагает фильтрацию stateful
Локалхост в надежных руках.
Меж тем изменения ПО/правил с июня-июля:
Дефрагментирует фреймы.
Неудачную расшифровку (в т.ч. проверку размеров) и SNI-less игнорирует.
По интересному совпадению, rdp научился понимать фрагменты CH сразу после выпуска nDPI с фиксом.
У них в планах, нарушить работу всех ваших игрушек, десинхронизирующих nDPI.
Насколько я понял, цель фрагментации CH в chrome - вовсе не обман DPI, а принуждение веб серверов к отказу от предположения, что CH пойдет один блоком. Чтобы они вынуждены были учитывать такой сценарий, а не упрощать себе жизнь, тем самым не полностью поддерживая стандарт.
Собрать разбросанные фрагменты не настолько алгоритмически сложно и CPU затратно, сколько расшифровать сам пакет. Удивительно, что этого не было сделано сразу.
Текущая ситуация по QUIC примерно такая.
Опробовано порядка 12 провайдеров в RU из разных городов.
На большинстве из них QUIC блокируется путем анализа SNI из расшифрованного QUIC initial.
Если SNI плохой, то блокируется stateful все udp “соединение”.
Анализируется только udp port 443.
Поскольку поведение у всех примерно одинаковое, то можно сказать, что блокирует ТСПУ.
Но тут есть важная оговорка. Модуль парсера кривой.
тут есть статический curl для x86_64 и arm с поддержкой nghttp3 (curl) и quiche (curlq)
Если попробовать этими 2 курлами подергать инстаграм, то видно, что curl виснет, а curlq прокатывает.
Так же firefox после пробивки TCP (чтобы он начал переходить на QUIC) спокойно берет http3, а chrome - только http2.
Можно проверить, загнав через ncat на свой VPS : блобы из zapret:files/fake. quic_initial_facebook_com.bin не доходит, а quic_initial_facebook_com_quiche.bin доходит.
То есть вывод, что парсер сечет chrome и nghttp3, но не сечет quiche и firefox.
Без обхода блокировок по TCP броузеры все равно не пойдут на QUIC, так что разницы практической мало.
Разблокируется через nfqws --fake.
Есть и исключение у провайдеров. Tiera, как обычно. Аплинк глобалнет продолжает полностью блокировать QUIC. Больше нет никаких подвисаний сессии. Тупо режут long header в обе стороны.
Есть ли новости какие? Просто он такой быстрый, вон авито по http3 картинки подгружает, translate.google.ru тоже отсвечивает соединениями с QUIC…