Доброе время суток
накопилось несколько вопросов
Подскажите пожалуйста новичкусистема FreeBSD 7.0 Squid 3.0
1. за что отвечает параметр auth_param basic credentialsttl 2 hours
если я правильно понял через 2 часа пользователю необходимо будет перерегистрироваться чтобы иметь доступ в интернет
если да то как снять ограничения на время действия сессии2. как ограничить пользователям доступ к закачке c torrent серверов
заранее спасибо за разяснения
>
>2. как ограничить пользователям доступ к закачке c torrent серверов
>вопрос снимается
не совсем правильно тестироавал соеденения
сейчас с настройками по умолчанию торент через прокси не работаетно возник другой вопрос
правильно ли я понимаю
delay_parameters 1 32000/64000 10000/10000000
ограничивает скорость закачки на подсеть 64к и для локального пользователя 32к
а также при закачке пользователем файла больше 10м скорость закачки падает до 10к
>правильно ли я понимаю
>delay_parameters 1 32000/64000 10000/10000000
>ограничивает скорость закачки на подсеть 64к и для локального пользователя 32к
>а также при закачке пользователем файла больше 10м скорость закачки падает до
>10кНет, неправильно. Указанная конфигурация вообще мало осмысленна.
Запись вида ХХХ/УУУ означает: буфер(бакет) размером УУУ байт, отдача из которого ведется на скорости ХХХ байт/сек.
Бакет первоначально заполняется на максимально возможной скорости, но клиенту отдается все равно не быстрее скорости ХХХ. По мере опорожнения бакета клиентом, он с той же скоростью доливается из инета. Если бакет аггрегированный (класса 2 или 3), то доливание опорожняющегося бакета ведется согласно политики WF2Q+ - равномерно для всех клиентов, использующих общий бакет. Равномерность работы политики деления бакета между клиентами тем лучше, чем больше бакет вмещает пакетов, предназначенных для разных клиентов.
В случае пула 2 класса вида (AA/BB CC/DD) создается один общий бакет размером DD, и столько индивидуальных бакетов размера ВВ, сколько юзеров будут загнаны в данный пул. Пакеты из общего бакета будут отдаваться в индивидуальные бакеты на скорости, не большей СС, а оттуда клиентам - на скорости, не большей АА. Если СС меньше АА, то образуется боттлнек, и скорость будет не выше СС - при условии одного пользователя коллективного пула. Логичнее уж задавать параметры, как -1/ВВ СС/DD
В случае пула третьего класса вида (AA/BB CC/DD EE/FF), будет создан один общий бакет размером FF, N бакетов размера DD, где N - количество сетей класса С использующих данный пул, и М бакетов размера BB, где М - количество индивидуальных пользователей данного пула.
Поэтому нужно производить расчет размеров памяти, необходимой для функционирования делей-пулов.
(DD + M*BB) для второго класса и (FF + N*DD + M*BB) для третьего должно иметь разумный размер относительно объема ОЗУ.
Выбор же значения скоростей зависит от близости клиента к сердцу сисадмина и толщины канала. Тут есть простор для творчества. Размеры же бакетов следует делать максимально возможными при имеющихся мозгах.
Пардон, я все время забываю, что в конфиге сквида бакеты перечисляются в обратном порядке - от аггрегированного к индивидуальному, а не наоборот.Поэтому заменить
AA/BB CC/DD EE/FF на
EE/FF CC/DD AA/BB
Понимаю что туплю но всётаки
исходя из документаций найденых в интернете правило для ограничения скорости до AA при достижении BB выкаченного объёма -1/-1 AA/BB
или я всётаки чего то не понял
и реализовать схему когда пользователям раздаёться на определённой скорости а при попытке скачать файл большого объёма скорость ещё падала при помощи пулов нельзя ?и вообщем если не трудно рекомендации по настройке пула при внешнем канале 512 и порятка 10-15 машин в сети
заранее спасибо
>и реализовать схему когда пользователям раздаёться на определённой скорости а при попытке
>скачать файл большого объёма скорость ещё падала при помощи пулов нельзя ?Можно, но не очень просто.
Есть штатная директива MAX_REPLY_SIZE, но она только задает статически глобальный разрешенный размер объекта. Чтобы разбрасывать по разным пулам объекты разного размера, следует сделать внешний АЦЛ, которому будет передаваться хедер объекта с размером. В ответ внешний ацл будет возвращать Ok/Err (меньше-равно/больше)
external_acl_type RSIZE1M %{Hdr:Content-Length} /path/to/helper 1
external_acl_type RSIZE10M %{Hdr:Content-Length} /path/to/helper 10
external_acl_type RSIZE100M %{Hdr:Content-Length} /path/to/helper 100А потом сделать вот так:
delay_access 1 allow all RSIZE1M
delay_access 1 deny alldelay_access 2 allow all RSIZE10M
delay_access 2 deny alldelay_access 3 allow all RSIZE100M
delay_access 3 deny all
>и вообщем если не трудно рекомендации по настройке пула при внешнем канале
>512 и порятка 10-15 машин в сетиПри условии, что все машины в сети равноприоритетны, 512/10 = 50кбит или 6 кбайт на машину. Учитывая возможность мультиплексирования траффика с коэффициентом до 5-6, закладываем индивидуальному юзеру полосу в 24 кбайта. От полосы для прокси отрезаем 90%, чтобы юзеры не заткнули канал наглухо и не перекрыли возможность удаленного администрирования и хождения остальных протоколов. Пул будет выглядеть так:
delay_parameters 1 56000/5000000 24000/1000000
Т.е. один клиент отъедает не более 24кБайт/сек, все клиенты скопом - не более 56кБайт. Под эту музыку будет расходоваться 5Мб на аггрегированый бакет, и 10*1МБ на индивидуальные бакеты. На самом деле расход памяти будет еще больше - на вспомогательные структуры сквида. Но ориентироваться можно на эти 15-20 мегабайт, потребляемые только одним пулом. Если клиентов будет вдвое больше - расход ОЗУ тоже будет вдвое больше. Если клиентов мало, а мозгов много, то полезно увеличивать размер аггрегированого бакета - от этого траффик будет скользить мягко и плавно. В любом случае, его размер лучше делать в 1/3-1/2 от суммарного объема пользовательских бакетов.
В любом случае, на период настройки полезно отключить все фильтры на проксе, перевести себя в одну группу с простыми смертными, дать большую нагрузку и покрутить ручки, оценивая субъективную юзабельность канала.
>Понимаю что туплю но всётаки
>исходя из документаций найденых в интернете правило для ограничения скорости до AA
>при достижении BB выкаченного объёма -1/-1 AA/BB
>или я всётаки чего то не понялНа самом деле, штатная документация к сквиду описывает работу делей-пулов сквида совершенно неадекватно. И примеры конфигурации, которые даны даже в шаблонном конфиге, приводят к кривой работе делей-пулов.
В частности, политика WF2Q+, используемая для "справедливого" деления полосы между сессиями, крайне негативно реагирует на верхний порог пропускной способности больший, чем реальная полоса. А поскольку у нас канал еще используется под другие протоколы, указывая -1/Х, мы заведомо создаем проблемы для работы шейпера. Если траффик преимущественно уходит на прокси, то нужно явно отрезать 85-90% - не так для экономии канала, сколько для корректной работы самих пулов.
Во-вторых, во всех примерах указаны совершенно мизерные размеры бакетов, по недомыслию сделанные численно равными нарезаемым полосам. Вот пример из штатного окнфига сквида:
delay_parameters 2 32000/32000 8000/8000 600/8000
По образу и подобию этого примера сделаны все виденные мною чужие конфигурации
delay_parameters 2 АА/АА ВВ/ВВ СС/СС
В результате - тормоза, затыки и прочие глюки. Стоит увеличить индивидуальные бакеты до 100-500 кб, а аггрегированые - до 1/3 от суммы индивидуальных бакетов, как поведение сквида преображается.
Поэтому, запоминаем слова Генриха Мюллера, сказанные им Максу Штирлицу:
-- Верить, Штирлиц, нельзя никому! Мне - можно...