Ваш NGFW не выдерживает 5 минут нагрузки? Значит, вы не тестировали как надо

Представим, что у вас в распоряжении новый физический или виртуальный межсетевой экран. В маркетинговых материалах указаны впечатляющие показатели: «до 100 Гбит/с», «миллион соединений в секунду» и другие внушительные цифры. Стоит ли принимать их на веру? Разумеется, нет. Необходимо разместить устройство в лабораторных условиях и проверить соответствие заявленным характеристикам. Для этого существует бенчмаркинг — не единичная проверка доступности, а структурированное тестирование, где каждый показатель несёт конкретную информационную ценность.

Ниже — разбор методики RFC 9411. Расскажем, зачем нужны пять фаз трафика, какие метрики обязательны, какие опциональны, что делать с ними на практике и как потом объяснить результаты руководству. С примерами, рекомендациями и ответами на частые вопросы.

Откуда взялась «сценарная» нагрузка

Ранее межсетевые экраны проверяли подобно грузовому транспорту: просто подавали линейный поток пакетов и наблюдали за целостностью передачи. Современные устройства функционируют на уровнях гораздо выше IP: они анализируют TLS, выявляют вредоносное ПО, взаимодействуют с облачными системами анализа. Для корректной оценки их производительности необходим реалистичный, сценарный поток данных: эмуляция веб‑браузеров с контролируемой активностью, разнообразные размеры файлов, различное соотношение шифрованного трафика, иногда — моделирование взаимодействия с социальными сетями.

Именно поэтому в RFC 9411 определены пять чётких фаз. Они отражают динамику реального трафика, который имеет периоды активности и затишья, а не поступает постоянным непрерывным потоком.

Пять фаз, критически важных для полноценного тестирования

Init: подготовка сцены

Что происходит. Генератор и DUT обмениваются служебными пакетами (ARP, ND, LLDP), формируют таблицы MAC и инициализируют маршруты. Если вы используете эмуляцию браузеров, именно здесь каждому виртуальному клиенту назначается IP‑адрес, TCP‑порт и даже «User‑Agent».

Сколько ждать. Практика показывает: 5 – 10 с достаточно, чтобы проверки ARP‑кэша стабилизировались, особенно в виртуальных средах. В физическом оборудовании с медленными SFP+ модулями иногда требуется до 30 с — рекомендуется интерактивно контролировать счётчик link‑up.

Потенциальные проблемы. Если пропустить Init на кластерном межсетевом экране, возможна несинхронизация сессионных таблиц: первая половина ramp‑up будет обрабатываться через активный узел, вторая — через резервный, что приведет к потере пакетов.

Рекомендация. Активируйте в логах DUT фильтр «Learning state». Как только прекратится появление новых MAC-адресов — можно переходить к следующему этапу.

Ramp‑up: мягкий разгон

Задача — вывести поток на целевой уровень с линейным, ступенчатым или экспоненциальным ростом без резких скачков. Понятие «мягко» зависит от масштаба: для 10 Гбит/с достаточно 10 с, а для 400 Гбит/с — рекомендуется длительность 30 – 40 с, чтобы избежать переполнения очереди ASIC.

Почему не снимаем метрики. DUT в этот момент активно создаёт сессии, заполняет кеш DPI‑сигнатур, выполняет криптографические операции SHA‑256 для TLS. Показатели будут нестабильными, что может привести к ложноотрицательным результатам. График CPS при ramp‑up полезен только для отладки: убедитесь, что повышение нагрузки происходит равномерно.

Реальный пример. При тесте NGFW резкий скачок с 0 до 100 % за 2 с приводит к потере 0,3 % пакетов. После распределения нагрузки на период 15 с потери отсутствуют, sustain стабилен.

Sustain: ядро теста

Минимум 5 минут. Почему не меньше? Некоторые механизмы, такие как TCP slow‑start, циклы обновления CRL или автоматическая перегрузка IPS‑сигнатур, проявляются через 2 – 3 мин. Краткосрочный тест не зафиксирует эти явления.

Частота выборки. 1 с — оптимальный вариант; 2 с — допустимый максимум. Это позволяет наблюдать нестабильность сессионной таблицы и пиковые значения TTFB. Записывайте минимум, среднее и максимум: иногда именно единичный выброс до 500 мс критически влияет на пользовательский опыт.

Следите за steady‑state. Стабильный уровень Throughput ± 5 %, CPS ± 10 %, потерь < 0,001 %. Если наблюдается отклонение от этих параметров, это требует детального анализа. Например, постепенное увеличение TTLB может свидетельствовать о медленном исчерпании буферов.

Ramp‑down: контролируемое снижение

Как снижаем. Зеркально отражаем процесс ramp‑up, но в обратном направлении. Закрываем сессии FIN/ACK, а не RST. В противном случае DUT маркирует соединение как «abnormal», нарушает сбор статистики, а график приобретает нерегулярную структуру.

Зачем это нужно. Позволяет наблюдать, как устройство освобождает ресурсы. Если при 100 k FIN в секунду межсетевой экран демонстрирует нестабильность, то в реальных условиях при сбое канала клиентские подключения также будут завершаться некорректно — важно выявить эту проблему заранее.

Дополнительное преимущество. Некоторые NGFW переключаются в режим fail‑open при массовом потоке FIN. Ramp‑down позволяет оценить риск возникновения уязвимости в политике безопасности.

Collect: сбор результатов

Автоматическая агрегация. Большинство инструментов тестирования (BreakingPoint, TRex, IxLoad) поддерживают автоматическое формирование сводных отчётов. Однако рекомендуется сохранять данные в формате .csv — часто требуются специфические метрики (например, Вт/Гбит).

Чек‑лист отчёта:

• График throughput, CPS, TTFB — общая картина.
• Таблица KPI со средними и пиковыми значениями.
• Логи DUT: ошибки, например «IPS signature cache miss», «SSL proxy queue full».
• Конфигурация тестового стенда (версии FW, сигнатур, параметры шейпинга).

После сбора — переводим DUT в состояние покоя (3-5 мин без нагрузки) перед новой итерацией, чтобы предыдущие сессии были полностью закрыты, а кеши вернулись в исходное состояние.

Шесть обязательных метрик и почему они критически важны

Документ RFC 9411 определяет их как ключевые контрольные точки (benchmarks). Если хотя бы одна отсутствует в отчёте, анализ нельзя считать полноценным: это сравнимо с ситуацией, когда при медицинском обследовании измеряется температура, но игнорируются пульс и давление.

• Inspected Throughput (инспектированная пропускная способность) — реальный поток данных после всех фильтров.
  Как измерять. Оцениваем объём на входе и выходе «кабель‑кабель» (Layer 2).
  Для чего. Маркетинговые «100 Gbit/s» отражают чистую пересылку данных; нас интересует реальная производительность при включённых DPI, IPS, TLS‑дешифрации.
  Практика. 9,87 Gbit/s (9 525 007 kbit/s) на 10‑гигабитном линке — всего −2 % от теоретического максимума, что является превосходным результатом.
• Concurrent Connections (одновременные соединения) — количество сессий, которое DUT поддерживает в памяти в данный момент.
  Как измерять. Фиксируем значение счётчика state‑table каждую секунду.
  Зачем. При атаке память достигает предела раньше, чем снижается пропускная способность. График с постоянным значением свидетельствует о стабильности; колебания указывают на проблемы с тайм‑аутами или оперативной памятью.
• Connections per Second (соединений в секунду, CPS) — скорость установления новых TCP или QUIC соединений.
  Почему важно. При SYN‑флуде возможно критическое снижение производительности устройства без значительного увеличения общего объёма трафика. CPS демонстрирует устойчивость именно к такому сценарию.
• Application Transactions per Second (транзакций уровня 7 в секунду) — полностью завершённые запрос‑ответы HTTP(S), DNS и других протоколов.
  Зачем. Это метрика, отражающая успешное получение страницы пользователем. Высокий Throughput при низком TPS означает, что пакеты передаются, но ответы не достигают получателя.
• TLS Handshake Rate (рукопожатия TLS в секунду) — число успешных последовательностей ClientHello → Finished в единицу времени.
  Узкое место. Чаще всего ограничивающим фактором является не само шифрование, а создание proxy‑контекста и кеширование сессий.
• TTFB/TTLB (Time to First Byte / Time to Last Byte) — задержка до получения первого и последнего байта ответа.
  Диагностика. Увеличение TTFB свидетельствует о задержках на начальном этапе (TLS, прокси). Рост TTLB при стабильном TTFB указывает на перегрузку инспекторов контента.

Эти шесть показателей обеспечивают полное представление о работе устройства: пропускную способность (Inspected Throughput), устойчивость по числу одновременных сессий (Concurrent Connections), скорость установления новых соединений (Connections per Second), успешность транзакций прикладного уровня (Application Transactions per Second), эффективность обработки шифрованного трафика (TLS Handshake Rate) и задержки ответа пользователю (Time to First/Last Byte). Без любой из этих метрик итоговый тест‑отчёт будет неполным.

Практический пример №1

Допустим, тестируется межсетевой экран «Х». Моделируем нагрузку: 75 % HTTPS, 25 % HTTP. В фазе sustain наблюдаем:

• Inspected Throughput — 18,2 Гбит/с.
• Concurrent — около 1,3 млн.
• CPS — колеблется 38-40 тыс./c.
• TTFB — 17 мс (avg), TTLB — 52 мс (avg).

Увеличиваем процент HTTPS до 90 — Throughput снижается всего на 4 %, а CPS — сразу на 30 %. Следовательно, ограничивающим фактором является создание TLS‑прокси, а не пропускная способность. Решение: активировать аппаратный ускоритель или уменьшить глубину DPI.

Опциональные, но очень полезные метрики

• Процент зашифрованного трафика. Наглядно демонстрирует, как DUT функционирует при увеличении доли HTTPS.
• Потерянные пакеты на входе/выходе — помогает выявить проблемы с внутренними очередями.
• CPU / RAM самого устройства — если доступны счётчики, полезно сопоставлять задержки с пиками нагрузки.
• Энергоэффективность (Вт на Гбит) — параметр, всё чаще запрашиваемый центрами обработки данных и экологически ориентированными заказчиками.

Как правильно снимать данные и не исказить картину

Базовые правила

• Измерения проводим только в фазе sustain. Ramp‑up/down предназначены для плавного входа/выхода из нагрузки.
• Шаг выборки ≤ 2 с. Чем меньше интервал, тем точнее фиксируются кратковременные пики.
• TCP‑сессии завершаются FIN/ACK, не RST. RST нарушает достоверность статистики.
• Потери > 0,001 %? Тест классифицируется как нестабильный.

Рекомендации для лабораторий

• При использовании аппаратного тестера: проверяйте, не достигает ли он собственных предельных значений. Рекомендуется выполнить «эталонный тест» без DUT: запустить идентичный профиль трафика напрямую. Если тестер обеспечивает 22 Гбит/с, а вы планируете оценить межсетевой экран на 25 Гбит/с — корректное тестирование невозможно.

• Для виртуальных тестеров: убедитесь, что vSwitch не ограничивает пропускную способность пакетов. В некоторых случаях тест демонстрирует нестабильность из-за лимита vNIC в 10 Гбит/с.

Практический пример №2

Тестовая лаборатория в виртуальной среде. Hyper‑V + виртуальный генератор трафика. При достижении 15 Гбит/с наблюдаются потери пакетов. После переключения сетевого адаптера на SR‑IOV потери исчезают, throughput увеличивается до 19 Гбит/с. Вывод: необходимо анализировать не только DUT, но и инфраструктуру тестирования.

Интерпретация: анализируем графики как специалисты

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

• Ровная полка throughput (Inspected Throughput) и стабильная CPS (Connections per Second) — оптимальный сценарий: DUT эффективно справляется с нагрузкой, буферы функционируют без переполнения, сборка мусора происходит своевременно. Такой график обычно достигается после корректной настройки тайм‑аутов и при достаточном объёме оперативной памяти.
• Нестабильность CPS при равномерном throughput. Часто свидетельствует о том, что таблица состояний (state table) заполнена соединениями с продолжительным временем жизни: короткие соединения (например, браузерные WebP‑пиксели) закрываются мгновенно, а длительные сохраняются в памяти. Рекомендуется:
  • уменьшить TCP timeout для FIN_WAIT_2;
  • активировать aggressive ageing только для неактивных сессий;
  • проверить наличие асимметричной маршрутизации — иногда часть трафика проходит в обход кластера, что приводит к задержке сессий.
• Повышение TTFB (Time to First Byte) при стабильном TTLB (Time to Last Byte). Обычно указывает на увеличенные задержки при инициализации TLS‑рукопожатий — очередь к криптографическому процессору, истощение пула RSA‑контекстов или активный анализ сертификатов (TLS inspection). Первоочередные действия: активировать аппаратное ускорение (при наличии) и проверить пропускную способность PCIe‑шины на соединении «DUT – HSM».
• Рост TTLB при стабильном TTFB. Задержка возникает после начала передачи:
  • Серверная часть не справляется с нагрузкой — проверьте логи на наличие ошибок 503 или задержки в SQL‑запросах.
  • DUT выполняет глубокий анализ крупных вложений — проверьте, не активирован ли режим full file rewrite в прокси.
  • Включена компрессия (compression) на межсетевом экране — процессор выполняет сжатие GZIP, что задерживает отправку пакета.
• Стабилизация на графике Concurrent Connections (одновременные сессии) при продолжающемся росте CPS. Это означает, что устройство удаляет старые записи быстрее, чем создаёт новые. Потенциальная угроза: при реальной атаке легитимные клиентские соединения могут быть вытеснены из таблицы. Рекомендуется увеличить лимит state‑table или активировать syn‑proxy для фильтрации неполных сессий.
• Периодические снижения throughput с интервалом X секунд. Часто совпадает с циклом обновления CRL/OCSP или IPS‑сигнатур. В логах ищите «pattern update» — если время совпадает, настройте обновления на период минимальной нагрузки.

Что включать в отчёт

Качественный отчёт содержит не только численные данные, но и краткое аналитическое заключение, объясняющее причины наблюдаемых явлений. Рекомендуемый формат:

Сценарий: трафик 80 % HTTPS, 20 % HTTP, объект 64 KB.
Результат: Inspected Throughput достиг 18 Гбит/с, но CPS снизился на 30 % спустя 3 мин.
Причина: лимитирующим фактором стал TLS‑прокси: заполнение очереди на аппаратный криптомодуль достигало 85 % (ssl_proxy_queue_full в логе). TTFB увеличился до 250 мс, TTLB сохранил стабильность — инспекция контента не оказывает существенного влияния. После деактивации глубокого анализа (IPS + AV) CPS вернулся к исходному уровню, Throughput возрос до 19,6 Гбит/с.

Обязательные компоненты:

• Графические материалы (скриншоты или SVG-графики throughput/CPS/TTFB).
• Отдельный файл .csv с исходными данными (интервал ≤ 2 с) — необходим для дополнительных расчётов, например, средней пакетной нагрузки PPS или энергоэффективности в ваттах на гигабит.
• Версии программного обеспечения, набор активированных сигнатур, дата обновления CRL, тип криптографического ускорителя.

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

Ответы на частые вопросы

Зачем фиксировать TTLB, если TTFB уже есть?

TTFB показывает, как быстро сервер инициировал ответ, TTLB — сколько времени потребовалось для передачи всего объекта. Разница выявляет узкие места после инициализации: шифрование, компрессию, задержки дисковой подсистемы.

Можно ли исключить Ramp‑down и завершить тест немедленно?

Технически это возможно, но таблицы соединений в DUT могут остаться заполненными частично закрытыми сессиями, что приведёт к искажению результатов последующего теста. Непродолжительный период плавного снижения нагрузки (3-5 секунд) предотвращает эту проблему.

Как определить «оптимальные» размеры объектов?

RFC рекомендует 1, 16, 64, 256 КБ и комбинированные варианты. Практический совет: адаптируйте соотношение размеров к вашему реальному трафику (анализ логов фронтенд‑серверов будет полезен) — это приблизит результаты к реальным условиям эксплуатации.

Как проводить тестирование HTTP/3?

Методология аналогична, но необходимо фиксировать специфические метрики QUIC: quic_conns, quic_cwnd, quic_loss. Соединения завершаются механизмом «immediate close», а не FIN/ACK, что влияет на характер графика CPS.

Обязательно ли активировать все функции безопасности при тестировании?

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

Глоссарий

• DUT/SUT — устройство/система под тестом.
• Sustain — фаза стабильной нагрузки, где меряются KPI.
• TTFB / TTLB — время до первого / последнего байта данных.
• CPS — соединения в секунду.
• QUIC — транспортный протокол поверх UDP (HTTP/3).
• ALPN — расширение TLS для выбора протокола (h2, h3).
• DPI — глубокий анализ пакетов.
• Ramp‑up / Ramp‑down — плавное увеличение / снижение нагрузки.
• RFC 9411 — документ IETF, описывающий методику тестов NGFW/NGIPS.
• Inspected Throughput — инспектированная пропускная способность: фактический объём трафика после всех проверок на выходе из устройства.
• Concurrent Connections — одновременные соединения: общее количество активных сессий, хранящихся в таблице состояний DUT.
• Connections per Second (CPS) — соединения в секунду: скорость, с которой устройство устанавливает новые TCP или QUIC‑сеансы.
• Application Transactions per Second (TPS) — транзакции прикладного уровня в секунду: число завершённых HTTP(S)/DNS/SMTP запросов‑ответов без ошибок.
• TLS Handshake Rate — частота TLS‑рукопожатий: сколько успешных TLS‑handshake завершается каждую секунду.
• Time to First Byte (TTFB) — время до первого байта ответа после отправки запроса.
• Time to Last Byte (TTLB) — время до получения последнего байта ответа.
• Init — фаза инициализации: обмен ARP/ND, построение таблиц MAC, распределение IP‑адресов.
• Collect — сбор результатов: агрегация логов и экспорт исходных данных (.csv) после завершения теста.
• Бенчмаркинг — процесс тестирования производительности устройства через структурированные сценарии нагрузок, с использованием стандартизированных метрик.