Поведенческая классификация транспортов в современных D

О документе. Это образовательно-аналитический материал. Цель — объяснить, как работают современные системы классификации трафика на уровне механизмов и архитектуры, и почему одни классы транспортных протоколов теряют различимость быстрее других. Документ не содержит рекомендаций по обходу фильтрации, не предлагает инструментов, конфигураций или параметров. Все факты сопровождаются ссылками на первичные источники (академические публикации, документация RFC, открытые трансляции и публичные исследования сообщества).

1. Контекст: почему «обычный сайт работает, а туннель — нет»

За 2024–2026 годы у пользователей в РФ зафиксирована устойчивая картина: серверная инфраструктура и легитимные веб-сервисы на TCP/443 и UDP/443 остаются доступны, при этом целевые туннельные соединения к тем же портам либо не устанавливаются вовсе, либо устанавливаются и быстро разрываются, либо демонстрируют выраженную деградацию (потери, всплески RTT). Симптом одинаков для совершенно разных по криптографии и архитектуре решений — от Shadowsocks до VLESS+Reality.

Объяснение, которое часто дают «фильтр научился расшифровывать ваш протокол», — неверно. Современные системы классификации трафика практически нигде не пытаются нарушить криптографическую стойкость соединения. Они опираются на иной слой признаков: то, как выглядит соединение в целом — его метаданные, тайминги, статистика размеров пакетов, особенности handshake, последовательности TLS-расширений, присутствие/отсутствие тех или иных полей, поведение после установления сессии. Этот сдвиг от «сигнатура полезной нагрузки» к «поведенческой классификации» — главная содержательная причина, по которой решения, ещё в 2023 году считавшиеся надёжными, в 2026 году перестают работать.

Цель документа — на уровне механизмов разобрать:

из чего складывается «поведенческий портрет» соединения;
какими принципиально разными способами устроена классификация TCP- и UDP/QUIC-трафика;
какие классы транспортных протоколов по архитектурным причинам устойчивее или менее устойчивы к такой классификации;
к каким теоретическим пределам подошёл этот arms race согласно академической литературе.

2. Архитектура современных классификаторов на примере ТСПУ

Понимание того, что на самом деле происходит с пакетом, начинается с архитектуры. Российская система фильтрации трафика (ТСПУ — технические средства противодействия угрозам) и Великий китайский фаервол (GFW) — два наиболее изученных современных DPI-комплекса, при этом построенные принципиально по-разному.

2.1. Распределённый pipeline ТСПУ

Согласно публичной академической работе «Russia's TSPU» (Xue et al., IMC'22) и последующим публикациям сообщества, ТСПУ — распределённая система, физически установленная «в разрыв» каналов оператора связи в десятках точек по стране. По разным оценкам и публичным трансляциям, общая инсталляция включает порядка нескольких тысяч устройств, объединённых в единую систему централизованного управления.

На каждой площадке стоит характерная цепочка устройств:

Оператор → Bypass (оптический) → Балансировщик → Фильтры (DPI) → обратно

Bypass — оптический переключатель, обеспечивающий fail-safe: в случае отказа балансировщика или фильтров трафик «прокатывается» мимо системы.
Балансировщик — программируемый ASIC (по данным открытых трансляций — Barefoot Tofino, ~3.2 Тбит/с агрегированной пропускной способности на устройство), распределяющий сессии по фильтрам с симметричным хешем f(src_IP, dst_IP, IP_protocol) — что важно, без участия L4-портов. Это обеспечивает попадание прямого и обратного трафика одной сессии на одно и то же ядро одного и того же фильтра.
Фильтры — Linux-машины с DPDK-движком, выполняющие собственно DPI. Это L2-устройства без IP-интерфейсов в data plane (то есть «не видны» в traceroute и не имеют адреса для прямой адресации).

ТСПУ распределён ещё и логически: фильтры умеют принимать решения локально по уже выкаченным спискам (IP, домены, сигнатуры протоколов), а через служебный канал (gRPC) передают агрегированные события в центральную систему управления (ЦСУ).

2.2. Двухстадийная модель блокировки

Ключевая особенность, плохо известная за пределами специалистов, — блокировка протоколов в ТСПУ не моментальная. Из публичных трансляций и анализа поведения системы складывается следующая картина:

Стадия 1 (детект). Фильтр локально распознаёт сессию как принадлежащую к определённому классу (например, «Telegram», «вероятный VPN»). По умолчанию для свежераспознанного класса срабатывает не блокировка, а действие log — событие фиксируется и передаётся в централизованную систему.
Стадия 2 (анализ). На центральной стороне накапливаются события от множества фильтров, выделяются IP-адреса и порты, демонстрирующие устойчивый паттерн.
Стадия 3 (распространение). Очищенные списки IP+порт раскатываются обратно на фильтры (поведение block) и/или на балансировщик (BGP-фильтрация по IP).

Полный цикл от первого детекта до фактической блокировки оценивается в диапазоне от единиц минут до десятков минут, в отдельных сценариях — до нескольких часов. Существующие сессии, как правило, не разрываются принудительно: они просто не смогут переустановиться с того же адреса.

Это объясняет частое наблюдение: «всё работало два часа, потом перестало». Это не «адаптация в реальном времени», а ровно описанный pipeline: детект → накопление статистики → раскатка списка.

2.3. Отличие от GFW

GFW устроен иначе: централизованные DPI-комплексы стоят на международных стыках Китая. Это даёт другую точку компромисса: GFW обрабатывает существенно больший суммарный поток на единицу железа, поэтому вынужден экономить ресурсы (например, инспектировать только первые пакеты flow и применять эвристики типа sport > dport для отсева большей части UDP-трафика — см. Zohaib et al., USENIX Security 2025). ТСПУ распределён по операторам и на каждое устройство приходит меньший объём; это потенциально позволяет ТСПУ применять более «дорогие» политики на единицу сессии.

Принципиально оба класса систем сейчас движутся в одном направлении: от чисто сигнатурного матча в полезной нагрузке — к классификации по метаданным, поведению handshake и структурным аномалиям.

3. Поведенческая классификация: на что смотрит современный DPI

Когда говорят «DPI распознаёт ваш протокол», стоит заменить это на более точную формулировку: «классификатор сопоставляет наблюдаемой сессии один из заранее известных классов трафика по совокупности признаков». Признаки сейчас группируются примерно в четыре пласта.

3.1. Структурные признаки внутри handshake

Для TLS — это в первую очередь форма ClientHello:

набор поддерживаемых cipher suites и его порядок;
набор и порядок TLS extensions (extension list);
параметры supported_groups, signature_algorithms, key_share;
набор ALPN-протоколов;
наличие/отсутствие GREASE-значений (RFC 8701) и их позиции.

Совокупность этих полей описывают известные fingerprint-схемы — JA3 (устаревшая, MD5-хеш) и JA4/JA4+ (актуальная, см. публичную спецификацию FoxIO, 2023). Идея проста: легитимные браузеры (Chrome, Firefox, Safari) и легитимные клиентские стеки (мобильный Chrome, Edge на iOS, NSS-based приложения) дают строго определённые наборы значений, известные в публичных датасетах. Любая кастомная реализация TLS (например, написанная на Go через стандартный crypto/tls, на Rust через rustls с дефолтными настройками, на Python через requests) формирует другой fingerprint, который при достаточной массовости становится дискриминантным признаком целого класса инструментов.

Принципиальный момент: фингерпринт собирается из открытых полей ClientHello, никакая криптография при этом не нарушается. Защититься «более стойким шифром» от такой классификации невозможно по построению.

Аналог для QUIC — структура самого Initial-пакета: длины Connection ID, набор и порядок Transport Parameters, конкретные значения GREASE, особенности раскладки CRYPTO-фреймов внутри пакета. Здесь классы инструментов также различаются структурно.

3.2. Post-handshake поведение

Даже если handshake выглядит «как у браузера», после него начинается полезный обмен — и здесь у транспорта-туннеля поведение принципиально иное, чем у браузера, заходящего на новостной сайт. Браузер открывает TLS-сессию, делает несколько HTTP/2-запросов, получает ответы конечного размера и завершает либо переиспользует сессию для других ресурсов на том же домене. Туннель открывает одну долгую сессию, через которую гонит непрерывный двунаправленный поток с распределением размеров пакетов, типичным для передачи данных, а не для загрузки страницы.

Что измеряется конкретно:

распределение размеров TLS records / QUIC datagrams (среднее, дисперсия, перцентили);
межпакетные интервалы и их регулярность;
соотношение объёмов прямого и обратного трафика (asymmetry);
продолжительность сессии;
паузы между активными «пачками» данных.

Подобные подходы хорошо описаны в академической литературе по traffic classification — см., например, работы Wang et al. по применению ML к зашифрованному трафику и обзорные статьи последних лет в IEEE Communications Surveys & Tutorials. Современные классификаторы могут использовать как явные пороговые правила, так и обученные модели (от классических random forest до lightweight нейросетей), способные различать классы трафика с высокой точностью на входной выборке из метаданных без доступа к содержимому.

3.3. Активное зондирование (active probing)

DPI-системе не обязательно ждать, пока подозрительная сессия сама себя «выдаст». Если соединение помечено как подозрительное, фильтр (или вспомогательный сервис) может самостоятельно инициировать тестовые подключения к тому же IP+порту и проверить, ведёт ли себя сервер как заявленный класс. Если предъявленный snapshot говорит «это веб-сервер за TLS», а на пробное подключение приходит специфический ответ кастомного транспорта (или, наоборот, не приходит ничего) — класс установлен.

Active probing исторически был ключевым приёмом GFW против Tor (см. Ensafi et al., FOCI 2015) и Shadowsocks (см. Alice et al., 2020). Современный набор «правильных» ответов для proxy-серверов под TLS-маскировку — это полноценный реальный веб-сервер (например, Caddy, Nginx) с настоящим сертификатом и осмысленным контентом, обслуживающий «нечужие» зонды как обычный публичный сайт. Любой более слабый вариант (статическая страница-заглушка, отсутствие ответа, разрыв соединения) — индикатор класса.

3.4. Статистическая массовость

Это самый «нечестный» по природе фактор и самый недооценённый в дискуссиях. Чем популярнее становится конкретная схема (конкретный TLS fingerprint, конкретный набор Transport Parameters, конкретный паттерн потока), тем больше у классификатора накопленных позитивных примеров и тем выше уверенность срабатывания. То есть протокол может быть архитектурно устойчив, но как только он начинает использоваться сотнями тысяч серверов, стандартизированный набор открытых полей его клиентов и единообразное поведение его сессий становятся сигнатурой по факту.

Этот эффект объясняет, почему «вчерашняя серебряная пуля» теряет различимость: дело часто не в новой технологии у DPI, а в банальном накоплении выборки.

4. TLS-уровень: реассемблирование, фрагментация и устойчивость

Современный TCP-DPI в обеих системах (ТСПУ, GFW), судя по публичным данным, выполняет полноценную реассемблировку TCP-сегментов перед тем, как приступить к разбору TLS. Это означает, что любые попытки разложить ClientHello по нескольким TCP-сегментам на уровне socket API (типа последовательных send() с маленькими кусками) к моменту анализа уже собраны фильтром обратно — DPI смотрит на сплошной поток.

Это важная архитектурная точка: чтобы разорвать процесс реассемблировки, нужны манипуляции ниже уровня сокета — то есть либо контроль над формированием самих IP/TCP пакетов (что доступно только при доступе к сетевому стеку — на роутере или с правами администратора), либо работа на уровне TLS (фрагментация TLS records). Последнее показано в работе Niere et al., IEEE S&P 2025 («Transport Layer Obscurity»), где было продемонстрировано, что фрагментация на уровне TLS records (через стандартный API OpenSSL) обходит реассемблировку GFW без необходимости root-прав; тот же документ идентифицировал «третий middlebox» в системе фильтрации Китая. С академической точки зрения важно то, что 92% серверов Tranco Top 1M толерантны к такой фрагментации, а 96% доменов CitizenLab Censored List — также.

ТСПУ в части TCP-реассемблировки публично менее изучен, но косвенные данные (поведение по SNI-блокировке) указывают на наличие схожего механизма реассемблировки. Ни одна из систем при этом, насколько известно из открытых исследований, не выполняет активной нормализации потока (то есть не «склеивает» перекрывающиеся сегменты по строго определённой политике) — эта область остаётся областью архитектурных различий и в 2026 году по-прежнему предметом исследований.

4.1. ECH (Encrypted Client Hello)

RFC 9849 (ECH) — стандартное архитектурное решение проблемы plaintext-SNI: настоящий SNI шифруется асимметричным ключом сервера и помещается во внутренний ClientHelloInner, а во внешнем ClientHelloOuter стоит generic-домен (так называемое «public name»). DPI без приватного ключа сервера прочитать настоящий SNI не может.

Текущий статус ECH в публичной картине:

GFW (по состоянию на FOCI'25, Niere et al.): ECH в QUIC не блокируется, при условии что outer SNI не входит в blocklist.
ТСПУ: с конца 2024 года блокирует ECH к Cloudflare по комбинации признаков (outer SNI = cloudflare-ech.com плюс наличие ECH-расширения). ECH к не-Cloudflare провайдерам пока не блокируется, но серверная экосистема ECH очень узкая (Cloudflare — основной провайдер).

Это иллюстрирует общий принцип: даже архитектурно сильное решение становится мишенью, как только его развёртывание сводится к одному крупному провайдеру с предсказуемым outer SNI. Архитектурная стойкость ECH остаётся в силе; уязвимость возникает на уровне развёртывания.

5. QUIC-уровень: параллельная вселенная

QUIC устроен принципиально иначе, чем TCP/TLS, и DPI-системы вынуждены обрабатывать его по другой модели. Понимание этой разницы критично для трезвой оценки устойчивости QUIC-based транспортов.

5.1. Stream reassembly vs packet filter

Отличие, зафиксированное в открытых публикациях:

	TCP/TLS	QUIC
Модель обработки в DPI	потоковая реассемблировка	пакетный фильтр
Реассемблировка ClientHello/CRYPTO	да	как правило, нет
Агрегация по сессии	да	ограниченно
Извлечение SNI	из реассемблированного потока	из первого Initial-пакета
Возможность блокировки	RST-инжекция или silent drop	только packet drop

Источники: Zohaib et al., USENIX Security 2025 — для GFW. Для ТСПУ деталь о типе обработки QUIC в публичной литературе слабее зафиксирована, но косвенные признаки (отсутствие подтверждённого reassembly CRYPTO-фреймов) указывают на схожую модель.

5.2. SNI-extraction в QUIC

Здесь происходит контринтуитивная вещь. QUIC Initial-пакет шифруется ключом, детерминированно выводимым из публичных полей самого пакета (Destination Connection ID и version-specific salt — см. RFC 9001 для v1, RFC 9369 для v2). Это означает, что любой посредник, видящий пакет, способен вычислить ключ и расшифровать содержимое CRYPTO-фрейма — то есть получить TLS ClientHello со всеми extension-ами, включая SNI. В этом смысле QUIC Initial не приватен от пассивного наблюдателя на пути.

GFW делает это в проде с 2024 года; ТСПУ, согласно публикациям Paderborn University (апрель 2025) и наблюдениям сообщества (ntc.party, net4people), также извлекает SNI из QUIC Initial — что позволило в 2024 году впервые наблюдать селективный по домену throttling QUIC-трафика к YouTube в России (до этого с 2022 года ТСПУ просто блокировал весь QUIC v1 по plaintext-fingerprint без извлечения SNI).

5.3. Тонкие места моделей DPI

Из академической литературы и публичных тестов (USENIX'25 artifacts, github.com/gfw-report) известны конкретные характеристики GFW:

Flow timeout: ~60 секунд неактивности → state сбрасывается;
Residual blocking: после срабатывания блокировка действует ~180 секунд, scope — 3-tuple (src_ip, dst_ip, dst_port);
Direction asymmetry: блокируется только трафик клиент→сервер;
Fail-open в blacklist-режиме: если содержимое не парсится как известный класс — пакет пропускается;
Inspection scope: только первый Initial-пакет flow; последующие идут по «быстрому пути».

Аналоги для ТСПУ систематически не измерены и являются открытым исследовательским вопросом сообщества.

5.4. Blacklist vs whitelist режим — фундаментальная разница

Важнейшее архитектурное различие, недостаточно обсуждаемое в публичной дискуссии:

В blacklist-режиме (классический режим федеральной фильтрации в РФ для проводных операторов) система блокирует то, что распознала как нарушающее правила. Всё, что не распознано, по умолчанию проходит. Это — fail-open.
В whitelist-режиме (наблюдается в российской мобильной сети, особенно в режимах региональных «замедлений» — см. публичные репозитории whitelist-ов сообщества и ntc.party) система пропускает только то, что распознала как разрешённое. Всё, что не распознано, по умолчанию блокируется. Это — fail-closed.

Эти два режима порождают совершенно разные требования к транспорту. В blacklist-сценарии любое архитектурно нестандартное соединение, которое DPI «не понял», скорее всего проходит. В whitelist-сценарии то же самое соединение по той же причине будет заблокировано. Таким образом, общие утверждения «протокол X устойчив» имеют смысл только с указанием режима, в котором они проверялись.

6. Сравнительная устойчивость классов транспортов: архитектурный анализ

В этом разделе перечислены классы транспортных решений с обоснованием, какие архитектурные свойства делают их более или менее устойчивыми к описанной выше классификации. Это не оценки конкретных продуктов и не рекомендации; это обсуждение свойств, выводимых из публичной документации этих классов.

6.1. Прозрачные транспорты без маскировки (Shadowsocks, vanilla VMess/VLESS, MTProto-proxy)

Класс характеризуется тем, что после первого handshake (или вместо него) идёт непрерывный поток шифротекста без какой-либо имитации легитимного протокола поверх. Уязвимости архитектурные:

Отсутствие осмысленного TLS-handshake → плотная последовательность пакетов без структурного «вступления»;
Распределение размеров пакетов и временные интервалы характерны для туннеля передачи данных, не для работы веб-приложения;
При active probing соединение либо отвечает фирменным образом, либо никак не отвечает — оба варианта дискриминантны.

Этот класс начали успешно классифицировать ещё в конце 2010-х (см. серию публикаций о блокировке Shadowsocks в Китае в 2019–2020). С тех пор инструменты классификации только улучшились; в whitelist-сценариях этот класс тривиально отсеивается отсутствием легитимной классификации.

6.2. TLS-маскировка с tunnel-семантикой post-handshake (Trojan, ShadowTLS и аналоги)

Класс характеризуется правдоподобным TLS-handshake (часто с проксированием реального сертификата и SNI крупного публичного домена), но после установления соединения внутри идёт всё тот же tunnel-трафик. Что улучшается:

TLS fingerprint может быть сделан правдоподобным, особенно при использовании реальных TLS-стеков под капотом;
Active probing к внешне «легитимному» сайту получает легитимный ответ.

Что остаётся:

Post-handshake распределение трафика по-прежнему характерно для туннеля;
Долгие сессии с асимметрией и ровным потоком данных не похожи на типичный браузерный pattern для этого домена.

В режимах поведенческой классификации этот класс остаётся уязвим.

6.3. Высокоточная имитация TLS-стека (VLESS+Reality и подобные)

Класс делает шаг дальше: не просто «правильный TLS-handshake», а fingerprint-уровень совпадения с конкретным браузером, плюс прокидывание соединений к реальному сайту (для тех клиентов, кто «не наш»), что делает active probing бесполезным. Архитектурная сила класса максимальна на handshake-уровне.

Уязвимости, которые проявились в 2025–2026:

Post-handshake поведение: Reality защищает рукопожатие, но не структуру потока после него. Браузерный «портрет» работы с реальным сайтом и tunnel-портрет потока к тому же сайту различаются, и эта разница доступна классификатору.
Массовость: как только данный класс развёртывается на десятках тысяч серверов, у классификатора накапливается достаточно позитивных примеров, и возникает дискриминантный набор поведенческих признаков «именно этой схемы», даже при идеально воспроизведённом fingerprint.
Серверная сторона: у фильтра остаются признаки на уровне ASN, репутации диапазонов, времени жизни доменов, корреляций IP↔SNI.

Итого: класс очень силён архитектурно на уровне handshake, но не устраняет поведенческую различимость на уровне сессии в целом. Это объясняет, почему Reality, считавшаяся «золотым стандартом» в 2023, в 2026 показывает деградацию.

6.4. QUIC-based транспорты (Hysteria2, TUIC и аналоги)

Класс характеризуется работой поверх QUIC/UDP, с собственным протоколом поверх QUIC streams. Сильные стороны:

UDP/443 в blacklist-сценариях исторически менее активно фильтруется;
Архитектурно унаследованные свойства QUIC: резистентность к сегментной реассемблировке, поскольку DPI чаще всего работает в packet-filter режиме на QUIC.

Слабые стороны:

QUIC Initial у этих транспортов содержит свои отличительные структурные признаки (Transport Parameters, ALPN-значения), что даёт JA4-аналог fingerprint;
Поведение QUIC-потоков (распределение размеров, тайминги, отсутствие HTTP/3-семантики обычного браузерного трафика) дискриминантно;
В whitelist-режимах: QUIC-трафик с SNI вне whitelist отсекается так же, как и TCP/TLS.

6.5. Полная имитация на уровне реального HTTP/3-стека (NaiveProxy и архитектурно близкие решения)

Класс отличается тем, что использует сетевой стек реального браузера (Chromium network stack) или его эквивалент в качестве клиента, и правдоподобный HTTP-сервер (Caddy, Nginx с подходящим модулем) на серверной стороне. В качестве транспорта — стандартный HTTP/2 CONNECT (или HTTP/3) к легитимно выглядящему домену.

Что важно архитектурно:

TLS fingerprint = настоящий Chromium fingerprint, поскольку это и есть Chromium-стек;
Active probing к серверу получает ответ настоящего Caddy/Nginx, поскольку это и есть Caddy/Nginx;
Post-handshake поведение приближается к легитимному HTTP-трафику, поскольку это HTTP, а не tunnel-протокол поверх HTTP.

Что остаётся уязвимым (об этом мало говорят):

Семантика трафика на уровне приложения (HTTP CONNECT для туннелирования к произвольным хостам) отличается от типичного браузерного паттерна — браузер не открывает long-lived CONNECT-сессии к одному и тому же домену с непрерывным двунаправленным потоком в десятки минут;
Развёртывания с предсказуемой инфраструктурой (один и тот же тип серверов, одни и те же домены, одна и та же конфигурация Caddy) подвержены тому же эффекту массовости.

Тем не менее, на сегодня этот класс действительно демонстрирует наивысшую устойчивость к описанным выше формам классификации, по архитектурным причинам — он минимизирует количество отличий от легитимного веб-трафика на каждом уровне (fingerprint, probing, частично — поведение).

6.6. Сводка по архитектурным свойствам

Архитектурное свойство	Что закрывает	Чего не закрывает
Шифрование туннеля	приватность контента	классификацию по метаданным
Правдоподобный TLS handshake	JA3/JA4 fingerprint, active probing	поведение post-handshake
Реальный сертификат + сайт-обложка	active probing	поведение трафика на уровне сессии
Использование настоящего браузерного TLS-стека	fingerprint целиком	приложение-уровневую семантику
Имитация HTTP-семантики (CONNECT через реальный HTTP-сервер)	поведение handshake и большую часть сессионного профиля	специфику long-lived CONNECT и эффект массовости
ECH	plaintext SNI	блокировку по outer SNI и наличию ECH-расширения
QUIC-транспорт	TCP-reassembly как вектор	пакетную классификацию QUIC и whitelist-режимы

7. Whitelist vs blacklist: почему «работает в Москве, не работает в регионе»

Эта тема заслуживает отдельного раздела, поскольку постоянно вводит наблюдателей в заблуждение. Один и тот же транспорт, работающий стабильно у одного пользователя, может полностью не работать у другого. Чаще всего это объясняется не «адресной блокировкой», а режимом фильтрации в данной точке сети.

В blacklist-режиме (типичный режим федеральной фильтрации для проводных операторов в обычной обстановке) система пытается распознать запрещённое и пропускает всё, что не распознано. Транспорт, который выглядит «непонятно для DPI», скорее всего работает.

В whitelist-режиме (наблюдается на мобильных сетях, особенно в режимах региональных ограничений) система пропускает только то, что попадает в список разрешённого (по SNI и/или CIDR). Транспорт, который выглядит «непонятно для DPI», блокируется по дефолту.

Это означает, что одно и то же свойство транспорта (например, «выглядит как нечто, чего DPI не классифицирует») имеет противоположные последствия в разных режимах. Утверждения вида «X работает» имеют смысл только с указанием режима. На практике: транспорты, которые имитируют конкретный легитимный сервис, попадающий в whitelist, выживают в обоих режимах; транспорты, которые рассчитаны на «непонятность», выживают только в blacklist.

Публично известные whitelist-наборы для российской мобильной сети поддерживаются сообществом в открытых репозиториях (см. github.com/hxehex/russia-mobile-internet-whitelist и обсуждения на ntc.party); состав — крупные российские сервисы (mail.ru, vk.com, yandex.ru, госуслуги и др.) и их CDN-диапазоны.

8. Что говорит академика о теоретических пределах

В академической литературе последних двух лет (USENIX Security 2025, IEEE S&P 2025, FOCI 2025, ACM CCS 2025) сложилась согласованная картина:

Сигнатурный матч устаревает. Большинство прорывных публикаций демонстрируют, что даже системы уровня GFW не выполняют активной нормализации потоков, не реассемблируют все необходимые слои и опираются на эвристики, доступные при ограниченных вычислительных ресурсах. Это — фундаментальное архитектурное ограничение: полноценный stateful inspection в реальном времени на национальных стыках с многотерабитной нагрузкой требует компромиссов.
Поведенческая классификация фундаментально мощнее. Серия работ показывает, что даже идеально замаскированный handshake не закрывает классификацию по метаданным сессии (распределению размеров пакетов, временным паттернам, ассиметрии). Этот тип признаков не разрушается криптографией.
Эффект массовости объективен. Чем популярнее транспортная схема, тем выше её различимость по построению: классификатор получает больше данных, формирует более устойчивые модели, и ошибка классификации падает. Это означает, что любой «универсальный рецепт» обречён на самораспад по мере распространения.
Архитектурные подходы, минимизирующие отличия от реального легитимного трафика на всех слоях, имеют наибольший потенциал долговременной устойчивости — поскольку для их детекции классификатор должен научиться отличать то-же-самое-без-кавычек от того-же-самого-в-кавычках. В пределе это та же задача, что и «отличить хороший трафик от плохого без доступа к содержимому» — теоретически разрешимая, но практически дорогая.
DPI как класс систем тоже исследуем. Работы по fingerprinting'у самих DPI-устройств (например, Xue et al., dMAP, CCS 2025) показывают, что сами фильтры детектируемы по их «амбивалентностям» в ответах на специально сконструированные пробы. Это означает: классификатор и классифицируемый — части одной измеримой системы, и arms race в этой паре — не «оборона vs нападение», а взаимное измерение.

9. Что это значит на практике (безоценочно)

Сводя картину последних двух лет к нескольким общим утверждениям:

«Расшифровать ваш протокол» — почти никогда не происходит. Происходит классификация по открытым полям и метаданным. Это другой класс задачи и от криптографической стойкости почти не зависит.
TCP и QUIC — две принципиально разные дисциплины. Одни и те же утверждения нельзя автоматически переносить с одного на другой; внутренняя архитектура классификаторов у этих двух транспортов разная.
Устойчивость в blacklist-режиме и в whitelist-режиме — разные свойства. Решения, оптимизированные под одно, могут не работать в другом.
Архитектурное преимущество = минимум отличий от настоящего легитимного трафика на каждом из слоёв. Это включает: fingerprint, поведение при active probing, post-handshake распределение трафика, уровень приложения, репутацию инфраструктуры. Чем больше слоёв «совпадают по-настоящему», тем дольше класс протекает под классификатором.
Массовость — естественный убийца ранее работавших схем. Это объективное свойство системы, а не «плохая новость» о конкретном решении.
Окно реакции системы — минуты, не миллисекунды. Двухстадийный pipeline (детект → накопление → раскатка списка) объясняет наблюдаемое поведение «работало, потом перестало» гораздо лучше, чем гипотезы о моментальной адаптации.

Ничто из этого не является рекомендацией. Это — описание того, почему наблюдаемая картина выглядит именно так, как она выглядит, и каких вещей не следует ожидать от «следующего серебряного решения».

Источники (для самостоятельной проверки)

Академические работы:

Xue et al., «Russia's TSPU: Censorship Pattern in the Wild», ACM IMC 2022.
Zohaib et al., «Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China», USENIX Security 2025 (Best Paper Honorable Mention). Артефакты: github.com/gfw-report/usenixsecurity25-quic-sni
Niere et al., «Transport Layer Obscurity: Circumventing the GFW with TLS Record Fragmentation», IEEE S&P 2025.
Niere et al., «ECH Blocking: A Cross-Country Measurement Study», FOCI 2025.
Xue et al., «dMAP: Fingerprinting DPI Devices by Their Ambiguities», ACM CCS 2025.
Ensafi et al., «Examining How the Great Firewall Discovers Hidden Circumvention Servers», FOCI 2015 (Tor active probing).
Jia et al., «QUICstep: Circumventing QUIC-based Censorship», 2023.

Стандарты:

RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport.
RFC 9001 — Using TLS to Secure QUIC.
RFC 8999 — Version-Independent Properties of QUIC.
RFC 9369 — QUIC Version 2.
RFC 8446 — TLS 1.3.
RFC 8701 — GREASE for TLS.
RFC 9849 — TLS Encrypted Client Hello.

Открытые ресурсы и сообщество:

gfw.report — отчёты исследовательской группы по GFW.
ntc.party — основная русскоязычная исследовательская площадка по ТСПУ.
github.com/net4people/bbs — тематические треды по отдельным аспектам цензуры.
censoredplanet.org — глобальная система измерения цензуры.
ooni.org — Open Observatory of Network Interference.
Спецификация JA4/JA4+ — github.com/FoxIO-LLC/ja4

Документация TLS/QUIC-стеков:

google/quiche — каноничная реализация QUIC от Google.
Документация Chromium network stack.

Версия документа: v1, 2026-04-14. Документ описывает наблюдаемое состояние систем классификации трафика по состоянию на момент публикации; ландшафт меняется быстро, и отдельные конкретные параметры (timeout-ы, scope блокировок, статус ECH у конкретных провайдеров) могут устареть.

Поведенческая классификация транспортов в современных DPI: что детектируется, почему и какие классы протоколов архитектурно устойчивее