[g3fox]

Основная нагрузка это не "маршрутизация" а программные прерывания, которые создаёт драйвер сетевой карты.

 

From 6.5 Mpps to 9.4 Mpps via build_skb() and tunning.

 

отсюда

 

И что вы хотели этим сказать? Что "маршрутизация" занимает больше процессорного времени, чем softirq? Или что?

Я так-то не спорю, что 10Г через тазик прокачать можно. Но ТС хочет их не просто прокачать, а ещё и выполнить некий анализ трафика.

Поэтому указал, что если просто вставить 10Г карточку это ещё не означает, что через тазик сразу пройдёт 10Гбит и при этом процессор будет 100% idle. Как кто-то выразился ранее "перекладывание пакетов из интерфейса в интерфейс" тоже жрёт дофига ресурсов если речь идёт о гигабитах, а не о 10мбит/с.

[Dark_Angel]

+1 за решение на миррор портах и указания маршрутизаторам после анализа.

 

Трафик через анализатор, пусть даже только HTTP, и пусть даже только по списку урлов - это не так просто как кажется. А завтра захотите парсить по регекспам надо будет всё перестраивать или ставить на фильтр железо мощнее чем ядро сети.

 

У меня от "Для того, чтобы переложить ethernet-кадр с интерфейса на интерфейс, много ресурсов не нужно." тоже немного подгорело, но спешу уверить вас, alibek, что это не так, если пакет обрабатывается, а не просто копируется.

Изменено 27 ноября, 2014 пользователем Dark_Angel

[alibek]

Не буду спорить, на низком уровне с вопросом не знаком.

Однако СКАТ на довольно среднем сервере обрабатывает около 2 Гбит/с трафика.

При этом он не просто пропускает трафик через себя, но и сверяется со списком РКН и Минюста, а это более 10 тысяч записей.

[Dark_Angel]

Он скорее всего это делает для списка портов ( 80, 21, 8080 может ) и per flow. Соответственно он не анализирует все 2 Гбита.

 

Опустим тот факт, что если с этим тазиком что-то случится ( например поломается роутинг или приедет какой-то кривой список ), то весь трафик никуда не пойдет.

 

Короче говоря, настоятельно рекомендуется, все виды анализа трафика ( netflow, dpi, investigation, etc. ) выносить на мирроры. Чтобы между клиентом и интернетом было только необходимое железо для работы и чтобы это железо не было занято левой работой.

 

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

[alibek]

Он скорее всего это делает для списка портов

Нет. В реестре есть записи для нестандартных портов и он их обрабатывает.

[^rage^]

И что вы хотели этим сказать? Что "маршрутизация" занимает больше процессорного времени, чем softirq? Или что?

softirq - это и есть сетевой стек. форвардинг, шейперы, netfilter, ipsec - это всё softirq.

 

Я так-то не спорю, что 10Г через тазик прокачать можно. Но ТС хочет их не просто прокачать, а ещё и выполнить некий анализ трафика.

никто не анализирует вообще весь трафик. а если и анализирует, то стараются кешировать результаты анализа.

 

Поэтому указал, что если просто вставить 10Г карточку это ещё не означает, что через тазик сразу пройдёт 10Гбит и при этом процессор будет 100% idle. Как кто-то выразился ранее "перекладывание пакетов из интерфейса в интерфейс" тоже жрёт дофига ресурсов если речь идёт о гигабитах, а не о 10мбит/с.

 

ну я же кидал ссылку на netmap. там вообще трафик до сетевого стека не доходит. приложение работает с netmap api, которое просто предоставляет к rx/tx ring сетевой карточки.

[Dark_Angel]

Нет. В реестре есть записи для нестандартных портов и он их обрабатывает.

 

Значит он парсит список и настраивает фильтры на те порты, которые есть в списке. Других требований к фильтру по закону нет, и я не думаю что он фильтрует весь трафик.

[Bigmazy]

Неправильно, фильтрует по протоколу, если идет http сессия (это определяет детектор), то не зависимо от порта применит правила фильтрации.

[SyJet]

На сколько я знаю скат вообще как-то странно работает с сетевыми, обратите внимание, даже если нет трафика проц все равно чем-то сильно занят

[Bigmazy]

Это архитектурно сделано, диспетчер всегда работает с nic, борьба за latency (правда в основном проявляется на старых процах). Не даром ведь получить не более 30 микросекунд задержки.