Динамический шейпинг.
Динамический шейпинг.
Есть ли возможность реализовать динамический шейпинг?
NAS БСД, принцип работы примерно такой:
Есть тарифные планы типа Анлим хоум( у нас пока нету, но очень нужны, конкуренты жмут) там скорость ограничевается в зависимости от загрузки, т.е. допустим при серфе, играх, мелких скачиваниях скорость фиксированная,а при длительной закачке она режется.
Под длительной я понимаю закачку близкую к "полочке" т.е если на протяжении 60 мин человек скачивает на скорости близкой к максимальной в Тарифном плане, то скорость падает в 2 раза, если качает на ней еще 2 часа то падает еще в 2 раза и в дальнейшем, в случае закачки там и остается. Не качает 2 часа поднимается в 2 раза, не качает еще час то поднимается до начального значения.
Как я понимаю это можно сделать так:
снял статистику за 2 часа и если обьем равен или больше 0.8X(X=максимальному обьему на данной скорости), то режем, потом снимаем обьем за следующие 2 часа,и если
он больше или равен 0.4X то режем, если меньше то вверх.
Если в следующие 2 часа меньше чем 0.2 то вверх,если равно или больше то оставляем, потом 2 часа меньше или равно 0.4 вверх.
Итого 3 состояния и 3 действия. Но под это можно подстроится поэтому можно добавить еще. та же проверка только раз в 6ч если больше или равно 0.5, то до 0.2, через 6ч опять проверка.
Или как можно реализовать шайпинг при длительной закачке мой метод топорный.
Заранее спасибо.
NAS БСД, принцип работы примерно такой:
Есть тарифные планы типа Анлим хоум( у нас пока нету, но очень нужны, конкуренты жмут) там скорость ограничевается в зависимости от загрузки, т.е. допустим при серфе, играх, мелких скачиваниях скорость фиксированная,а при длительной закачке она режется.
Под длительной я понимаю закачку близкую к "полочке" т.е если на протяжении 60 мин человек скачивает на скорости близкой к максимальной в Тарифном плане, то скорость падает в 2 раза, если качает на ней еще 2 часа то падает еще в 2 раза и в дальнейшем, в случае закачки там и остается. Не качает 2 часа поднимается в 2 раза, не качает еще час то поднимается до начального значения.
Как я понимаю это можно сделать так:
снял статистику за 2 часа и если обьем равен или больше 0.8X(X=максимальному обьему на данной скорости), то режем, потом снимаем обьем за следующие 2 часа,и если
он больше или равен 0.4X то режем, если меньше то вверх.
Если в следующие 2 часа меньше чем 0.2 то вверх,если равно или больше то оставляем, потом 2 часа меньше или равно 0.4 вверх.
Итого 3 состояния и 3 действия. Но под это можно подстроится поэтому можно добавить еще. та же проверка только раз в 6ч если больше или равно 0.5, то до 0.2, через 6ч опять проверка.
Или как можно реализовать шайпинг при длительной закачке мой метод топорный.
Заранее спасибо.
-
- Site Admin
- Сообщения: 5749
- Зарегистрирован: Пт янв 28, 2005 3:11 pm
- Контактная информация:
Что-то навороченное щас рисовать некогда, а простенькое - пжалста. К netfilter есть такой patch-o-matic: connbyte.~AsmodeuS~ писал(а):поделитесь примерами
connbytes
Match by how many bytes or packets a connection (or one of the two flows constituting the connection) have tranferred so far, or by average bytes per packet.
The counters are 64bit and are thus not expected to overflow

The primary use is to detect long-lived downloads and mark them to be scheduled using a lower priority band in traffic control.
The transfered bytes per connection can also be viewed through /proc/net/ip_conntrack and accessed via ctnetlink
[!] --connbytes from:[to]
match packets from a connection whose packets/bytes/average packet size is more than FROM and less than TO bytes/packets. if TO is omitted only FROM check is done. "!" is used to match packets not falling in the range.
--connbytes-dir [original|reply|both]
which packets to consider
--connbytes-mode [packets|bytes|avgpkt]
whether to check the amount of packets, number of bytes transferred or the average size (in bytes) of all packets received so far. Note that when "both" is used together with "avgpkt", and data is going (mainly) only in one direction (for example HTTP), the average packet size will be about half of the actual data packets.
Example:
iptables .. -m connbytes --connbytes 10000:100000 --connbytes-dir both --connbytes-mode bytes ...
А раз можно проверить, сколько прошло по соединению, значит можно и промаркировать. Когда будет достигнут очередной лимит, метка поменяется и правила шейпера завернут пакет в другую дисциплину обслуживания с другим приоритетом/скоростью/иещёчегохошьчем. Кстати, connbyte далеко не единственная возможность трассировки соединений - их в нетфильтер афигеть скока

Хоть вопрос и не ко мне, но отвечу:
ЗЫ надеюсь, вы читали уже http://abills.net.ua/wiki/doku.php?id=a ... radattr:ru ? Довольно много вопросов отпадут
Дистр - в принципе роли особой не играет. Кто-то юзает легковесный Gentoo, кто-то - тяжелую Fedora... В моем случае шейпинг реализован вообще на роутере с Bering (дистрибутив, которому для запуска и полноценной работы в минимальном конфиге достаточно дискеты, предназначен специально для роутеров)chtito писал(а):а на каком дистре этим лучше заниматься?
Шеллскриптов ИМХО даже более, чем достаточно.chtito писал(а): И еще: достаточно ли будет шелл скриптами делать свое дело или придется более основательно программировать?
ЗЫ надеюсь, вы читали уже http://abills.net.ua/wiki/doku.php?id=a ... radattr:ru ? Довольно много вопросов отпадут

Ой, значит для шейпинга нужен pppd?надеюсь, вы читали уже http://abills.net.ua/wiki/doku.php?id=a ... radattr:ru ?
