Implementação de delay pool com Squid

<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.

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