Проблема минимальной скорости и класса по умолчанию для HTB

У меня есть некоторые сомнения по поводу структуры HTB, которую я использую.

Моя цель - ограничить скорость загрузки и выгрузки пользователей в локальной сети. У каждого пользователя сети есть личный список доменов со скоростью вниз и вверх для домена, который он не может превышать.

Это означает, что для пользователя user1 доступ к slashdot.org может быть ограничен 8 КБ при загрузке и 3 КБ для загрузки, а для пользователя user2 на slashdot.org может быть ограничен доступ 4 КБ вниз и 1 КБ вверх.

На данный момент я настроил пару iptables / tc, которая прекрасно работает, но в очень небольшом масштабе, используя 2 или 3 виртуальных хоста одновременно (к сожалению, я не могу выполнить тест в реальном размере).

Вот моя текущая структура (я покажу только ту, что находится на выходе из локальной сети, а та, что для загрузки, является просто «копией» этой)

HTD qdisc (дескриптор 2 :), присоединенный к интерфейсу, класс трафика по умолчанию - класс FFFF.

Корневой класс 2: 1 непосредственно под диском HTB, имеющим для скорости и потолка емкость DOWNLINK.

Класс по умолчанию 2: FFFF как дочерний элемент 2: 1, со скоростью 1 кбит / с и пределом емкости DOWNLINK.

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

На данный момент вот что я сделал:

Создайте новый класс tc с уникальным идентификатором (взятым из базы данных, а не точки здесь), в качестве родительского класса 2: 1, значение скорости составляет 1 бит / с, значение ceil установлено на ограниченную скорость загрузки.

Вот команды tc:

-------------- BEGIN SCRIPT --------------
DOWNLINK=800

## Setting up the static tc qdisc and class

$tc qdisc add dev $LAN_IFACE root handle 2: htb default 0xFFFF

# Main class so the default class can borrow bandwith from the others
$tc class replace dev $LAN_IFACE parent 0x2: classid 0x2:0x1 htb rate $DOWNLINK ceil $DOWNLINKkbps

# add the default class of class id 2:a under the main class of classid 2:1
$tc class replace dev $LAN_IFACE parent 0x2:0x1 classid 0x2:0xFFFF htb rate 1kbps ceil $DOWNLINKkbps prio 0

# add to the leaf class 2:10 for default traffic a sfq qdisc
$tc qdisc add dev $LAN_IFACE parent 0x2:0xFFFF handle 0xFFFF: sfq perturb 10

## The dynamic part called each time a new restriction for a couple domain/user is added
$tc class replace dev $LAN_IFACE parent 0x2:0x1 classid 0x2:0x$idHex htb rate 1bps ceil $speedDownkbps prio 1

# Add the sfq at the leaf class 2:1$id
$tc qdisc add dev $LAN_IFACE parent 0x2:0x$idHex handle 0x$idHex: sfq perturb 10

# $id is the mark added by iptables for this couple domain/user
$tc filter replace dev $LAN_IFACE parent 0x2:0 protocol ip prio 3 handle 0x$id fw flowid 0x2:0x$idHex
-------------- END SCRIPT --------------

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

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

Еще один момент, я добавил по умолчанию prio 0 и ограниченный класс prio 1, поэтому в случае, если класс по умолчанию должен занять (почти всегда в соответствии с его очень низкой скоростью), этот класс будет обслуживаться перед другим ограниченным доменом. Но разве эти домены не будут голодать, если я оставлю ceil класса по умолчанию в качестве корневого класса?

Как мне добиться того, чтобы пользователи могли поддерживать приличную интерактивность и пропускную способность для неограниченного использования, одновременно ограничивая скорость для нескольких пар доменов / пользователь?

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

Я действительно плохо знаком с tc и сетевым QoS, поэтому любые советы, критики (конструктивные;)) будут приветствоваться.

Винсент.

Поскольку вы не включили классификаторы, сложно определить, какой именно трафик вы имеете в виду в каждом классе. Например, исходящий http или ssh трафик очень важен для интерактивности, входящий http не так уж и много.

Я бы гарантировал определенную пропускную способность для каждого сервиса , сказав: у меня есть x кбит / с для входящего трафика httpd, и он распределяется поровну между пользователями. Если у вас есть 10 или 100 пользователей, это справедливо. «Если у вас есть высокоприоритетные пользователи или пользователи с низким приоритетом в каждой из этих служб, вам нужно иметь дополнительные классы и классификаторы для них.

(Также я надеюсь, что вы знаете, что вы можете формировать исходящий трафик только из интерфейса, а не из входящего. Это означает, что если вы хотите ограничить восходящую линию связи, вам придется работать либо с исходящим интерфейсом в Интернете, либо использовать промежуточное устройство очереди . Руководство lartc.org - очень хороший ресурс.)