Другой способ — Token Bucket Filter, который реализуется в пределах вашего фильтра. Это типичный шейпер, который может использоваться, если вам нужно просто ограничить полосу пропускания по какому-нибудь критерию.

Тут все очень просто и имеется всего один параметр: avrate. Либо объем трафика остается ниже avrate и фильтр классифицирует его как сконфигурированный classid, либо, в случае превышения заданной границы, выполняется указанное действие, которое по-умолчанию выполняет переклассификацию.

Для оценки загруженности канала, ядро использует экспоненциальное взвешенное смещенное среднее значение, которое менее чувствительно к коротким пикам.

Используются следующие параметры:

• burst/buffer/maxburst

• mtu/minburst

• mpu

• rate

Которые ведут себя идентично описанным в разделе Token Bucket Filter. Обратите внимание, если вы установите mtu слишком низким, то входящий трафик будет подавлен, в то время как исходящий TBF qdisc передаст с более низкой скоростью.

Еще одно важное отличие такого фильтра – он может только либо пропустить пакет, либо отбросить. Он не может задержать пакет на какое-то время.

Если правило "решит", что произошло превышение заданного предела, то оно выполнит соответствующее действие. Имеются четыре вида действий:

continue

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

drop

Очень жестокое действие, которое просто отказывает "в праве на жизнь" трафику, объем которого превысил заданную величину. Часто используется во входных фильтрах и имеет ограниченное применение. Например, представим, что имеется сервер имен, который не в состоянии работать при нагрузке выше чем 5Мбит/сек, в этом случае можно построить входной фильтр, который ограничит входящий трафик для нашего сервера.

Pass/OK

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

reclassify

Действие, заданное по-умолчанию. Наиболее часто сводится к переклассификации в Best Effort (в данном контексте фразу "Best Effort" следует понимать как — "лучшее из оставшегося". прим. перев. )

Единственный, известный нам, реальный пример приведен в разделе Защита от SYN flood.

Ограничение входящего icmp-трафика до 2 Кбит. При превышении предела — пакеты отбросить.

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

Этот метод может использоваться для полного подавления icmp-трафика:

Фактически означает: "отбросить все icmp-пакеты, размер которых превышает 1 байт". Чисто теоретически, пакеты могут иметь размер в 1 байт, но на практике вы с ними никогда не встретитесь.

Если у вас возникла потребность в большом количестве правил, например, когда у вас много клиентов, причем все имеют различные спецификации QoS (от англ. Quality of Service — Качество Обслуживания), то может сложиться ситуация, когда ядро будет тратить недопустимо большое количество времени на поиск подходящего правила в наборе.

По-умолчанию, все фильтры находятся в одной большой цепочке, и располагаются в порядке убывания приоритетов. Если набор содержит 1000 правил, то для некоторых пакетов может потребоваться выполнить 1000 проверок, чтобы решить, что с ними делать дальше.