форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Рассказ о том, почему ALTQ работает только с исход..."	+/–
Сообщение от opennews on 22-Ноя-05, 13:53
Daniel Hartmeier, автор пакетного фильтра pf, созданного для OpenBSD, подробно поясняет (http://www.bsdforums.org/forums/showthread.php?t=36706), как работают системы лимитирования пропускной способности  и почему ALTQ может гарантированно ограничивать и приоритезировать только отправляемый в заданный сетевой интерфейс трафик, и какие существуют решения для контроля входящего трафика (управление TCP потоком и шейпер на два интерфейса в системе). URL: http://www.bsdforums.org/forums/showthread.php?t=36706 Новость: http://www.opennet.dev/opennews/art.shtml?num=6481
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от Coctic on 22-Ноя-05, 13:53
Это не ответ "почему ALTQ работает только с исходящим трафиком", это рассказ о том, что иногда фильтровать входящий трафик бессмысленно, и поэтому лень заморачиваться на написание такой фильтрации, хотя иногда она полезна.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от BB (??) on 22-Ноя-05, 16:49
	Гы, а что мешает благородному Дону шейпить исходящий траффик на _внутреннем_ интф. ??? О чем в статье кстати и написано ?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Аноним on 22-Ноя-05, 16:56
	>Гы, а что мешает благородному Дону шейпить исходящий траффик на _внутреннем_ интф. >??? О чем в статье кстати и написано ? А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите еще один сервер для шейпинга ставить ? В этом случае от простейшего UDP/ICMP/TCPSYN флуда никакой шейпер не спасет.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от _Ale_ (??) on 22-Ноя-05, 17:08
	>А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите >еще один сервер для шейпинга ставить ? вот именно, для этой цели какой-нить 586 в любой организации всегда найдется.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Аноним on 22-Ноя-05, 17:21
	>>А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите >еще один сервер для шейпинга ставить ? >вот именно, для этой цели какой-нить 586 в любой организации всегда найдется. Это если сам сервер для "каких-нибудь целей", т.е. простой не важен. Для серверов выполняющих конкретные задачи лишнее звено добавлять тразвомыслящий администратор не станет. Этот 586 сведет на нет надежность всей системы, займет драгоценное место в стойке, будет требовать дополнительных мощностей бесперебойников.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от VladimirOstrovskiy (??) on 22-Ноя-05, 18:54
	оборони меня создатель от так мыслящих админов. Аминь.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от bmc (??) on 23-Ноя-05, 12:53
	Что не так? Я тоже гавно всякое на трассы не согласен ставить.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	9. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от BB (??) on 22-Ноя-05, 17:29
	Бррр, а причем здесь рваные голоши ???? грамотный флуд забъет тебе канал по любому. Эт прости меня уже сетевой вандализм направленый на DoS и от него придется защищаться емного другими средствами, можно темже Snort&&snortsam
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от AD (??) on 23-Ноя-05, 11:31
	Народ не хочет понять, что ALTQ - это не шейпер, а менеджер очередей физических интерфейсов. На входящем трафике очередей нет, так как если трафик попадает в драйвер, то он уже принят. ALTQ сдесь ну ничего не может сделать, не той системы граната. Хочется полисинга входящего трафика - используйте dummynet.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

2. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от _Ale_ (??) on 22-Ноя-05, 14:07
Если Вам оно так надо (заморачиваться входящим трафиком), почему бы Вам не переписать ALTQ, а  то видите ли, сами "мы" ничего не сделали, зато можем критиковать и обвинять выдающихся людей в лени....
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от _Ale_ (??) on 22-Ноя-05, 14:14
опечатка - "переписать не ALTQ, а PF"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от 123 (??) on 22-Ноя-05, 16:48
ALTQ - это часть проекта KAME и было портировано в PF
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от Storm (??) on 22-Ноя-05, 18:27
Про дропанье пакетов и DoS - это все понятно. Только шейпинг входящего траффика часто нужен для tcp клиента именно_на_этой_машине. Очередь для входящих пакетов совсем не сложно сделать, это действительно лень, причем совсем непонятная. А что касается `переписать ALTQ', умажаемый Ale - это идите на с такими заявлениями, ибо что делают другие люди для сообщества вы понятия не имеете, а  переписывать ALTQ - дело DH, а не их.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от BB (??) on 22-Ноя-05, 20:23
	>Про дропанье пакетов и DoS - это все понятно. Только шейпинг входящего >траффика часто нужен для tcp клиента именно_на_этой_машине. Очередь для >входящих пакетов совсем не сложно сделать, это действительно лень, причем >совсем непонятная. Эээээ, простите что за клиент может проживать на FW для которого надо шейпить тарафик ??? (примерный ответ я конечно знаю, но также знаю как это сделать по другому, не менее красиво :-Р )
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Sergey (??) on 23-Ноя-05, 12:54
	>  Только шейпинг входящего траффика часто нужен... и причем тут шейпинг? > Очередь для входящих пакетов совсем не сложно сделать... т.е. предыдущий роутер отсортировал и приоритизировал свой трафик, а ваш на входе переделает по-своему? А если каждый маршрутизатор будет очередь перелопачивать на входе по-своему, кому будет щастье?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	17. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от _Ale_ (??) on 23-Ноя-05, 13:50
	>А что касается 'переписать ALTQ', умажаемый Ale - это идите на с такими >заявлениями, ибо что делают другие люди для сообщества вы понятия не >имеете, а  переписывать ALTQ - дело DH, а не их. To Storm интернет дал таким как вы безграничные возможности послать безнаказанно человека, который, возможно, имеет ученую степень, старше вас по возрасту, и совершенно не знаком с вами. продолжайте в том же духе...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Storm (??) on 23-Ноя-05, 17:05
	Вам я, в свою очередь, разрешаю и далее разбрасываться такими заявлениями как `сами "мы" ничего не сделали'.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от gadm on 24-Ноя-05, 14:28
Народ. :) Ну что вы пургу все гоните?-) 1. Шейпить входящий траффик невозможно. Запомните это раз и навсегда. Шейпинг -- управление загрузкой физического канала. И хоть ты удропайся входящие пакеты -- если тебе их с другой стороны шлют, канал всё равно будет на 100% загружен. :) 2. Если под фразой "входящий траффик" понимается, к примеру, траффик по входящему дейта-каналу FTP-сессии, так его вполне можно зашейпить. Неужели никому не пришла в голову светлая мысль шейпить выход этого соединения? Или кто-то плохо помнит, что ALTQ вносит _задержки_ в прохождение пакетов, а TCP PUSH'и не будут ехать быстрее, чем в обратную сторону едут TCP ACK'и?-) TCP -- протокол с flow control'ем, слава КПСС.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от gadm on 24-Ноя-05, 14:34
	И, кстати, именно из-за этого не имеет смысла делать спутниковые каналы более скоростными, чем 2 МБит/сек -- TCP через геостационарный спутник со скоростью, большей, чем 1 МБит/сек не работает. Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать, что свет проходит 70 тысяч километров при передаче пакета. Скорость света -- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего приближения). При окне в 64 килобайта получаем скорость 128 килобайт в секунду -- примерно 1 мегабит/сек. :) Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами). А вы говорите, не зашейпится. ;)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Аноним on 24-Ноя-05, 16:18
	>приближения). При окне в 64 килобайта получаем скорость 128 килобайт в >секунду -- примерно 1 мегабит/сек. :) По 1 Мб на каждую TCP сессию. Запустил многопоточную качалку и доволен :-)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	22. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от _Ale_ (??) on 24-Ноя-05, 16:35
	Ограничить число сессий по ИП
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от zyxman on 24-Ноя-05, 19:11
	>Ограничить число сессий по ИП за такое полагается канделябром :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Sergey (??) on 25-Ноя-05, 14:06
	>>Ограничить число сессий по ИП >за такое полагается канделябром :) just try it! Ежели пров черным по белому пишет что вот, держите анлим за ваши деньги, но шобы мне канал не сажали вот вам 15 TCP сессий и ешьте их как хотите. Интересно кому канделябром в таком или похожем раскладе?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	28. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Мимо шел on 18-Дек-05, 19:59
	>>за такое полагается канделябром :) >Ежели пров черным по белому пишет что вот, держите анлим за ваши >деньги, но шобы мне канал не сажали вот вам 15 TCP >сессий и ешьте их как хотите. >Интересно кому канделябром в таком или похожем раскладе? Смотря какие деньги. Если так, как у меня - полная халява - то я закрою глаза и на лимит сессий, и на негарантированную полосу. А если кто сурьезные деньги плОтит, а ему на мегабит 100 сессий дают... И ведь я знаю таких! При этом купленный мегабит оборачивается в 700-800 кбит в пиках, и 200-300 кбит среднего в долгосрочке. Тут не канделябром, тут топором надо. Меж рогов.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	24. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от v3625 (ok) on 25-Ноя-05, 08:52
	>И, кстати, именно из-за этого не имеет смысла делать спутниковые каналы более >скоростными, чем 2 МБит/сек -- TCP через геостационарный спутник со скоростью, >большей, чем 1 МБит/сек не работает. > >Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time >линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно >в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать, >что свет проходит 70 тысяч километров при передаче пакета. Скорость света >-- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну >сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего >приближения). При окне в 64 килобайта получаем скорость 128 килобайт в >секунду -- примерно 1 мегабит/сек. :) > >Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами). >А вы говорите, не зашейпится. ;) Существует вроде такой параметр масштабирования окна, которыйможно передать в сегменте SYN. Максимальный размер окна может быть 655334 * 2^14 байт. (RFC 1323, Стивенс - глава 2.5)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Valentin Nechayev on 18-Дек-05, 13:14
	>Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time >линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно >в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать, >что свет проходит 70 тысяч километров при передаче пакета. Скорость света >-- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну >сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего >приближения). При окне в 64 килобайта получаем скорость 128 килобайт в >секунду -- примерно 1 мегабит/сек. :) Выставляю окно в 256K без проблем. И скорости соответствующие. >Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами). Не надо друзей, сам сидел на таком канале. 2MBit/s получалось без напряга. >А вы говорите, не зашейпится. ;) Речь в теме немного не о том. Но в данном случае Вы несли полную чушь - и по скорости, и по количеству потоков ограничения совсем другие. И в пике потребления мы получали 38Mbit/s по спутнику - это на весь AS.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	27. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
	Сообщение от Valentin Nechayev on 18-Дек-05, 13:29
	>Народ. :) Ну что вы пургу все гоните?-) Взаимно? > >1. Шейпить входящий траффик невозможно. Запомните это раз и навсегда. Шейпинг -- >управление загрузкой физического канала. И хоть ты удропайся входящие пакеты -- >если тебе их с другой стороны шлют, канал всё равно будет >на 100% загружен. :) Это в клиническом случае полного отсутствия flow control'а у передающего (грубо говоря, это есть флуд в чистом виде и за него полагается по голове). В случае если есть какое-то управление потоком - например, в TCP оно включено так что убрать не получится - то задержки и дропы входящего потока будут не сразу и не столь аккуратно, но регулировать потребление получится. Что точно не получится: грамотная приоритизация для интерактивного и особенно изохронного трафика. Например, выделить в отдельный класс голосовой трафик и давать пакетам такого трафика безусловный приоритет над веб-трафиком. Пример того что точно получится: ограничить потребление некоторой подсетью не более K% трафика; дать ей минимальный приоритет; сделать (с помощью некоторого дополнительного регулятора над полосами в pipe на основании данных счётчиков) ограничение  вида "потреблять не более M% если канал загружен". Основная проблема ALTQ, аналогичных линуксовых средств (tc) почему не подходит входящий поток, а также почему они напрямую не применимы на vlan'ах и прочих видах субпотоков - завязанность алгоритмов шейпинга на реальные текущие характеристики физического интерфейса: длину очереди, пропускную способность; прямой доступ к точке входа в физический интерфейс. При отсутствии знания о текущей очереди алгоритмы очередей вырождаются настолько, что перестают чем-то принципиально отличаться от dummynet'овских средств (ну разве что возможностями TBF по адаптивному занятию полосы в зависимости от загрузки канала...) >Неужели никому не пришла в голову светлая мысль шейпить выход этого соединения? >Или кто-то плохо помнит, что ALTQ вносит _задержки_ в прохождение пакетов, >а TCP PUSH'и не будут ехать быстрее, чем в обратную сторону >едут TCP ACK'и?-) TCP -- протокол с flow control'ем, слава КПСС. И что с того?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

29. "Рассказ о том, почему ALTQ работает только с исходящим трафиком"	+/–
Сообщение от iTux on 13-Мрт-09, 10:10
Ладно, пример того почему надо шейпить входящий трафик... Клуб, на каждый комп приходить должно не более 128кбит, pf+altq(cbq) ограничивает только исходящий, а мне нужно и то и другое, и желательно в синхроне, ибо трафик не резиновый (на 10Мбитах... по мегабайт-но)... Скажи те чем по вашему порезать канал для каждого ИПа в сети ????? Я НИКОГО НЕ ОБСУЖДАЮ, но если нет инструментария то и говорить не очем, просто так и напишите что АЛЬТКУ не способен резать входящий канал.... А НЕ РАЗВОДИТЕ ДЕМАГОГИЮ по поводу ПОЧЕМУ !!!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Рассказ о том, почему ALTQ работает только с исходящим трафи..."	+/–
Сообщение от Аноним (??) on 15-Июн-11, 03:50
В клуб порезать не проблема, причём на исходящих в локалку. а вот на входящих в внешку реально плохо что неработает , иногда очент надо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема