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

Привет, Хабр! Меня зовут Максим, я инженер команды Нагрузочного тестирования в 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):

Генератор TRex:

Принцип: генератор не слабее 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. Что фиксируем на каждой точке

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

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

Результаты

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

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

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

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

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

Выводы

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

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

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

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