В новом отчете лаборатории «Инфосистемы Джет» полезнее всего не паспортные гигабиты, а то, как устройства ведут себя при росте базы правил. Именно здесь чаще всего ломается красивая презентация вендора. На стенде коробка может выглядеть бодро на 200 правилах, а потом почти рассыпаться на 2 000, 5 000 или 10 000 правилах.
Главный вывод простой. Считать нужно не только EMIX Throughput, но и CC, CPS, PPS, то есть параллельные соединения, новые соединения в секунду и пакеты в секунду. В отчете Jet как раз хорошо видно, что проблема бывает не в одном «просевшем гигабите», а в системной деградации всей плоскости обработки трафика. Для корпоративной сети такой сценарий обычно больнее, чем просто скромная пиковая производительность.
На сайте указано, что последний апдейт опубликован 25 марта 2026 года. В проекте заявлены 264 теста, 9 нагрузочных кейсов и 12 решений. Нагрузочные замеры делали на EMIX-профиле, собранном по реальному трафику корпоративной сети «Инфосистемы Джет», а пределом считали ситуацию, где потери пакетов или сессий превышают 1%.
Где начинается настоящая проблема
Самый показательный пример в карточке UserGate. На 200 правилах МЭ UserGate NGFW 7.4.1 показывает 8,57 Гбит/с EMIX. На 10 000 правилах остается 0,787 Гбит/с. Падение составляет около 90,8%.
Провал идет не только по полосе. CC падает с 10,3 до 0,914 тыс., CPS с 8,28 до 0,715 тыс./с, PPS с 1,25 до 0,114 млн/с. То есть при росте числа правил устройство теряет не одну красивую маркетинговую цифру, а почти всю рабочую форму сразу.
На этом фоне особенно жестко смотрится PT NGFW 1.7.2 на платформе 2010. В открытой витрине Jet у PT линия почти плоская: 23,73 Гбит/с на 200 правилах и 23,7 Гбит/с на 10 000 правилах. Спор здесь уже не про нюансы округления, а про архитектурную устойчивость к росту политики.
Нюанс обязателен. Абсолютные цифры между разными устройствами нельзя читать как честный бой «лоб в лоб» без поправки на платформы, методики и набор включенных модулей. В отчете смешаны разные версии методик, а железо у части решений заметно разное. Но зависимость внутри одного устройства от роста числа правил все равно очень ценна. Если одна и та же платформа обваливается по мере усложнения политики, от этого факта уже не уйти.
Сравнительная таблица по открытому отчету
| Устройство | Платформа | EMIX при 200 правилах, Гбит/с | EMIX при 10 000 правилах, Гбит/с | Падение | Что бросается в глаза |
|---|---|---|---|---|---|
| UserGate NGFW 7.4.1 | F8010 | 8,57 | 0,787 | −90,8% | Обвальная деградация. Одновременно проседают EMIX, CC, CPS и PPS. |
| PT NGFW 1.7.2 | 2010 | 23,73 | 23,7 | −0,1% | Почти линейное поведение без заметного обвала на росте числа правил. |
| С-Терра Экран-М | x86, 128 CPU, 512 GB RAM | 23,53 | 23,34 | −1,2% | Кривая стабильная, но платформа явно не похожа на обычную серийную коробку. |
| Континент 4.1.9 | IPC-3000F40 | 7,75 | 5,54 | −31,1% | Деградация заметная, но не катастрофическая. |
| Check Point R81.20 | 7000 Plus | 8,5 | 5,54 | −34,8% | Просадка существенная, но без ухода почти в ноль. |
| InfoWatch ARMA Стена | не указана | 6,2 | 4,18 | −32,6% | Средняя деградация без экстремального провала. |
| ViPNet Coordinator HW5 5.3 | HW5000 | 1,22 | 0,70 | −42,6% | Низкая база и дальнейшее заметное ухудшение под ростом правил. |
| Решение китайского производителя 8.0 | 7000 series | 2,50 | 0,68 | −72,8% | Очень сильная чувствительность к усложнению политики. |
| Ideco NGFW v18 | EX | 4,2 | 0 | −100% | На 10 000 правил в открытой витрине стоят нули, отдельно упомянута длительная компиляция правил. |
Если смотреть не только на строку «10 000 правил МЭ», картина для UserGate остается такой же жесткой. На 200 правилах МЭ и 20 NAT правилах устройство показывает 8,46 Гбит/с, а на 10 000 правилах МЭ и 1 000 NAT правилах остается 0,78 Гбит/с. То есть NAT почти не меняет общую драму, потому что основная деградация начинается раньше, на самом росте числа правил.
Есть и еще один неприятный штрих. В комментарии к нагрузочному тесту UserGate прямо сказано, что для повышения производительности активировали оптимизацию fw_established и отключили детализацию диагностики, а без этих изменений пропускная способность фиксировалась примерно на уровне вдвое ниже опубликованных значений. Для закупщика или архитектора такая сноска важнее десятка рекламных слайдов. Сноска показывает, насколько итог зависит от специальных послаблений в конфигурации.
Почему поле Fail Close / Fail Open нельзя читать отдельно
В отчете отдельно вынесено поведение устройства при высокой нагрузке, то есть Fail Close / Fail Open. Поле полезное, потому что помогает понять, будет ли коробка в критическом режиме жестко резать трафик или попытается пропускать часть потока. Но наличие такого переключателя еще не делает устройство устойчивым. Если на росте числа правил уже разваливаются CC, CPS и PPS, один только режим аварийного поведения архитектурную проблему не лечит.
Главная мысль из нового отчета простая. NGFW нужно оценивать не по максимальной цифре на пустой политике, а по тому, как устройство держит сложную реальную базу правил. Иначе после запуска в промышленную сеть можно получить не защиту, а дорогую точку деградации.
Практический вывод
Новый отчет Jet полезен не потому, что в нем много таблиц, а потому что он показывает реальную болезненную точку рынка. Падение производительности при добавлении правил бывает не плавным, а обвальным. Для части решений база политики выглядит как вторичный параметр, а для части решений именно база правил становится главным ограничением.
Если читать таблицу без маркетингового тумана, вывод такой: при выборе NGFW нельзя смотреть только на «гигабиты из брошюры». Нужно смотреть, сколько правил устройство переживает без резкого сжатия EMIX, CC, CPS и PPS. Иначе первая же взрослая политика с NAT, IPS, фильтрацией и контролем приложений быстро объяснит, что проблема была не в канале, а в самой архитектуре продукта.
Что спрашивать у вендора до закупки?
Просите не одну красивую цифру, а полную кривую на 200, 2 000, 5 000 и 10 000 правилах. Сразу требуйте EMIX, CC, CPS и PPS, список включенных модулей, профиль трафика, сведения о NAT, параметры SSL Inspection и App Control, а также точное условие, при котором тест считается упершимся в предел. Отдельно спрашивайте, нужны ли специальные оптимизации ради публикации красивого результата, отключалась ли диагностика и как долго применяются большие политики на реальном устройстве.
Какую версию тестировали: релизную, сертифицированную или бета-версию?
Этот вопрос обязателен. В одной витрине могут соседствовать и релизные версии, и промежуточные сборки. Например, у UserGate отдельно фигурируют UserGate NGFW 7.4.1 и UserGate 7.1.0 RC. Для закупки важно фиксировать не просто название продукта, а точную версию, статус сборки, сертификационный статус и дату, когда именно получены цифры. Иначе сравнение превращается в спор между разными состояниями одного и того же продукта.
Почему одной цифры EMIX недостаточно?
Потому что полоса пропускания может выглядеть терпимо даже там, где уже рушатся новые и параллельные соединения. Для живой корпоративной сети просадка по CC и CPS часто опаснее, чем умеренное падение по Гбит/с. Если устройство теряет способность держать таблицу соединений и быстро открывать новые сессии, пользователи замечают деградацию раньше, чем канал упирается в потолок.
Можно ли честно сравнивать продукты из отчета друг с другом?
Только с оговорками. Платформы, версии методики, наборы модулей и даже класс железа местами различаются слишком сильно. Поэтому абсолютный рейтинг надо читать осторожно. Но поведение каждого отдельного устройства внутри своей линейки тестов остается очень показательной вещью. Если решение резко сыпется при росте числа правил, проблема уже не в способе подачи таблицы.
Какие условия теста сильнее всего меняют результат?
Больше всего на цифры влияют профиль трафика, включенные модули безопасности, ширина правил, NAT, SSL Inspection, App Control, IPS и режимы оптимизации. Иногда на результат заметно влияет даже диагностика и глубина журналирования. Поэтому у вендора нужно спрашивать не только итоговое значение, но и полный контекст, в котором значение получено.
Почему важно смотреть не только на 200 и 10 000 правил, но и на промежуточные точки?
Потому что деградация редко выглядит как аккуратная прямая. У одних решений просадка начинается уже на 2 000 правилах, у других кривая ломается ближе к 5 000. Промежуточные точки показывают форму падения и помогают понять, есть ли у устройства запас на рост политики в ближайшие год-два.
Что еще стоит проверить кроме самих нагрузочных цифр?
Проверьте публикацию и компиляцию большой политики, поведение при обновлении правил без простоя, работу под стрессом в течение длительного времени, долю потерянных пакетов, аварийное поведение Fail Close / Fail Open и зависимость результата от отключения тех или иных функций. Бывает так, что коробка красиво держит короткий замер, но начинает неприятно вести себя в длинном рабочем режиме.
