LINUX.ORG.RU
ФорумAdmin

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


0

0

КАК? Интересуют варианты с использованием SQUID или с использованием netfilter/iptables/iproute2. Вообще таковое возможно? Например, чтоб файлы размером до 5 метров попадали в некую общую очередь а свыше - в очередь с низким приоритетом/ограниченным каналом. Либо соединения, по которым интенсивно бегают байты дольше минуты -- ограничивались

★★

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

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

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


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

redgremlin ★★★★★ ()

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

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

a_andry ()

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

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

mky ★★★★★ ()

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

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

af5 ★★★★★ ()

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

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

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

nnz ★★★★ ()

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

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

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

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

nnz ★★★★ ()

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

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

mky ★★★★★ ()

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

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

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

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

nnz ★★★★ ()

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

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

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

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

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

azure ★★ ()

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

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

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

azure ★★ ()

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

да, 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 (и даже работает), все же лучше указать конкретные числа (даже если они не будут использованы, как в случае с редиректом пакетов) чтобы избежать непредвиденного поведения программы.
Фильтр не сработал ни на один из пакетов. ЧЯДНТ?

azure ★★ ()

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

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

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.