Jaguar77 Опубликовано 20 февраля, 2017 · Жалоба Здравствуйте, есть ли возможность на Linux средствами tc ограничить скорость TCP соедиения ? Тоесть, что б например скорость соедиения не превышала 1 мегабит, но 2 соединения могли давать 2 мегабита. Адреса источника и назначения должны быть любыми... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 20 февраля, 2017 · Жалоба Внесите задержку побольше, например 5000мс, тогда скорость сама по себе упадет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 20 февраля, 2017 · Жалоба Внесите задержку побольше, например 5000мс, тогда скорость сама по себе упадет. За такие ответы надо расстреливать на месте Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 20 февраля, 2017 · Жалоба надо расстреливать на месте mikrotikway.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
moonfire Опубликовано 20 февраля, 2017 · Жалоба Как идея, заставить iptables + bash-скрипты добавлять новое правило в tc при создании новой tcp сессии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vodz Опубликовано 20 февраля, 2017 · Жалоба Как идея, заставить iptables + bash-скрипты добавлять новое правило в tc при создании новой tcp сессии. Интересно было б послушать, как "iptables+bash" будут реагировать на "создание новой tcp сессии". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
moonfire Опубликовано 20 февраля, 2017 · Жалоба Например, iptables -j LOG и потом парсить этот лог в онлайн режиме башом или любым другим скриптом, выполняя нужные действия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 20 февраля, 2017 · Жалоба А на микротике можно просто промаркировать все TCP соединения и ограничивать скорость по ним через PCQ, каждому соединению будет дана своя скорость, одинаковая для всех соединений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vodz Опубликовано 20 февраля, 2017 · Жалоба Например, iptables -j LOG и потом парсить этот лог в онлайн режиме башом или любым другим скриптом, выполняя нужные действия. Значить файлы надо качать по 10 килобайт на соединение, муторно, зато быстро, ибо лаг то какой по отслеживанию... :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 20 февраля, 2017 · Жалоба http://www.linuxgazette.ru/rus/articles/taleLinuxTC.html SFQ, Stochastic Fair Queuing ESFQ, Extended Stochastic Fair Queuing Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
moonfire Опубликовано 20 февраля, 2017 · Жалоба Эта штука не ограничивает скорость, а регулирует размер и распределение по очередям. Скорость регулирует шейпер или полисер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vodz Опубликовано 20 февраля, 2017 · Жалоба http://www.linuxgazette.ru/rus/articles/taleLinuxTC.html SFQ, Stochastic Fair Queuing ESFQ, Extended Stochastic Fair Queuing Что-то ограничения не радуют. Да и вообще похоже немного не то: Обычная дисциплина SFQ становится неэффективной, если пользователи работают с программами, поддерживающими несколько потоков. В этом случае SFQ не способен поровну разделить канал между пользователями. Однако доступ к дополнительным параметрам алгоритма, обеспечиваемый дисциплиной обработки очереди ESFQ позволяет решить описанную проблему использованием другого хэша, например, по исходному адресу. Несколько потоков vs по адресу? Хм. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jaguar77 Опубликовано 20 февраля, 2017 · Жалоба Насколько я понял, ESFQ поделит канал поровну, но не сможет ограничить именно скорость соединения.... К примеру если канал 100 мегабит, и 1 поток, то его скорость будет 100 мегабит. Надо именно задать скорость Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 21 февраля, 2017 · Жалоба Здравствуйте, есть ли возможность на Linux средствами tc ограничить скорость TCP соедиения ? средствами tc, скорее всего нет. (если не создавать правила для всех возможных/разрешённых вариантов match правила с классами скоростей). Но это безумие. Тут необходимо следить за создающимися/умирающими сессиями, и ограничивать их. Известных способов сделать это средствами tc, скорее всего нет. Если не крутить что то что будет реализовывать алгоритм вышеописанный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vodz Опубликовано 21 февраля, 2017 · Жалоба Способов нет скорее всего из-за безумной задачи. Что это вообще должно быть? Хост, гарантированно устанавливающий по одному соединению на "клиента" (кавычки тут от не представленных условий задачи)? Ну тогда, наверное можно дать каждому "клиенту" по серому IP, ограничить скорость по IP, а потом уже натить дальше. Сойдёт? А если соединений произвольное количество, то что должно решать это ограничение скорости? Ведь пока не упрётся в полку, то от негарантированного количества соединений никакой "справедливости" не просматривается, а как упрётся - так и вообще ничего не надо, само сбалансируется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 21 февраля, 2017 · Жалоба Как ни смешно, но только добавлением задержки можно формально решить эту задачу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 21 февраля, 2017 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jaguar77 Опубликовано 22 февраля, 2017 · Жалоба :-) Спасибо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 22 февраля, 2017 (изменено) · Жалоба 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. Я о написанном. Изменено 22 февраля, 2017 пользователем bomberman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 22 февраля, 2017 · Жалоба Любопытно. Но верно ли я понимаю логику работы фильтра: Имеем 1024 - класса, которые ограничивают сессии. (1024 по 1Мб) Хешированием, по ключам (src,dst,proto,proto-src,proto-dst) раскидываем потоки/соеденения по этим калссам. А если соеденений будет более 1024. Выходит кто то будет делить между собой скорость класса? P.s. Я о написанном. Да. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
moonfire Опубликовано 22 февраля, 2017 · Жалоба Как ни смешно, но только добавлением задержки можно формально решить эту задачу. 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, несколько я понимаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 22 февраля, 2017 · Жалоба Класс, а все как один говорили, что не возможно. Единственное, что туда будет попадать не только TCP, несколько я понимаю. Можно же завернуть неTCP трафик фильтром с меньшим номером в класс без шейпера на нем... А вместо drr можно, наверное, соорудить дерево из HFSC или HTB если нужно резать и суммарную полосу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 22 февраля, 2017 (изменено) · Жалоба Любопытно. Но верно ли я понимаю логику работы фильтра: Имеем 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. вопрос автору, поста. Где и зачем это понадобилось? (любопытство) :-) Изменено 22 февраля, 2017 пользователем bomberman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 февраля, 2017 · Жалоба Как ни смешно, но только добавлением задержки можно формально решить эту задачу. Далеко не всегда. Зависит от СС и прочих настроек тцп на сервере и немного от клиентских. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 22 февраля, 2017 · Жалоба TCP создан для сетей с задержками, так что это не поможет. Гуглить tcp window scaling long fat networks Погодь, разве мы обсуждали вопрос, как "бороться" с задержками? :) А эту борьбу мы проходили в конце 90-х, когда сидели на спутниковых каналах. + будут проблемы с интерактивными сессиями Естественно будут. Но топикстартер и не просил шустрый интерактив. Он просил как-нибудь порезать скорость сессий. Класс, а все как один говорили, что не возможно. Единственное, что туда будет попадать не только TCP, несколько я понимаю. Ну это тоже подпорка. Причем, с не совсем понятной производительностью. Хотя, если она подойдет автору, значит это его решение. Как ни смешно, но только добавлением задержки можно формально решить эту задачу. Далеко не всегда. Зависит от СС и прочих настроек тцп на сервере и немного от клиентских. Т.е. автор будет решать задачу на сервере, а кто-то в это же время ему будет мешать ее решить, ломая настройки на его сервере? :) Ну а клиент, да, окошко может поменять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...