Ограничение скорости Интернет для разных категорий пользователей на прокси-сервере Squid (Delay pools)

В процессе использования прокси-сервера Squid при большом количестве пользователей и относительно небольшой пропускной способности каналов предоставленных интернет-провайдерами может возникнуть потребность ограничить пропускную способность доступа в интернет разным категориям пользователей. Один из основных механизмов позволяющих реализовать такие ограничения в Squid является механизм пулов задержки - Delay pools. Пулы задержки позволяют ограничить скорость получаемого прокси-сервером интернет-трафика в зависимости от разных условий, например в зависимости от того, какой пользователь запрашивает этот трафик. В конфигурации Squid по умолчанию механизм пулов задержки выключен, и поэтому при доступе к прокси-серверу между клиентами используется простая конкуренция по принципу “кто первый встал, того и тапки”.

Как примерно я понимаю работу Squid в конфигурации с включёнными пулами задержки:
- клиент запрашивает с прокси-сервера какой-либо http-объект;
- в случае если запрашиваемый объект есть в кэше Squid (статус TCP_HIT в access.log), то прокси-сервер отдает этот объект клиенту на максимальной скорости
- в случае если запрашиваемого объекта нет в кэше (статусы TCP_MISS, TCP_TUNNEL и другие в access.log), то прокси-сервер отдает этот объект клиенту с ограничениями настроенными в пулах задержки.

Далее мы рассмотрим простейший пример применения пулов задержки. В рассматриваемом примере будет использоваться три категории пользователей, для каждой из которых будет задано ограничение максимальной скорости интернет:
- Первая категория будет определять трудновоспитуемых пользователей, у которых большую часть интернет-трафика можно классифицировать как, мягко говоря, непрофильный. Эта категория будет иметь самую низкую скорость доступа в интернет;
- Вторая категория – это стандартные пользователи с ограничением скорости позволяющим выполнять более или менее комфортный интернет-серфинг;
- Третья категория – пользователи с повышенной границей пропускной способности в рабочее время и без ограничений в нерабочее время. 

Для начала убедимся в том, что Squid собран с поддержкой Delay pools

squid3 -v

Squid Cache: Version 3.5.4
Service Name: squid
configure options:
...
 '--enable-delay-pools'
...

***

Категоризацию пользователей мы будем выполнять на основе групп безопасности в домене Active Directory. Соответственно предварительно нам нужно создать эти группы доступа. К ранее описанной группе KOM-Internet-Standard, которая будет у нас определять рядовых пользователей, добавляем ещё две группы: KOM-Internet-Standard-Fast и KOM-Internet-Standard-Slow

Чтобы правила распределения пропускной способности для разных категорий пользователей работали правильно, необходимо чтобы членство в группах было взаимоисключающим, то есть если пользователь добавляется в одну группу (например KOM-Internet-Standard-Fast), то его нужно исключить из других групп (KOM-Internet-Standard и KOM-Internet-Standard-Slow).
Не забываем включить эти группы в группу KOM-Internet-AllUsers, которая используется для объединения всех пользователей для компонент отчетности.

Создадим вспомогательные конфигурационные файлы (предполагается, что файл conf_param_groups_standard уже был создан нами ранее)

sudo sh -c "echo 'KOM-Internet-Standard-Fast' > /etc/squid3/conf_param_groups_standard_fast.txt"
sudo sh -c "echo 'KOM-Internet-Standard-Slow' > /etc/squid3/conf_param_groups_standard_slow.txt"

Открываем на редактирование файл конфигурации Squid

sudo nano -Y sh /etc/squid3/squid.conf

Определяемся c ACL:

...
acl localnet src 10.0.0.0/8
acl WorkingTime time 08:00-18:00
acl StandardAccessFast  external memberof "/etc/squid3/conf_param_groups_standard_fast.txt"
acl StandardAccess      external memberof "/etc/squid3/conf_param_groups_standard.txt"
acl StandardAccessSlow  external memberof "/etc/squid3/conf_param_groups_standard_slow.txt"
...
http_access allow StandardAccessFast auth localnet
http_access allow StandardAccess auth localnet
http_access allow StandardAccessSlow auth localnet
#
http_access deny all
...

Определяемся сколько пулов будем использовать, исходя из количества категорий, на которые будут поделены все пользователи. Например 3 пула – 1 (быстрый), 2 (стандартные ограничения), 3 (медленный).

...
delay_pools 3
...

Для каждого пула нужно назначить класс.

В текущей версии Squid есть 5 классов и их определения можно найти в squid.conf. Я истолковал для себя эти классы следующим образом:

Указываем отдельной строчкой классы для каждого из пулов по порядку в вид:
delay_class <номер пула> <класс>

...
delay_class 1 2 # fast pool
delay_class 2 2 # standard pool
delay_class 3 2 # slow pool 
...

Для каждого пула зададим параметры ограничения с помощью тэга delay_parameters. Состав этих параметров зависит от выбранного ранее класса для каждого из пулов. Информацию о том, какие параметры могут задаваться для пулов в зависимости от классов можно также найти в squid.conf

Вид записей delay_parameters в зависимости от класса пула должен иметь следующий вид: 

Каждое из ограничений записывается в виде пары значений в формате restore/maximum, где restore - количество байт/сек. клиентских запросов которые могут поступать в пул, а maximum это максимально возможное количество байт/сек. которые способен обработать пул в одну единицу времени, то есть его возможная ёмкость. Если какое-либо из ограничений не требуется, то соответствующая пара значений заменяется ключевым словом “none”.

Рассчитаем параметры

Предположим, имеется заявленная интернет-провайдером скорость канала в 12 Mбит/с. Часть канала в качестве резерва оставляем под задачи отличные от Squid (1 Мбит/с). Поэтому далее отталкиваемся от условия что на Squid выделяется 11 Мбит/с. Распределяем гарантированную пропускную способность между пулами, например так:

Пул 1 - 3 Мбит/с - 3 000 000 Бит/с = 375 000 Байт/с.
Пул 2 - 8 Мбит/с - 8 000 000 Бит/с = 1 000 000 Байт/с
Пул 3 - не будет иметь гарантированной пропускной способности.

...
delay_parameters 1 375000/375000		   # 3 Mbit/sec for all
delay_parameters 2 1000000/1000000 25000/25000   # 8 Mbit/sec for all and maximum 200 Kbit/sec for one
delay_parameters 3 none 6250/6250		   # maximum 50 Kbit/sec for one
...

Для первого пула мы гарантируем скорость в 3 Mбит/с с простой конкуренцией между участниками пула. Каждый из участников этого пула может занять до 3 Mбит/с, если полоса пропускания не занята другими участниками пула.

Для второго пула мы гарантируем скорость в 7 Mбит/с. При этом, с учётом среднего количества одновременно работающих с прокси пользователей, например в 50, каждый из участников пула сможет использовать не более 200 Кбит/с.

Для третьего пула мы не будем ограничивать общую пропускную способность, но ограничим скорость доступа для одного участника пула до 50 Кбит/с

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

Другой вариант определения параметров пулов, при котором нет общих ограничений для отдельных пулов, но есть чёткие ограничения для каждого клиента в каждом из пулов:

...
delay_parameters 1 none none 112500/112500 #maximum 900 Kbit/sec for one user
delay_parameters 2 none none 75000/75000 #maximum 600 Kbit/sec for one user
delay_parameters 3 none none 50000/50000 #maximum 400 Kbit/sec for one user
...

Далее определяем доступ к пулам с использованием ранее заданных ACL. Тэг delay_access, по аналогии с тэгом http_access позволяет определить попадание пользователей в тот или иной пул, на основе ACL:

...
delay_access 1 allow StandardAccessFast WorkingTime
delay_access 2 allow StandardAccess
delay_access 3 allow StandardAccessSlow
...

В нашем примере для первого пула используется дополнительный ACL WorkingTime, который означает то, что ограничение скорости действует лишь в указанный интервал времени суток (в остальное время ограничения не используются).

Проверка попадания в пул идет по порядку с пула 1, затем 2, … и т.д. до пула N. После первого же попадания в пул дальнейшие правила delay_access пропускаются. Если проверка всех правил не определяет запрос клиента ни к одному пулу, то запрос клиента идёт напрямую без каких-либо задержек.

***

После настройки squid.conf проверяем не допустили ли мы явных синтаксических ошибок:

sudo squid3 -k parse

Применяем новую конфигурацию:

sudo squid3 -k reconfigure

***

Проверить результат работы ограничений скорости работы Интернет на клиентах можно с помощью всевозможных онлайн-тестов, таких как, например http://www.speedtest.net/ru/

Дополнительные источники информации:

Блог любителя экспериментов - squid, настройка delay pools