Динамические приложения

Динамическое приложение - это воспроизводимый прикладной сценарий, созданный из PCAP-файла. Он используется, когда нужно не просто отправить записанные пакеты, а превратить реальный обмен клиента и сервера в управляемую нагрузку: выбрать нужные сессии, сохранить логику обмена, менять пользовательские значения и запускать один и тот же сценарий с разным числом пользователей, скоростью и параметрами.

В отличие от PCAP Replay, динамическое приложение работает как L7-сценарий. Система анализирует запись, выделяет TCP/UDP-сессии, определяет клиентскую сторону, сохраняет выбранные шаги обмена и позволяет параметризовать прикладные данные: логины, токены, идентификаторы, URL, номера заказов, cookies и другие значения, которые должны отличаться между пользователями или запусками.

Рис. 13 — Библиотека динамических приложений

Используйте динамические приложения, если нужно:

• воспроизвести пользовательский сценарий из реального трафика;
• проверить устройство на реалистичной L7-нагрузке, а не на синтетическом HTTP или простом потоке пакетов;
• запускать один и тот же сценарий с разным количеством пользователей и CPS;
• менять значения внутри запросов или ответов без повторной записи PCAP;
• проверить обработку stateful-сессий через устройство между двумя агентами Пересвет-СТ.

Если нужно без изменений отправить весь файл захвата или отдельные сессии, обычно достаточно PCAP Replay. Если нужно управлять прикладными значениями и масштабировать пользовательский сценарий, используйте динамическое приложение.

Общая схема работы

Создание и использование динамического приложения проходит в два этапа:

1. Подготовка приложения в библиотеке. Пользователь загружает PCAP, выбирает клиентскую сторону, выбирает сессии, задает параметры и сохраняет приложение.
2. Использование приложения в задаче. Пользователь добавляет плагин «Динамические приложения», выбирает одно или несколько приложений из библиотеки и задает нагрузочные параметры: пользователей, CPS, скорость, таймаут, режим прохождения и значения параметров.

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

Подготовка PCAP

Качество исходного PCAP определяет, получится ли стабильное динамическое приложение. Перед загрузкой подготовьте запись:

1. Записывайте обмен между понятными клиентской и серверной сторонами.
2. Оставьте в файле только нужный сценарий или минимальный набор сессий.
3. Убедитесь, что в выбранных сессиях есть полезная нагрузка в обоих направлениях: клиент -> сервер и сервер -> клиент.
4. Используйте IPv4 TCP/UDP-сессии с корректными портами.
5. Сохраняйте файл в классическом формате PCAP, а не PCAPNG.
6. Для запуска Dynamic Applications используйте Ethernet PCAP (linktype=1, DLT_EN10MB).

Важное ограничение linktype

PCAP с Raw IP (linktype=101, DLT_RAW) может распознаться на этапе просмотра сессий в библиотеке, но не поддерживается при запуске плагина «Динамические приложения». Такой сценарий будет отклонен до старта задачи с ошибкой про неподдерживаемый linktype 101.

Для динамических приложений используйте PCAP с Ethernet-заголовками (linktype=1). Если исходная запись сделана без L2-заголовка, переснимите трафик в точке, где доступен Ethernet-уровень, или подготовьте корректный Ethernet PCAP до загрузки в библиотеку.

Шаги создания приложения

Мастер создания динамического приложения состоит из следующих шагов:

1. Загрузка PCAP - выбор файла, название, описание и теги приложения.
2. Выбор клиента - выбор IP-адреса стороны, которая инициирует соединения.
3. Сессии - просмотр найденных TCP/UDP-сессий и назначение понятных имен.
4. Параметризация - выделение изменяемых участков в hex-представлении или поиск по тексту, hex или regex.
5. Обзор и сохранение - проверка сессий и параметров.
6. Значения по умолчанию - пользователи, скорость, таймаут и поведение параметров.
7. Сохранение - публикация приложения в библиотеке.

На шаге выбора клиента укажите IP-адрес стороны, которая начинает пользовательское действие. От этого выбора зависит направление сессий: клиентская часть будет воспроизводить запросы, а серверная часть будет отвечать по сохраненному сценарию. Если выбрать сервер как клиента, сценарий может стартовать с неверного направления или не найти ожидаемые сессии.

На шаге сессий выберите только те TCP/UDP-сессии, которые относятся к нужному пользовательскому действию. Не выбирайте фоновые соединения, служебную телеметрию, DNS-запросы или лишние keep-alive обмены, если они не нужны для проверки.

Требование к выбранным сессиям

Выбранная сессия должна содержать полезную нагрузку в обе стороны. Если в PCAP есть только запрос без ответа или только ответ без запроса, приложение не считается пригодным для stateful-воспроизведения.

Параметры нужны, чтобы менять значения внутри прикладного обмена без изменения PCAP. Например, можно выделить логин пользователя, номер заказа, идентификатор устройства, токен авторизации, путь URL, значение cookie или поле JSON/XML. Параметр можно выделить в представлении пакета или найти поиском по строке, hex или регулярному выражению.

Используйте понятные имена параметров. В задаче оператор будет видеть именно их, поэтому username, order_id или csrf_token лучше, чем param1.

Перед сохранением проверьте правильный клиентский IP, список выбранных сессий, направление обмена, наличие параметров, имена параметров, описание и теги. На этом этапе лучше удалить лишние сессии и переименовать параметры, чем потом искать причину некорректной нагрузки в задаче.

Если приложение не сохраняется, проверьте ошибки валидации. Чаще всего они связаны с неверным клиентским IP, пустым списком сессий, некорректными IPv4-метаданными или отсутствием payload в одном из направлений.

Использование в задаче

Чтобы запустить приложение:

1. Создайте задачу.
2. Добавьте клиентский и серверный плагин Динамические приложения или используйте готовый шаблон.
3. Выберите агенты, интерфейсы, источники и цели.
4. Выберите одно или несколько приложений из библиотеки.
5. Настройте пользователей, CPS, скорость, таймаут и режим прохождения.
6. Укажите значения параметров, если приложение их содержит.
7. Запустите задачу и контролируйте метрики на дашборде Applications.

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

Табл. 185 – Параметры динамического приложения при запуске задачи

Название	Описание	Значение
Приложения	Одно или несколько приложений из библиотеки	Выберите приложения в модальном окне
Режим прохождения	Повторять сценарий или выполнить один проход	«Один проход» запускает пользовательские сессии один раз; циклический режим повторяет сценарий до остановки задачи
Режим распределения	Как делить нагрузку между приложениями	Вес или процент
Количество пользователей	Общее число параллельных пользователей	Распределяется между выбранными приложениями
CPS	Скорость старта пользовательских сессий	Задайте общее значение для сценария
Таймаут	Максимальное ожидание ответа	По умолчанию 30 секунд
Режим скорости	Оригинальные тайминги или ручная скорость	Выберите режим в зависимости от цели теста
Целевая скорость	Общая скорость трафика	Указывается в bps, Kbps, Mbps или Gbps
Следовать таймингам	Сохранение задержек из оригинального PCAP	Включено для режимов, где важна реальная динамика
Замена портов	Замена L4 source/destination port	Используйте для переноса сценария на другой стенд
Параметры клиента/сервера	Значения, выделенные при создании приложения	Могут быть статическими, списком, случайными, инкрементальными или извлекаемыми из ответа

Ограничение режима «Один проход» с таймингами

Для динамических приложений «Один проход» означает, что пользовательские сессии проходят сценарий один раз и завершаются. При включенном «Следовать таймингам» сохраняются задержки из исходного PCAP, но максимальное окно одного прохода составляет 86400 секунд (24 часа). Если исходная запись содержит более поздние пакеты или длинные паузы за пределами этого окна, эти пакеты не попадут в захваченный трафик (PCAP) агентов; для таких сценариев сократите запись, отключите следование таймингам или используйте циклический режим.

Табл. 186 – Источники значений параметров динамического приложения

Источник	Описание	Пример применения
Статическое	Одно значение для всех сессий	Один логин, домен или токен
Список	Значения используются по кругу	Набор пользователей или URL
Случайное	Случайное целое число в диапазоне	Номер заказа, идентификатор клиента
Инкремент	Префикс + начальное значение + шаг	user_1, user_2, user_3
Извлечение	Значение берется из ответа сервера и подставляется в следующие запросы	Session ID, CSRF token, cookie

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

Ограничения и частые причины ошибок

Формат PCAP

• Поддерживается классический PCAP. PCAPNG нужно предварительно сохранить как PCAP.
• Для запуска Dynamic Applications требуется Ethernet linktype=1.
• Raw IP linktype=101 не поддерживается при запуске Dynamic Applications.
• Для выбранных сессий ожидаются IPv4 TCP/UDP-метаданные.

Сессии и payload

• Нужно выбрать хотя бы одну сессию.
• Каждая выбранная сессия должна существовать в PCAP для выбранного клиентского IP.
• В каждой выбранной сессии должен быть payload в направлении клиент -> сервер и сервер -> клиент.
• Однонаправленные сессии, пустые ответы и служебные TCP-соединения без прикладных данных не подходят.

Направление клиента

• Клиентский IP должен соответствовать стороне, которая начинает пользовательское действие.
• Если клиент выбран неверно, система может не найти сессии или воспроизвести обмен в неправильном направлении.
• Для двухагентного сценария клиентский и серверный плагины должны использовать согласованные сети и интерфейсы.

Скорость и длительность

• В режиме оригинальных таймингов сохраняются задержки из записи. Длинные паузы в PCAP переносятся в сценарий.
• В режиме ручной скорости платформа масштабирует запуск пользователей и сессий по указанным значениям.
• В режиме «Один проход» пользовательские сессии выполняются один раз и завершаются.
• Для длительных записей с большими паузами лучше сократить PCAP или использовать циклический режим.

Параметры

• Не меняйте байты, которые ломают формат протокола, длину поля или контрольную структуру приложения, если это не поддержано сценарием.
• Проверяйте, что параметр встречается именно в нужном шаге, а не в похожем фрагменте другого пакета.
• Для токенов и cookies, которые выдаются сервером, используйте извлечение из ответа вместо статического значения.

Рекомендации

• Делайте PCAP коротким и предметным: один пользовательский сценарий лучше, чем длинная запись с фоновым трафиком.
• Сначала сохраните и запустите приложение без параметров, чтобы проверить базовое воспроизведение.
• Добавляйте параметры постепенно и проверяйте сценарий после каждого важного изменения.
• Используйте понятные имена сессий и параметров: они попадут в задачу и помогут анализировать ошибки.
• Для диагностики включайте захват трафика (PCAP) на агентах и сравнивайте фактический обмен с исходным PCAP.
• Если задача не стартует из-за ошибки валидации, исправляйте приложение или PCAP, а не пытайтесь запускать частично пригодные сессии.

Перед запуском задачи убедитесь, что приложение сохранено в библиотеке без ошибок, PCAP имеет Ethernet linktype=1, выбран правильный клиентский IP, выбранные сессии содержат payload в обе стороны, значения параметров заданы для всех обязательных полей, агенты онлайн и синхронизированы, а клиентские и серверные сети соответствуют выбранному стенду.