ROC‑AUC 1,000 против 0,500: Как я совместил мультиплексирование и HTTP-2-профиль трафика

В нашем тестовом стенде p95 latency снизилась с 579 до 108 мс, а Random Forest на выбранных признаках показал ROC‑AUC 0,500. Рассказываю об архитектуре, методике и ограничениях результата.

В статье разбираю архитектуру ghostmux, проверки устойчивости и исправления, подготовленные для REALITY

Небольшая оговорка о результатах ML‑ классификации: ROC‑AIC = 0,500 означает что, конкретная модель на конкретных признаках не показала качества выше случайного угадывания. Это не доказывает универсальную неразличимость трафика для любых моделей и методов анализа.

Название: reality‑mux‑http2- это TCP‑ транспорт, где Reality отвечает за слой TLS 1.3, а сам mux выполняет роль мультиплексирования потоков, а размеры пакетов маскируются под профиль HTTp/2.

Коротко о результатах:

Метрика Vision reality‑mux‑http2

p95 latency +-0.579 +-0,108

запросов в секунду относительно Vision baseline +27%

ROC‑AUC Random Forest 1,000 0,500

Когда я проводил измерения производительности, то использовал тестовый распределительный стенд с RTT 100 мс. Для ML‑эксперимента я обучил Random Forest глубиной 3 на признака распределения размеров пактов, включая max‑len и count.

Основная проблема: быстрый транспорт может быть слишком предсказуемым

Мультиплексирование позволяет передавать несколько логических потоков поверх одного соединения. Это уменьшает расходы на установления соединений и позволяет эффективнее использовать уже открытый транспорт. Но производительность‑ это не единственное свойство сетевого протокола, которое стоит измерять.
Если мультиплексор Регулярно создает один и тот же набор размеров кадров и пакетов, этот профиль может стать статистически устойчивым. Классификатору не обязательно понимать содержимое передачи: для разделения потоков иногда достаточно таких наблюдаемых характеристик как вроде: максимального размера payload и числа пакетов.

В моем эксперименте появился именно такой компромисс:
Vision открывал новое соединение для каждого запроса. Это увеличивало стоимость обмена: повторные этапы установления соединения заметно влияли на хвостовую задержку.
mux.cool ^[1] использовал мультиплексирование и показывал высокую производительность, однако выбранный нами классификатор разделял его трафик по признакам размера пакетов с высокой точностью
Задача моего проекта reality‑mux‑http2 состояла в том, чтобы сохранить преимущества мультиплексирования и при этом изменить наблюдаемый профиль размеров payload.

Архитектура reality‑mux‑http2 
В архитектуре reality‑mux‑http2 транспорт и мультиплексирование разделены на слои:

Логические потоки
│

ghostmux

│

Reality / TLS 1.3

│

Сетевой путь

Reality и TLS 1.3 обеспечивает транспортный слой, а ghostmux распределяет данные потоков и отвечает за формирование кадров. Такое разделение позволяет независимо проверять обработку соединений, корректность мультиплексирования и поведение ^[2] размеров payload.
Я ориентировался на максимум 16 384 байта для payload. Это значение соответствует начальному значению Sttings_max_size в HTTP/2. Но ghostmux не является реализацией http2: он не воспроизводит все правила этого протокола, поведение ^[3] браузера или форматирование заголовков. В этой работе под http2- профилем понимается сходство в распределении размеров payload.

Логические потоки
│

ghostmux

│

Reality / TLS 1.3

│

Сетевой путь

Как я проверил ML‑классификацию
Для эксперимента я использовал Random Forest с ограничением глубины дерева depth=3. В качестве признаков брали параметры распределения размеров пакетов, в том числе:
max_len — максимальную наблюдаемую длину payload;
count — количество элементов в анализируемой выборке.

Качество оценивалось метрикой ROC‑AUC. Для бинарной классификации значение 0,5 соответствует уровню угадывания, а значение 1,0 означает идеальное разделение тестовых образцов.
На выбранных признаках результаты получились следующими:

Трафик ROC‑AUC
Vision 1,000 
reality‑mux‑http2 0,500

Для Vision классификатор получил идеальное разделение классов. Для reality‑mux‑http2 те же выбранные признаки не дали модели качества выше случайного угадывания.

Мои результаты для reality‑mux‑http2 нужно трактовать строго в рамках эксперимента. ROC‑AUC зависит от используемых признаков, состава выборки, способа разделения данных и сложности модели. В частности, для надежной оценки обучающие и тестовые данные данные следует разделять по независимым соединениям или прогонам. Если образцы из одного соединения окажутся в обеих выборках, модель может получить избыточный сигнал.

Производительность: что дает повторное использование соединения
В сценариях с короткими запросами открытие нового соединения для каждого запроса может заметно влиять на задержку. Мультиплексирование позволяет передавать несколько логических потоков уже через установленное соединение и избегать повторения ^[4] этого процесса для каждого запроса.

• В тестовом стенде с RTT 100 мс reality_mux_http2:
  на 27% больше запросов в секунду по сравнению с Vision;
  p95 latency около 0,108 с против 0,579 с у Vision
  улучшение p99 latency в 2,8 раза;
  производительность на уровне mux.cool ^[1] в рассматриваемом сценарии.

p95 latency у reality‑mux‑http2 примерно в 5.4 ниже чем у Vision. Это сравнение касается именно p95, а не общей скорости протокола

Проверка корректности и устойчивости
Производительность имеет смысл только при корректной обработке потоков и соединений. Поэтому я проверял систему несколькими способами.

1. Data reces: На correctness gate E0 под нагрузкой зафиксировано 0 date reces.
2. Fuzzing: Парсеры кадров и обработчиков SOCKS5 прошли 2,66 млн исполнений без crashes. В таких тестах особенно важна обработка некорректного ввода:обрезанных заголовков, неверных длин и граничных значений.
3. Soak test: во время 45- минутного теста rss процесса вышел на стабильное плато, а утечек файловых дескрипторов не обнаружено.

Утечка CLOSE‑WAIT: от наблюдения к исправлению
В ходе тестирования под высокой сменяемостью соединений я обнаружил рост числа сокетов в состоянии CLOSE‑WAIT. Это состояние означает, что удаленная сторона закрыла соединение, а локальная сторона еще не завершила его обработку. Само по себе оно не всегда указывает на дефект, но устойчивый рост таких сокетов требует проверки.
Я сопоставил поведение соединений с путями закрытия потоков и нашел сценарий ожидания без ограниченного срока. исправление состояло в том, чтобы ограничить длительность операции при истечении срока. после этого я повторил нагрузочный тест и убедился в том. что сокеты не накапливаются при высокой сменяемости соединений.

Исправление в интеграции с REALITY
Для работы стека мне потребовалась собственная ветка интеграции с Reality. В ходе тестирования я подготовил три исправления:
1. Буфер для крупных сертификатов: В одном из сценариев размер сертификата составлял 8273 байта, тогда как буфер был ограничен 8192 байтами. Я увеличил его размер до 65 536 байт и добавил проверки граничных значений.
2.Явная ошибка ^[5] вместо аварийного завершения: При неверной длине camouflage‑данных прежний код мог завершится аварийно. Я заменил это поведение на явную ошибку ErrCamouflageLengthMusmatch, которую вызывающий код может обработать.
3.Совместимость hybrid key‑share ML‑KEM: Третья проблема проявлялась при handshake: стороны не могли согласовать используемый вариант hybrid key‑ share ML‑KEM. Исправление требует тестирования совместимых конфигураций и предсказуемой обработки неподдерживаемых параметров.

Сравнение с классической связкой VLESS+REALITY+VISION
Мой подход reality‑mux‑http2 кардинально отличаются от того, как устроен стандартный стек в Xray‑core. Традиционно там используется протокол VLESS, который отвечает за аутентификацию и передачу данных, поверх него работает REALITY(защита от активного зондирования), а режим Vision пытается защитить от пассивного анализу (fingerprinring).
Проблема классической связки в том, что VLESS и мультиплексирование (mux.cool) конфликтуют с Vision. Из‑за этого приходится выбирать либо безопасность (Vision), либо скорость (мультиплексирование).
В моем проекте я вынес мультиплексор ghostmux над слоем REALITY. Это позволило мне:
1. Сохранить скорость, которую дает мультиплексирование (p95 +-0.108 мс)
2 Обеспечить профиль размеров пакетов, неотличимый от HTTP/2 (ROC‑AUC 0,500), что делает мой продукт устойчивее к ML‑анализаторам, чем Vision.
Кратко говоря: я совместил скорость мультиплексирования со стойкостью REALITY и протоколом VLESS, но добавил поведенческую маскировку своего мультиплексора, работающего на уровне TCP.

Исходный код
Весь код, скрипты для ML‑анализа (Random Forest) выложены в открытый доступ на GitHub https://github.com/Hagalzz/reality‑mux‑http2  ^[6]