Pull to refresh

Comments 98

Можете выложить полный конфиг htb?
спасибо, очень актуально!
Не нашел пакет HTB в своей Ubuntu 9.04 Server. Т.е., там нет /etc/htb/*.
В репозиториях тоже нет.
Значит собирать надо самому?
HTB — это дисциплина шейпера, который встроен в ядро и управляется командой tc
то что мы тут назвали «конфиг htb» — это куча файликов, которые парсит скрипт htb.init и превращает их в команды tc. htb.init есть в пакетах или нет — не помню, фактически это bash-скрипт, его можно скачать с оффсайта sourceforge.net/projects/htbinit/
Я уже начал догадываться. Спасибо за быстрый ответ. :)
UFO just landed and posted this here
UFO just landed and posted this here
Отлично будет работать, только наверное надо будет как то автоматизировать генерацию конфигов классов пользователей, чтоб вручную потом не править 40 файликов, когда надо измениь скорость. Или же отказаться от htb.init и напрямую управлять шепером с помощью утилиты tc
UFO just landed and posted this here
Главная проблема — это как будет фильтроваться трафик и попадать в тот или иной класс. для 30-40 человек и 10МБит — это не критично, а вот если у вас 10к пользователей, то могут возникнуть проблемы. Если кому-то интересно — могу расписать чуть подробнее.
Конечно интересует! Пока моя сеть настолько не выросла, но возможно в будущем ;-)

А в принципе — пакеты фильтруются с помощью маркировки файрволом,
в /usr/src/linux-2.5.73/include/linux/netfilter_ipv4/ipt_mark.h марки объявлены как unsigned longs,
тоесть может быть 2^32 марок пакетов, тоесть 4 294 967 296 классов трафика или пользователей =)
существует две популярные схемы создания соответствия ip->htb class: «ipmark» и «ipclassify».
Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).

У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.

У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.

Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)

зы марков 2^32, а вот классов увы может быть только 0xffff

зыы на днях соберусь — распишу подробно все три схемы с примерами.
Если напишите статью — пожалуйста, оставьте тут ссылку на нее.
А по поводу разрастания таблиц iptables — товарищ когда то писал самодельный патч для ядра, для того чтоб фильтровать трафик по большому черному списку IP. Чем нравится linux — если тебе перестает хватать стандартных вещей — ты можешь написать что то специализированное и очень быстрое, но такая необходимость возникает редко, все обычно уже написано =)
я думаю вы имеете ввиду ipset. Да, это известный и удобный патч, но в данном случае использовать его не получится, тк нам нужно уникальное правило ip->ipmark.
Нет, тот патч в свободное плавние не вышел.
Можно сделать гораздо проще, пропачить ядро так, чтоб класс назначался так:
допустим исходящий или входящий адрес 192.168.0.x тогда назначить класс x
тогда просто для других целей, не идентификации пользователей, надо использовать классы > 255
Офигеть! Вот и выходит как я говорил — все что надо уже написано )))
А как сделать что-то похожее на домашнем виндовс? Только чтобы не разграничивать не по пользователям, а по приложениям.
Спс. Посмотрю на триал для начала!
насколько хорошо работает динамический шейпинг входящего трафика для торрентов? я когда пробовал, у меня торренты все время сжирали канал по-максимуму. В итоге закачки через wget или aria2c еще как-то отбирали канал у торрентов, но серфинга фактически не было.
Я не ставил своей целью сделать так, чтоб каждый пользователь мог одновременно и серфить и качать торренты на полную, просто разделил канал, чтоб условно говоря торренты первого не мешали серфинуг второго. И это прекрасно работает, значит ничего не мешает сделать и чтоб у одного пользователя торренты не мешали серфингу. Чтоб это сделать — надо всего лишь добавить каждому пользователю по два класса — http, а так же аська, jabber, игры — в один класс, которому назначен высокий приоритет и гарантированная полоса, и все остальное — во второй класс, с минимальным приоритетом.
К сожалению отфильтровать трафик торрентов не так просто, поэтому и прийдется действовать методом исключения. Хотя я уже видел патчи для ядра, позволяющие фильтровать по протоколу третьего уровня.
торрент трафик грубо это все по портам 10000+ (может даже 1000+). Кроме редчайших исключений, потому фильтровал я так. Делал
World Of Warcraft использует порты 3724, 6112, and 6881-6999 — ваш фильтр даст ему минимальный приоритет…
Немного ошибся, фильтры 7 уровня (имеется в виду уровень модели OSI) вот их страничка l7-filter.sourceforge.net/
делал так и торренты съедали все из ceil. на серфинг не хватало.
можешь выслать конфиги, попробую подсказать в чем проблема
попробую найти, но в свое время я забил и остановился на статическом шейпинге и простом ограничении скорости в торрент-клиенте.
В таком случае можно разделить канал на много больше полос, отдельно для http, jaber, ssh и т.д. А весь остальной трафик сделать низкоприоритетным
а зачем? в моем случае низкоприоритетный трафик от торрентов забивал практически весь канал и серфинг не работал.
ммм… Странно. Я видимо чего-то недопонимаю в условии задачи.
2 варианта
1) Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.
2) Офис. Не много машин. Около N мегабит канал. Все равноправны. Мы сразу разделим его на полосы с различными приоритетами. А потом все это добро распределим между пользователями. Во 2м случае влияние низкоприотетного трафика не должно сказываться на высокоприоритетном (в идеале конечно). Если у вас к примеру X машин. То вы указываете минимально гарантированную скорость равную ширине канала без поправки в 2-3% от первого параметра и поделенную на кол-во пользователей (X). Максимальное же пропускную способность можно установить как (0,9*N)/X.
Указанные параметры притянуты за уши, дабы проиллюстрировать решение. Не более того
>Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.

Нууу… Это так, если Вы честный, богатый и процветающий провайдер, канал Вам обходится дешево, клиенты платят много и нет конкурентов. Но наверняка в такой вселенной давно уже победил бы коммунизм.

Реально же многие (если не все) мелкие провайдеры продают больше полосы, чем имеют. Вот и приходиться шейпить все кроме веба, игр и VoIP.

У меня как раз два провайдера, один честный и багатый, продает только гарантированные каналы, но дорого, а второй — продает гораздо больше чем имеет, но дешево =)
UFO just landed and posted this here
Описаное тут — в принципе тот же tc, только через обертку из htb.init. Как по мне это несколько проще для понимания.
UFO just landed and posted this here
viperet почему именно пингвин и htb? Какие преимущества дает это по сравнению например с бсд? Сижу выбираю для себя решение, хотелось бы услышать ваше мнение.
Я уже описывал в комментариях к другой статье, про объединение каналов, но напишу еще раз :-)
Linux потому что…
У меня в качестве сервера/роутера используется старый компьютер, на основе Celeron 300 MHz, со 128 MB памяти и HDD на 4 GB. Поэтому к выбору ОС я подходил очень основательно! Вначале правда HDD там вообще небыло, поэтому использовал специализированный дистрибутив для роутеров Zeroshell linux на livecd, кстати в новой версии добавили кучу вкусного, практически все что я долгими трудами и кропотливой настройкой сделал у себя на стандартном дистрибутиве там есть из коробки. Тогда еще пробовал несколько дистрибутивов для роутеров на FreeBSD но они не пошли на том железе (я очень удивился). Когда появился жесткий диск, стал выбор нового дистрибутива, zeroshell уже не устраивал. Выбрал Ubuntu Linux, потому что пакеты скачиваютя уже собраными, их ненадо самому компилировать. На таком процессоре, как у меня, сборка скажем Samba затянулась бы надолго, а пересобрать ядро — вообще долгий процесс и даже для временных файлов места бы нехватило. К тому же у меня был слабый интернет-канал, и я специально перемерял — скомпилированные бинарники весили меньше, чем их исходники.
Так что выбор был вполне осознанным, до этого я администрировал и Red Hat и Debian и FreeBSD.

А htb потому что вначале сделал QoS на cbq, но его возможностей явно нехватало, вот и перешал на htb
Ок, спасибо.

ЗЫ что вы, я в мыслях не держал, реально сижу и глаза разбегаются, столько решений. Лет пять назад как то все попроще было.
Плюс не нужны devel пакеты для компиляции.
Спасибо, попробу настроить на роутере!
Удалось? Случайно не ASUS WL-500? ;)
Подскажите по каким критериям можно выделить трафик skype?
выделить скайп по портам так просто не получится, помочь сделать это вам могут фильтры L7, читайте l7-filter.sourceforge.net/protocols, там указано что уже написаны фильтры для выделения Skype
UFO just landed and posted this here
Почитайте, там на сайте написано. Правило определения skype-skype быстро работает, а вот skypeout — довольно медленно
А что делать если скорость соединения зависит от времени? У меня скорость в интернет днем 512кбит, а ночью 1мбит(«сильной» ночью и того больше), и не охота чтобы ночью полоса простаивала… можно ли динамически менять значения скорости? И как это сделать?
Та же примерно проблема… По тарифу скорость одна, и довольно большая, но на деле сильно зависит от загрузки внешнего канала и сильно прыгает…
можно указать параметр TIME для того чтобы запрограммировать зависимость ширины канала от времени:
### Time ranging parameters
#
# TIME=[.../]-;[/][,[/]]
# TIME=60123/18:00-06:00;256Kbit/10Kb,384Kbit
# TIME=18:00-06:00;256Kbit
#
# This parameter allows you to change class bandwidth during the day or
# week. You can use multiple TIME rules. If there are several rules with
# overlapping time periods, the last match is taken. The , ,
# and fields correspond to parameters RATE, BURST, CEIL
# and CBURST.
#
# is single digit in range 0-6 and represents day of week as
# returned by date(1). To specify several days, just concatenate the
# digits together.

только там тонкость есть - чтоб это првило работало надо htb.init. вызывать с каким то параметром по крону, читайте маны ;-)
Мне когда надо было — я маркировал трафик через iptables с -m time, ну а остальное уже по накатаной.
Друзья, вроде бы по теме, но немного офтопик. У меня тут VServer, доступ через рут, апач2, установлен Plesk, несколько vhost'ов, висит всё это дело на debian (etch).
Так вот для одного vhost'а нужно ограничить трафик. Ну что бы с ip качалось только в несколько кбпс. Но только на этот vhost.
Там специальный файл для этого уже выделен, vhost.conf, туда можно писать всё то, что обычно в конфиге апача светится.

Пробовал установить (apt-get) libapache2-mod-bw, но после вроде бы успешной инсталяции его не видно ни в каталогах апача (mods) и нельзя установить волшебной командой «a2enmod bw».

Может это вообще не тот метод и есть что-то поинтереснее?
Тут есть одна проблемка…

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

То же самое с телефонией (SKYPE, SIP) и много с чем ещё. Даже простые закачки (на базе TCP) одного из пользователей могут занять входящий канал по-полной, наплевав на остальных. Хотя TCP это сделать сложнее, поскольку в случае потерь идёт существенный срез по скорости.
Машина на той стороне не будет посылать ещё, если не будет подтверждений от нашей машины — на этом можно играть.
можно, но это верно только для TCP, где есть congestion control. У битторента через удп(и скайпа), есть похожий механизм, но он более «жадный»(агресивный, как зметил shandor). При большом количестве коннектов у торрент клиента входящий поток пакетов может существенно превышать выделенный вам лимит.
А битторрент через удп вообще есть? У меня все клиенты что я знаю умеют только TCP.

Насчёт скайпа — он поддаётся L7 анализу и тем более у него фиксированная ширина полосы, он около 8 килобайт в секунду ест и ему как раз надо наименьшую задержку.
mutorrent — самый популярный клиент умеет UDP(правда он единственный). но даже в работе в режиме tcp при большом кол-ве коннектов, личеры будут вам слать больше, чем разрешает вам провайдер. Поэтому лучше ограничивать скоростью не двумя мегабитами(для приведенного примера), а меньше.
кстати даже у TCP может быть очень агрессивный контроль потока.
Теоретически входящий поток могут регулировать шейперы на стороне клиента — например, известнейший cFosSpeed — www.cfos.de/speed/cfosspeed_e.htm.

К сожалению, пока он не умеет взаимодействовать с другими компьютерами по сети, но вроде разработчики планировали внедрить такую функциональность.
> взаимодействовать с другими компьютерами по сети
в нашем случае требуется взаимодействие роутера (домашнего сервера) и сервера провайдера. Ни один провайдер на такое не пойдёт.
Это понятно. Ну хотя бы управлять каналом на участке от компа до домашнего роутера — к примеру…
а смысл управлять этим каналом? он как правило 100Мбит и проблем особых нет.
Ну лучше как-то управлять, чем никак не управлять — особенно если в сети много компьютеров, а узким местом является интерфейс домашнего роутера. Было бы неплохо, чтобы на него и от него важные пакеты шли с большим приоритетом.
Вдумайтесь в то что вы говорите.
Управлять = резать, дропать.
По дорогущему каналу пришёл пакет, а вы его собираетесь убрать только потому, что пользователь «превысил» лимит? Совсем неразумная политика.
Да почему же дропать? Пропустить с меньшим приоритетом, если в очереди есть пакеты большего приоритета (HTTP, RTP и т.д.)
До клиента 100 Мбит как правило — какие там могут быть очереди?
Ну почти убедили! :)

Так что, cFosSpeed и прочие шейперы фактически бесполезны, что-ли?
В рамках задачи «честно поделить канал» — бесполезны.
Сейчас использую pf+priq. канал 2мегабита. 5 юзеров.
Когда rtorrent-у было позволено создавать 100+ одновременных соединений — приоритезация нифига не работала (работала, но я этого не чувствовал). Тупило все и у всех. Ограничил 32 соединениями — и о чудо — все летает.
Однажды обнаружил, что «чтото тормозит все». 2000 соединеий от одного чела на 25 порт :)
Нет больше исходящих соединений на 25 порт :)

Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
ng_one2many курить? и что с MPD делать?
Вы случаем не через ADSL работаете? Ну и еще некоторые провайдеры для домашних тарифов ограничивают число одновременных соединений.

> Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
Вам надо объеденить два интернет-канала? Тогда вам сюда habrahabr.ru/blogs/linux/54748/ (на линуксе)
Еще подумал, хорошим противодествием должно быть указание скоростей открытия соединений в единицу времени. А то получается лавинообразное образование огромного кол-ва соединение, даже если данных нужно реально мало.
Уважаемый автор, не могли бы вы создать подробную инструкцию по настройке динамического шейпинга с целью разделения приоритетов трафика в пределах одной машины? А то с переходом на linux найти аналог cFosSpeed так и не удалось, а по этой инструкции настроить уровня знаний не хватает.

Желательно бы готовое решение с уже описанными в правилах программами для торрентокачалки, аськи, браузеров. Я и многие страждущие был бы премного благодарен.
Нужно каким то образом отфильтровать этот трафик, например файрволом и пометить (MARK)
а потом в конфигурации класса htb.init указать вместо RULE= такую штуку
MARK=это значит что в данный класс будут попадать пакеты с данной отметкой
а что у вас делает файлик eth1-2:10.local?
# root class containing total bandwidth
RATE=100Mbit
RULE=192.168.0.75,
RULE=194.9.14.86,
Интерфейс eth1 — смотрит у меня в локальную сеть. Соответственно на нем шейпим исходящий трафик пользователей, и этот класс, в который попадает трафик от пользователей до сервера (тут указаны его внутренний и внейшний адреса), пришлось создать, чтоб не ограничивать скорость аплоада файлов на сервер.
То есть если бы небыло этого класса, то скорость скажем заливки фильма на сервер шейпилась бы на уровне моего исходящего интернет-канала.
Надеюсь объяснил понятно )))
да вполне, спасибо, у меня та же схема — eth1-провайдер, eth0-локалка. А еще такой вопросик если к внутреннему интерфейсу подключены следующие сети 192.168.0.0/18, 192.168.64.0/18, 172.17.0.0/16, 10.0.0.1/24 адрес сервера. как быть тогда?=) Внешний адрес скажем 194.9.14.86
да кстати при htb compile пишет
find: warning: you have specified the -maxdepth option after a non-option argument (, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.<?source>
Это что
Это почти у всех так пишет ) у меня тоже, но все работает. на оффсайте htc.init вроде как есть патчи исправляющий это предупреждение.
с Вашими конфигами (разница в ip-адресах) в логах пишет:
Jan 24 00:42:01 promeline kernel: [227188.455801] HTB: quantum of class 10002 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.468883] HTB: quantum of class 10010 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.505408] HTB: quantum of class 10020 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.523841] HTB: quantum of class 10030 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.549608] HTB: quantum of class 10002 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.554105] HTB: quantum of class 10010 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.567500] HTB: quantum of class 10020 is big. Consider r2q change.
Jan 24 00:48:50 promeline kernel: [227596.597421] HTB: quantum of class 10030 is big. Consider r2q change.

Почитал такое тоже у многих хотя работает, но подтупливает. Пробовал увеличить параметр r2q до 5 — пишет тоже самое, ставлю 6 — пишет наоборот что quantum маленький. Единственный выход уменьшать RATE.
Кстати можно шейпить исходящий канал путем создания правил для второго интерфейса и маркировкой пакетов. Viperet может дополните статью?
HTB.upload
Так а в чем проблема шейпить исходящий канал? У меня там в конфиге правила для интерфейса eth1 — они и шейпят исходяший трафик пользователей.
ну в Ваших конфигах просто выделяется полоса в 2 мегабита, насколько я понял, а маркировка позволяет каждому юзеру давать разную полосу
То мне было просто лениво каждому еще и для аплоада правила создавать! Обычно проблемы с даунлоадом, а аплоад не загружен.

Посмотрел ваши конфиги — маркировать пакеты отдельно через iptables совсем не обязательно, параметр RULE в конфигах htc.init делает то же самое.

Посмотрел ваши конфиги — маркировать пакеты отдельно через iptables совсем не обязательно, параметр RULE в конфигах htc.init делает то же самое.

так не получается
а как сделать так чтоб канал делился равномерно по ip, а не по потокам? Выходит что один Download Master c 8 потоками забирает на себя весь rate класса.
создавайте под каждый IP свой класс HTB, как в примере.
неправильно выразился, весь ceil класса,
то есть, канал раскидан всем ip с одинаковым CEIL класса, но если с одного ip включается многопоточная закачка, то шейпер делит поровну скорость между потоками, а хотелось бы чтоб делил скорость поровну между адресами.
P.S.Слышал про flow classifier но как и с чем его едят, так толком и не вразумляю.
Sign up to leave a comment.

Articles