Перейти к содержанию
Как правильно добавить self-test и прочую отладку в тему
Где взять тестовые сборки
Официальное хранилище ПО в виде файлов
  • 0

зачем вы загоняете в conttrack весь локальный трафик?

umka

Ответ от umka,

 Поделиться

Вопрос

umka Пользователь

umka

Опубликовано
Опубликовано

Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..

14 ответов на этот вопрос

Рекомендуемые сообщения

  • 0
ndm Старожил

ndm

Опубликовано
Опубликовано
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.
  • 0
umka Пользователь

umka

Опубликовано
  • Автор
Опубликовано
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.

как минимум там трафик к самой точке, мультикаст из локалки, и был трафик от NAS подключенного по зернету (сейчас нету, но видел)

root@Keenetic_Giga:/opt/root# grep src=192.168.1. /proc/net/nf_conntrack | grep dst=192.168

ipv4 2 udp 17 16 src=192.168.1.36 dst=192.168.1.1 sport=57476 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57476 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.36 dst=192.168.1.1 sport=57458 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57458 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 14 src=192.168.1.36 dst=192.168.1.1 sport=52105 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=52105 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 431 src=192.168.1.36 dst=224.0.0.2 [uNREPLIED] src=224.0.0.2 dst=192.168.1.36 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 582 src=192.168.1.2 dst=224.0.0.22 [uNREPLIED] src=224.0.0.22 dst=192.168.1.2 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 4 src=192.168.1.36 dst=192.168.1.1 sport=55056 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=55056 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 28 src=192.168.1.36 dst=192.168.1.1 sport=50030 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50030 mark=0 nfm_marker = 0 use=2

ipv4 2 tcp 6 1199 ESTABLISHED src=192.168.1.34 dst=192.168.1.1 sport=50850 dport=22 src=192.168.1.1 dst=192.168.1.34 sport=22 dport=50850 [ASSURED] mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=50763 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50763 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=57699 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57699 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 10 src=192.168.1.34 dst=192.168.1.1 sport=58345 dport=53 src=192.168.1.1 dst=192.168.1.34 sport=53 dport=58345 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.33 dst=192.168.1.1 sport=57291 dport=53 src=192.168.1.1 dst=192.168.1.33 sport=53 dport=57291 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 9 src=192.168.1.1 dst=192.168.1.255 sport=138 dport=138 [uNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=138 dport=138 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 3 src=192.168.1.36 dst=192.168.1.1 sport=49447 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=49447 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 11 src=192.168.1.36 dst=192.168.1.1 sport=54243 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=54243 mark=0 nfm_marker = 0 use=2

скорее всего в конфете ядра забыто проверять локальный трафик. А это потребление памяти - которого можно избежать без потери функциональности.

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.

как минимум там трафик к самой точке, мультикаст из локалки, и был трафик от NAS подключенного по зернету (сейчас нету, но видел)

root@Keenetic_Giga:/opt/root# grep src=192.168.1. /proc/net/nf_conntrack | grep dst=192.168

ipv4 2 udp 17 16 src=192.168.1.36 dst=192.168.1.1 sport=57476 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57476 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.36 dst=192.168.1.1 sport=57458 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57458 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 14 src=192.168.1.36 dst=192.168.1.1 sport=52105 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=52105 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 431 src=192.168.1.36 dst=224.0.0.2 [uNREPLIED] src=224.0.0.2 dst=192.168.1.36 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 582 src=192.168.1.2 dst=224.0.0.22 [uNREPLIED] src=224.0.0.22 dst=192.168.1.2 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 4 src=192.168.1.36 dst=192.168.1.1 sport=55056 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=55056 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 28 src=192.168.1.36 dst=192.168.1.1 sport=50030 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50030 mark=0 nfm_marker = 0 use=2

ipv4 2 tcp 6 1199 ESTABLISHED src=192.168.1.34 dst=192.168.1.1 sport=50850 dport=22 src=192.168.1.1 dst=192.168.1.34 sport=22 dport=50850 [ASSURED] mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=50763 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50763 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=57699 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57699 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 10 src=192.168.1.34 dst=192.168.1.1 sport=58345 dport=53 src=192.168.1.1 dst=192.168.1.34 sport=53 dport=58345 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.33 dst=192.168.1.1 sport=57291 dport=53 src=192.168.1.1 dst=192.168.1.33 sport=53 dport=57291 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 9 src=192.168.1.1 dst=192.168.1.255 sport=138 dport=138 [uNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=138 dport=138 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 3 src=192.168.1.36 dst=192.168.1.1 sport=49447 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=49447 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 11 src=192.168.1.36 dst=192.168.1.1 sport=54243 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=54243 mark=0 nfm_marker = 0 use=2

скорее всего в конфете ядра забыто проверять локальный трафик. А это потребление памяти - которого можно избежать без потери функциональности.

В этом нет ничего страшного, и это необходимо для работы ip hotspot.

  • 0
Padavan Старожил

Padavan

Опубликовано
Опубликовано

Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

  • 0
umka Пользователь

umka

Опубликовано
  • Автор
Опубликовано
Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

вопрос больше не к памяти. 16к соединений много - но к примеру один торрент на NAS + 2 ноута в держат 2k соединений на роутере. То есть роутер даже в этих настройках потянет с десяток клиентов - не более.

Сколько больше вопрос к CPU. Текущие настройки будут вынуждать прогонять весь мультикаст/броадкаст/мултикаст прокси через все iptables input правила. Пока трафик не большой - это ладно, а с ростом - получим съедание CPU. Достаточно лишь 4-5 клиентам начать смотреть видео через igmp proxy.

К примеру - сейчас копирование файла с wifi на eth - съедает 30-32% в ksoftirqd (точнее не скажу - perf отсутствует в репозитории).

А это время от iptables в том числе.

  • 0
zyxmon Старожил

zyxmon

Опубликовано
Опубликовано
....точнее не скажу - perf отсутствует в репозитории....

Есть iperf

opkg list iperf*
iperf - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with single thread support.
iperf-mt - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with multithread support.

  • 0
umka Пользователь

umka

Опубликовано
  • Автор
Опубликовано
....точнее не скажу - perf отсутствует в репозитории....

Есть iperf

opkg list iperf*
iperf - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with single thread support.
iperf-mt - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with multithread support.

iperf и perf это 2 очень большие разницы.

iperf служит для тестирования сетевых соединений. perf служит для анализа производительности ядра linux.

имелось ввиду второй.

https://perf.wiki.kernel.org/index.php/Main_Page

к слову

root@Keenetic_Giga:/opt/root# opkg update

Downloading http://opkg.keenopt.ru/all/Packages.gz.

Inflating http://opkg.keenopt.ru/all/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/all.

Downloading http://opkg.keenopt.ru/mipsel/Packages.gz.

Inflating http://opkg.keenopt.ru/mipsel/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/mipsel.

Downloading http://opkg.keenopt.ru/kng_re/Packages.gz.

Inflating http://opkg.keenopt.ru/kng_re/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/kng_re.

root@Keenetic_Giga:/opt/root# opkg list | grep perf

root@Keenetic_Giga:/opt/root# opkg list iperf*

root@Keenetic_Giga:/opt/root#

этого тоже нету... понятно что можно подтянуть что-то из openwrt .. но..

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

вопрос больше не к памяти. 16к соединений много - но к примеру один торрент на NAS + 2 ноута в держат 2k соединений на роутере. То есть роутер даже в этих настройках потянет с десяток клиентов - не более.

Сколько больше вопрос к CPU. Текущие настройки будут вынуждать прогонять весь мультикаст/броадкаст/мултикаст прокси через все iptables input правила. Пока трафик не большой - это ладно, а с ростом - получим съедание CPU. Достаточно лишь 4-5 клиентам начать смотреть видео через igmp proxy.

К примеру - сейчас копирование файла с wifi на eth - съедает 30-32% в ksoftirqd (точнее не скажу - perf отсутствует в репозитории).

А это время от iptables в том числе.

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

  • 0
umka Пользователь

umka

Опубликовано
  • Автор
Опубликовано

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

это копейки. Простейший тест вам покажет что для загрузки одной странички с картинками любого сайта - надо 50-70 соединений.

запустите скрипт

$ while [ 1 ]; do lsof -n -i TCP | grep -v '*:*' | wc -l; lsof -n -i UDP | grep -v '*:*' | wc -l; sleep 0.5; done

и походите по страничкам. news.yandex.ru дает 40 конектов, newsru.com - дает 80,

открыл 3 страницы подряд - получил 120 конектов, открыл 4ю - получил 150... Открыл одноклассники еще прыжок на 120 соединений. И того активных 500 соединений, просто так. Дальше начинаем вспоминать что большинство браузеров не закрывают сразу сокеты и держат "а вдруг еще что-то потребуется". Это без всяких торрентов замечу.

У вас и ваших клиентов точно только одна вкладка открыта и они открывают странички раз в минуту/две? Они никогда не ходят по соц сетям, и пользуются только страницами со статическим HTML? Они никогда не сохраняли открытыми вкладки - в которых иногда включено автообновление?

Что там говорилось о безумии?..

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

Точно?

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

224.0.0.0 является сетью для muticast если верить RFC. видимо у нас с вами разные multicast.

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

Вы не пытались проанализировать контекст выполнения всех этих операций? Linux kernel так и не научился обрабатывать пакеты в параллель, во всяком случае не в той версии ядра что у вас используется. Как раз таки по этому наличие второго CPU на этой железке никого не спасет.

И как раз таки по этому

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

ЭЭ.. вы не пытались систематизировать свои знания? iptables это утилита управления.

Подсистема в ядре давно называется NetFilter, в данной подсистеме есть 2 части. xtables, и conntrack.

В этом легко убедится если глянуть в конфигурацию ядра

config NF_CONNTRACK

tristate "Netfilter connection tracking support"

и

config NETFILTER_XTABLES

tristate "Netfilter Xtables support (required for ip_tables)"

Кроме того - вы давно делали профайлинг работы netfilter в ядре? особенно в случае нескольких тысяч соединений?

PS. мое желание было лишь вам подсказать что можно исправить что бы сделать продукт лучше, но не смею навязывать вам свои знания. Видимо проще дождаться пока поддержка этого железа будет в openwrt и перейти туда. или просто убрать все ваши правила - и поставить свои. К сожалению создание собственных ядер для этой железки будет отложено пока не появится openwrt.

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

это копейки. Простейший тест вам покажет что для загрузки одной странички с картинками любого сайта - надо 50-70 соединений.

запустите скрипт

$ while [ 1 ]; do lsof -n -i TCP | grep -v '*:*' | wc -l; lsof -n -i UDP | grep -v '*:*' | wc -l; sleep 0.5; done

и походите по страничкам. news.yandex.ru дает 40 конектов, newsru.com - дает 80,

открыл 3 страницы подряд - получил 120 конектов, открыл 4ю - получил 150... Открыл одноклассники еще прыжок на 120 соединений. И того активных 500 соединений, просто так. Дальше начинаем вспоминать что большинство браузеров не закрывают сразу сокеты и держат "а вдруг еще что-то потребуется". Это без всяких торрентов замечу.

Это в случае использования http/1.0, которые плюс ко всему сразу же закрываются, а не висят постоянно.

А вслучае использования http/1.1 к каждому из серверов создается одно отдельное перманентное соединение, а никак не 500.

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

Точно?

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

224.0.0.0 является сетью для muticast если верить RFC. видимо у нас с вами разные multicast.

То, что это мультикастные адреса, не делает их автоматически используемыми для передачи video-трафика.

Этот адрес - 224.0.0.1 - вообще-то означает "Все хосты", и скорее всего используется для сигнализации mDNS, Zeroconf или miniDLNA.

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

Вы не пытались проанализировать контекст выполнения всех этих операций? Linux kernel так и не научился обрабатывать пакеты в параллель, во всяком случае не в той версии ядра что у вас используется. Как раз таки по этому наличие второго CPU на этой железке никого не спасет.

Пакеты в параллель обрабатываются на ура, в 3.4 уже есть RPS.

Тут дело именно в драйвере WiFi от Mediatek.

Если вы реально умеете анализировать контексты и профилировать драйверы, то почему вам не прийти бы к нам на работу, вместо бестолкового флуда на форуме?

  • 0
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

ЭЭ.. вы не пытались систематизировать свои знания? iptables это утилита управления.

Подсистема в ядре давно называется NetFilter, в данной подсистеме есть 2 части. xtables, и conntrack.

В этом легко убедится если глянуть в конфигурацию ядра

config NF_CONNTRACK

tristate "Netfilter connection tracking support"

и

config NETFILTER_XTABLES

tristate "Netfilter Xtables support (required for ip_tables)"

Кроме того - вы давно делали профайлинг работы netfilter в ядре? особенно в случае нескольких тысяч соединений?

Я смотрел не только в конфигурацию, но в и код, и не только смотрел, но и писал (ц)

Потому мне не нужно рассказывать как там что устроено.

Последний профайлинг был сделан в начале июня, и дал некоторое улучшение.

А вообще мы не гонимся именно за суперпроизводительностью netfilter, поскольку у нас есть огромный арсенал средств программного и аппаратного ускорения трафика, который постоянно пополняется.

Еще вопросы?

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
 Поделиться
Перейти к списку вопросов

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю