Instalando e Configurando o Squid

Por Jennifer Vesperman - 26/07/2001

fonte: http://br.geocities.com/cesarakg/installing-configuring-squid.html

O que o Squid pode fazer pelo seu site?

Coloque o Squid entre os usuários e a Internet para fazer cache das páginas web. Os usuários irão
navegar mais rapidamente, o tráfego HTTP irá utilizar menos largura de banda, e você pode
economizar com despezas de conexão -- ou utilizar a banda economizada para outros tráfegos.

Encontrando o Squid
O código fonte do Squid está disponível em squid-cache.org. Também há uma lista de mirrors. As
instruções de instalação estão disponíveis no arquivo README no arquivo tar dos fontes.
Existe também um pacote RPM para o Red Hat Linux, e pacotes para o FreeBSD e NetBSD.
Instruções para instalar os pacotes estão disponíveis nos sites dos pacotes. Todos os três conjuntos
de pacotes vem com o código fonte do Squid e instruções adicionais para instalação dos fontes.
O script ./configure possui várias opções. Um conjunto de opções recomendadas é
./configure --enable-heap-replacement --enable-cache-digests --
enable-dlmalloc.

Configurando o Squid
O arquivo de configuração do Squid está no diretório $SQUID-HOME/etc/squid.conf. O
arquivo contém extensos comentários para cada opção. Este artigo é uma referência rápida para
quais opções você provavelmente irá querer alterar. Sua rede local pode exigir configurações não
mencionadas neste artigo.
Quando você tiver o Squid configurado, execute squid -z para criar a estrutura de diretório do
cache. A seguir você pode iniciar o Squid.

Configuração básica
• Cheque http_port, icp_port e htcp_port. 3128 é um bom valor padrão, e 8080 é
uma alternativa razoável para HTTP. A porta 80, ou qualquer outra porta normalmente
utilizada por algum outro serviço devem ser evitadas se possível.
• Deixe cache_mem com o valor de 8 Mbytes para começar, a menos que você tenha entre
0.5 Gbytes e 1 Gbyte de RAM disponível normalmente. Caso positivo, configure cache-
mem para 128 Mbytes. Ajuste cache_mem assim que os padrões do cache local se tornarem
conhecidos.
• Aumente o maximum_object_size para 40 Mbytes. Se arquivos grandes são
rotineiramente baixados, aumente este valor para 250 Mbytes ou até 700 Mbytes.
• Configure cache_dir para uma área que tenha bastante espaço. Tecnicamente ele
pertence a /var, mas você pode não querer que ele seja becapeado. Não configure o mesmo
para usar mais de 70 porcento do espaço, o Squid usa este diretório para armazenar arquivos
journal também. Linhas tipo cache_dir ufs /var/cache/squid 80000 16
256 são comuns..
 • Mude access_log e cache_log para on. O primeiro parâmetro informa a você quem
está fazendo o quê, e o último informa quando as coisas não estão certas.
• cache_swap_log é o local para os arquivos journal mencionados em cache_dir. O
local padrão é o mesmo diretório de cache_dir
• pid_filename deve ser configurado. /var/log/squid/squid.pid é um bom
lugar. O Squid utiliza este arquivo para o desligamento, rotação de arquivos de log, ou para
reler suas configurações.
• refresh_pattern é um parâmetro que afeta como os objetos são verificados para saber
qual o mais recente. Um valor padrão razoável é refresh_pattern . 0 20% 10080
• cache_mgr é para pessoas que configuram o cache para relatar problemas. Certifique-se
de usar um endereço de email que você realmente leia.
• cache_effective_user e cache_effective_group devem ser configurado para
um usuário e grupo "proxy". Muitas distribuições tem este usuário e grupo pré-instalados.
• Faça um chown recursivo nos direórios de cache e log para o usuário "proxy" antes de
iniciar o Squid. Este usuário deve poder ler o arquivo de configuração e o diretório em que o
mesmo está.
chown -R proxy.proxy /var/log/squid /var/cache/squid

• Configure visible_hostname para o nome de domínio qualificado. Por exemplo,

gw.mybox.com
• Retire o comentário da linha dns_testnames. Se ele não consegue resolver nomes como
"netscape.com", "internic.net", e "nlanr.net", seu sistema precisa de correções.
• Passe memory_pools para off a menos que haja bastante memória livre na máquina
• Passe log_icp_queries para on. As consultas ICP vem de outros proxies -- se você não
tem cache-irmão ou cache-pai e estiver recebendo estas consultas, você vai querer ver estas
no arquivo access.log.

Configuração básica de ACLs

As listas de controle de acesso administram o acesso a sua rede. Este exemplo básico limita o
acesso ao proxy à rede 1.2.3.4/24. Ela combina com sucesso se uma solicitação vem de qualquer
endereço entre 1.2.3.0 e 1.2.3.255 (inclusive).
acl our_network src 1.2.3.4/24
http_access allow our_network
http_access deny all

As ACLs são verificadas de cima para baixo. Os clientes que tem o endereço IP em
our_network recebem permissão, qualquer outro irá cair para a regra deny all e receberá
uma mensagem de erro. O formato para a definição de classe é acl listname src
network/netmask.
As ACLs tem uma última linha implícita que reverte a linha anterior. Esta serve como proteção
contra o esquecimento da regra http_access deny all, mas acrescentar explicitamente
aquela linha torna a ACL mais legível e ajuda a garantir que ela não foi esquecida quando a ACL
foi alterada.

miss_access
Se um objeto não está no cache ou não está marcado como recente, o Squid verifica com o servidor
de origem se ele ainda é atual e solicita uma nova cópia se ele não for atual. Este comportamento
serve bem aos usuários locais, mas não é desejável se o cliente que fez a solicitação é um servidor
proxy vizinho. As seguintes linhas ACL permitem que sejam passados objetos que não estão no
cache para a rede local, mas negam este serviço para qualquer um fora da rede local.
miss_access allow our_network
miss_access deny all

icp_access
Os caches se comunicam com mensagens ICP para descobrir se eles tem conteúdo recente que
satisfaça a uma requisição. As linhas ACL icp_access são usadas para controlar os caches com
os quais o Squid pode se comunicar.

Configuração para velocidade

Para maximizar a velocidade, minimize o número de solicitações simultâneas que o Squid pode
tratar. Quanto mais soliticações o Squid tem que processar em paralelo, mais tempo cada solicitação
toma. Cada bit de latência que você pode reduzir aumenta a velocidade do servidor.
• Utilize uma máquina multi-processada com I/O assíncrona habilitada
• Execute uma versão do Squid com DNS interno, ou aumente o número de servidores DNS
Planeje ter 20 ou 30 servidores DNS. Consultas DNS podem ser lentas -- alguns backbones
continetais podem tomar um minuto ou mais para resolver uma requisição DNS.

O que fazer e o que não fazer

• Coloque um servidor de nomes na máquina com o Squid. É um nível extra de cache, e
minimiza pontos de choque. Não sobrecarregue um único DNS para um grupo de máquinas,
especialmente se aquele servidor tem outras coisas a fazer.
• Use o DNS root nacional mais perto de você como forwarder. Se alguém mais pesquisou
pelo mesmo endereço recentemente, ele deve estar em cache. Não use ele como seu único
forwarder. Use pelo menos uma outra máquina em sua rede, e uma na rede do seu provedor.
• Aumente o tamanho do seu fqdncache e ipcache. Maior é melhor. Endereços antigos
são menos importantes que muitas entradas e longos TTLs. Faça cache de endereços por
pelo menos 24 horas, e faça cache de respostas negativas por pelo menos 5 minutos.
• Não faça cache de objetos grandes. Depois da CPU e RAM, a I/O de disco é seu maior
gargalo. Tente não colocar em cache qualquer coisa maior que um megabyte.
• Divida seu cache em vários drives físicos. Quatro drives de 5 Gbytes são melhores que um
drive de 20 Gbytes -- você economiza tempo usando múltiplos discos. Discos IDE são tão
bons quanto SCSI, a menos que você estiver utilizando Ultra Wide SCSI.
• Não coloque dois drives de cache na mesma controladora IDE, mas você pode colocar
quatro drives SCSI de alta velocidade ou seis drives SCSI de velocidade normal em uma
única controladora SCSI. Não misture drives Ultra Wide SCSI com drives não Ultra-Wide
SCSI na mesma cadeia.
• Tsete seu hardware antes de confiar no mesmo. Alguns servidores tem combinações
incompatíveis ou semi-compatíveis de hardware. É trágico ver um servidor de US$30,000
com um Ultra Wide SCSI que tem uma I/O de disco pior que um P100 com um IDE de 5400
rpm. Você pode ter que comprar antes de testar, mas pelo menos você pode avisar o chefe
antes que o mesmo entre em operação.

Configuração para economia

Boa parte do que os proxy caches fazem é economizar dolares. É fácil desperdiçar seu proxy -- e
dinheiro de verdade em largura de banda -- se você não entender o que está acontecendo.
Geralmente é fácil economizar dinheiro se você conhece o problema. A maioria dos serviores web e
conteúdo web são operados ou produzidos por pessoas que realmente não entendem o protocolo
HTTP. Como administrador de cache, os erros deles irão cair sobre os seus ombros.

Espaço em disco e memória

Um cache sempre pode usar mais espaço de disco, mas conforme o espaço do seu cache de disco
cresce, você precisa de mais memória para indexar ele. Existe uma regra direta para a memória.
Divida o tamanho do seu cache de disco por 13 Kbytes, e multiplique o resultado por 130 bytes.
Acrescente o tamanho de cache_mem, e acrescente mais 2.5 Mbytes para arquivos executáveis,
bibliotecas, e outras cargas. Por exemplo: temos um drive de 10 Gbytes, e um cache_mem de 8
Mbytes.
10 Gbytes / 13 Kbytes = 769.230
769.230 x 130 bytes = 99.999.900 bytes (ou 97.565 Kbytes)
97.656 Kbytes + 2.5 Mbytes + 8 Mbytes = 10.849.656 Kbytes ou cerca de 108 Mbytes

O servidor de exemplo precisa de 108 Mbytes disponíveis para o Squid para suportar 10 Gbytes de
cache_dir.
Acrescente tanto espaço de disco quanto RAM que você pode aacrescentar para suportar o mesmo.
O Squid tem uma péssima performance quando ele começa a fazer swap. Lembre de deixar
memória sobrando na máquina para qualquer outra coisa que você tenha instalado (DNS, cron,
sistema operacional, etc.).

Padrões de refresh
Os padrões de refresh determinam o tempo de vida dos objetos. Durante a vida de um objeto, o
Squid irá servir o objeto sem executar uma solicitação IMS ("if modified since" -- se modificado
desde). Assim que terminar o tempo de vida, o Squid irá manter o objeto, mas irá enviar uma
solicitação IMS para o servidor de origem. Se o objeto foi modificado desde que foi cacheado pela
primeira vez, o Squid irá solicitar uma nova cópia. Se não, então ele irá manter a cópia antiga. De
qualquer forma, o objeto é marcado como novo, novamente.
Aqui está nosso padrão de refresh básico (default):
refresh_pattern . 0 2% 4320

O ponto (.) é o padrão expressão regular, e combina com qualquer coisa. São usadas as expressões
regulares POSIX (veja man 7 regex).
O zero (0) é o tempo mínimo que um objeto pode ser considerado novo. Se for diferente de zero,
então ele irá substituir qualquer cabeçalho com informação de expiração que for dado com o objeto.
Se o fornecedor de conteúdo fornecer um cabeçalho de expiração, devemos honrar o mesmo.
O último termo (4320) é o tempo máximo que um objeto pode ser considerado novo. O objeto se
torna antigo após esta quantia de minutos no cache.
O valor de 20 porcento é usado para nosso caso padrão, para o qual não há informação do provedor
de conteúdo sobre o tempo de vida do objeto. O Squid usa x porcento (20 porcento neste exemplo)
da diferença entre a hora da última modificação do objeto e a hora atual, e usa este valor como o
tempo de vida do objeto. Se o tempo de vida do objeto é menor que o mínimo configurado pelo
refresh_pattern, ele é aumentado até aquele valor. Se for maior que o valor máximo
informado, ele é reduzido para aquele valor.
Arquivos não-padrão
Alguns tipos de arquivos podem ser mantidos por muito mais tempo que outros. Arquivos zip,
tar.gz, tgz e .exe raramente tem seu conteúdo alterado sem que também seja alterado o nome.
Usando expressões regulares, podemos criar um conjunto de padrões como o que segue:
refresh_pattern -i exe$ 0 50% 999999
refresh_pattern -i zip$ 0 50% 999999
regresh_pattern -i tar\.gz$ 0 50% 999999
refresh_pattern -i tgz$ 0 50% 999999

Opções no padrão de refresh

Note que estas opções violam o padrão HTTP. Não use as mesmas levianamente.
override-expire finge que não há cabeçalhos de expiração nos objetos e faz o cálculo baseado
no momento da última modificação. Esta opção permite que você faça cache de sites que abusem
dos cabeçalhos de expiração, mas também inibe a atualização de conteúdo que seja frequentemente
alterado (tipo sites de notícias).
ignore-reload evita que o objeto seja atualizado quando o usuário aperta o botão de atualizar
do seu browser. Isto não funciona bem quando o objeto não tem o tamanho do conteúdo -- você
pode terminar com um objeto corrompido que os usuários não podem atualizar.
reload-into-ims transforma os erloads em validações. Cuidado: servidores web podem
permitir que um objeto seja atualizado sem que seja alterado a hora da última modificação. O
servidor pode então insistir que o objeto ainda é válido quando na verdade não é.

Mais coisas a fazer e a não fazer

• Aumente o maximum_object_size. 40 Mbytes não é tão grande. 800 Mbytes pode
fazer cache de grandes downloads.
• Certifique-se de ter pelo menos um ou dois servidores de nomes locais para o Squid
consultar. Não deixe ele consultar qualquer outro servidor diretamente. Isto mantém as
consultas DNS fora do site do Squid em um mínimo.
• Aumente o ipcache_size e o fqdncache_size.
• Tenha um proxy-pai se você puder. É mais barato percorrer uma hierarquia que percorrer
múltiplos sites diretamente.
• Não use o ICP se você tem um único proxy-pai que você sempre usa.
• Use o calamaris para analizar periodicamente os logs e procurar por alterações que você
pode fazer em seus refresh_patterns. Não há uma "boa" configuração única. Os
usuários alteram seus hábitos de navegação e criam novos arquivos, e novas tecnologias
estão sempre sendo desenvolvidas. Adapte-se.

Problemas e Armadilhas
• Em muitos clientes, o "reload" força o cache a recarregar o objeto de sua origem. Isto pode
causar problemas de teste.
• Não teste o Squid com páginas que tenham cabeçalhos "não guarde em cache". O Squid não
irá colocar elas em cache.
• Utilize o access.log quando estiver fazendo testes para ver se você está recuperando
páginas do Squid.
• As listas de controle de acesso tem uma última linha implícita que reverte a regra da última
 linha explícita.

Últimas palavras
O Squid pode melhorar a velocidade de navegação e reduzir o consumo de banda HTTP. O arquivo
squid.conf permite bastante flexibilidade, mas pode ser intimidante a princípio. As
configurações informadas neste artigo ajudam a iniciar -- mas são apenas o início. Faça
experiências!

Leitura Adicional
• Squid, A User's Guide
• Squid configuration manual
• $SQUID-HOME/etc/squid.conf
• RFC 2616: Hypertext Transfer Protocol - HTTP/1.1
Jennifer Vesperman gosta de pensar que nasceu com uma pastilha de silício grudada em sua
coluna, mas não consegue fazer que seus pais admitam isto. Ela contribui para o Open Source,
principalmente como usuária e defensora. Jenn é a coordenadora atual do Linuxchix.org

Versão inglesa oreillynet.com Copyright © 2000 O'Reilly & Associates, Inc.

Tradução do original em http://www.oreillynet.com/pub/a/linux/2001/07/26/squid.html