Вопросы Теги

Обеспечивает ли многопортовый модуль iptables преимущество в производительности по сравнению с несколькими отдельными правилами?

(я пока не могу комментировать, поэтому ответ)

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

Я предполагаю, что ваш маршрутизатор имеет адрес 192.168.56.1 (если нет, попробуйте 192.168.56.255), но это не обязательно. Посмотрите, сможете ли вы пропинговать его, и можете ли вы открыть страницу конфигурации вашего маршрутизатора, если вы перейдете на этот IP-адрес в веб-браузере.

Если да, установите этот IP-адрес в качестве шлюза. Отправленная вами команда кажется правильной.

3
23.03.2018, 15:08
2 ответа

iptables просматривает каждое правило из таблицы до тех пор, пока не будет найдено совпадение с конечной целью, поэтому меньшее количество правил означает меньшую загрузку ЦП. Хотя некоторые правила работают быстрее, чем другие, например, правило multiport для 15 портов может быть быстрее, чем эквивалентное правило set (, как в ответе Hauke ​​Laging ).. Так что важно не только количество правил, но и их тип.

Исходный код для tcp/udp , multiport и set соответствуют некоторым эмпирическим правилам, но поскольку трудно предсказать, где все работает медленно , я бы рекомендовал протестировать возможные наборы правил iptables и посмотреть, какой из них быстрее. Например, я запускаю iperf3 со списком всего из 3 портов, и модуль tcp был немного быстрее, чем многопортовый и набор . модули, которые предлагали аналогичную пропускную способность.

Если вы все еще увлекаетесь микробенчмарками, я подсчитал количество циклов ЦП, необходимых для запускаipt_do_tableфункции ядра, с помощью этого самого,очень примитивный скрипт SystemTap :

global call_cycles = 0

probe kernel.function("ipt_do_table@net/ipv4/netfilter/ip_tables.c").call {
    call_cycles = get_cycles()
}

probe kernel.function("ipt_do_table@net/ipv4/netfilter/ip_tables.c").return {
    delta = get_cycles() - call_cycles
    printf(" <- delta = %d\n", delta)
}

Это мои результаты для пакета, проходящего через все правила на виртуальной машине под управлением Linux 4.15:

Модуль Порты Правила Прогон 1 Прогон 2 Прогон 3 Прогон 4 Прогон 5
TCP 4500 4500 973148 1032564 856528 410894 854708
многопортовый 4500 300 89370 259250 99752 225275 182256
набор 4500 1 28463 43494 28315 33589 40988
3
27.01.2020, 21:21

Я не знаю, как Linux обрабатывает правила Netfilter на уровне кода операции. Но многопортовый подход может выполнять несколько проверок за одну операцию.

Так как 1 Гбит/с не так много для процессора (даже медленного ), неудивительно, что вам нужны крайние случаи. Но оба подхода даже при одинаковой пропускной способности могут генерировать совершенно разные нагрузки. Поскольку это материал ядра, он, вероятно, даже не показан в /proc/loadavg. Таким образом, вам придется запустить приложение с интенсивным использованием ЦП -в той же системе и измерить его производительность, чтобы увидеть реальную разницу.

Но я думаю, что ваше сравнение несколько несправедливо, потому что мультипорт проверяет один раз для -p tcp, тогда как мультируль делает ту же самую проверку 65536 раз. Таким образом, вы бы сделали что-то вроде этого:

iptables -N tcp_ports
iptables -A INPUT -p tcp -j tcp_ports
for ((i=1;i<65536;i++)); do iptables -A tcp_ports --sport $i...

Я просто понимаю, что вы не можете пропустить проверку TCP, потому что это требование для --dport. Но это одна из причин, почему подход с несколькими правилами работает медленнее.

Я не уверен, что мультипорт предназначен для таких случаев, как ваш. Для сравнения были созданы огромные списки ipset. Так что это может быть то, что вы на самом деле ищете. 

ipset create foo bitmap:port range tcp:10000-19999
ipset add foo tcp:10000-19999
iptables -A INPUT -p tcp -m set --match-set foo dst
2
27.01.2020, 21:21

Теги

Похожие вопросы