Implementação de delay pool com Squid: mudanças entre as edições
| Linha 59: | Linha 59: | ||
* '''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 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 | * '''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 qunado buscamos limitarmos usuários individualmente. Mas observe que há uma armadilha: dependendo das regras, 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á solução para o problema, que é utilizar a classe 3. | ||
* '''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 no | * '''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. | ||
{{exclamação1|No Squid 3.x há ainda as classes 4 e 5, que atuam também sobre o login de usuários autenticados e tags.}} | {{exclamação1|No Squid 3.x há ainda as classes 4 e 5, que atuam também sobre o login de usuários autenticados e tags.}} | ||
Edição das 12h20min de 8 de novembro de 2011
<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: 08 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 tráfego
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
{exclamação1|Observe que todas as regras do tipo http_access (liberação) ou http_deny (bloqueio),
Buckets
Buckets ou baldes são fruto da famosa teoria de tráfego por baldes. 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. 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 qunado buscamos limitarmos usuários individualmente. Mas observe que há uma armadilha: dependendo das regras, 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á solução para o problema, que é utilizar a classe 3.
- 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. |
Rajadas (bursts)
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
Controle de tráfego com TC, HTB e Iptables