The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"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.ru/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 email(??) 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 email 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 email 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 email on 13-Мрт-09, 10:10 
Ладно, пример того почему надо шейпить входящий трафик... Клуб, на каждый комп приходить должно не более 128кбит, pf+altq(cbq) ограничивает только исходящий, а мне нужно и то и другое, и желательно в синхроне, ибо трафик не резиновый (на 10Мбитах... по мегабайт-но)... Скажи те чем по вашему порезать канал для каждого ИПа в сети ?????

Я НИКОГО НЕ ОБСУЖДАЮ, но если нет инструментария то и говорить не очем, просто так и напишите что АЛЬТКУ не способен резать входящий канал.... А НЕ РАЗВОДИТЕ ДЕМАГОГИЮ по поводу ПОЧЕМУ !!!!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру