Нужен был инструмент для генерации трафика в одну сторону, без ожидания ответов. Схема не предполагала, что удаленная сторона может отвечать, поэтому iperf не подходил. Также необходимо было управлять скоростью, например, на уровне 100, 200, 500 или 1000 Mbps. Первым попавшимся под руку инструментом оказался hping3.

Трафик генерировался с виртуальной машины (4 ГБ RAM, 8 CPU, Ubuntu 24, NIC на ESXi 25G x2).

У hping3 есть флаг --flood, который позволяет отправлять пакеты с максимальной скоростью без задержки между ними. Запускаем тест и для начала проверим его возможности:

hping3 --udp -p 5000 -d 9000 --flood <ip>

Максимальная скорость составила 2.1 Gbps, что связано с однопоточной архитектурой hping3, которая не позволяет полноценно загружать многоядерные процессоры. Этот инструмент работает через стандартный стек Linux и не использует DPDK или другие "ускорители". Каждый пакет проходит через системные вызовы (sendto()), что создает высокую нагрузку на CPU. Но скорости выше 2 Gb/s не требовалось; градаций от 100 Mb/s до 1 Gb/s было достаточно.

Чтобы управлять скоростью трафика, я решил поэкспериментировать с размером пакета (-d) и интервалом отправки пакетов (-i). Попробовал честно рассчитать необходимые значения:

100 Mbit = 12,500,000 bytes
12,500,000 / 1472 (размер пакета) = 8491 пакетов/сек → интервал 1/8491 = 0.0001178 сек = 118 µs (микросекунды)

Запускаем с интервалом u118:

hping3 --udp -p 5000 -d 1472 -i u118 <ip>

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

Далее я опытным путем подобрал значения интервалов для достижения требуемых скоростей:

hping3 --udp -p 5000 -d 1472 -i u95 <ip>
Speed: 99.17 Mbps 

hping3 --udp -p 5000 -d 1472 -i u35 <ip>
Speed: 208.31 Mbps 

hping3 --udp -p 5000 -d 1472 -i u4 <ip>
Speed: 989.28 Mbps

В принципе, со своей задачей hping3 справился, но изначально он создавался для задач анализа сетевой безопасности (или наоборот 🙂)

Приведу примеры, когда он может пригодиться.


▎Тесты на защиту от DDoS

icmp-флуд
hping3 --icmp --flood <ip>

tcp-флуд
hping3 -S -p 80 --flood <ip>

udp-флуд
hping3 --udp -p 53 --flood -d 1000 <ip>

▎Spoofing (подделка src ip/mac)

ip spoofing
hping3 -a <bad_ip> -S -p 22 <ip>

mac spoofing
hping3 --spoof 00:11:22:33:44:55 -p 80 <ip>

▎Сканирование

tcp syn-сканирование(аналог nmap)
hping3 -S -p 80 <ip>

Сканирование диапазона портов
hping3 -S -p 1-1000 <ip>

▎Проверка IPS/IDS

Вставим SQL-инъекцию в пакет, сработает ли IDS?
echo "SELECT * FROM users" | hping3 -p 80 -E /dev/stdin <ip>

Тест на переполнение буфера.
Проверим падает ли сервис при отправке огромного пакета:
hping3 -p 80 --data 10000 <ip>

Ну и наконец, раз инструмент называется hping3, должен быть и обычный ping:

hping3 -1 <ip>

Выводы: hping3 отлично подходит для задач тестирования фаерволов, анализа IPS/IDS и проверки устойчивости к DoS-атакам. Однако для задач точного измерения скорости лучше использовать другие инструменты, например, iperf.

P.S. На последнем Linkmeetup 25 узнал о Trex. Да, первый раз услышал 🤷. По описанию — мощный инструмент с многопоточностью и низкой нагрузкой на CPU за счет DPDK оптимизаций; можно генерировать трафик свыше 100G. Вероятно, в следующий раз попробую его. Но в пользу hping3 скажу, что он не требует конфигурационных файлов — установил и используй в CLI.