Squid delay pools не работает

• delay_pools — не работает, Andrey Mitrofanov, 13:05 , 11-Авг-11, ( 1 )
  • delay_pools — не работает, stakado, 13:25 , 11-Авг-11, ( 2 )
    • delay_pools — не работает, sherlock, 13:56 , 11-Авг-11, ( 3 )
      • delay_pools — не работает, stakado, 15:03 , 11-Авг-11, ( 4 )
        • delay_pools — не работает, sherlock, 06:02 , 12-Авг-11, ( 5 )

>> Драсьте!
>> Возникла необходимость ограничить скорость пользователям, для этого решил воспользоваться
>> delay_pools. Вроде делаю всё правильно, но отчего-то не работает, вот выдержка
>> из конфига (конфиг эксперементальный):
> Делай сквиду restart, а не reconfigure. Бага сквида, объявленная (в ФАК-е, кажется)
> фичейф: если делаешь reconfigure, то delay_pool-ы больше не работают.
>> delay_access 1 allow it
>> Фильм качается со скоростью около 10 мбайт/сек — т.е. ограничение скорости не
>> работает.

Уже почитавши форум стал делать restart, до этого делал reload.
Ща экспериментировал и заметил странную вещь: если в конфиге указать:
delay_parameters 1 5000/5000 — качает со скоростью чуть более 5 мб/сек
если же указать delay_parameters 1 2000/2000 — качает со скоростью чуть менее 2 кб/с.

Что же я делаю не так?

>[оверквотинг удален]
>> фичейф: если делаешь reconfigure, то delay_pool-ы больше не работают.
>>> delay_access 1 allow it
>>> Фильм качается со скоростью около 10 мбайт/сек — т.е. ограничение скорости не
>>> работает.
> Уже почитавши форум стал делать restart, до этого делал reload.
> Ща экспериментировал и заметил странную вещь: если в конфиге указать:
> delay_parameters 1 5000/5000 — качает со скоростью чуть более 5 мб/сек
> если же указать delay_parameters 1 2000/2000 — качает со скоростью чуть менее
> 2 кб/с.
> Что же я делаю не так?

У Вас пересекающие группы, группа IT еще и попадает в LAN
попробуйте переписать так:

delay_access 2 allow lan !it

я конечно не уверен в механизме, но не исключено, что механизм работы такой:
проверяются права доступа в 1 пул, отрабатывается, урезается скорость, потом проверяются права доступа во 2-ой пул, опаньки, IT снова в него попали, им переназначается скорость. Проверьте.

> У Вас пересекающие группы, группа IT еще и попадает в LAN
> попробуйте переписать так:
> delay_access 2 allow lan !it
> я конечно не уверен в механизме, но не исключено, что механизм работы
> такой:
> проверяются права доступа в 1 пул, отрабатывается, урезается скорость, потом проверяются
> права доступа во 2-ой пул, опаньки, IT снова в него попали,
> им переназначается скорость. Проверьте.

Сделал так — ничего не изменилось.

Возможно я где-то в другом месте накосячил — привожу свой конфиг полностью:
[root@gtw new_router]# cat /etc/squid/squid.conf
# Recommended settings
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
acl Apache rep_header Server ^Apache
broken_vary_encoding allow apache
cache_mem 32 MB
ftp_passive off
refresh_pattern ^ftp: &n. 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
coredump_dir /var/spool/squid

# // My changes
http_port 3128
cache_mgr stakado@polymer
cache_dir ufs /home/services/squid 5000 32 512
access_log /var/log/squid/access.log squid

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

# ACL: общие
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8

# ACL: подразделения
acl lan src 10.0.0.0/24
acl wifi src 10.0.1.0/24
acl admin src 10.0.0.2/255.255.255.255
acl it src 10.0.0.2/255.255.255.255 10.0.0.13/255.255.255.255 10.0.0.23/255.255.255.255
acl mts src 10.0.0.3/255.255.255.255 10.0.0.6/255.255.255.255 10.0.0.11/255.255.255.255
acl otk src 10.0.0.20/255.255.255.255
acl medics src 10.0.0.30/255.255.255.255
acl pushers src 10.0.0.8/255.255.255.255
acl servers-bux src 10.20.0.0/255.255.255.0

# ACL: время
acl tubes-time time MTWHF 08:00-12:20
acl tubes-time time MTWHF 13:50-17:00

acl all_traffic url_regex .*
acl local_httpd url_regex ^http://service\.polymer

# Онлайн видео
acl tubes-mime rep_mime_type -i video/*
acl tubes url_regex -i youtube\.com
acl tubes url_regex -i rutube\.ru
acl tubes url_regex -i tv-tube\.ru
acl tubes url_regex -i vkadre\.ru

# ACL: Списки
acl fileshares url_regex ‘/etc/squid/lists/fileshares.list’
acl counters url_regex ‘/etc/squid/lists/counters.list’
acl porno url_regex ‘/etc/squid/lists/porn.list’
acl various url_regex ‘/etc/squid/lists/various.list’
acl socialnets url_regex ‘/etc/squid/lists/socialnets.list’

# ACL: порты и методы установки соединений
acl CONNECT method CONNECT
acl HEAD method HEAD

acl SSL_ports port 443 563

acl Safe_ports port 80 # http
acl Safe_ports port 9009 # turbobit
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 8080 # other http

delay_pools 2
delay_class 1 1
delay_class 2 1
delay_access 1 allow it
delay_access 1 deny all
delay_access 2 allow lan !it
delay_access 2 deny all
delay_parameters 1 10000/10000
# delay_parameters 1 3000/3000
delay_parameters 2 -1/-1

# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Общие правила доступа
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow lan local_httpd
http_access allow wifi local_httpd

# Запрет на просмотр видео
http_access deny lan !it tubes-time tubes
deny_info http://service.polymer/tubes.html tubes
http_reply_access deny lan !it tubes-time tubes-mime
deny_info http://service.polymer/tubes.html tubes-mime

# Правила доступа по подразделениям
# Открыть доступ серверам 1С к база каспера и рбк (для скачивания 1С-ом базы кладр)
http_access allow servers-bux kav-bases
http_access allow servers-bux rbc

# Заблокировать счетчик на mail.ru Дену — иначе не печатаются письма
http_access deny pushers counters
deny_info http://service.polymer/1×1.gif counters

# Открыть доступ сети и фай-фаю
http_access allow lan
http_access allow wifi

# Закрыть доступ всем остальным
http_access deny all

# Default settings
icp_access allow all

Ну вроде все верно, а попробуйте еще такой вариант, использовать 2 класс, а не 1

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Хотел сделать данную статью завершающей о squid. Но не получилось. Будет еще Данная статья будет узкотематическая. В статье рассмотрю возможности ограничения скорости локальных клиентов, т.н. часто применяемое понятие delay pools. Начну с теории.

Как работает ограничение скорости (delay pools) в squid

Дословно, delay pools переводится как пул задержки. Почему он так переводится, потому что так и есть Пул с данными наполняется по мере расходования наполненного содержимого. При этом, если пул наполнен «до завязки», то squid задерживает поступление данных. Т.о. фактически, squid ограничивает не отдаваемую скорость, а ту скорость, с которой он наполняет пул. Для бОльшего понимания, давайте рассмотрим пул в качестве аналогии в виде дырявого ведра или бассейна. При этом, сверху ведра расположен squid, который заливает в ведро поток байтов из шланга определенного диаметра. Диаметр шланга — это некая аналогия ограничителя скорости. А снизу ведра/бассейна — локальные клиенты, которые «орашаются» потоком байтов через дыры в дне ведра. При этом, ведро имеет некоторый объем, который squid может наполнить байтами.

Когда клиент делает запрос на получение какого-либо объекта — прокси-серверу (будь то картинка, html страница или любой другой объект), squid сначала помещает/заливает данный объект в ведро (. очень спорное утверждение). Если объект больше объема ведра, то в ведро помещается его часть, только после наполнения ведра, объект отдается клиенту. (с какой скоростью происходит первичное наполнение?) По мере опустошения ведра клиентом, остаток объекта дозаливается. При этом, squid «ставит в очередь» поступающие данные и не посылает новые новые запросы удаленному серверу запрашиваемому сайту. Т.о. объем ведра определяет количество байтов, которые доступны клиенту на максимальной скорости, пока ведро не опустошится. После чего клиент получает данные, согласно диаметра шланга squid Так же, если объем запрашиваемого объекта меньше объема ведра, то клиент получает этот объект с максимальной скоростью (. тоже очень сомнительно). То есть с той скоростью, с которой клиент обменивается со squid (но не более диаметра шланга. ). При этом, данные ведра можно «каскадировать». Количество уровней каскадирования определяет класс пула.

После некоторого недопонимания работы squid, долгого чтения мануалов и практических опытов, показавших реальную схему работы, предыдущий абзац перефразирован в следующий вид:

Когда клиент делает запрос на получение какого-либо объекта — прокси-серверу (будь то картинка, html страница или любой другой объект), squid:

• отдает объект клиенту с максимальной скоростью (точнее со скоростью, с которой позволяет железо между клиентом и squid’ом) — если объект имеет статус *_HIT (то есть находится в кэше),
• либо с ограниченной скоростью (то есть со скоростью шланга) — если объект *_MISS (то есть не содержится в кэше/запрашивается у удаленного сервера).

Ну и естественно, объект со статусом *_MISS помещается в кэш (если это не запрещено правилами конфигурации), и следующий запрос к этому объекту будет как к кэшированному. Если клиент захлебывается и не успевает опустошить ведро, пока squid в него заливает, то squid ставит в очередь поступающие данные и не отправляет новые запросы удаленному серверу запрашиваемому сайту. По мере опустошения ведра клиентом, остаток объекта дозаливается. Т.о. объем ведра определяет сколько данных клиент может получить на максимальной скорости при условии, что эти данные кэшированы. При этом, данные вЁдер можно «каскадировать». Количество уровней каскадирования определяет класс пула.

ИМХО Видимо разработчик delay pools имел очень быстрый интернет и очень медленную локальную сеть. ))

Настройка delay pools

Параметры конфигурационного файла для настройки delay pools

Для реализации ограничения скорости в squid используются следующие параметры конфигурационного файла: acl, http_access, delay_pools, delay_access, delay_parameters, delay_class. C acl и http_access мы разобрались в предыдущих статьях о squid. В данном случае — они просто определяют кому (acl) в целом разрешен доступ (http_access) к прокси-серверу. А вот другие 4 параметра необходимо рассмотреть более подробно. Кроме того, данный функционал будет работать только если squid скомпилирован с ключом —enable-delay-pools.

Давайте разберем указанные параметры:

delay_pools количество

Параметр задает количество delay pools (количество ведер). Значение может быть от 0 (по-умолчанию) до бесконечности. Каждому ведру можно присоединить любое количество acl.

delay_class номер_пула класс_пула

Параметр определяет класс для каждого delay_pools ведра. В соответствии с заданным классом будут применяться некие параметры и «уровень каскадирования ведер» (сколько уровней ведер будет друг под другом). Существует несколько классов, которые я опишу ниже. У каждого класса существуют соответствующие ему настройки. Для каждого delay_pools задается единственный класс.

delay_access номер_пула allow|deny имя_acl

Параметр задает попадание (allow) или не попадание (deny) пользователей в заданный пул (номер_пула). Точнее сказать, задаются не пользователи, а те сущности, что заданы в acl. То есть можно ограничить скорость не только для пользователя, но и, например, к некоторому сайту, указав его как acl name dstdomain site. При этом, проверка принадлежности к данному классу происходит до первого совпадения. Если пользователь по какому-либо параметру совпадает с acl, и для него указано правило allow, то для него применяются параметры текущего пула, если задано правило deny, то на пользователя правило пула не применяются. Если запрос не попал ни в один delay pools то информация отправляется напрямую клиенту без задержек. Синтаксис использования данного параметра аналогичен http_access.

delay_parameters номер_пула параметры_пула

Устанавливает некоторые параметры (параметры_пула) для указанного пула (номер_пула). При этом, в зависимости от класса заданного номера_пула, параметры_пула — различаются. О параметрах я расскажу ниже, когда буду говорить о классах. Для одного delay pools может использоваться только один delay_parameters.

Классы delay pools

Прежде чем говорить о классах delay pools, давайте вспомним о структуре IP адресов. Для этого необходимо почитать статью Основы локальных сетей. И вспомнить, что маска подсети основывается на двоичных битах:

Собственно, для чего это вспоминать? для того, что squid управляя скоростью оперирует разграничениями на основе длинны битовой маски. То есть squid рассматривает хосты из 4 октета Ipv4-адреса (то есть с маской 255.255.255.0), а подсети squid рассматривает на основе маски 255.255.0.0. Так же, важно понимать, что при формировании delay_parameters скорость указывается в байтах, а не в бит ах (как измеряют скорость провайдеры). Мы ведь знаем, что 1 байт = 8 бит? )

Итак, классы пулов. delay_class позволяет задавать индивидуальные параметры скорости для сети/подсети/хоста/пользователя и кое-чего еще в зависимости от класса. Во второй версии squid существовало 3 класса, в третьей версии добавлено еще 2. Итого существуют следующие классы delay pools:

1. Класс 1 содержит ограничения для всех запросов, попадающих в пул. Единое ведро для всех сетей.
2. Класс имеет 2 ограничения: общие (аналогично первому классу), плюс индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса IPv4). Единое ведро для всех сетей, которое «орошает» находящееся «под ним» 255 ведер для хостов.
3. Класс имеет 3 ограничения: общие, индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса IPv4) (аналогично первому классу). Плюс между ними вклиниваются ограничения для сетей подсетей (биты 17 – 32 сетевого адреса IPv4). Единое ведро для всех сетей, которое «орошает» находящееся «под ним» 255 ведер для подсетей, которые, в свою очередь, каждое из 255 подсетей «орошает» находящееся «под ним» 255 ведер для хостов.
4. Класс имеет 4 ограничения: все, что определено в классе 3, плюс добавлены ограничения для конкретного авторизованного пользователя. Единое ведро для всех сетей, которое «орошает» находящееся «под ним» 255 ведер для подсетей, которые, в свою очередь, каждое из 255 подсетей «орошает» находящееся «под ним» 255 ведер для хостов, которые, в свою очередь, каждое из 255 хостов «орашает» n-ведер для каждого авторизованного пользователя.
5. Класс имеет единственное ограничение: запросы обрабатываются в соответствии с заданным тегом, который присвоен при помощи external_acl. Единое ведро для всех запросов, отмеченных заданным тегом в списке доступа external_acl.

ПРИМЕЧАНИЕ: Если IP адрес представить как a.b.c.d, то:

-> биты с 25 по 32 это класс «d»
-> биты с 17 по 24 это класс «c»
-> биты с 17 по 32 это «c * 256 + d»

ПРИМЕЧАНИЕ 2: Из-за использования битовых масок IPv4 в классах 2,3,4, данные классы не применимы к Ipv6 трафику. классы 1 и 5 могут использоваться для IPv6.

Задание параметров (delay_parameters) для разных классов пулов (delay_class)

Как я уже говорил, для каждого класса могут быть заданы определенные наборы параметров, которые в целом похожи друг на друга. Параметры для классов 1,2,3,4 можно задать вот такой схемой:

delay_parameters pool total_rest/total_max net_rest/net_max ind_rest/ind_max usr_rest/usr_max

• pool — номер пула, для которого определяются параметры;
• total — ширина канала на всех. Задает диаметр шланга для ведра 1 класса.
• net — ширина канала на подсеть. Задает диаметр шланга для каждого (из 255) ведер подсетей, используется в классе 3,4.
• ind — ширина канала на отдельный адрес. Задает диаметр шланга для каждого из 255 хостов, используется в классах 2,3,4.
• usr — ширина канала на отдельного авторизованного пользователя. Задает диаметр шланга для ведра для каждого авторизованного пользователя в классе 4.
• rest — скорость заполнения (байт/с)/диаметр шланга (значение -1 определяет отсутствие ограничений).
• max — объем ведра (байт), максимальный объем заполненности ведра.

Соответственно, первый класс будет содержать только delay_parameters pool total_rest/total_max, второй — delay_parameters pool total_rest/total_max ind_rest/ind_max, третий — delay_parameters pool total_rest/total_max net_rest/net_max ind_rest/ind_max, четвертый — все указанные параметры.

Примеры delay pools

Работа по настройке delay pools заключается в следовании по следующим шагам:

• создаем acl и соответствующее http_access разрешение для доступа пользователя(ей) к squid
• задаем количество пулов, к которым будем присоединять соответствующие acl параметром delay_pools
• задаем каждому пулу свой класс параметром delay_class
• задаем каждому пулу задаем свои параметры через delay_parameters
• задаем каждому пулу, кто или что в него будет попадать через delay_access

Давайте начнем с простого примера. Предположим, у нас есть некоторое соединение с интернет в 1 Мбит/с, при этом, нам нужно выделить на squid только 512 Кбит/с, чтобы остальная часть канала была отдана под другие сервисы. Для данной задачи нам подойдет пул класса 1:

У данной схемы есть следующий недостаток: некоторые пользователи могут получить гораздо больше скорости, чем остальные. Чтобы избавиться от данной проблемы, можно использовать пул 2 класса. При этом, если у вас сеть больше размера /24, то есть в вашей сети более 255 хостов, то можно использовать пул 3 класса вместо 2 класса. Класс 3 позволяет ограничить скорость для 65536 хостов (255 подсетей * 255 хостов в этих подсетях). Давайте к прошлому примеру ограничим хосты скоростью в 64Кбит/с. При этом, избранных пользователей направим на пул с более высокой скоростью в 256 Кбит/с:

Хочу обратить внимание на слово «традиционно». Я так написал, потому что синтаксис delay_access аналогичен http_access и по умолчанию используется правило, противоположное последнему. Поэтому традиционно доступ к пулам, к которым применяются «избранные» пользователи завершают запрещающим правилом для всех — delay_access deny all.

Так же, хочу отметить, что в настоящее время смысл устанавливать объем ведра максимальный размер пула, то есть значения total_max, net_ma, ind_max, usr_max, имеет очень спорны характер. Т.к. современные сайты содержат в большинстве своем некэшируемый контент (js, php и др.), поэтому запрашивается напрямую с удаленного сервера. Соответственно, локальному клиенту он отдается со скоростью, заданной в delay_parameters. Хотя в сети много почти все мануалы уверенно утверждают, что если мы зададим объем ведра, то данный объем клиент получит на максимальной скорости интернета. Это, имхо, неверно!

Ограничения delay pools и нюансы работы

У технологии delay pools есть некоторые ограничения в работе, которые нужно учитывать при конфигурировании. Предположим, у нас есть вот такой конфиг:

Данные правила задают скорость 15000 байт/с круглосуточно и 12000 байт/с с 10 до 13 часов. При данном конфиге, если пользователь в 09.59 начал закачку какого-то большого объекта, то он его докачает со скоростью 15000 байт/с и в 10.00 скорость закачки не понизится. То есть если соединение уже было создано, то delay pool его не закрывает и не режет. delay pools отрабатывает при создании сессии.

Многие в сети называют технологию delay pools, как честный дележ канала, но на самом деле честностью тут и не пахнет и понятие честности тут весьма условно. Это выражается в том, например, что если у нас есть некий пул первого класса, в котором работают большое количество клиентов, то некоторому жадному клиенту ничто не мешает занять весь канал, не давая работать другим. Аналогично это правило и для всех остальных классов. Эту особенность в большей степени важно учитывать при задании диаметров «шлангов» для общих ограничений, например, всей сети (где уровень честности понижается), и в меньшей степени для индивидуальных пулов (где управлять «честностью» можно более гибко).

Когда запрос проходит через каскад пулов, то конечная скорость рассчитывается с учетом ограничений всех пулов. Например, рассмотрим пул 3 класса в котором заданы ограничения для всех, для подсетей и для отдельных хостов. Даже если ограничения хоста 20 Кбайт/с, а у подсети 30 Кбайт/с и при этом, у пуля для всех установлен лимит шланга в 2 Кбайта/с, то конечный клиент получит именно 2 Кбайта/с. Даже с учетом, что у некоторых пулов есть довольно большой ресурс трафика, клиент будет ограничен самым маленьким лимитом.

Так же, стоит учитывать, что устанавливаемые ограничения скорости действуют только на фактически переданные клиенту и не включают технические данные (например TCP, ICP, DNS и др.)

Резюме

Итого, в статье я рассмотрел возможности squid ограничивать скорость с помощью т.н. технологии delay_pools. Это мое понимание данного вопроса и я был бы рад, если кто-то из читателей сделал дельное дополнение в комментариях. В статье я не рассмотрел параметр delay_initial_bucket_level, смысл которого мне до сих пор не понятен. А так же не рассмотрел пул 5 класса, т.к. данный класс использует external_acl’s tag= в котором я тоже не смог разобраться Для большинства реализаций вполне достаточно классов с 1 по 3. Надеюсь, что изложил я свои мысли понятно и буду рад комментариям.

Источник