{{indexmenu_n>1}} ====== Поиск ухудшения качества доступа к интернет ====== [[dpi:dpi_options:opt_statistics:statistics_ipfix|DPI выгружает информацию о всех сессиях клиентов в формате IPFIX (NetFlow v10)]]. Самая простая и изученная метрика DPI по проверке качества связи - [[https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D1%83%D0%B3%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0|RTT]]. DPI позволяет измерить RTT и поделить его по направлениям (к абоненту и от абонента) и уточнить по протоколам и устройствам при необходимости. Большая задержка в течение продолжительного времени "от абонента" скорее всего говорит о том, что абонент испытывает сложности с доступом к онлайновым сервисам — играм, видео, коммуникации. Как правило, задержка возникает из-за WiFi-сети абонента, но может говорить и о перегрузке узлов сети. Действия: - Перейти в раздел QoE Аналитика → Абоненты → Нетфлоу\\ {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_1.png?nolink&400|}} - Создать фильтр, где: * предлагается ограничить поиск по протоколу http/https, чтобы отсеять возможные особенности других протоколов при установке TCP соединения * указать среднюю скорость, чтобы делать выборку из абонентов, активно пользующихся интернет * указать нижний порог RTT от клиента {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_3.png?nolink&700|}} Рекомендуется работать с абонентами из выгрузки, у которых среднее (а еще лучше медианное) RTT больше 100 за 24 часа. Для этого можно: - Выгружать данные ежедневно в свою базу данных через API или напрямую из Click House QoE, уже в ней накладывать фильтры. - Сделать триггер в графическом интерфейсе с заданными параметрами. При обработке важно учесть следующие факторы: - Стоит проверить географическое распределение "проблемной" выгрузки. "Кучность" как правило появляется из-за перегрузок сети или старого коммутатора, проблему можно устранить на стороне оператора. Бывает, что "плохой" район подключен по устаревшей технологии (DSL или радиодоступ), тогда плохой RTT уже "не баг, а фича". - Абонент может не испытывать дискомфорт из-за задержки (и прямо говорит об этом если его спросить по телефону), например в случаях: * работают устройства IoT, может быть слабый сигнал у них * работает на устаревшем оборудовании и не ждет чудес * не пользуется онлайновыми сервисами - Проблемы в Wi-Fi сети могут возникать по причинам: * зашумленный Wi-Fi диапазон 2.4 в многоквартирном доме * слабый роутер * сложная топология или большие размеры квартиры/дома - Иногда невозможно определить хост, куда обращался абонент с высоким RTT\\ {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_4.png?nolink&1100|}}\\ Такое может быть по трем причинам: * обращение по IP * не http протокол * не указан SNI - В дополнение к RTT можно использовать метрику % ретрансмитов при поиске проблемных абонентов. Если продолжительное время (>30 минут) наблюдается существенное превышение фонового значения по ретрансмитам (обычно 4-5%), это признак деградации услуги у абонента. Использовать ретрансмиты без RTT не рекомендуется, велика вероятность ложного срабатывания. {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_5.png?nolink&1100|}} Пример запроса в базу:\\ {{ :dpi:qoe_analytics:cases:queries_from_database:subs_bad_rtt_sample.sh |Скачать скрипт}} Параметры в скрипте:\\ ''format="CSV"'' - формат вывода. По умолчанию CSV. Возможные форматы: https://clickhouse.com/docs/en/interfaces/formats/\\ ''periodSecs=24*3600'' - период в секундах. По умолчанию 24 часа\\ ''rttMore=100'' - значение RTT. По умолчанию 100