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

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

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

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

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

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

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

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

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

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

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

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

Подготовка PCAP

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

Записывайте обмен между понятными клиентской и серверной сторонами.
Оставьте в файле только нужный сценарий или минимальный набор сессий.
Убедитесь, что в выбранных сессиях есть полезная нагрузка в обоих направлениях: клиент -> сервер и сервер -> клиент.
Используйте IPv4 TCP/UDP-сессии с корректными портами.
Сохраняйте файл в классическом формате PCAP, а не PCAPNG.
Для запуска 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 до загрузки в библиотеку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как формируется нагрузка

В динамическом приложении пользователь, сессия и соединение - это разные сущности. Один пользователь моделирует одну независимую копию прикладного сценария, но сам сценарий может содержать несколько TCP- и UDP-сессий. Поэтому один пользователь не равен одному соединению.

Например, если приложение содержит пять выбранных сессий и для него назначено 100 пользователей, расчетный профиль содержит 500 сессий. В зависимости от последовательности и таймингов исходного сценария часть из них может выполняться одновременно, а часть - последовательно. Фактическое число одновременно активных соединений нужно смотреть по метрике Active Sessions на дашборде Applications.

Табл. 185 – Основные показатели нагрузочного профиля

Показатель	Что означает	Как использовать
Пользователи	Количество независимых копий выбранных прикладных сценариев	Определяет масштаб пользовательской активности, но не равно количеству соединений
Сессии сценария	TCP- и UDP-сессии, выбранные при создании приложения	Один пользователь может последовательно или одновременно проходить несколько сессий
Расчетное количество сессий	Сумма произведений «пользователи приложения × сессии в приложении»	Показывается при распределении нагрузки между приложениями и задает размер профиля
CPS	Скорость открытия новых сессий в секунду	Определяет, насколько быстро профиль выходит на рабочую нагрузку и как часто создается новое состояние соединений
Active Users	Количество пользователей, для которых уже была установлена хотя бы одна сессия	Показывает выход пользовательской нагрузки на заданный уровень
Active Sessions (CC)	Фактическое число соединений, одновременно активных в данный момент	Используйте для оценки реальной конкурентности соединений во время теста
Целевая скорость	Общая заданная скорость трафика для выбранной смеси приложений	Не описывает нагрузку полностью без пользователей, CPS, CC и состава приложений
Flows Completed	Количество сценарных потоков, завершивших ожидаемый обмен	Сопоставляйте с запущенными потоками и длительностью теста
Flows Failed	Количество потоков, которые не завершили ожидаемый обмен	Анализируйте по времени, стороне и причине ошибки; для безошибочного профиля значение должно оставаться нулевым

После выхода на установившийся режим количество одновременных соединений можно приблизительно оценить как CC ≈ CPS × среднее время жизни сессии. Для динамических приложений это только ориентир: результат также зависит от числа сессий внутри каждого приложения, их последовательности, исходных или масштабированных таймингов, ответов серверной стороны, таймаутов и повторного прохождения сценария. Источником фактического значения служит метрика Active Sessions.

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

Почему скорость растет плавно

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

Так первые несколько соединений не получают всю полосу задачи, а проверяемая система не испытывает искусственный стартовый всплеск. Равенство CC = CPS также не означает скачок в момент запуска: CPS — скорость открытия сессий в секунду, а CC — число одновременно активных соединений. Номинально такой профиль может набраться примерно за одну секунду, но TCP handshake, готовность прикладных сессий, тайминги сценария и ответы сервера могут увеличить время выхода на целевую скорость.

Одинаковая скорость не означает одинаковую нагрузку

Два теста с целевой скоростью 10 Gbps могут давать принципиально разную нагрузку на проверяемую систему. При слишком малом CC на каждое соединение приходится большая доля общей скорости, и выбранный сценарий или тракт могут не позволить достичь цели. Большое число коротких соединений при высоком CPS, напротив, дополнительно нагружает создание и удаление состояний, распределение потоков, очереди обработки и прикладной анализ. Между этими режимами может находиться рабочий диапазон, в котором заданная скорость достигается без ошибок.

Поэтому результат по пропускной способности следует указывать вместе с составом приложений, числом пользователей, CPS, фактическим CC и реально достигнутой скоростью. Формулировка «10 Gbps, 200 CC» описывает другой профиль, чем «10 Gbps, 1600 CC», даже если средняя скорость совпадает. Это позволяет воспроизводимо находить рабочую область системы не только по скорости, но и по количеству одновременно обрабатываемых соединений.

Как оценивать результат

В начале теста система переходит от нулевой нагрузки к заданным значениям числа пользователей, CPS, CC и скорости. Этот переходный период может отличаться от установившегося режима: ошибки могут появиться только во время быстрого роста нагрузки, продолжаться после выхода на целевой профиль или полностью отсутствовать. Для корректного анализа:

сравнивайте тесты с одинаковыми приложениями, пользователями, CPS, скоростью, длительностью и режимом таймингов;
рассматривайте отдельно период выхода на нагрузку и установившийся интервал;
проверяйте графики фактической скорости, Active Users, Active Sessions, Flows Completed и Flows Failed;
не считайте последующую стабилизацию отменой ошибок, возникших в начале теста;
анализируйте клиентскую и серверную стороны раздельно: связанные симптомы одного нарушенного обмена могут быть зарегистрированы на обеих сторонах;
при поиске границы изменяйте один параметр за прогон, например CPS или пользователей, сохраняя остальные условия неизменными.

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

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

Для динамических приложений «Один проход» означает, что пользовательские сессии проходят сценарий один раз и завершаются. При включенном «Следовать таймингам» сохраняются задержки из исходного 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​

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

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

Как формируется нагрузка​

Как оценивать результат​

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

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