Привет, Хабр! Меня зовут Максим, я инженер команды Нагрузочного тестирования в Ideco. Вместе с командой мы развиваем Ideco NGFW Novum и регулярно гоняем его под синтетической нагрузкой - и для проверки регрессии по производительности, и чтобы честно отвечать на вопрос заказчика «а сколько он у вас держит».

У производительности NGFW есть неудобное свойство: один и тот же межсетевой экран на двух разных стендах легко показывает разные числа - и оба теста при этом честные. Причина в том, что производительность - не константа, «зашитая в железо», и сильно зависит от методики. Один тестировщик меряет «голый» форвардинг, другой - HTTP на крупных объектах; один требует ноль потерь, другой допускает процент; один снимает пиковые цифры, другой держит нагрузку несколько минут; на одном стенде стоит свежая сборка, на другом - версия постарше. Поменяйте один параметр - и результат меняется в разы. Сравнивать цифры имеет смысл только тогда, когда выложены обе методики.

Поэтому мы в этой статье говорим о том, как всё устроено у нас: как собран стенд, почему генератор - TRex в режиме ASTF, что именно мы считаем «потерей» и какой у нас критерий успешности по дропам, как бинарным поиском находим максимум и зачем удерживаем каждую точку 300 секунд. Цель - чтобы наши измерения мог воспроизвести любой и точно понять, что стоит за каждой цифрой. В конце отдельно разберём, почему два честных стенда легко получают разные числа - это не «у кого-то ошибка», а сумма методических решений.

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

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

Что вообще меряют у NGFW и почему числа несравнимы

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

  • Throughput (пропускная способность) - сколько Гбит/с устройство пропускает на уже установленных соединениях. Зависит от размера пакета/объекта: на мелких пакетах упираемся в обработку заголовков (PPS), на крупных - в копирование/инспекцию полезной нагрузки.

  • CPS (Connections Per Second) - сколько новых соединений в секунду NGFW успевает обработать. Это установка сессии, поиск правила, запись в таблицу состояний, логирование. Часто именно CPS, а не Гбит/с, первым упирается в потолок.

  • CC (Concurrent Connections) - сколько одновременных сессий помещается в таблицу состояний. Упираемся в память и в скорость её обхода. Один активный пользователь держит десятки–сотни соединений (вкладки, мессенджеры, фоновые синхронизации, стримы). CC определяет, сколько пользователей/устройств работают одновременно, не вытесняя друг друга.

  • Latency / jitter - задержка, которую вносит устройство.

Ключевая мысль, которую мы хотим донести читателю: число без методики бессмысленно. «100 Гбит/с» без указания размера объекта, набора включённых функций, числа правил/сигнатур, длительности теста и допустимого процента потерь - это не результат, а “воздух“. Дальше - наша методика, при которой результат становится воспроизводимым.

Почему TRex и почему ASTF

Генератор - это половина результата. Среди прочих генераторов трафика, один из основных для себя мы выбрали TRex - открытый генератор трафика от Cisco на базе DPDK.

Почему именно он:

  • Воспроизводимость и доступность. Open-source: методику и конфиги можно опубликовать, и любой повторит измерения без лицензии на «железный» генератор за десятки тысяч долларов. Для аппаратных Spirent/Keysight это невозможно.

  • Производительность. На DPDK TRex выдаёт десятки–сотни Гбит/с и миллионы CPS с одного сервера - достаточно, чтобы нагрузить наш DUT с запасом (генератор не должен быть узким местом).

  • Два режима под две задачи. STL (stateless) - для «пакетной» нагрузки и классики RFC 2544. ASTF (Advanced Stateful) - для эмуляции реальных L4–L7 сессий.

Почему ASTF, а не stateless. NGFW - устройство stateful: оно отслеживает соединения, держит таблицу состояний, разбирает L7. Гонять по нему поток несвязанных пакетов (STL) - значит мерить не то, чем устройство занимается в бою. ASTF поднимает настоящие TCP-сессии с эмуляцией прикладного протокола (HTTP), даёт осмысленные CPS и CC и заставляет работать те самые движки - IPS, DPI, контент-фильтр, - ради которых NGFW и покупают. Единственное исключение - тест «сырой» пропускной способности на крупных UDP-кадрах (1518 байт): там L7 не нужен, это потолок пакетной обработки.

Про ограничение TRex - и почему здесь оно не мешает. TRex ASTF эмулирует L7 по шаблонам и не выполняет настоящее TLS-рукопожатие. Но в описанных ниже тестах расшифровка трафика на NGFW отключена, поэтому ограничение не влияет на результат: устройство само не разбирает TLS - значит, и от генератора настоящий TLS не требуется. Мы корректно снимаем нагрузку на машину состояний, IPS, DPI и контент-фильтр на том трафике, который NGFW реально обрабатывает без расшифровки.

Сценарии с включённой расшифровкой - отдельная история и отдельный инструмент: там, где нужен полноценный TLS, мы используем аппаратный генератор Keysight BreakingPoint (IXIA) с другим профилем трафика. Эти результаты - тема отдельной статьи.

Стенд

Схема стенда: TRex (порт 0) - DUT: Ideco EX - TRex (порт 1).

Device Under Test (DUT):

Параметр

Значение

Продукт / версия

Ideco NGFW v21

Платформа (ПАК)

Ideco EX (старшая модель линейки)

CPU

Xeon(R) Gold 6338N

RAM

128Gb

Сетевые карты

Intel E810, 2xQSFP28 (100Gbps)

Генератор TRex:

Параметр

Значение

Версия TRex

v3.06

CPU

Xeon(R) Gold 6338N

RAM

128Gb

Сетевые карты

Intel E810, 2xQSFP28 (100Gbps)

ОС

Fedora 42 server

Режим

ASTF

Принцип: генератор не слабее DUT, чтобы упирались мы в межсетевой экран, а не в TRex. Перед серией прогонов делаем калибровку - гоним профиль «в обход» DUT (loopback), убеждаемся, что генератор выдаёт целевой CPS/throughput без потерь на самом TRex.

Методика

Ориентир - RFC 9411

Четыре принятых решения: профиль трафика, критерий потерь (не более 1% по session drops), и длительность удержания точки (300 с).

Чтобы сразу снять вопрос «а почему вы меряете именно так», обозначим опору. Методику мы строим по RFC 9411 - Benchmarking Methodology for Network Security Device Performance (стандарт IETF, обновляет RFC 3511; за ним стоит сообщество NetSecOPEN). Это профильный норматив именно для NGFW, и его главная цель - результаты, сопоставимые между разными вендорами и лабораториями, за счёт реализма, повторяемости и прозрачности.

Из RFC 9411 мы берём:

  • трафик приложений вместо «голых» пакетов - меряем, как устройство обрабатывает реальные сессии (отсюда TRex ASTF, а не stateless);

  • набор метрик - пропускная способность, CPS, одновременные соединения (CC);

  • стандартные размеры объектов в HTTP-тестах (у нас - 16 KB и 64 KB);

  • установившийся режим и повторяемость - отсюда удержание точки и фиксированный критерий;

  • допустимый порог неуспешных транзакций как часть критерия, а не абсолютный ноль - у нас это 1%.

Где мы делаем явный выбор - проговариваем его: открытый генератор TRex (вместо аппаратного), конкретный порог 1%, длительность точки 300 с, расшифровка в этих тестах выключена. Именно совпадение этих параметров и делает два результата сравнимыми; их расхождение - и есть причина, по которой «одно и то же устройство» показывает у разных тестировщиков разные числа.

1. Профили трафика

Методика опирается не на один профиль, а на набор, который характеризует устройство в разных измерениях - от «сырой» пропускной способности до обработки реального смешанного трафика с включёнными движками. Профили:

  • UDP, кадры 1518 байт, двунаправленно - верхняя граница «сырой» пропускной способности: крупные кадры, минимум накладных расходов на сессии. Потолок L2/L3-обработки. В реальной сети это трафик перекачки больших объёмов информации: бэкапы, репликация, файловые хранилища, видео.

  • TCP/HTTP, объект 64 KB и TCP/HTTP, объект 16 KB - пропускная способность на реальных HTTP-транзакциях. Чем меньше объект, тем выше доля установления соединений и тем ниже Гбит/с при той же полосе - поэтому 16 KB заведомо «тяжелее» 64 KB. В разрезе реальной сети это обычный веб и API: браузинг, порталы, обмен с облаками. Ближе к повседневному трафику.

  • EMIX - смесь протоколов в пропорциях, характерных для корпоративного трафика. Самый показательный тест: на нём мы и нагружаем движки NGFW. В TRex это составной ASTF-профиль из нескольких pcap с весами - поэтому состав фиксируем явно.

  • TCP CPS - чистая установка/разрыв TCP-сессий: скорость работы машины состояний (новые сессии в секунду).

  • TCP CC - наращиваем число одновременных TCP-сессий и удерживаем: ёмкость таблицы состояний conntrack (упор в память).

Общие параметры (одинаковы во всех прогонах ради сопоставимости): настройки tcp-stack, число правил firewall, число сигнатур IPS, состав EMIX, профили контроля приложений и контент-фильтра. Во всех тестах расшифровка на NGFW выключена.

Состав профиля EMIX

Сразу оговорюсь, что EMIX профилей у нас арсенал и это один из профилей для тестирования в режиме "без TLS расшифровки".

2. Что считаем «потерей» и почему порог - 1%

В stateful-тесте «потеря» - это не потерянный пакет, а сброшенный поток. Долю потерь считаем по счётчикам TRex ASTF дословно:

loss% = (udps_keepdrops + tcps_drops + tcps_conndrops) / open_flows × 100%

где:

  • tcps_conndrops - TCP-соединения, сброшенные на стадии установки (не дошли до established);

  • tcps_drops - уже установленные TCP-соединения, которые были сброшены;

  • udps_keepdrops - UDP-потоки, сброшенные по таймауту/keepalive;

  • open_flows - всего открытых потоков (знаменатель).

Формула это и есть условие воспроизводимости: точку считаем «пройденной», если loss% ≤ 1.

Почему 1%, а не 0. Строгий RFC 9411 допускает 0,001% дропов по соединениям, более старый стандарт RFC 2544 определяет throughput как максимальную скорость с нулевыми потерями, . На практике это слишком хрупкий критерий для долгого stateful-теста: один микробёрст или единичный таймаут роняет весь тест, и результат начинает «шуметь» от прогона к прогону. Поэтому мы используем подход когда находим максимальную нагрузку, при которой потери не превышают заданного порога. Порог 1% - осмысленный компромисс: он отсекает деградацию, но устойчив к статистическому шуму.

3. Бинарный поиск максимума

Линейный перебор нагрузки от нуля до потолка с шагом - это долго и неточно. Мы ищем максимум бинарным поиском по искомой величине теста - целевому CPS, числу одновременных сессий или множителю нагрузки ASTF; остальные метрики (throughput, CC, latency) фиксируем как производные на найденном максимуме.

Бинарный поиск даёт точный результат за обычно 8-12 прогонов вместо десятков.

4. Фаза удержания - 300 секунд

Каждую точку поиска мы удерживаем под нагрузкой 300 секунд (5 минут). Короткий прогон проходит за 10–30 секунд выглядит красиво, но проблемы вылезают только на выдержке нагрузки:

  • переполнение очередей и таблицы состояний по мере накопления сессий;

  • паузы на сборку мусора / периодические housekeeping-задачи;

  • рост задержки и микропотери, которых не видно на коротком окне;

  • тепловой троттлинг.

Структура одной итерации:

  1. Ramp-up (30 с) - плавный выход на целевую нагрузку, чтобы не было «холодного» всплеска.

  2. Измерительное окно 300 с - установившаяся нагрузка; статистику для критерия 1% считаем только по этому окну.

  3. Ramp-down - даём сессий завершиться корректно.

5. Что фиксируем на каждой точке

Метрика

Источник

Достигнутый CPS

TRex ASTF

Throughput, Гбит/с (RX/TX)

TRex / счётчики DUT

Одновременные сессии (CC)

TRex active_flows

Потери, % (по формуле выше)

TRex (tcps_drops, tcps_conndrops, udps_keepdrops)

Latency

TRex latency stream

Утилизация CPU DUT

Ideco

Память / заполнение таблицы сессий

Ideco

Тесты из маркетинговых материалов

Тесты на пропускную способность и сессии гоняем на «голом» firewall - они характеризуют сам межсетевой экран. EMIX дополнительно прогоняем с последовательным включением движков, чтобы показать «цену» инспекции. Во всех тестах TREX расшифровка трафика на NGFW отключена; сценарии с расшифровкой вынесены в отдельную методику.

Метрика

Профиль

ед. измерения

Модули DUT

Throughput

UDP, 1518 байт

макс. Гбит/с

FW

Throughput

TCP/HTTP, 64 KB

макс. Гбит/с

FW

Throughput

TCP/HTTP, 16 KB

макс. Гбит/с

FW

Throughput

EMIX (смешанный)

макс. Гбит/с

FW
FW + IPS
NGFW (FW + IPS + CF + DPI)

CPS

TCP, без L7

макс. новых сессий/с

FW

CC

TCP, удержание

макс. одновременных сессий

FW

Результаты

Пропускная способность, межсетевой экран (FW):

Тест

Примечание

Пропускная способность

UDP 1518B, двунаправленно

крупные кадры, L2/L3-потолок

200 Гбит/с

TCP / HTTP, объект 64 KB

реальные HTTP-транзакции

100 Гбит/с

TCP / HTTP, объект 16 KB

мельче объект - тяжелее

62 Гбит/с

EMIX

смешанный корпоративный трафик

92 Гбит/с

Здесь сразу видно главное свойство, о котором мы говорили: число зависит от профиля. На крупных UDP-кадрах - 200 Гбит/с, на HTTP с объектом 16 KB - уже 62. Это не «разные устройства», это разная нагрузка на одном и том же FW.

EMIX по уровням инспекции - «влияние» каждого движка:

Модули

Пропускная способность

Firewall

92 Гбит/с

Firewall + IPS

31 Гбит/с

NGFW (FW + IPS + контроль приложений + контент-фильтрация)

15,5 Гбит/с

Включение IPS срезает пропускную способность примерно втрое (с 92 до 31), полный набор движков - ещё вдвое (с 31 до 15,5). Это ожидаемо: каждый уровень инспекции разбирает содержимое, и это не бесплатно. Здесь же проявляется и чувствительность к составу трафика: на отдельных наборах протоколов движок инспекции расходует память быстрее и раньше выходит на насыщение - поэтому так важно фиксировать профиль и держать точку 300 секунд, а не снимать пик.

Сессии, межсетевой экран (FW):

Метрика

Значение

Новых сессий в секунду (TCP CPS)

800 000

Одновременных соединений (TCP CC)

21 000 000

Выводы

  1. Методика важнее одной цифры: фиксированные профиль, критерий 1% потерь, бинарный поиск и удержание 300 с - с опорой на RFC 9411 - делают результат воспроизводимым и сравнимым между релизами и лабораториями.

  2. ASTF на TRex даёт честную stateful-нагрузку и доступен любому.

  3. Цена инспекции NGFW измерима: в нашем случае на EMIX включение IPS снижает пропускную способность с 92 до 31 Гбит/с, полный набор движков - до 15,5 Гбит/с.

Будем рады обсуждению в комментариях: какие профили и критерии используете вы?