Содержание

This is an old revision of the document!

Точка входа для LLM при анализе выгрузок неопознанного трафика (application protocol вида quic_unknown). Здесь описан метод классификации IP-узлов CDN по их роли в инфраструктуре провайдера сервисов. Наборы признаков (сеты хостов) по провайдерам — в пространстве имён :services.

Задача — классифицировать трафик QUIC или HTTPS с 0-RTT, в котором отсутствует SNI (поле host пустое).
На вход — выгрузки из внутренней системы QoE: агрегированный netflow (top hosts) и сырой netflow (raw flow).
Цель — определить роль конкретного узла IP:443 в инфраструктуре CDN и присвоить метку сервиса (например youtube, google_play).

Работа поверх DPI: есть риск, что протокол уровня приложений распознан неверно. Особенно осторожно — с протоколами малого объёма: при недостатке данных ложные срабатывания чаще.
В нераспознанный трафик часто попадают 0-RTT пакеты. Анализируй окружение неизвестного протокола, а не отдельный флоу.
Оценивай вероятность наличия того или иного трафика на AS. Возможно, что под сервис маскируется другой тип трафика (в т.ч. через SNI). Если AS принадлежит крупной компании (например Meta) — ожидаемо увидеть трафик её сервисов.
Проверяй однотипные выгрузки из нескольких временных диапазонов — это даёт стабильный набор признаков.

Метод строит «землю» (ground truth) из флоу, где SNI виден, и применяет её к тому же IP там, где SNI отсутствует.

Из агрегированного netflow получить top host IP by traffic за период с фильтром application protocol = “quic_unknown …”, сортировка по суммарному объёму в обе стороны. Это IP-кандидаты на классификацию.

По каждому IP-кандидату выгрузить сырой netflow, где поле host (SNI) не пустое. Это выборка: какие SNI реально жили на этом IP.

Схема raw flow (важно):

Host IP — канонический IP сервера, по нему группируем.
Host — SNI/hostname, это и есть признак.
Серверный порт двунаправленного флоу выводится из направления: если Host IP == Source IPv4, то серверный порт = Source port, иначе = Destination port. Порт 443 попадает то в источник, то в назначение — прямой фильтр по Destination port = 443 отрежет половину трафика.

Для каждого IP посчитать долю записей, чей host попадает по маске в набор сервиса. Если доля превышает порог сервиса — присвоить метку узлу IP:443.

Знаменатель — все записи с непустым host на данном IP.
Доля — записи, чей host совпал с любой маской набора, к знаменателю (по числу записей, не по объёму и не по уникальным FQDN).
Семантика * — fnmatch: звёздочка = любая подстрока, включая точки. *storage.googleapis.com ловит и storage.googleapis.com, и firebasestorage.googleapis.com, и bucket.storage.googleapis.com.
Регистр — матчинг регистронезависимый.
Порог — у каждого сервиса свой (см. страницы в :services). Если порог берут несколько сервисов на одном IP — метка по максимальной доле.

Мультитенантность. Принадлежность IP netblock'у провайдера ≠ сервис. Пример: 35.241.31.20 — адрес Google Cloud (35.x), но по «земле» на 100% отдаёт h3.market.xiaomi.com (магазин Xiaomi поверх GCP). Метку google_cloud ставить нельзя — ни одна googleapis-маска не совпадает, и это правильный результат. Классифицируй по SNI-«земле», а не по владельцу адреса.
Общие фронты (GFE). На общих фронтах Google один IP отдаёт play + maps + cloud + прочее, и ни одна доля не дотягивает до порога — IP остаётся без метки. Это ожидаемо; не занижай порог, чтобы «дотянуть».
Объём vs число записей. Доля считается по числу записей. Несколько тяжёлых видеосессий доминируют по объёму, но по числу host'ов картина обратная — не путай метрики.
IPv6 и anycast. Среди кандидатов бывают IPv6 и anycast-адреса; «земля» протухает при ротации. Согласуй период шага 1 и шага 2.

Наборы масок по провайдерам — в :services:

google — youtube, google_play, google_maps, google_cloud, google_cdn
facebook / meta
tiktok
apple

Автоматизированные инструменты для рутинных выгрузок (top hosts, raw flow по IP).
Discovery новых сетов и источников такого типа трафика — пополнение страниц в :services.

При выгрузке из QoE ограничивать размер через limit; запрещено превышать limit = 1000.
При выгрузке RAW netflow не выставлять большие временные диапазоны (несколько минут), это сильно нагружает систему.