Можно ли эффективно ограничить входящую полосу пропускания?

НЕТ .

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

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

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

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

Я слышал неоднозначные результаты по ограничению входящей полосы пропускания, но это должно быть возможно с устройством ifb в ядре. Хотя одна правда заключается в том, что сказал @ voretaq7, вы можете «ограничить» входящие пакеты, если вы принимаете все входящие пакеты и перенаправляете их с перенаправлением или зеркалированием на одно из устройств «I_ntermediate F_unctional B_lock». К ним вы можете прикрепить любые фильтры, обычно ограниченные до «исходящая» фильтрация.

Это может показаться бесполезным, так как вы должны принимать весь трафик в ifb - но затем вы можете решить, какой трафик выходит из этой очереди ожидания «IN» для остальной части в вашей системе.

Это дает преимущество в том, что пакеты не отбрасываются, если они не являются пакетами с более низким приоритетом. Конечно, если вы подвергаетесь DoS-атаке, ключевая проблема, вероятно, будет в том, что общий входящий трафик больше, чем может выдержать ваша линия, поэтому попытки повлиять на это с помощью этого метода бесполезны. Этот метод будет работать только с допустимыми потоками по любому желаемому протоколу (TCP, UDP, ICMP и т. Д.). То есть, если я хочу установить приоритет DNS над массовыми загрузками, я могу это сделать, однако, независимо от того, какой у вас алгоритм трафика, если у вас 30 МБ /, то при самом быстром прерывании нормальной тактовой частоты 1000 Гц вам все равно придется иметь дело с 30 КБ трафик / тиканье часов, и это при условии, что вам позвонят вовремя. Это основная причина, по которой у вас должна быть высокая скорость пакета, потому что с этим трудно справиться с одним ограничением скорости.

Было бы полезно , если ваша сетевая карта имеет несколько очередей ввода-вывода. Многие карты имеют 6-12 очередей / направление, которые могут обеспечить некоторую «автоматическую» классификацию в отдельные очереди на основе, как правило, более ограниченных параметров фильтрации на карте Ethernet.

Что может быть более полезным - если вы можете разделить свой трафик на эти несколько очередей, так это то, что вы можете установить привязку процессора для очередей. Если вы обнаруживаете, что ограничены в пакетах обработки ЦП, с multiQ, это может помочь распределить входящий трафик для обработки на разные ядра (не используйте Hyperthreading - это, скорее всего, вызовет проблему производительности, поскольку потоки не работают. для общих данных, но с отдельными потоками данных. Лучше всего обрабатывать их с помощью ЦП с использованием отдельных кешей L1 и L2 (L3 по-прежнему будет совместно использоваться, как правило, между несколькими ядрами), но вы можете, по крайней мере, выделить кэши L1 и L2 их собственным «потокам»).

Из-за проблем с пропускной способностью, которые у меня были с одиночными очередями и политикой, я отказался от управления входом - и у меня было только 5 МБ входящий в то время (сейчас 7 МБ), поэтому я не пытался понять, насколько эффективно использование multiq и ifb при формировании входящего трафика. Как бы то ни было, я обычно использую формирование и элементы управления на уровне приложения - не идеально, но довольно надежно.

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