Squid: ограничиваем скорость


Возможностей у Squid настолько много, что разработчики часто даже не успевают их подробно описывать. Общая настройка, как правило, проблем не вызывает, сложности начинаются, когда необходимо настроить ограничения на использование канала, организовать доступ к прокси при помощи внешних средств или выбрать программу для работы с журналами.

Ситуация, когда один канал нужно справедливо разделить между пользователями, отнюдь не редкость. В Squid регулировка пропускной способности канала производится при помощи пулов. За настройки отвечает группа параметров “Delay Pools“. Большинство параметров этой секции требуют компиляции squid с опцией ‘–enable-delay-pools‘. По умолчанию так и есть. Узнать параметры сборки установленного Squid, можно введя команду «squid –v».

Принцип ограничения скорости прост. Каждый запрашиваемый объект сначала попадает в буфер, а только затем передается клиенту. Каждый пул определяется двумя параметрами: скоростью его заполнения и размером буфера. Если объем данных меньше размера буфера, то клиент получает их с максимальной скоростью, но при достижении лимита информация будет выдаваться в соответствии с установками. По мере опустошения пула Squid будет получать остальную часть запрашиваемой информации.

Скорость заполнения пула зависит от класса. Для каждого пула при помощи delay_class должен быть установлен один из пяти классов (до версии 2.6 - один из трех):

1 – ограничения действительны для всех;
2 – действуют общие ограничения, плюс индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса);
3 - действуют общие ограничения, плюс индивидуальные ограничения для сетей (биты 17 - 24) и отдельных хостов (биты 17 - 32);
4 – все, что определено в классе 3, плюс введены ограничения для конкретного пользователя;
5 – запросы группируются в соответствии с их тегами, определенными при помощи external_acl.

Отсюда можно сделать вывод, что чем выше класс, тем через большее количество ограничений проходит соединение. Так для четвертого класса сначала действуют общие ограничения, затем ограничения подсети, отдельного узла и, наконец, для пользователя. То есть не стоит ожидать, что пользователь получит четко прописанную часть канала, если его подсеть выбрала свой лимит.

Класс для пула задается при помощи параметра delay_class, аргументами которого являются номер пула и номер класса. Количество пулов задается параметром delay_pools. Например, создадим два пула и определим для каждого из них свой класс. Для этого прописываем в squid.conf следующие строки:

$ sudo vim /etc/squid/squid.conf
# Задаем списки доступа, по которым будем распределять юзеров по пулам
acl office src 192.168.1.0/24
acl office2 src 192.168.2.0/24
acl user src 192.168.1.20/32
acl boss src 192.168.1.12/32

delay_pools 2 # 2 пула
delay_class 1 2 # пул 1, класс 2
delay_class 2 3 # пул 2, класс 3

Принадлежность пользователей к пулу задается при помощи delay_access, его синтаксис напоминает http_access:

delay_access pool allow/deny ACL

Поиск пула для конкретного адреса будет происходить только до первого совпадения, поэтому при объявлении пулов необходимо соблюдать нужный порядок. В одной строке следует использовать только один ACL, если прописать их несколько, в пул попадет только первый. Также как и в http_access, чтобы в него не попал “лишний” адрес, каждый пул следует закрывать при помощи конструкции deny all.

delay_access 1 allow office
delay_access 1 allow user
delay_access 1 deny all
delay_access 2 allow office2
delay_access 2 allow boss
delay_access 2 deny all
http_access allow office office2 boss user
http_access deny all

В первый пул включены клиенты, описанные в ACL office и user, во второй - office2 и boss. Следует помнить, что ACL, не указанные в delay_access, будут выходить в Сеть без ограничений. Далее при помощи delay_parameters задаем ограничения по скорости для каждого пула. В зависимости от класса пула количество аргументов будет различным. Так для четвертого класса полный формат записи выглядит так:

delay_parameters пул общий сеть индивидуальный_пользователь

Соответственно, в третьем классе не используется последний аргумент, а во втором отсутствуют “сеть” и “пользователь”. Количество пар должно соответствовать классу, если что-то пропустить, сквид откажется работать. Ограничения на каждой из позиций состоят из пары скорость_заполнения/объем_пула. Но значения здесь указываются в байтах, а скорость провайдеры считают в битах. В позициях, в которых нет ограничений, устанавливаем -1:

delay_parameters 1 16000/16000 8000/8000
delay_parameters 2 32000/32000 -1/-1 16000/16000

То есть для первого пула установлено общее ограничение в 128К и 64К для индивидуального адреса. Для второго общее ограничение – 256К, лимита на подсеть нет, но есть установка для отдельного IP-адреса. Для каждого пула должна быть только одна строка delay_parameters.

Используя различные типы acl, можно ввести ограничения по времени, протоколам, типу файлов и др. Например, при помощи такой конструкции легко ограничить скорость любителям качать мультимедиа:

acl multimedia urlpath_regex -i .mp3$ .mpeg$ .avi$
delay_pools 3
delay_class 3 1
delay_access 3 allow multimedia
delay_access 3 deny all
delay_parameters 3 8000/8000

Теперь при закачке файлов указанных типов скорость выше 64 кбит подниматься не будет. Аналогично устанавливаются ограничения по времени. Например, чтобы уменьшить для всех пользователей скорость до 32 кбит в рабочее время, применяем следующее правило:

acl work_hours time M T W T F 9:00-18:00
delay_class 4 2
delay_access 4 allow work_hours
delay_access 4 deny all
delay_parameters 4 -1/-1 4000/4000

Таким же образом настраиваются ограничения по протоколам, адресам и другим типам ACL, поддерживаемым Squid. Но чтобы правила работали правильно, их следует располагать в том порядке, в котором они должны применяться. Например, если одним пользователям устанавливаются ограничения по адресу, а другим по времени, то сначала следует прописать пул для первых, а затем для вторых. Здесь нужно быть очень внимательным.

http://system-administrators.info/?p=2471

Обновлено: 13.03.2015