Ограничение _больших_ закачек в скорости

А с какой целью надо?

>Например, чтоб файлы размером до 5 метров

А как сетевая подсистема об этом узнает? Ладно, если клиент корректно поле ТОС ставит, по нему можно.

squid это точно умеет, найдите любую нормальную доку в гуле про нарезку скорости в сквиде. tc - может что-то получится если поколдовать с burst и cburst.

Был когда то патч для iptables дающий --connbytes. Не знаю, есть ли он сейчас, но так он мог бы вам помочь.

для сквида читайте про delay_pools

Для начала сойдёт:

http://www.opennet.ru/docs/RUS/traf_limit/

Готовое решение лежит в википедии (описание критерия connbytes).

В современных ядрах (2.6.26 Debian Lenny) он есть. В древних (2.6.18 CentOS 5) — нету.

>Готовое решение лежит в википедии (описание критерия connbytes).

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

Но если хотите полной уверенности — делайте дисциплины/классы/фильтры с prio и т.п.

connbytes как патч существовал ещё для 2.4 ядер, например, он был в ASP 9.0 (2.4.22). И не надо мешать в кучу версию ядра и опции его сборки в дистрибутиве.

Я не историк. Я знаю, что в текущей версии оно есть. А что там было n лет назад — знаете ли, лень разгребать.

И не надо мешать в кучу версию ядра и опции его сборки в дистрибутиве.

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

> А с какой целью надо?

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

> А как сетевая подсистема об этом узнает?

Т.к. преимущественно проблемным у меня есть хттп трафик, то в случае со сквидом, например, есть возможность знать размер запрашиваемого файла. Ну или первые 5 метров потока пропускать нормально, а все что свыше - как-то маркировать и обслуживать в другой очереди.

> (описание критерия connbytes)

Да, пожалуй, это можно использовать. Для пакетов где пришло более 5 метров ставить пометку FWMARK и приоретизировать трафик при помощи iproute2. Попробую.

Главное, чтобы ваша система это поддерживала.

да, connbytes есть. Может что-то не так делаю, но..
1) iptables -t mangle -I PREROUTING -i eth0 -p tcp --sport 80 -m connbytes --connbytes 512000: --connbytes-dir both --connbytes-mode bytes -j MARK --set-mark 2
по-русски, ставить отметку 2 на все все пакеты, если по этому соединение пробежало более 500 кбайт. по результататам проверки - это работает.
2) tc q add dev eth0 ingress
3) tc f a dev eth0 parent ffff: proto ip prio 24 handle 0x2 fw flowid 1:1 action mirred egress redirect dev ifb0

Проверяю: # tc -s f s dev eth0 parent ffff:
filter protocol ip pref 24 fw
filter protocol ip pref 24 fw handle 0x2 classid 1:1

action order 1: mirred (Egress Redirect to device ifb0) stolen
index 1 ref 1 bind 1 installed 188 sec used 188 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0


В то время как iptables показывает, что пакеты маркируются. Не могу понять, где ошибка. classid указан от фонаря, т.к. один из разрабов iproute2 указывал мне на то, что хотя tc и принимает фильтры без указания classid (и даже работает), все же лучше указать конкретные числа (даже если они не будут использованы, как в случае с редиректом пакетов) чтобы избежать непредвиденного поведения программы.
Фильтр не сработал ни на один из пакетов. ЧЯДНТ?

Обязательно нужно
ip link set dev ifb0 up

И, может, нужно назначить дисциплину на ifb0.

mky, можешь у себя денить проверить? я то ifb0 поднимал. Думаю, что классовая дисциплина не обязательна.

В общем, получается, что в IFB трафик попадает до того, как будет отмаркирован в iptables. Так что я вам фигню насоветова, сорри. Получается, что вам подходят варианты: 1) Squid (можно долго и много настраивать); 2) IMQ (патчить ядро, если ещё найдете подходящую версию); 3) ограничивать полосу для закачек по исходящему трафику.