bw ниже, чем ожидалось

Я думаю тебе нужно увеличить burst а также соответственно.

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

Я бы сказал, что вы наверняка можете добиться аналогичного эффекта, отбрасывая пакеты, вместо того, чтобы получать их. Для таких протоколов, как TCP, которые имеют механизмы самонастройки полосы пропускания, это будет эффективно работать. Взгляни на http://www.linuximq.net/faq.html

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

Нет.

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

Продолжая аналогию с пожарным шлангом, если вам нужно 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 находятся в процессе формирования входящего трафика. Как бы то ни было, я обычно использую формирование и элементы управления на уровне приложения - не идеально, но довольно надежно.

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