Implementação de delay pool com Squid

De Eriberto Wiki
Ir para navegação Ir para pesquisar

<absHTML>

<tbody> </tbody>
Esta página está em construção e deverá estar pronta em poucos dias. Por favor, volte depois ou consulte-a agora com cautela e paciência.

</absHTML>

by (C) João Eriberto Mota Filho <eriberto (a) eriberto pro br>

Artigo criado em: 10 de novembro de 2011.

Última atualização: veja o rodapé desta página.

Tiny URL ou bit.ly: http://bit.ly/delay_pool


Este artigo foi escrito com base em um Debian Squeeze 6.0.3, utilizando Squid 2.7. O Squid mais atual (3.1) possui diversas features a mais, inclusive na área de delay pool. No entanto, este artigo já resolve um dos maiores problemas dos administradores de rede: o controle de downloads.



O que é delay pool?

Delay Pool ou Delay Pools, como alguns chamam, é um recurso do Squid que permite limitar o tráfego HTTP de usuários ou até de redes inteiras. Ele é essencial para que tenhamos condições justas para todos os que navegam em sites a partir de uma rede.

O grande objetivo deste artigo será a limitação da velocidade de download por usuário, apesar de que serão citadas outras variantes de controle.

Para a implementação dos recursos aqui citados, o Squid deverá estar previamente configurado e funcionando normalmente como proxy na rede.

O delay pool somente cuida do tráfego HTTP. É muito importante que todo o resto do tráfego seja controlado. Para isso, consulte o artigo Controle de tráfego com TC, HTB e Iptables. Lembre-se: HTB e delay pool são indispensáveis em QUALQUER rede!



Unidades de medida

As unidades básicas de medida na informática são:

  • b: bit. Representa a menor informação possível.
  • B: byte. Um conjunto de 8 bits.

Em telecomunicações, as unidades de medida possuem base decimal. Isso quer dizer que o multiplicador/divisor é sempre 1000 e não 1024, como estamos acostumados. Assim, 1 KB/s (kilobyte por segundo) corresponde a 1000 B/s (bytes por segundo). Ainda, 1 Mb/s (megabit por segundo) corresponde a 1000 Kb/s (kilobits por segundo) que, por sua vez, é igual a 125 KB/s (kilobytes por segundo). Este último cálculo se deu da seguinte forma: 

1 Mb/s = 1000 Kb/s
1000 Kb/s ÷ 8 = 125 KB/s
O delay pool trabalha com B e B/s.



ACLs, buckets, classes, pools e rajadas

Veremos alguns termos básicos utilizados no Squid e, particularmente, no delay pool.

ACLs

As ACLs (Active Control Lists) servem para definirmos regras no Squid. Elas criam um escopo referente a uma determinada situação. Exemplo: 

acl minharede src 192.168.1.0/24

A ACL anterior foi denominada minharede e refere-se a tudo que seja originado (src = source) na rede 192.168.1.0/24.

O delay pool atua sobre tráfegos que estejam liberados no Squid. Ou seja: o tráfego tem que estar em condições de ocorrer sem problemas. Um comando para liberar o tráfego através Squid para rede citada seria: 

http_access allow minharede

É possível bloquear alguns tipos de tráfego com http_access deny. Exemplo: 

acl proibidos url_regex -i \.(orkut|facebook)\.com
http_access deny proibidos

No caso anterior, foi utilizado um sistema de expressão regular (veja mais sobre o assunto logo adiante) para dizer que todas os sites com domínio .orkut.com e .facebook.com, em letras maiúsculas ou minúsculas (opção -i), deverão ser bloqueados. Se a relação de sites proibidos for longa, há como colocar cada um em uma linha dentro de um arquivo. A referência ao arquivo poderá ser feita pela ACL da seguinte forma: 

acl proibidos url_regex -i "/etc/squid/proibidos.txt"
Evite utilizar muitos bloqueios como, por exemplo, um milhão de sites de pornografia. Isso vai exigir que você tenha uma máquina hiperpoderosa para comparar cada URL solicitada por um usuário da rede com cada linha de bloqueio. Acredite: a cada dia, milhões de sites são criados e não há como bloquear tudo o que existe ou existirá daqui a 10 minutos.

É muito importante ressaltar que o acl sempre trabalha com OR lógico e que http_access usa AND lógico. Observe: 

acl rede1 src 10.0.0.0/8
acl rede2 src 192.168.1.0/24
acl proibidos url_regex -i \.(orkut|facebook)\.com
http_access deny rede1 proibidos

No caso anterior, foram criadas três ACLs e uma regra. Nessa regra houve um AND que utilizou duas ACLs: rede1 AND proibidos. Isso quer dizer que a tudo o que for rede1 e proibidos será bloqueado. Um exemplo: a máquina 192.168.1.12 tentando acessar http://www.orkut.com.

Mas imagine se a linha http_access deny fosse assim: 

http_access deny rede1 rede2 proibidos

Nesse caso, estaríamos dizendo que tudo o que fosse rede1 e rede2 e proibidos seria bloqueado. Mas isso é impossível, pois um IP de origem não pode pertencer, ao mesmo tempo, às redes 10.0.0.0/8 e 192.168.1.0/24. Em outras palavras, a regra nunca teria efeito algum.

Observe que todas as regras do tipo http_access criadas por você deverão ser colocadas logo após a sentença # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS, existente dentro do arquivo de configuração do Squid. Isso porque a última regra sempre deverá ser http_access deny all. Isso garantirá que tudo o que não for habilitado pelo administrador de rede será bloqueado por default.

Utilizamos aqui a sentença url_regex na ACL. Essa sentença serve para buscar ocorrências em toda a URL. Há também urlpath_regex, que busca somente depois do domínio. Em outras palavras, utilizando urlpath_regex em: 

http://eriberto.pro.br/site/wp-content/uploads/2011/11/737-800.jpg

será analisada somente a parte 

site/wp-content/uploads/2011/11/737-800.jpg.

Para saber sobre todas as possibilidades de ACLs no Squid 2.7, consulte o site http://www.visolve.com/squid/squid27/accesscontrols.php. Para o Squid 3.0, veja http://www.visolve.com/squid/squid30/accesscontrols.php.

Buckets

Buckets ou baldes são fruto da famosa teoria de tráfego por baldes e bastões (tokens). Partimos do princípio de que temos balde(s) cheio(s) de bastões. Cada pacote de rede necessita apanhar um bastão para ter o seu tráfego liberado.

No Squid, cada bastão (token) tem o tamanho de 1 byte.

Há várias formas de utilizar os baldes. Exemplo: você tem um balde onde cabem 30 KB e que leva 1 segundo para esvaziar. Os downloads serão feitos com base nesse balde. Em outras palavras, a cada 1 segundo só poderemos encher o balde com 30 KB de dados (que representam os bastões). Isso será responsável pela limitação de velocidade.

É interessante citar que diversos sistemas de controle de tráfego modernos utilizam a teoria dos baldes. Um exemplo clássico é o delay pool. Outro é a disciplina HTB (Hierarchy Token Bucket), muito conhecida.

Classes

O delay pool do Squid 2.7 possui três classes. São elas:

  • Classe 1: realiza o controle de toda a rede. Para isso, utiliza apenas um balde. Em outras palavras, em um link de 10 Mb/s, caso seja configurada uma classe 1 de 7 Mb/s, a soma de todas as conexões HTTP não poderão ultrapassar a 7 Mb/s. Com isso, 3 Mb/s ficarão livres para outras atividades e protocolos.

  • Classe 2: há dois baldes. O primeiro limita a rede como um todo, exatamente como faz a classe 1. O segundo balde limita os endereços IP individualmente, considerando apenas o último octeto. Essa pode ser a classe a ser utilizada quando buscamos a limitação de usuários individualmente. Mas observe que há uma armadilha: dependendo das regras e da situação de rede, IPs como 172.20.10.5 e 172.20.11.5 serão englobados pelo mesmo balde, uma vez que os dois possuem 5 como último octeto. Então, haverá a divisão da velocidade de um único balde por dois tráfegos diferentes. Há duas soluções para o problema: fazer regras muito específicas ou utilizar a classe 3 (melhor opção por ser mais fácil).

  • Classe 3: há três baldes. O primeiro balde limita tudo. O segundo atua no terceiro octeto somente e pode ser utilizado como um delimitador de uma subrede inteira. O terceiro balde atua nos dois últimos octetos (isso mesmo! no terceiro octeto novamente e no quarto). Essa classe é perfeita para limitar usuários individualmente.
No Squid 3.x há ainda as classes 4 e 5, que atuam também sobre o login de usuários autenticados e tags.



Pools e rajadas

As pools (uniões) são o resultado da agregação de uma ou mais ACLs com uma regra de tráfego. As regras determinarão a velocidade a qual cada situação de rede será submetida.

Cada pool, dependendo da classe, utiliza um ou mais pares de números. O primeiro desses números é o restore rate e o segundo é o maximum size. O maximum size representa o tamanho do balde a ser utilizado e o restore rate é a velocidade com a qual ele é reabastecido com bastões. Assim, observe a pool a seguir: 

delay_parameters 1 -1/-1 25000/90000
delay_access 1 allow rede_usuarios

O -1 significa livre. Então, -1/-1 quer dizer um balde de tamanho ilimitado, sendo preenchido com bastões, instantanea e constantemente. Já 25000/90000 significa que temos um balde onde cabem 90.000 bastões. Como cada bastão no Squid equivale a 1 byte, temos um balde de 90.000 bytes, que é igual a 90 KB. Ainda, cada balde será reabastecido com 25.000 bastões por segundo, que correspondem a 25.000 bytes por segundo. Com isso, teremos um efeito denominado rajada.

Especificamente, o balde em questão iniciará com a velocidade de 90 KB/s e irá decaindo até chegar a 25 KB/s. Isso serve para que o sistema livre-se rapidamente de arquivos menores em download. No entanto, esse tipo de procedimento pode ser prejudicial à rede. Assim, é aconselhável, para a maioria dos casos, não permitir rajadas. Então, a não ser que haja motivos para não fazer dessa forma, use os mesmos valores para restore rate e maximum size. Exemplo: 25000/25000. Isso será o suficiente para que não ocorram rajadas.

A ordem das regras

A ordem das regras (ACLs) interfere diretamente no funcionamento do Squid. A primeira regra que englobar uma determinada situação será aplicada e as demais ignoradas.

Considere um exemplo hipotético de regras: 

1) Todos podem acessar qualquer JPG sem restrição.
2) Cada usuário terá a sua velocidade de download restrita a 1 Mb/s entre 08:00h e 10:00h.
3) Cada usuário terá a sua velocidade de download restrita a 3 Mb/s.

Agora, imagine a seguinte situação: um usuário fará o download de uma figura JPG de 10 MB de tamanho e, em paralelo, de um arquivo .exe também com 10 MB. Imagine ainda que são 08:45h. Com as regras anteriores, o arquivo JPG será baixado na maior velocidade possível, enquanto o arquivo .exe estará limitado a 1 Mb/s. Se fossem 11:00h, o JPG seria novamente baixado na maior velocidade possível e o .exe a 3 Mb/s.

O raciocínio para o arquivo .exe, caso seja baixado às 09:00h, será o seguinte:

  • Regra 1: O .exe é um JPG? Não. Então, vamos para a próxima regra.
  • Regra 2: Está para ocorrer um download e a hora está entre 08:00h e 10:00h? Sim. Então, aplica-se a regra e não serão lidas as próximas. Será feito o download a 1 Mb/s.

Agora, observe as regras: 

1) Cada usuário terá a sua velocidade de download restrita a 3 Mb/s.
2) Todos podem acessar qualquer JPG sem restrição.
3) Cada usuário terá a sua velocidade de download restrita a 1 Mb/s entre 08:00h e 10:00h.

Observe que houve uma inversão na ordem. A antiga regra 3 agora é a primeira. Então, considere que são 09:00h e que faremos um download de um JPG. O raciocínio será o seguinte:

  • Regra 1: Está para ocorrer um download? Sim. Então, aplica-se a regra e não serão lidas as próximas. Será feito o download a 3 Mb/s.
Em resumo, as regras mais restritivas deverão aparecer primeiro e as mais amplas no fim.



Exemplo simples de configuração

Considere uma ACL previamente existente em um Squid já configurado: 

acl rede_usuarios src 192.168.10.0/24

Vamos implementar apenas uma pool, classe 2, para que possamos controlar o tráfego de cada IP individualmente. Não haverá um controle para a rede como um todo. 

delay_pools 1
delay_class 1 2

Então, apenas reforçando, a primeira linha definiu que haverá apenas uma pool e a segunda diz que a pool 1 será classe 2.

A velocidade de cada usuário será de 200 Kb/s (kbits por segundo), que correspondem a 25000 B/s (bytes por segundo). O cálculo foi: 200 / 8 * 1000. Então, o resultado final será: 

delay_parameters 1 -1/-1 25000/25000
delay_access 1 allow rede_usuarios

A primeira linha disse que a pool 1 não sofrerá controle global de rede (-1 significa livre). Diz ainda que cada usuário terá a sua velocidade de download reduzida para 25000 B/s (= 25 KB/s), sem direito a rajadas (o primeiro 25000 representa o regime de reabastecimento do balde, enquanto o segundo é o tamanho total de tal balde).

A segunda linha diz que a pool 1 será aplicada a quem for englobado pela ACL rede_usuarios.

Note que o objetivo foi controlar downloads individualmente. Isso só foi possível com a classe 2, que considera apenas o último octeto, porque estamos em uma rede com máscara classe C. Então, só teremos variação no último octeto. No entanto, para downloads individuais, o ideal é sempre trabalhar com a classe 3 do delay pool, que considera os dois últimos octetos.



Recursos especiais para as ACLs

O uso de expressões regulares

O Squid permite o uso de expressões regulares. Isso quer dizer que podemos utilizar caracteres com significados especiais para referenciarmos situações. Caracteres colocados entre colchetes, por exemplo, permitirão a criação de uma lista de elementos possíveis. Assim, test[ae] pode ser interpretado como testa e teste. O símbolo de interrogação refere-se à existência opcional do caractere anterior. Assim, [js]?html? representa, de uma só vez, htm, html, jhtm, jhtml, shtm e shtml. Da mesma forma, jpg e jpeg poderiam ser trocados por jpe?g.

Um resumo sobre a função desses caracteres especiais, conhecidos como metacaracteres, pode ser encontrado em http://aurelio.net/regex/guia/metacaracteres.html#2.

Agora, veja a seguinte ACL: 

acl exclusao urlpath_regex -i \.([js]?html?|jpe?g|php|png|txt)$

Esta ACL define exclusao como sendo tudo que tiver um ponto, seguido de htm ou html ou jhtm ou jhtml ou shtm ou shtml ou jpg ou jpeg ou php ou png ou txt no fim da linha (simbolizado pelo caractere cifrão). A opção -i serve para fazer o Squid ignorar a caixa do caractere (case insensitive). Ou seja: -i jpg casa com jpg, JPG, jpG, JpG etc. Ainda, urlpath_regex faz a busca somente depois do nome do domínio na URL, como já foi explicado anteriormente.

Um exemplo um pouco mais sofisticado

Considere as seguintes ACLs: 

acl rede_usuarios src 172.20.0.0/16
acl rede_gerentes src 172.21.0.0/16
acl exclusao url_regex -i \.(htm|html|php|txt|jpg|png)$
acl expediente time MTWHF 6:30-19:00

A primeira ACL já é conhecida. A segunda define uma rede de gerentes.

Utilizando expressões regulares, a terceira ACL define exclusao como sendo tudo que tiver um ponto, seguido de htm, html, php, txt, jpg ou png, no fim da linha. A opção -i serve para fazer o Squid ignorar a caixa do caractere (case insensitive). Ou seja: -i jpg casa com jpg, JPG, jpG, JpG etc.

A terceira linha define expediente como sendo os dias de segunda a sexta-feira, das 06:30h às 19:00h.

Definiremos que haverá 4 pools e que cada uma utilizará a classe 2. 

delay_pools 4
delay_class 1 2
delay_class 2 2
delay_class 3 2
delay_class 4 2

Liberaremos todo o tráfego das extensões citadas na ACL exclusao: 

delay_parameters 1 -1/-1 -1/-1
delay_access 1 allow exclusao

A seguir, estabeleceremos os limites dos usuários como sendo 200 Kb/s (= 25000 B/s) durante o expediente: 

delay_parameters 2 -1/-1 25000/25000
delay_access 2 allow rede_usuarios expediente

Definição dos limites dos gerentes de rede somente durante o expediente (280 Kb/s = 35000 B/s): 

delay_parameters 3 -1/-1 35000/35000
delay_access 3 allow rede_gerentes expediente

Por fim, definiremos a velocidade dos usuários fora do expediente (560 Kb/s = 70000 B/s): 

delay_parameters 3 -1/-1 70000/70000
delay_access 3 allow rede_usuarios



Veja também



Links externos



Redes sociais

  • Twitter: Para novidades sobre artigos, livros e palestras, siga-me em eribertomota.


Disponível em “https://eriberto.pro.br/wiki/index.php?title=Implementação_de_delay_pool_com_Squid&oldid=1481”