Деление канала почти по честному
-
Дело в том, что каждая очередь есть канал, а каждое правило загоняет указанные IP в одну указанную очередь. Если делать диапазон в правиле, то все хосты из указанного диапазона будут делить одну очередь/полосу между собой
-
А имеет ли какое нибудь значение место правила в очереди? Вверху оно находится, внизу и.т.д???
-
А имеет ли какое нибудь значение место правила в очереди? Вверху оно находится, внизу и.т.д???
Эээ Срабатывает первое подходящее правило по списку, поэтому важно быть уверенным, что какое-либо вышестоящее правило не перекроет ваше. И еще - ДНС и ICMP загоните в очередь с высоким приортетом - ширина очереди 1-3% от ширины канала
-
Ну про DNS ясно, а зачем ICMP загонять в очередь с высоким приоритетом?
-
Ну про DNS ясно, а зачем ICMP загонять в очередь с высоким приоритетом?
Точно сказать - хызы, но воде как этот протокол относится к служебным, и поэтому лучше всего обеспечить его приоритетом повыше. По крайней мере такие рекомендации встречаются довольно часто.
-
Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум. ???
-
Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум. ???
Смотри Firewall Rules - там есть такая опция ' количество подключений-сессий с одного IP адреса'.
Но опять-же, это если вы не используете сквид как прокси. А в сквиде есть свой шейпер per/IP и тротлинг указанных расширений(то есть ограничение скорости закачек для определенных типов файлов) -
Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум. ???
Колличество сессий ограничить довольно просто, если используешь веб-конфигуратор, то go to Firewall > Rules. Нажми "edit rule" для интересующего тебя разрешающего правила, далее "Advanced Options", там всплывет несколько настроек:
Simultaneous client connection limit - ограничивает количество соединений с одного IP-адреса.
Maximum state entries per host - Максимальное количество записей в таблице состояний созданных данным правилом (опять же per ip)
Maximum new connections / per second - колличество новых соединений в одну секнду.
State Timeout in seconds - Время, через которое запись в таблице состояний удаляется, если передача данных м-у двумя узлами закончена, например TIME_WAIT:TIME_WAIT или CLOSING:ESTABLISHED.А вот со вторым правилом все немного сложнее, тут нужен шейпинг, iptables с наложенным patch-o-matic это умеет, а вот pf+altq наверно нет, хотя…
-
Даааа… Чем больше узнаёшь тем меньше знаеш :-\ . Ну а какие нибудь усреднённые значения для ограничения сессий есть(сколько с одного адреса, и. т. д.)? Или может какой нибудь мануал на эту тему (желательно мануал, что не тупо скопировать, а разобратся ;D)
-
Даааа… Чем больше узнаёшь тем меньше знаеш :-\ . Ну а какие нибудь усреднённые значения для ограничения сессий есть(сколько с одного адреса, и. т. д.)? Или может какой нибудь мануал на эту тему (желательно мануал, что не тупо скопировать, а разобратся ;D)
А что не понятного? Делаешь на лане правило разрешения
LAN | TCP | LanIP:anyPORT > anyIP:80
и указываешь, например,
Simultaneous client connection limit = 10 -
Да в принципе понятно. Только какая именно разница будет между 10 и допустим 100 сессиями? (как они вобще на канал влияют). В Traffic Inspector выставлял и 50 и 10 и 500 сессий особых различий не заметил.
-
Да в принципе понятно. Только какая именно разница будет между 10 и допустим 100 сессиями? (как они вобще на канал влияют). В Traffic Inspector выставлял и 50 и 10 и 500 сессий особых различий не заметил.
Ну тут ты не прав, у меня на шлюзе внешний канал 1 gb/s, некоторые юзверы умудряются тянуть с торрента аж в 20000 потоков ) Я первый раз увидел, у меня чуть глаз не выпал ) Так что тут хочешь не хочешь, приходится ограничивать колличество сессий.
Да и на TI это нормально работает, сам проверял. Т.е. ставишь 100 соединений пер ип, запускаешь торрент, открывешь несколько вкладок в браузере, и все, сервер блокирует все новые попытки соедениться. -
Ну а для нормального веб серфинга сколько сессий рекомендуется разрешить?
-
Да мне кажется ты не туда смотришь, т.е. твоя цель в чем? Поровну поделить канал между пользователями, т.е. если wan=512 кбит/c, если лезет один пользователь, отдать ему 512, если 2, то поделить поровну (256 + 256), и не важно сколько у них сессий, 100 у первого и одна у второго.
Если так, то Pf+altq тебе не поможет.А вообще смотри сам, скажем для серфинга 30 сессий за глаза, лично для меня. А лучше всего эксперементируй и слушай отзывы потребителей, так найдешь золотую середину.
-
Нашёл: 1)TCP-сессия - это соединение, которое устанавливается с Вашим провайдером при попытке доступа к какому-либо объекту в Интернет. Например, при открытии браузером некоторой странички, будут открыты сессии, во-первых, для выкачивания структуры страницы, во-вторых для выкачивания всех объектов, находящихся на этой страничке (рисунки, скрипты, приложения, java-апплеты и т.д.). Однако, из-за малого размера каждого объекта, сессии в данном случае будут быстротечны, поэтому даже для открытия странички, очень загруженной различными обектами, достаточно 3 - 5 сессий. Действительно при открытии нескольких окон браузера существует вероятность занятия всего лимита сессий, однако данная ситуация весьма кратковременна, и не особо заметна. Другое дело, если Вы выкачиваете файл. В данном случае сессия занята длительное время (столько, сколько нужно, чтобы выкачать файл). Количество сессий соответствует числу выкачиваемых файлов, вот здесь и существует опасность занятия всего канала. Теперь более менее понятно куда копать ;D
-
Молодцом! Но теме "Деление канала почти по честному" не соответствует. :)
-
Ну и последний вопрос по приоритетам - какой выше 0 или 7 ?
-
0 - min
7 - max