Implementação de delay pool com Squid

De Eriberto Wiki
Revisão de 12h28min de 9 de novembro de 2011 por Eriberto (discussão | contribs) (→‎Veja também)
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: 09 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 citados neste artigo, 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 de nominada 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 utilizada 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 http_access trabalha com 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 3 ACLs e uma regra. Nessa regra houve um AND: rede1 AND proibidos. Isso quer dizer que a tudo o que for rede1 e proibidos será bloqueado. 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. Ou seja, 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 todas as possibilidades de ACL 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 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 o último octeto. Essa pode ser a classe a ser utilizada quando buscamos limitarmos 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 limitados pelo mesmo balde, uma vez que os dois possuem 5 como último octeto. 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 é utilizado para algo similar a subredes, atuando no terceiro octeto somente. O terceiro balde atua nos dois últimos octeto (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 as regras de tráfego correspondente. Essas regras determinarão a velocidade a qual cada situação de tráfego será submetida.

Cada pool, dependendo da classe, utiliza um ou mais pares de números. O primeiro é 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 no Squid, 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. O balde inicia com a velocidade de 90 KB/s e vai decaindo até chegar a 25 KB/s. Isso serve para livrar-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. Assim, a não ser que tenho motivos para não fazer dessa forma, use os mesmos valores para restore rate e maximum size. Exemplo: 25000/25000.

A ordem das regras

A ordem das regras (ACLs) interfere diretamente no funcionamento do delay pool (e no restante do Squid também). A primeira regra que englobar a situação será executada e as demais não serão lidas. Exemplo: 

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 .exe a 3 Mb/s.

O raciocínio para o arquivo .exe, por exemplo, 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 172.20.0.0/16

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 corresponde 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 que fizer um download igual ou superior a 25 KB terá sua velocidade reduzida para 25000 B/s (= 25 KB/s). Ou seja: o primeiro 25000 é o tamanho do download e o segundo representa a velocidade final.

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

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. O símbolo de interrogação, por exemplo, refere-se à existência opcional do caractere anterior. Assim, htm e html poderiam ser substituídos por html?. 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 aqui.

Agora, veja a seguinte ACL: 

acl exclusao urlpath_regex -i \.(htm?|jpe?g|php|png|txt)$

Esta ACL define exclusao como sendo tudo que tiver um ponto, seguido de htm ou html ou jpg ou jpeg ou php ou png ou txt 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. Ainda, urlpath_regex faz a busca somente depois do nome do domínio na URL. Ou seja, 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.

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=1471”