squid, настройка delay pools

13 апреля, 2012 Рубрики: Linux, SQUID, Настройка сервера Linux

настройка delay pools в squidХотел сделать данную статью завершающей о 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 ~ # ipcalc  192.168.0.1/24
Address:   192.168.0.1          11000000.10101000.00000000. 00000001
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.0.0/24       11000000.10101000.00000000. 00000000
HostMin:   192.168.0.1          11000000.10101000.00000000. 00000001
HostMax:   192.168.0.254        11000000.10101000.00000000. 11111110
Broadcast: 192.168.0.255        11000000.10101000.00000000. 11111111
Hosts/Net: 254                   Class C, Private Internet

Собственно, для чего это вспоминать? для того, что 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:

# зададим acl и разрешим доступ:
acl all src 0/0
http_access allow all
# создадим 1 пул
delay_pools 1
# зададим первому пулу первый класс
delay_class 1 1
# зададим первому пулу скорость 512 Кбит/с (= 512 Кбит/с / 8 = 64 КБайт/с = 64000 Байт/с)
# и размер пула в 50 Мбайт
delay_parameters 1 64000/50000000
# включим всех в первый пул
delay_access 1 allow all

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

# зададим 2 acl и разрешим доступ:
acl all src 0/0
acl vip src 10.0.0.1 10.0.0.2
http_access allow all
# создадим 2 пула
delay_pools 2
# зададим первому пулу первый класс, а второму - третий
delay_class 1 1
delay_class 2 3
# зададим первому пулу скорость 256 Кбит/с (= 256 Кбит/с / 8 = 32 КБайт/с = 32000 Байт/с) и размер пула в 20 Мбайт
delay_parameters 1 32000/20000000
# зададим второму пулу скорость 512 Кбит/с (= 512 Кбит/с / 8 = 64 КБайт/с = 64000 Байт/с) и размер пула в 50 Мбайт для всей сети
# для подсетей отменим ограничения за ненадобностью (-1/-1)
# зададим для хостов скорость 64 Кбит/с (= 64 Кбит/с / 8 = 8 КБайт/с = 8000 Байт/с) и размер пула в 10 Мбайт для всей сети
delay_parameters 2 64000/50000000 -1/-1 8000/10000000
# включим вип-пользователей в первый пул и "традиционно" запретим использование данного пула всем остальным
delay_access 1 allow vip
delay_access 1 deny all
# включим всех во второй пул
delay_access 2 allow all

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

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

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

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

acl workday time 10:00-13:00
acl our_networks src 192.168.0.0/24
http_access allow our_networks
<...>
delay_pools 2
delay_class 1 1
delay_parameters 1 15000/15000
delay_access 1 allow  our_networks
delay_access 1 deny all

delay_class 2 1
delay_parameters 2 12000/12000
delay_access 2 allow our_networks workday
delay_access 2 deny all

Данные правила задают скорость 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. Надеюсь, что изложил я свои мысли понятно и буду рад комментариям.

 С Уважением, Mc.Sim!




Теги: , ,

28 комментариев к “squid, настройка delay pools”

  1. eberron
    14 апреля, 2012 at 20:23
    1

    А тут не опечатка?

    ># включим всех во второй пул
    >delay_access -1- allow all

    должно же быть 2 вместо 1?

    • 14 апреля, 2012 at 20:32
      2

      Да. точно. Спасибо. Исправлено.

  2. sisdba
    27 апреля, 2012 at 22:51
    3

    delay_parameters 1 64000/50000000 -1/-1 8000/10000000
    Должно быть delay_parameters 2 ;)

    • 28 апреля, 2012 at 09:26
      4

      Да, молодец. Все верно. Исправлено.

  3. pwthrash
    14 июня, 2012 at 20:38
    5

    “Мы ведь знаем, что 1 бит = 8 байт? )” – наверное имелось ввиду 1 байт = 8 бит ? :-D

    • 14 июня, 2012 at 21:32
      6

      ))
      Действительно. Спасибо, pwthrash!

  4. sweeter
    7 августа, 2012 at 13:16
    7

    спасибо за материал, реально не мог понять принцип delay. только здесь врубился

    Спасибо

    • 9 августа, 2012 at 10:09
      8

      Пожалуйста. Приходите еще!

  5. dd-f
    27 ноября, 2012 at 00:09
    9

    # зададим второму пулу скорость 512 Кбит/с (= 512 Кбит/с / 8 = 64 КБайт/с = 64000 Байт/с) и размер пула в 50 Мбайт для всей сети
    # для подсетей отменим ограничения за ненадобностью (-1/-1)
    # зададим для хостов скорость 64 Кбит/с (= 64 Кбит/с / 8 = 8 КБайт/с = 8000 Байт/с) и размер пула в 10 Мбайт для всей сети
    delay_parameters 2 64000/50000000 -1/-1 8000/10000000

    Здравствуйте. Есть вопрос.
    Какой смысл в использовании пула 3 класса в данном случае если ограничений для подсетей нет(-1/-1)
    Ни то же самое будет если установить пул 2 класса и
    delay_parameters 2 64000/50000000 8000/10000000
    ?

    • 2 декабря, 2012 at 19:13
      10

      Приветствую.
      Я документального подтверждения не нашел, но существует мнение, что пул второго класса общим параметром действует на сети с маской 255.255.255.0, соответственно, если в локальной сети адресация более обширна, например 255.255.0.0, то данный пул будет делать не совсем то, что хочется )
      Соответственно, 3 пул этот недостаток гарантированно исправляет. Как-то так, наверно…

  6. df
    27 ноября, 2012 at 17:28
    11

    В четвертом блоки с конфигами опечатка
    delay_sccess 2 deny all
    надо
    delay_access 2 deny all

    • 2 декабря, 2012 at 19:14
      12

      Спасибо за замечание. Поправил.

  7. Alexey
    14 декабря, 2012 at 19:48
    13

    Коллеги, а как ограничить скорость к определенному внешнему хосту? К примеру, к сайтам соц. сетей?
    Подскажите примерном, пожалуйста.

    • 19 декабря, 2012 at 00:59
      14

      Алексей, а что мешает создать соответствующий acl типа dstdomain, и указать его в правиле в виде:
      delay_access номер allow имя_созданного_acl

      • Алексей
        19 декабря, 2012 at 21:38
        15

        Не внимательно прочитал статью – у вас об этом уже написано. Извините, пожалуйста и огромное спасибо за статью. Подписываюсь на сайт.

        • 20 декабря, 2012 at 13:29
          16

          Приходите еще – буду рад видеть.

  8. Alexey
    20 декабря, 2012 at 13:01
    17

    Кстати, после использования delay pools возникла не приятная проблема:
    Переодически сайты не открываются и вместо них возвращается ошибка Invalid URL. (*Missing or incorrect access protocol (should be http:// or similar))
    Прокси прозначный, http_port 3128 transparent В конфиге прописано.
    squid 3, centos6

    • 20 декабря, 2012 at 13:31
      18

      прозрачный прокси не может проксировать что-либо кроме http. То есть если Вы направили на него https, то это не будет работать.

  9. Alexey
    20 декабря, 2012 at 13:42
    19

    Так про https я ничего не говорил. Кстати, ведь вконтакте можно по https лазить, вы правы. Но я подключался по http.

    • 20 декабря, 2012 at 13:54
      20

      тут без логов не разобраться…

  10. Alexey
    20 декабря, 2012 at 14:02
    21

    Извините, вы не могли бы дать свои контакты, если у вас есть время мне помочь?

  11. Sasha
    25 февраля, 2013 at 16:16
    22

    Добрый день. Подскажыте если есть время. Стоит задача : установить скорость скачивания для файлов больше 5 мБ. в 30 кбт , для тех что меньше в 250 кбт. Какие параметры пула для етого использувать?

    • 9 марта, 2013 at 18:11
      23

      Добрый день.
      В целом, ограничение по объему файла – это не совсем корректная задача.
      squid такого не сможет…

  12. nokogerra
    3 апреля, 2013 at 15:40
    24

    Я правильно понимаю что delay pool не позволяет регулировать ширину канала именно интеренета для каждой группы пользователей squid, а работает только в локальной сети?

    • 3 апреля, 2013 at 21:45
      25

      не совсем верно.
      delay pool позволяет задать ограничение для acl, а что вы включите в этот acl – зависит от вас.
      Можно к acl привязать группу пользователей, тогда будет ограничение для группы.
      Как-то так…
      но опять же, тут не уместен будет термин “ширину канала именно интеренета”, squid не будет ограничивать ширину канала интеренета. Он будет ограничивать только те данные, которые пропускает через себя. Это я добавил, чтобы была ясность в терминологии.

  13. Nick
    27 ноября, 2014 at 16:17
    26

    Спасибо большое. Все четко и понятно. =)

  14. nekvit
    28 ноября, 2014 at 19:14
    27

    Единственный вопрос мне не дает покоя…

    Как же все таки расчитывать объем конкретных “корзин” (50М, 10М, 20М)? Есть ли какая нибудь технология расчета?

    • 18 декабря, 2014 at 15:26
      28

      эмпирически )))

Написать комментарий