Опубликовано: 08.08.2026 | Источник: SecurityLab (RSS)

```html

Анализ лимитов на интернет-трафик для ВКР: архитектура, метрики, обоснование

В марте 2026 года ФАС начала проверку законности введения провайдерами лимитов на проводной интернет для физических лиц. «Шведский стол» с безлимитным доступом медленно закрывается: операторы всё чаще переходят к тарифам с ограничениями для «тяжёлых» абонентов. Для студентов ИТ-направлений это не просто новость — это сигнал, что рынку нужны инженеры, понимающие, как проектировать системы управления трафиком, справедливые тарификации и методы контроля качества. Такой кейс отлично ложится в основу ВКР: он актуален, имеет открытые данные для анализа и требует реальных навыков проектирования.

Темы ВКР, которые можно построить на этом кейсе

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

Для каждой темы структура глав стандартна: Глава 1 — теория и анализ, Глава 2 — проектирование и архитектура, Глава 3 — тестирование, экономическое обоснование. Но чтобы работа была защищаемой, в главе 2 обязательно должны быть схемы, а в главе 3 — метрики и расчёты.

Аналитическая глава: сравниваем решения и обосновываем стек

Статья о лимитах — отличный повод сравнить существующие подходы к учёту трафика. В аналитической главе вашей ВКР можно рассмотреть:

• Аппаратные решения — специализированные устройства DPI (например, Cisco SCE, ТСПУ). Плюсы: производительность. Минусы: цена, сложность обновления.
• Программные решения — nDPI, OpenDPI, PF_RING. Плюсы: гибкость, низкий порог входа. Минусы: потребление CPU, возможные «тормоза» на высоких скоростях.
• Гибридные схемы — аппаратный акселератор + программный контроллер. Хороший выбор для дипломного проекта, так как позволяет обосновать и железо, и код.

Вот пример сравнительной таблицы, которую можно привести в дипломе:

На основе такой таблицы вы можете обосновать выбор программного DPI для прототипа, ссылаясь на ограниченный бюджет учебной работы и необходимость показывать алгоритмы в коде.

Проектная часть: схемы, алгоритмы и взаимодействие с биллингом

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

• диаграмму развёртывания (маршрутизатор, DPI-модуль, биллинг, сервер мониторинга);
• диаграмму последовательности для нескольких сценариев (обычное использование, достижение лимита, превышение лимита);
• алгоритм принятия решения о снижении скорости или блокировке.

Пример простого алгоритма на языке псевдокода:

if current_usage > threshold and speed_limited == false:
    set_speed_limit(new_speed)
    notify_billing("limit reached")
else if current_usage < threshold * 0.7:
    restore_full_speed()
    notify_billing("usage normal")
else:
    continue monitoring

Ориентируйтесь на современный стек: микросервисы, контейнеризация. Например, модуль DPI можно развернуть как отдельный микросервис, а для оркестрации использовать Kubernetes. Это добавит веса работе и покажет ваше владение инструментами.

Не забудьте про требования к оформлению архитектурной документации — ГОСТ 34.602-89 для технического задания и международный стандарт ISO/IEC 25010 для оценки качества программного обеспечения. Эти стандарты часто требуют в вузах, и их упоминание сильно упрощает защиту.

Тестирование и метрики: как доказать, что работа работает

В третьей главе нужно показать результаты. Для системы управления лимитами это:

• Нагрузочное тестирование — сколько пакетов в секунду обрабатывает DPI-модуль, как растёт задержка при увеличении числа абонентов.
• Метрики QoS (джиттер, задержка, потери пакетов) и QoE (например, MOS для видео).
• Скорость реакции системы — RTO (восстановление после сбоя) и RPO (максимальный период потери данных). Для биллинга это критично.
• Мониторинг — с помощью OpenTelemetry можно собирать трассировки запросов между DPI и биллингом, что позволит выявить узкие места.

В таблице ниже — пример метрик, которые стоит вынести в приложение к диплому:

Такая таблица доказывает, что вы не просто сделали «код», а провели полноценное исследование.

Чему вы научитесь

Работа с данным кейсом даёт практические навыки, которые можно перечислить в резюме:

• проектирование архитектуры сетевых сервисов (от монолита к микросервисам);
• использование DPI и NetFlow для учёта трафика;
• работа с OpenTelemetry и настройка мониторинга;
• оформление ТЗ по ГОСТ 34.602 и оценка качества по ISO/IEC 25010;
• нагрузочное тестирование с помощью генераторов трафика.

Частые ошибки студентов

FAQ по реализации ВКР

Насколько сложно реализовать систему с DPI в дипломе?

Если вы программируете не с нуля, а используете открытую библиотеку nDPI — вполне реально. Основная сложность — обработка высоких скоростей. В учебном проекте достаточно эмуляции сети с помощью mininet или virtualbox. Главное — показать работающий алгоритм, а не промышленное решение.

Обязательно ли писать код, если тема исследовательская?

Да, в большинстве случаев код обязателен. Даже для исследовательской работы нужен прототип или симуляция. Но можно написать скрипты на Python для анализа метрик, а не полноценный сервис. Это тоже считается реализацией.

Как оформлять UML-диаграммы и схемы?

Используйте PlantUML или Draw.io. Сохраняйте в PNG и добавляйте в приложение. Следите, чтобы все элементы на схеме были подписаны. Для диаграмм архитектуры также подходит C4 model.

Где брать тестовые данные для проверки?

Сгенерируйте синтетический трафик с помощью scikit-learn для создания случайных паттернов использования. Реальные данные оператора, разумеется, не дадут из соображений privacy. Но вы можете использовать открытые датасеты из университетских проектов.

Чек-лист перед сдачей

Резюме

Новость о проверке ФАС легковесных тарифов — не просто инфоповод. Это отличный фундамент для ВКР: тема решает реальную отраслевую проблему, содержит и исследовательскую, и инженерную часть. Вы сможете показать знания в области сетевых технологий, умение проектировать системы и проводить тесты.

Источник: Шведский стол закрывается. Провайдеры больше не хотят кормить «тяжелых» абонентов бесплатно (опубликовано 2026-03-17)

```