traffic control (устал :))

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС для молодых и начинающих системных администраторов.

Модераторы: SLEDopit, Модераторы разделов

pelmen
Сообщения: 1268
ОС: debian

traffic control

Сообщение pelmen »

Давно уже бьюсь с этой темой, читал lartc, "серфинг на забитом канале", еще кучу ссылок, но похоже , что пока я не пойму принципа, я не пойму документацию, т.к. возникают вопросы уже тогда, когда появляется в тексте слово "класс" и т.д. Т.е. смотрю в книгу и вижу фигу. Может быть мне кто-нибудь поможет?
Вопросов, собственно, несколько:
1. Я так и не понял, как можно рулить входящим трафиком, если на деле можно рулить только исходящим трафиком? Если я правильно понял то, что напимано в lartc, то мы просто отбрасываем пришедшие "лишние" пакеты и тогда они придут вновь, но чуть позже, с другим потоком. Так?
2. Что вообще за деревья , листья, классы, u32 какой-то, fifo .... ЗАЧЕМ ВСЕ ЭТО???? :))))))
3. Может мне не дано понять эту тему?

Может быть кто-нибудь покажет очень простой пример решения задачи tc, и распишет значение каждой введенной буквы и это будет хорошим началом для моего познания

А еще у меня такое ощущение, будто настройка tc не так сложна, как её описывают (руководства кажутся специально запутанными). Но это скорее паранойя
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
09.02.2010 18:59
Давно уже бьюсь с этой темой, читал lartc, "серфинг на забитом канале", еще кучу ссылок, но похоже , что пока я не пойму принципа, я не пойму документацию, т.к. возникают вопросы уже тогда, когда появляется в тексте слово "класс" и т.д. Т.е. смотрю в книгу и вижу фигу. Может быть мне кто-нибудь поможет?
Вопросов, собственно, несколько:
1. Я так и не понял, как можно рулить входящим трафиком, если на деле можно рулить только исходящим трафиком? Если я правильно понял то, что напимано в lartc, то мы просто отбрасываем пришедшие "лишние" пакеты и тогда они придут вновь, но чуть позже, с другим потоком. Так?
2. Что вообще за деревья , листья, классы, u32 какой-то, fifo .... ЗАЧЕМ ВСЕ ЭТО???? :))))))
3. Может мне не дано понять эту тему?

Может быть кто-нибудь покажет очень простой пример решения задачи tc, и распишет значение каждой введенной буквы и это будет хорошим началом для моего познания

А еще у меня такое ощущение, будто настройка tc не так сложна, как её описывают (руководства кажутся специально запутанными). Но это скорее паранойя

1. Рулить входящим можно так же как и исходящим. Отбрасываем часть пакетов, в результате нам их отправляют заново, с меньшей скоростью(точнее просто через некоторый промежуток времени - но ведь объем за время это и есть скорость). Таким образом мы становимся теми кто рулит скоростью прихода пакетов. Причем всех пакетов сразу - можем кого-то пропустить в первую очередь, кого-то во вторую и тд. Принципиальной разницы в какую сторону идет трафик(к нам в сеть или из нашей сети) тут нету. А насчет руления только исходящим не путайтесь - здесь имеется в виду "проходящим через исходящую(egress) очередь" - а не к трафику, исходящему из сети.
2. Иерархия системы управления трафиком - читайте это
3. Дано, дано - надо просто потренироваться. Создавайте виртуальную сеть и вперед. Или можете на реале - если не боитесь.

Простой пример показать не могу - как-то все не получается сделать просто - одно за другое цепляется и в итоге получается гора правил. Сейчас участвую в проекте, связанном с шейпером - если хотите можете связатся со мной(по адресу, указанному в статье он же джаббер). Если будет время готов пояснить какие-то моменты (сразу скажу что синтаксис tc комманд это к Евгению - я постарался упрятать синтаксис в api - и с тех пор благополучно забыл его). Если хотите основательной тренировки - присоединяйтесь. Лично я за время потраченное на этот проект разобрался в этом вопросе очень хорошо.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

А уже думали о том, что массив можно держать в mysql?
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 10:18
А уже думали о том, что массив можно держать в mysql?

Конечно - если посмотрите в гите, то можете найти там ./python/createdb.py - наброски базы данных. Пока решили разобраться с шейпером, а потом уже приводить все это к более удобному виду.

UPD
Ошибся - в ./python/createdb.py живет класс для работы с бд. Наброски бд в ./python/setupcfg.py
Спасибо сказали:
expdot
Сообщения: 176
ОС: Fedora 13, Win Vista

Re: traffic control

Сообщение expdot »

посмотрите скрипт htb.init
правда он немног устарел, но большинство функционала современного tc выполняет

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

2. все это из теории графов
проще говоря это дерево наследования траффика
представьте орграф без циклов в вершине которого стоит физический сетевой интерфейс, а его листья - вершины графа - виртуальные интерфейсы с заниженной скоростью
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

По документу http://remizov.pp.ru/ru/trn/doc/manuals/htb-manual (это оригинал статьи http://www.opennet.ru/base/net/htb_manual.txt.html)
Я буду рассуждать, а вы меня поправьте.
1. Сначала у нас появляется команда

Код: Выделить всё

tc qdisc add dev eth0 root handle 1: htb default 12

Это мы так обозначили, что весь трафик, УХОДЯЩИЙ через интерфейс eth0 (который смотрит в локальную сеть) будет попадать в очередь (название, id которой - "1:" или "1:0", что одно и тоже), и что весь трафик, который не попадает под описанные ниже фильтры будет относиться к классу 12 (это который 1:12). Пока вроде понятно, за исключением слова root.
Это типа определяем автовокзал, с которого уезжаем в Нижний Новгород (т.е. в локалку). Если человек попал в него без билета, то он едет на автобусе (потом поймете)

2. Дальше нам нужно определить классы, которые будут относиться к очереди 1:0. С помощью классов мы можем один тип трафика пускать с одной скоростью, а другой - с другой.
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

Тут есть несколько классов - мотоцикл, джип и автобус. Если у человека красный билет, то он едет на мотоцикле, синий - джип, билета нет - автобус. Но есть нюанс - они все потомки корневого класса (по одной дороге едут, на ней можно гнать 100 км/ч - МКАД наверное :) ), соответственно, если кроме автобуса больше никто по дороге не едет, то автобус может ехать чуть быстрее (заимствовать пропускную способность), а если движение плотное - то он едет 60км/ч (пробки не допускаются, это идеальная дорога :) )
Стоит обратить внимание, что в данном примере автобус имеет скорость в два раза большую, чем мотоцикл - 60 против 30. А джип вообще еле едет - 10.
И еще, можно было не прикреплять все автомобили к корневому классу (дороге), а сделать их самих корневыми классами. Тогда правильная аналогия была бы с одинаковыми автомобилями, но разными дорогами с разным качеством, но тогда они не могли бы разгоняться при пустой дороге (заимствовать)

3. Теперь нам надо поставить КПП, где будут выдавать билетики
По ссылке приведен пример фильтрации только клиента А:

Код: Выделить всё

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32  match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32  match ip src 1.2.3.4 flowid 1:11

Тут мы говорим, что все люди из квартиры №80 дома №4 по улице имени профессора 1.2.3 собирающиеся посетить Нижний Новгород (пакеты в локалку, eth0) идут на автовокзал №1: и едут на мотоцикле.
Остальные люди этого дома едут на джипе с того же автовокзала.
Я попробую дописать еще и В. Итак, осталось описать людей из дома №5 той же улицы. Допустим, хотим, чтобы они все ехали с того же автовокзала на автобусе, а квартира №22 - на мотоцикле (хотя логичнее наоборот, но все же)

Код: Выделить всё

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32  match ip src 1.2.3.5 match ip dport 22 0xffff flowid 1:10

Казалось бы, а где про автобус? А нигде, он у нас по умолчанию на этом автовокзале. Все кто без билетиков - едут на автобусе.

Поправьте, если я не прав.


Осталось только понять, зачем ЭТО:
Теперь можно назначить дисциплины очередей для краевых классов. По умолчанию устанавливается дисциплина pfifo.
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

expdot писал(а):
10.02.2010 11:04
посмотрите скрипт htb.init
правда он немног устарел, но большинство функционала современного tc выполняет

Вы про этот?
Если требуется небольшая обертка к htb для более простого записывания правил то может и подойдет(для тех кого пугает синтаксис). Но ИМХО разобраться в работе шейпера никак не поможет.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 11:17
По документу http://remizov.pp.ru/ru/trn/doc/manuals/htb-manual (это оригинал статьи http://www.opennet.ru/base/net/htb_manual.txt.html)
Я буду рассуждать, а вы меня поправьте.
1. Сначала у нас появляется команда

Код: Выделить всё

tc qdisc add dev eth0 root handle 1: htb default 12

Это мы так обозначили, что весь трафик, УХОДЯЩИЙ через интерфейс eth0 (который смотрит в локальную сеть) будет попадать в очередь (название, id которой - "1:" или "1:0", что одно и тоже), и что весь трафик, который не попадает под описанные ниже фильтры будет относиться к классу 12 (это который 1:12). Пока вроде понятно, за исключением слова root.
Это типа определяем гараж. Если человек попал в него без билета, то он едет на автобусе (потом поймете)

2. Дальше нам нужно определить классы, которые будут относиться к очереди 1:0. С помощью классов мы можем один тип трафика пускать с одной скоростью, а другой - с другой.
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

Тут есть несколько классов - мотоцикл, джип и автобус. Если у человека красный билет, то он едет на мотоцикле, синий - джип, билета нет - автобус. Но есть нюанс - они все потомки корневого класса (по одной дороге едут, на ней можно гнать 100 км/ч - МКАД наверное :) ), соответственно, если кроме автобуса больше никто по дороге не едет, то автобус может ехать чуть быстрее (заимствовать пропускную способность), а если движение плотное - то он едет 60км/ч (пробки не допускаются, это идеальная дорога :) )
Стоит обратить внимание, что в данном примере автобус имеет скорость в два раза большую, чем мотоцикл - 60 против 30. А джип вообще еле едет - 10.
И еще, можно было не прикреплять все автомобиль к корневому классу (дороге), а сделать их самих корневыми классами. Тогда правильная аналогия была бы с одинаковыми автомобилями, но разным качеством дорог, но тогда они не могли бы разгоняться при пустой дороге (заимствовать)

3. Теперь нам надо поставить КПП, где будут выдавать билетики
По ссылке приведен пример фильтрации только клиента А, а я попробую дописать еще и В:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11
Тут мы говорим, что все люди из из квартиры №80 дома №4 по улице имени профессора 1.2.3 идут в гараж №1: и едут на мотоцикле.
Остальные люди этого дома едут на джипе из того же гаража.
Итак, осталось описать людей из дома №5 той же улицы. Допустим, хотим, чтобы они все ехали из того же гаража на автобусе, а квартира №22 - на мотоцикле (хотя логичнее наоборот, но все же)
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.5 match ip dport 22 0xffff flowid 1:10
Казалось бы, а где про автобус? А нигде, он у нас по умолчанию в гараже все кто без билетиков - едут на автобусе.

Поправьте, если я не прав.

Классы это скорее ПДД, в которых написано, что автобусу разрешено ехать со скроростью 60, мотоциклу 30 и тд. А очереди, про которые вы не упомянули как раз и будут автобусом, мотоциклом и тд.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

Я немного изменил свой предыдущий пост, не могли бы вы ответить исходя из обновленного варианта?

и да, кстати по поводу "регулирования полосы входящего канала от провайдера путем регулирования исходящего канала в локалку" правильную ли я сейчас аналогию проведу:
Нижний Новгород рекламирует себя в Европе как туристический курорт. Европейцы сначала на самолете прилетают в Москву, а потом разным транспортом едут уже в НН. Соответственно в Москву прилетают битком набитые самолеты с европейцами. Вот только через Москву европейцы хотят летать еще и во Владимир, а самолеты все забиты именно теми, кто едет в НН. Как быть? Приходится на автовокзале в сторону НН каждого второго европейца убивать. Таким образом в НН будут приезжать полупустые автобусы. В городе НН видя такое дело поняли, что их попытки заманить туристов тщетны, деньги, вложенные в рекламу, не сильно себя окупают. Они решают сократить бюджет на рекламу вдвое. Таким образом европейцы будут реже ездить в НН через Москву, и остальные европейцы, которые хотят попасть во Владимир, смогут осуществить свои заветные туристические мечты.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 11:17
Осталось только понять, зачем ЭТО:
Теперь можно назначить дисциплины очередей для краевых классов. По умолчанию устанавливается дисциплина pfifo.
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10


Ваша аналогия хороша - но не совсем верна. Если придерживаться ее, то

Классы - пункты ПДД для конкретного транспортного средства. Например правило

Код: Выделить всё

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps

гласит, что скорость движения по нашей дороге не превышает 100кбит (км/ч :) ). А правило

Код: Выделить всё

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps

гласит что мотоцикл поедет с максимальной скоростью 100 если пустая дорога и со скоростью 30 если дорога полностью забита.

Очереди(это и есть те самые qdisc) - это конкретные транспортные средства - автобус, джип, мотоцикл. Они бываю разные. Например очередь типа pfifo работает так - первым пришел, первым ушел. Будем считать что это мотоцикл(и джип заодно). Очередь sfq - это что-то типа мясорубки(выпускает пакеты из всех соединений по очереди) - это у нас автобус. Внутри очередей тоже можно распределять трафик(Как и в автобусе можно уступать места инвалидам, пассажирам с детьми и тд). Например для некоторых действуют QoS биты и тд.

Фильтры - ну тут все как вы и описали - определяет какой трафик к какому классу относится.

Еще одна поправка - первое правило

Код: Выделить всё

tc qdisc add dev eth0 root handle 1: htb default 12
определяет "дисциплину" - т е способ распределения трафика на интерфейсе. У нас это HTB - как раз та самая иерархия(классы, очереди, фильтры) про которую вы рассказываете. Но дисциплина HTB далеко не единственная. Например в lartc описана CBQ, в которой все по другому и еще ряд более простых дисциплин типа просто обрезки трафика и тд. Так что про это правило можно говорить что как раз оно и создает дорогу с автобусами и прочим.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
Что такое handle, limit, perturb ?
handle - идентификатор? Просто название? Можно было просто написать 2: , 3: и 4: ?
А что за мясорубка? Чем будет хуже, если автобус тоже будет pfifo?
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 11:32
Я немного изменил свой предыдущий пост, не могли бы вы ответить исходя из обновленного варианта?

и да, кстати по поводу "регулирования полосы входящего канала от провайдера путем регулирования исходящего канала в локалку" правильную ли я сейчас аналогию проведу:
Нижний Новгород рекламирует себя в Европе как туристический курорт. Европейцы сначала на самолете прилетают в Москву, а потом разным транспортом едут уже в НН. Соответственно в Москву прилетают битком набитые самолеты с европейцами. Вот только через Москву европейцы хотят летать еще и во Владимир, а самолеты все забиты именно теми, кто едет в НН. Как быть? Приходится на автовокзале в сторону НН каждого второго европейца убивать. Таким образом в НН будут приезжать полупустые автобусы. В городе НН видя такое дело поняли, что их попытки заманить туристов тщетны, деньги, вложенные в рекламу, не сильно себя окупают. Они решают сократить бюджет на рекламу вдвое. Таким образом европейцы будут реже ездить в НН через Москву, и остальные европейцы, которые хотят попасть во Владимир, смогут осуществить свои заветные туристические мечты.

Ухх... тяжелая аналогия - я так мыслить не умею. Давайте я на трафике попробую пояснить.
Например смотрим мы страницы в интернете(т е общаемся в вебсервером). А наш сосед Вася в это время качает торрент. Посылаем вебсерверу запрос и к нам идут 5 пакетов с данными. В это время к Васе приходит 500 пакетов от остальных сидов. В самой обычной ситуации все эти 505 пакетов приходят на шейпер нашего общего с Васей провайдера и там тормозятся, а потом отдаются по очереди в соответствии со скоростью тарифа. Но провайдер не знает ничего не ни про нас, ни про Васю - он отдает все по очереди(fifo - первым пришел, первым ушел) - таким образом каждую секунду(например) нам достается 1 пакет, а Васе - 100 пакетов. Соответственно наша веб страничка будет открываться ЦЕЛЫХ 5 секунд - безобразие! Я думаю всем знакома ситуация, когда стоит торрент и пытаешься вылезти в веб - страницы открываются очень долго - вот как раз поэтому.
Что же нам делать - мы хотим получать свои странички нормально. Васе лишине 5 секунд при закачке фильма весом в 4,5гига погоды не сделают. Тогда мы ставим еще один промежуточный шейпер, на котором начинаем замедлять проходящий трафик - до скорости чуть меньшей чем скорость, описанная в нашем тарифе. Таким образом трафик не будет тормозится и скапливаться у провайдера - он будет тормозится и скапливаться у нас(это как с водой - тормозится в самом узком месте). А мы (помня про Васю) настроим 2 класса - в один пойдет http трафик с большим приоритетом, а во второй пусть идет васин торрент. Таким образом мы будем иметь возможность получать наши странички в первую очередь сколько бы пакетов не пришло Васе.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 11:58
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
Что такое handle, limit, perturb ?
handle - идентификатор? Просто название? Можно было просто написать 2: , 3: и 4: ?
А что за мясорубка? Чем будет хуже, если автобус тоже будет pfifo?

handle - насколько я помню номер фильтра(повторюсь что синтаксис tc не очень помню). К одному классу можно прицепить больше чем один фильтр.
По поводу очередей(pfifo, limit, perturb, sfq) - вам сюда - http://gazette.linux.ru.net/rus/articles/lartc/x852.html
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

В таком случае я попробую объяснить свое непонимание иначе:
У нас есть входящий интернет канал 1мбит, и локалка 100мбит. 10 компов в сети. им всем мы ходим задать по 100кбит (поровну). Вася начал качать обновления с удаленного сервера, у которого исходящий канал интернета 1мбит. Мне всегда казалось, что Вася посылает запрос к серверу через наш роутер, соответственно роутер начнет скачивать обновления для Васи в весь свой поток (1мбит). Он ведь не может сказать серверу обновлений "ей, парень, я знаю, у тебя исходящая скорость такая же как у меня входящая, но мне на это пофиг. Качает Вася, а я ему режу до 100кбит, так что будь любезен..." Соответственно я сделал вывод, что мы режем именно полученный трафик и не смотря на то, что в локалке у нас 100мбит, Вася все равно получит 100кбит и, соответственно будет посылать запрос (следующий пакет) серверу обновлений, в котором укажет "Ей, я получил твой ответ со скоростью 100кбит, так что не старайся мне отправлять слебующий пакет быстрее"
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

Дополнение:
По большому счету дисциплина и очередь это одно и тоже (qdisc - Queueing Discipline - Дисциплина организации очереди). Таким образом у интерфейсу можно подключить как простую(т е безклассовую) очередь (pfifo, sqf, tbf), так и более сложную (т е с классами - полноклассовую) типа HTB, CBQ. А к полноклассовой дисциплине уже можно подключать все что угодно - в том числе и другие полноклассовые дисциплины и безклассовые дисциплины. Для того чтобы не путаться я для себя называю "безклассовую дисциплину обработки очередей(Classless qdisc)" просто очередью, а "полноклассовую дисциплину организации очереди (Classful qdisc)" - дисциплиной. Но в принципе это одно и то же.

pelmen писал(а):
10.02.2010 12:42
В таком случае я попробую объяснить свое непонимание иначе:
У нас есть входящий интернет канал 1мбит, и локалка 100мбит. 10 компов в сети. им всем мы ходим задать по 100кбит (поровну). Вася начал качать обновления с удаленного сервера, у которого исходящий канал интернета 1мбит. Мне всегда казалось, что Вася посылает запрос к серверу через наш роутер, соответственно роутер начнет скачивать обновления для Васи в весь свой поток (1мбит). Он ведь не может сказать серверу обновлений "ей, парень, я знаю, у тебя исходящая скорость такая же как у меня входящая, но мне на это пофиг. Качает Вася, а я ему режу до 100кбит, так что будь любезен..." Соответственно я сделал вывод, что мы режем именно полученный трафик и не смотря на то, что в локалке у нас 100мбит, Вася все равно получит 100кбит и, соответственно будет посылать запрос (следующий пакет) серверу обновлений, в котором укажет "Ей, я получил твой ответ со скоростью 100кбит, так что не старайся мне отправлять слебующий пакет быстрее"

Вы не совсем верно понимаете. Почитайте про работу TCP. Мы можем сказать серверу обновлений подождать - мы просто отбросим один из пакетов - не будем посылать ack (подтверждение получения). Сервер обновлений подождет маленько и пошлет пакет заново. За то время что он "подождет" мы можем обработать других клиентов.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

Alex2ndr писал(а):
10.02.2010 12:51
Вы не совсем верно понимаете. Почитайте про работу TCP. Мы можем сказать серверу обновлений подождать - мы просто отбросим один из пакетов - не будем посылать ack (подтверждение получения). Сервер обновлений подождет маленько и пошлет пакет заново. За то время что он "подождет" мы можем обработать других клиентов.
А вот этого я правда не знал. Видимо по-этому я и не мог понять схему.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 13:04
А вот этого я правда не знал. Видимо по-этому я и не мог понять схему.

Попробую подробнее рассказать. Если ошибусь гуру меня поправят.
Я учился вот по этой книжке - http://www.soslan.ru/tcp/tcp00.html - Конкретно нашему вопросу(работа TCP) посвящены главы 17-21(расчет таймаутов повторной передачи - глава 21). Если продеретесь через это будете знать столько же, сколько и я. Только мне кажется трудно понять что-либо начав читать с 17 главы - лучше уж начинать с 1-ой.

Рассмотри общение Васи с сервером обновлений:
1. Соединение как-то устанавливается (обмен SYN и ACK пакетами - трехразовое рукопожатие ). Нас это пока не интересует т к там передается мало данных - т е объем пакетов маленький. Просто считаем что соединение уже установлено.
2. Обмен данными - сервер посылает Васе пакет с данными(обычно с флагом PSH), Вася в ответ посылает подтверждение получения - пакет с флагом ACK, содержащий номер пакета с данными (т н номер последовательности). В самом простом случае можно считать что пакеты идут по порядку - сначала пакет с данными, потом подтверждение, после получения подтверждения следующий пакет с данными.
3. После того как все пакеты с данными переданы, соединение закрывается. В закрытии соединения участвуют пакеты с флагом FIN и их подтверждения с флагом ACK. Т н четырехразовое рукопожатие. Тоже можно особо не заморачиваться - объем данных небольшой.

С позиции шейпера нас интересует 2 пункт - передача данных. Замедление скорости здесь происходит очень просто - на нашем шейпере, который стоит между сервером обновлений и Васей отбрасывается пакет данных. Вася его не получает, соответственно и ACK в ответ не отправляет. Сервер ждет положенное время и посылает пакет еще раз. Если нашему шейперу не хватило этого времени, для освобождения очередей он отбрасывает пакет снова. Сервер ждет еще БОЛЬШЕЕ время - и опять отправляет пакет. Допустим что шейпер разгреб свои очереди и пропустил этот пакет к Васе. Вася генерирует ACK и соединение идет дальше своим ходом. За счет того, что сервер обновлений ЖДАЛ объем трафика за единицу времени понизился - таким образом Вася общался с этим сервером на ПОНИЖЕННОЙ скорости. Через провайдера тоже прошел меньший объем трафика и его шейпер не переполнился - таким образом бразды правления трафиком по прежнему у нашего шейпера.

НО учтите - эта схема работает только для TCP. UDP ничего ни о каких подтверждения знать не знает - просто лупит и лупит пакетами дальше. С ним такой фокус не работает. По моим оценкам трафик tcp составляет 85-90% от общего трафика.
Спасибо сказали:
expdot
Сообщения: 176
ОС: Fedora 13, Win Vista

Re: traffic control

Сообщение expdot »

тут главное понимать разницу между шейпером и дроппером
первый помещает пакеты в очередь в которой они ждут дальнейшей участи, пока, конечно не кончится время жизни пакета
второй безоговорочно сбрасывает пакет ( реализуется установлением политикой (policy) и можно резать входящий трафик на подходе )
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

expdot писал(а):
10.02.2010 14:37
тут главное понимать разницу между шейпером и дроппером

Знаете, я прочел много литературы - но определение "дроппер" встретил впервые...

expdot писал(а):
10.02.2010 14:37
первый помещает пакеты в очередь в которой они ждут дальнейшей участи, пока, конечно не кончится время жизни пакета

Хмм - вы про какое время жизни говорите? про ttl? Если пакет будет стоять в очереди оно не кончится никогда.

expdot писал(а):
10.02.2010 14:37
второй безоговорочно сбрасывает пакет ( реализуется установлением политикой (policy) и можно резать входящий трафик на подходе )

вот вам определение шейпера - Wiki. Как видите он тоже отбрасывает пакет если очередь полна. Так что же такое "дроппер"? Шейпер с нулевой длиной очереди? Или просто файрвол который отбрасывает ненужные|запрещенные пакеты. А как тогда можно путать фаервол и шейпер?

Может не стоит вносить неясности в и без того мутную тему?
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

У меня возник вопрос. С точки зрения объема выкаченного у провайдера трафика не рациональнее ЛИ не отбрасывать пакет от сервера к Васе, а пропустить его к Васе, а ответ Васи "ПОЛУЧИЛ, ДАВАЙ СЛЕДУЮЩИЙ" отбросить, ведь ответ занимает гораздо меньший объем и лучше Вася повторит его, чем мы с сервера будем качать по 2 раза (грубо говоря) обновления.
Спасибо сказали:
expdot
Сообщения: 176
ОС: Fedora 13, Win Vista

Re: traffic control

Сообщение expdot »

http://lartc.org/lartc.html#LARTC.QDISC.TERMINOLOGY
термин Policing. там же есть и про шейпинг
ну не знаю я как обозвать это по русски
хотя, признаю что был не совсем прав
дропание на выходе тоже является шейпингом, а вот дропание на входе это уже policing

Alex2ndr писал(а):
10.02.2010 14:52
Хмм - вы про какое время жизни говорите? про ttl? Если пакет будет стоять в очереди оно не кончится никогда.

время и жизнь это образно )
я говорил про длину очереди
Спасибо сказали:
expdot
Сообщения: 176
ОС: Fedora 13, Win Vista

Re: traffic control

Сообщение expdot »

У меня возник вопрос
без сомнения лучше
я даже где то встречал желание организовать подобную систему
увы, дальше размышлений дело не дошло

в принципе и сейчас не плохо. протокол tcp разрабатывался с учетом требований к стабильности и надежности передачи
а накладные ресурсы нивелируются за счет алгоритма tcp slow start
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

Я пока эту-то схему не осилил :)
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

expdot писал(а):
10.02.2010 15:23
http://lartc.org/lartc.html#LARTC.QDISC.TERMINOLOGY
термин Policing. там же есть и про шейпинг
ну не знаю я как обозвать это по русски
хотя, признаю что был не совсем прав
дропание на выходе тоже является шейпингом, а вот дропание на входе это уже policing

Alex2ndr писал(а):
10.02.2010 14:52
Хмм - вы про какое время жизни говорите? про ttl? Если пакет будет стоять в очереди оно не кончится никогда.

время и жизнь это образно )
я говорил про длину очереди

Вот ваше же страница - но по русски - http://gazette.linux.ru.net/rus/articles/lartc/x1013.html . Это называется Ограничение.
Давайте просто не будем о дропанье на входе/выходе - мутные рассуждения - пользы и ясности ноль.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 15:15
У меня возник вопрос. С точки зрения объема выкаченного у провайдера трафика не рациональнее ЛИ не отбрасывать пакет от сервера к Васе, а пропустить его к Васе, а ответ Васи "ПОЛУЧИЛ, ДАВАЙ СЛЕДУЮЩИЙ" отбросить, ведь ответ занимает гораздо меньший объем и лучше Вася повторит его, чем мы с сервера будем качать по 2 раза (грубо говоря) обновления.

Домыслите логически - если сервер не получит подтверждения он все равно пошлет пакет ЗАНОВО. Так что при отбрасывании того или иного из пакетов мы все равно получим этот трафик снова. Проще отбросить пакет сервера - во первых он весит больше - а очереди на шейпере не резиновые. Во вторых - сейчас в нашем примере мы регулируем ВХОДЯЩИЙ трафик - а Васино подтверждение относится к ИСХОДЯЩЕМУ. А шейперы входящего и исходящего трафика никак не связаны. Таким образом шейпер на исходящем трафике ничего не знает о том что надо отбросить такой-то ACK пакет.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

Верно.
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

Итак, интернет-шлюз-локалка. В локалке помимо шлюза 2 компа (А и В). Шлюз ничего сам не качает для себя. Только пропускает. Нужно :
1. поделить канал 4 мбит на этих двух клиентов поровну (по 2 мбит)
2. при свободном соседнем канале выделять всю полосу

tc qdisc add dev eth0 root handle 1: htb default 12

tc class add dev eth0 parent 1: classid 1:1 htb rate 4000kbps ceil 4000kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2000kbps ceil 4000kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 2000kbps ceil 4000kbps

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.0.2 flowid 1:11
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.0.3 flowid 1:12


tc qdisc add dev eth0 parent 1:10 handle 2: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 3: pfifo limit 5

При таком положении дел у меня задача выполнится?
Если ДА, то что произойдет, если в локалку добавить комп №3 (С) ? Как в этом случае будет работать пропускная способность для него? Если ничего не менять.
Спасибо сказали:
Аватара пользователя
Alex2ndr
Сообщения: 443
ОС: Debian Lenny

Re: traffic control

Сообщение Alex2ndr »

pelmen писал(а):
10.02.2010 16:38
Итак, интернет-шлюз-локалка. В локалке помимо шлюза 2 компа (А и В). Шлюз ничего сам не качает для себя. Только пропускает. Нужно :
1. поделить канал 4 мбит на этих двух клиентов поровну (по 2 мбит)
2. при свободном соседнем канале выделять всю полосу

tc qdisc add dev eth0 root handle 1: htb default 12

tc class add dev eth0 parent 1: classid 1:1 htb rate 4000kbps ceil 4000kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2000kbps ceil 4000kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 2000kbps ceil 4000kbps

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.0.2 flowid 1:11
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.0.3 flowid 1:12


tc qdisc add dev eth0 parent 1:10 handle 2: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 3: pfifo limit 5

При таком положении дел у меня задача выполнится?
Если ДА, то что произойдет, если в локалку добавить комп №3 (С) ? Как в этом случае будет работать пропускная способность для него? Если ничего не менять.

Вроде выполнится - если не ошиблись в синтаксисе.
Если в локалку добавить 3-й комп, то он отправится в класс по умолчанию - 12. А т к очереди у этого класса нет (про причине отсутствия самого класса) то все его пакеты пойдут в лес :)
Спасибо сказали:
pelmen
Сообщения: 1268
ОС: debian

Re: traffic control

Сообщение pelmen »

мы создали класс 10, где указали rate 2000kbps ceil 4000kbps
а теперь мы хотим двум компам каждому по 2 мбит. Мы делаем фильтр для первого, указываем, что он идет через класс 10. Делаем фильтр для второго указываем, что он идет через класс 10. Или для второго другой класс нужно создавать, потому что в противном случае они будут эти 2 мбит делить между собой?
Этот же вопрос относится и к default, если под default у нас попали 2 компа, то они будут делить скорость или каждому по столько, сколько указано в default?
Спасибо сказали:
expdot
Сообщения: 176
ОС: Fedora 13, Win Vista

Re: traffic control

Сообщение expdot »

если трафик в каком то классе не расходуется, его пропускная способность распределяется между другими класами
pelmen писал(а):
10.02.2010 18:22
если под default у нас попали 2 компа, то

они разделят канал указанный в классе
Спасибо сказали: