Когда вендор показывает слайд с красивой цифрой «40 Гбит/с», почти всегда где-то внизу мелким шрифтом притаилось заветное «UDP 1518». Маркетологи обожают этот тест — он выдаёт максимальные числа, хорошо смотрится в сравнительных таблицах и при этом практически ничего не говорит о том, как устройство поведёт себя в живой корпоративной сети. Разберёмся, что за зверь этот RFC 2544, откуда в нём взялись 1518 байт и почему эта цифра — лишь отправная точка, но никак не финальный ответ.
Откуда вообще взялись эти 1518 байт
1518 байт — максимальный размер классического Ethernet-кадра: 1500 байт полезной нагрузки плюс 14 байт заголовка и 4 байта контрольной суммы. Всё, что крупнее, стандарт не пропустит без специальных договорённостей. Когда появился VLAN-тег (802.1Q), кадр вырос до 1522 байт, и часть оборудования при наивном подходе к стенду начинала удивительным образом «ломаться» именно на этой разнице в четыре байта. Поэтому корректный отчёт о тестировании всегда уточняет — гоняли трафик с тегами или без.
Зачем вообще выбрали максимальный кадр? Всё просто: чем больше полезных данных в одном пакете, тем меньше накладных расходов на заголовки в пересчёте на бит. Устройство принимает меньше решений на единицу переданной информации, реже лезет в таблицы, меньше работает с очередями. Это выгодно для красивой цифры в паспорте, но совсем не типично для реальной корпоративной сети — там рядом с крупными файловыми передачами живут сотни мелких DNS-запросов, коротких HTTPS-транзакций и фоновая телеметрия, которая сыплет пакетами постоянно.
Что тест реально измеряет — и что намеренно упускает
Классический прогон по RFC 2544 устроен незатейливо: на устройство подаётся поток UDP-кадров фиксированного размера, нагрузка постепенно растёт до первых потерь. Фиксируется «пропускная способность без потерь», задержка и процент потерянных кадров (frame loss). Методология создавалась для интерконнект-оборудования — маршрутизаторов и коммутаторов, где главная задача действительно «перекладывать биты как можно быстрее».
Для межсетевого экрана нового поколения (NGFW — Next-Generation Firewall) такой тест полезен примерно как проверка скорости печати у хирурга: формально что-то измерили, но к настоящей работе это имеет слабое отношение. UDP не требует установления соединения, не ждёт подтверждений, не порождает состояний в таблицах сессий. Именно эти состояния и составляют основную нагрузку на NGFW в реальной жизни — вместе с разбором приложений, инспекцией зашифрованного трафика и сравнением с базами сигнатур угроз.
Получается парадоксальная ситуация. UDP 1518 показывает, сколько железо пересылает при минимальной логике поверх пересылки. Но NGFW покупают именно за эту логику. Чем активнее задействованы функции защиты, тем дальше реальная производительность от паспортной цифры. Иногда разрыв достигает пяти и более раз — и это не баг, это просто цена глубокой инспекции трафика.
Три ловушки, в которые попадают при чтении тестов
Первая и самая распространённая — подмена «гигабит» на «быстро». При кадрах в 1518 байт устройство показывает высокий битрейт при относительно скромном количестве пакетов в секунду (PPS — packets per second). Как только трафик становится мелкозернистым — много DNS, TCP ACK, коротких HTTPS-сессий — картина меняется кардинально. Один и тот же NGFW при одинаковом битрейте, но с разными профилями пакетов может нагрузить процессор совершенно по-разному.
Вторая ловушка — отключённые функции безопасности. В описании сценария часто значится «базовый режим», а в сноске уточняется, что инспекцию TLS, систему предотвращения вторжений (IPS) и антивирусный модуль не включали. Но именно за них и платят деньги. Актуальная методология RFC 9411 от 2023 года прямо оговаривает: конфигурация, оптимальная для скорости, и конфигурация, оптимальная для безопасности, — это разные конфигурации. Сравнивать устройства нужно в сопоставимых режимах, иначе получается соревнование «кто сильнее выключит проверки».
Здесь стоит оговориться отдельно: включить «всё и сразу» — тоже не рецепт реализма. Грамотный сетевой архитектор настраивает разные профили для разных сегментов: строгая инспекция для периметра, облегчённая — для внутреннего трафика низкого риска. Именно такая средневзвешенная политика отражает реальную нагрузку на процессор при смешанном режиме работы. Тест в режиме «всё выключено» или «всё включено» описывает лишь два края диапазона, но не то, что происходит между ними каждый рабочий день.
Третья ловушка — однонаправленный и идеально ровный трафик. Реальная сеть работает в обе стороны, и нагрузка часто асимметрична: много входящего инспектируемого контента, меньше исходящего. Но дело не только в асимметрии объёмов. Многие архитектуры NGFW делят общую системную шину или пул памяти между входящим и исходящим потоками. Когда стенд гоняет UDP в одном направлении и заявляет 40 Гбит/с, при симметричной двусторонней нагрузке (Full Duplex) реальная пропускная способность может упасть не вдвое, а значительно сильнее — из-за конфликтов при обращении к разделяемой памяти. Этот эффект почти никогда не отражается в паспорте, хотя именно он определяет поведение устройства в боевых условиях. Плюс в жизни трафик никогда не бывает равномерным — всегда есть всплески, паузы, параллельные сессии. Стенд с симметричным UDP-потоком этого не воспроизводит, и некоторые устройства ведут себя принципиально иначе при смене профиля нагрузки.
Почему цифра «40 Гбит/с» может превратиться в «4 Гбит/с» после покупки
Включение инспекции TLS — пожалуй, самый драматичный тест-кейс для любого NGFW. Современный корпоративный трафик зашифрован примерно на 80–90%, и устройство должно его расшифровать, проверить содержимое, а затем зашифровать обратно. Операция вычислительно дорогая, и железо без специализированных аппаратных ускорителей теряет здесь от 60 до 80% паспортной производительности.
При этом важно понимать, о какой версии протокола идёт речь. Переход на TLS 1.3 с обязательным использованием совершенной прямой секретности (PFS — Perfect Forward Secrecy) создал качественно иную нагрузку на процессор по сравнению с TLS 1.2. Асимметричная криптография теперь задействуется при каждом рукопожатии без возможности кешировать сессионный ключ — и устройства без аппаратных ускорителей для этого типа операций теряют в производительности заметно сильнее, чем при инспекции старого протокола. Если вендор не уточняет, на какой именно версии TLS проводились замеры, — это повод задать вопрос напрямую.
Добавьте включённую базу сигнатур IPS — и цифра падает ещё. Типичная картина из реальных тестов выглядит так: вендор заявляет 100 Гбит/с в режиме «базовый файрвол», 25 Гбит/с с включённым IPS и 8 Гбит/с при полной инспекции TLS с одновременно работающим IPS. Все три цифры честные. Просто они описывают три разных режима работы. Задача покупателя — выяснить, какой из них соответствует его реальному сценарию развёртывания.
Что пришло на смену RFC 2544 в мире NGFW
Индустрия не сидела сложа руки. В 2023 году под эгидой консорциума NetSecOPEN был опубликован RFC 9411 — первая полноценная методология тестирования производительности именно для устройств класса NGFW и систем предотвращения вторжений нового поколения (NGIPS). Документ заменил устаревший RFC 3511 и впервые описал, как правильно строить тестовый стенд, какие профили трафика использовать и как оформлять результаты, чтобы их можно было воспроизвести и сравнить между лабораториями.
| Параметр | RFC 2544 (Классика) | RFC 9411 (Стандарт NGFW) |
|---|---|---|
| Уровень инспекции | L2–L3 (сетевой уровень) | L4–L7 (уровень приложений) |
| Тип трафика | Синтетические UDP-кадры | Реалистичный микс (IMIX, HTTPS, DNS) |
| Состояния сессий | Не учитывают (Stateless) | Глубокий учет таблиц (Stateful) |
| Функции защиты | Обычно выключены | Включены (IPS, TLS, AppID) |
| Ключевые метрики | Битовая скорость (Гбит/с), PPS | Транзакции в секунду, задержка приложений |
| Шифрование | Не проверяют | Обязательная инспекция TLS (SSL) |
Ключевое отличие от классики — акцент на Layer 7 и реальные нагрузки. NetSecOPEN разработал профили трафика, включающие около тысячи уникальных доменных имён (FQDN), CDN-запросы, субприложения и трекеры. По словам участников консорциума, реальные корпоративные сети обрабатывают тысячи типов приложений и уровней привилегий одновременно, поэтому тест должен это воспроизводить, а не имитировать однородный поток.
Кроме того, RFC 9411 требует, чтобы отчёт о тестировании обязательно перечислял все включённые функции безопасности. Если что-то отключено — нужно объяснить почему. Это простое требование отсекает значительную часть маркетинговых манипуляций: сложно писать «производительность 100 Гбит/с», когда в методологии чётко прописано, что надо указать «при отключённой инспекции TLS, IPS и антивирусе».
Тестирование по RFC 9411 уже проводят две аккредитованные независимые лаборатории — EANTC в Берлине и UNH-IOL в США. Тестовые инструменты Keysight BreakingPoint и Spirent CyberFlood поддерживают полный набор сценариев. Первые отчёты с сертификацией NetSecOPEN уже доступны публично — в частности, для Cisco Secure Firewall 1220CX, где зафиксированы конкретные показатели по TCP/HTTPS соединениям, задержкам и транзакциям в секунду при включённой инспекции.
Как использовать UDP 1518, не выбрасывая его совсем
Тест не плохой — он просто узкоспециализированный. UDP 1518 хорошо показывает верхнюю границу плоскости данных (dataplane) и качество реализации обработки крупных кадров. Это полезная «нулевая точка» для сравнения аппаратных платформ одного класса. Проблема не в самом тесте, а в привычке выдавать его результат за финальный вердикт о производительности.
Разумный минимум для осмысленного сравнения NGFW выглядит так. Во-первых, прогон по нескольким размерам кадров — хотя бы 64, 512, 1024 и 1518 байт. Это покажет, где именно устройство упирается: в количество пакетов в секунду или в ширину канала. Во-вторых, смешанный трафик, где есть TCP и HTTPS, а не один «удобный» протокол. Здесь часто используют смешанный профиль пакетов под общим названием IMIX (Internet Mix) — но и это понятие требует уточнения. Под «IMIX» в разных тестах могут скрываться разные распределения: «простой» вариант, профиль Cisco, профиль Juniper и другие, с принципиально разными пропорциями мелких и крупных пакетов. Без указания конкретного распределения весов (например, соотношения 7:4:1 для пакетов 64, 512 и 1518 байт) цифра IMIX остаётся почти такой же маркетинговой, как и UDP 1518 в одиночку. В-третьих, измерения с теми функциями, которые вы реально планируете держать включёнными в эксплуатации. Включили IPS и TLS-инспекцию в политику — тестируйте именно с ними.
Задержка: средняя ничего не говорит о худшем случае
Отдельного разговора заслуживает то, как в тестах обычно подаётся задержка. Чаще всего публикуют среднее значение — и оно звучит вполне прилично, скажем, 100–200 микросекунд. Но для ряда приложений принципиально важна не средняя задержка, а так называемая хвостовая (tail latency): что происходит с самыми медленными пакетами — теми, что попали в 99-й или 99,9-й процентиль распределения.
При обработке крупных кадров 1518 байт буферы устройства заполняются равномерно, и среднее действительно остаётся низким. Но в реальном смешанном трафике мелкие пакеты нередко «застревают» за крупными в очереди. Это порождает кратковременные микрозадержки (джиттер, jitter), которые в общем отчёте остаются невидимыми, зато отлично ощущаются на видеосвязи, IP-телефонии или терминальных сессиях. Поэтому профессиональный отчёт о тестировании должен содержать не только среднее значение задержки, но и графики её распределения — иначе картина намеренно или случайно остаётся неполной.
Сценарии, которые реально отвечают на вопрос «как будет в сети»
Если сравнивать NGFW всерьёз, опирайтесь на методики, которые специально писали под такие устройства. Помимо уже упомянутого RFC 9411, полезно смотреть на подходы независимых лабораторий — например, SE Labs публикует открытые методики тестирования с HTTP/HTTPS-профилями и распределениями размеров объектов, где важны не только гигабиты, но и задержка транзакций.
Три сценария, без которых картина остаётся неполной. Первый — производительность на смешанном трафике с реалистичным профилем приложений. Второй — поведение при росте числа одновременных сессий: у каждого NGFW есть лимит таблицы состояний, и деградация после его достижения бывает резкой. Третий — падение производительности при включении инспекции TLS и IPS одновременно, именно это число и является рабочим показателем для большинства корпоративных развёртываний.
Что спросить у вендора вместо «сколько по UDP 1518»
Хороший вопрос — не «какая скорость», а «в каком режиме и на каком профиле». Попросите отчёт с перечислением включённых функций, версий ПО, используемых шифров (и версии TLS — это принципиально), размеров кадров, направления трафика и длительности прогонов. Если цифра выглядит фантастически — попросите соседнюю метрику: задержку на том же профиле и производительность при включённой инспекции TLS. Если «скорость как у провода» и при этом задержки нулевые, значит, тест измерял в основном пересылку, а не работу защитного устройства.
Ещё один простой фильтр: спросите, в каком режиме устройство работало во время теста с точки зрения политик безопасности. «Разрешить всё» и «применить профиль для финансовой организации с включёнными антивирусом, IPS и SSL-инспекцией» — это разные конфигурации, и производительность у них разная. Вполне нормально, что вендор указывает обе цифры. Ненормально, когда указывает только первую.
Итог
UDP 1518 — честный и воспроизводимый тест. Просто он отвечает на вопрос «сколько этот чип может переложить байт в секунду», а не на вопрос «сколько трафика устройство потянет, когда вы включите то, за что платили деньги». Держите его в наборе как базовую точку отсчёта, но для реального выбора опирайтесь на сценарии из RFC 9411 и открытые стандарты NetSecOPEN. Тогда цифры в таблице сравнения начнут описывать реальную работу в сети — а не лучший результат в лабораторных условиях, специально подобранных для получения лучшего результата.