[Jaguar77]

Здравствуйте, есть ли возможность на Linux средствами tc ограничить скорость TCP соедиения ?

Тоесть, что б например скорость соедиения не превышала 1 мегабит, но 2 соединения могли давать 2 мегабита.

Адреса источника и назначения должны быть любыми...

[Saab95]

Внесите задержку побольше, например 5000мс, тогда скорость сама по себе упадет.

[s.lobanov]

Внесите задержку побольше, например 5000мс, тогда скорость сама по себе упадет.

 

За такие ответы надо расстреливать на месте

[kayot]

надо расстреливать на месте

mikrotikway..

[moonfire]

Как идея, заставить iptables + bash-скрипты добавлять новое правило в tc при создании новой tcp сессии.

[vodz]

Как идея, заставить iptables + bash-скрипты добавлять новое правило в tc при создании новой tcp сессии.

Интересно было б послушать, как "iptables+bash" будут реагировать на "создание новой tcp сессии".

[moonfire]

Например, iptables -j LOG и потом парсить этот лог в онлайн режиме башом или любым другим скриптом, выполняя нужные действия.

[Saab95]

А на микротике можно просто промаркировать все TCP соединения и ограничивать скорость по ним через PCQ, каждому соединению будет дана своя скорость, одинаковая для всех соединений.

[vodz]

Например, iptables -j LOG и потом парсить этот лог в онлайн режиме башом или любым другим скриптом, выполняя нужные действия.

Значить файлы надо качать по 10 килобайт на соединение, муторно, зато быстро, ибо лаг то какой по отслеживанию... :)

[Стич]

http://www.linuxgazette.ru/rus/articles/taleLinuxTC.html

 

SFQ, Stochastic Fair Queuing

ESFQ, Extended Stochastic Fair Queuing

[moonfire]

Эта штука не ограничивает скорость, а регулирует размер и распределение по очередям.

Скорость регулирует шейпер или полисер.

[vodz]

http://www.linuxgazette.ru/rus/articles/taleLinuxTC.html

 

SFQ, Stochastic Fair Queuing

ESFQ, Extended Stochastic Fair Queuing

Что-то ограничения не радуют. Да и вообще похоже немного не то:

Обычная дисциплина SFQ становится неэффективной, если пользователи работают с программами, поддерживающими несколько потоков. В этом случае SFQ не способен поровну разделить канал между пользователями. Однако доступ к дополнительным параметрам алгоритма, обеспечиваемый дисциплиной обработки очереди ESFQ позволяет решить описанную проблему использованием другого хэша, например, по исходному адресу.

Несколько потоков vs по адресу? Хм.

[Jaguar77]

Насколько я понял, ESFQ поделит канал поровну, но не сможет ограничить именно скорость соединения.... К примеру если канал 100 мегабит, и 1 поток, то его скорость будет 100 мегабит.

Надо именно задать скорость

[bomberman]

Здравствуйте, есть ли возможность на Linux средствами tc ограничить скорость TCP соедиения ?

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

Тут необходимо следить за создающимися/умирающими сессиями, и ограничивать их. Известных способов сделать это средствами tc, скорее всего нет. Если не крутить что то что будет реализовывать алгоритм вышеописанный.

[vodz]

Способов нет скорее всего из-за безумной задачи. Что это вообще должно быть? Хост, гарантированно устанавливающий по одному соединению на "клиента" (кавычки тут от не представленных условий задачи)? Ну тогда, наверное можно дать каждому "клиенту" по серому IP, ограничить скорость по IP, а потом уже натить дальше. Сойдёт?

А если соединений произвольное количество, то что должно решать это ограничение скорости? Ведь пока не упрётся в полку, то от негарантированного количества соединений никакой "справедливости" не просматривается, а как упрётся - так и вообще ничего не надо, само сбалансируется.

[vop]

Как ни смешно, но только добавлением задержки можно формально решить эту задачу.

[stasn1]

dev=imq0
tc qdisc del dev $dev root
tc qdisc add dev $dev handle 1025: root drr

for i in $(seq 1 1024); do
   h=$(printf %x $i)
   tc class add dev $dev parent 1025: classid 1025:$h drr
   tc qdisc add dev $dev parent 1025:$h handle $h: netem rate 1Mbit
done

tc filter add dev $dev protocol ip handle 1025 parent 1025: flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10

[Jaguar77]

:-) Спасибо

[bomberman]

dev=imq0
tc qdisc del dev $dev root
tc qdisc add dev $dev handle 1025: root drr

for i in $(seq 1 1024); do
   h=$(printf %x $i)
   tc class add dev $dev parent 1025: classid 1025:$h drr
   tc qdisc add dev $dev parent 1025:$h handle $h: netem rate 1Mbit
done

tc filter add dev $dev protocol ip handle 1025 parent 1025: flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10

 

 

Любопытно. Но верно ли я понимаю логику работы фильтра:

Имеем 1024 - класса, которые ограничивают сессии. (1024 по 1Мб)

Хешированием, по ключам (src,dst,proto,proto-src,proto-dst) раскидываем потоки/соеденения по этим калссам.

А если соеденений будет более 1024. Выходит кто то будет делить между собой скорость класса?

P.s. Я о написанном.

Edited February 22, 2017 by bomberman

[stasn1]

Любопытно. Но верно ли я понимаю логику работы фильтра:

Имеем 1024 - класса, которые ограничивают сессии. (1024 по 1Мб)

Хешированием, по ключам (src,dst,proto,proto-src,proto-dst) раскидываем потоки/соеденения по этим калссам.

А если соеденений будет более 1024. Выходит кто то будет делить между собой скорость класса?

P.s. Я о написанном.

 

Да.

[moonfire]

Как ни смешно, но только добавлением задержки можно формально решить эту задачу.

TCP создан для сетей с задержками, так что это не поможет. Гуглить tcp window scaling long fat networks

+ будут проблемы с интерактивными сессиями

 

dev=imq0

tc qdisc del dev $dev root

tc qdisc add dev $dev handle 1025: root drr

 

for i in $(seq 1 1024); do

h=$(printf %x $i)

tc class add dev $dev parent 1025: classid 1025:$h drr

tc qdisc add dev $dev parent 1025:$h handle $h: netem rate 1Mbit

done

 

tc filter add dev $dev protocol ip handle 1025 parent 1025: flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10

Класс, а все как один говорили, что не возможно. Единственное, что туда будет попадать не только TCP, несколько я понимаю.

[stasn1]

Класс, а все как один говорили, что не возможно. Единственное, что туда будет попадать не только TCP, несколько я понимаю.

 

Можно же завернуть неTCP трафик фильтром с меньшим номером в класс без шейпера на нем...

 

А вместо drr можно, наверное, соорудить дерево из HFSC или HTB если нужно резать и суммарную полосу.

[bomberman]

Любопытно. Но верно ли я понимаю логику работы фильтра:

Имеем 1024 - класса, которые ограничивают сессии. (1024 по 1Мб)

Хешированием, по ключам (src,dst,proto,proto-src,proto-dst) раскидываем потоки/соеденения по этим калссам.

А если соеденений будет более 1024. Выходит кто то будет делить между собой скорость класса?

P.s. Я о написанном.

 

Да.

 

Выходит тоже кастыль, но более ровный. И универсального решения задачи не выполняет?

С учётом количества классов (если память не подводит max classid = 0xffff ) ~ 65535 то и потоков доложно быть не более в таком случае. А значит решение для максимум 65535 соеденений.

 

Но ведь можно строить деревья правил и классов.

В таком случае получаем - 0xffff:0xffff классов. что куда интереснее для решения задачи. Но меняется подход. Нужно определиться со скоростью на ip, если взять за основу, на ip 65535 соеденений и делить её между потоками. Думается мне, что так будет правильнее. (Или я в чём то ошибаюсь?)

 

P.s. вопрос автору, поста. Где и зачем это понадобилось? (любопытство) :-)

Edited February 22, 2017 by bomberman

[Ivan_83]

Как ни смешно, но только добавлением задержки можно формально решить эту задачу.

Далеко не всегда.

Зависит от СС и прочих настроек тцп на сервере и немного от клиентских.

[vop]

TCP создан для сетей с задержками, так что это не поможет. Гуглить tcp window scaling long fat networks

 

Погодь, разве мы обсуждали вопрос, как "бороться" с задержками? :) А эту борьбу мы проходили в конце 90-х, когда сидели на спутниковых каналах.

 

+ будут проблемы с интерактивными сессиями

 

Естественно будут. Но топикстартер и не просил шустрый интерактив. Он просил как-нибудь порезать скорость сессий.

 

Класс, а все как один говорили, что не возможно. Единственное, что туда будет попадать не только TCP, несколько я понимаю.

 

Ну это тоже подпорка. Причем, с не совсем понятной производительностью. Хотя, если она подойдет автору, значит это его решение.

 

Как ни смешно, но только добавлением задержки можно формально решить эту задачу.

Далеко не всегда.

Зависит от СС и прочих настроек тцп на сервере и немного от клиентских.

 

Т.е. автор будет решать задачу на сервере, а кто-то в это же время ему будет мешать ее решить, ломая настройки на его сервере? :) Ну а клиент, да, окошко может поменять.