lucianopinheiro.net

Em agosto de 2009 defendi meu TCC na faculdade SEAMA, condição para obtenção de título em nível de graduação de Tecnólogo em Redes de Computadores. Fiz junto dos colegas Heverton e Renan, sob orientação do professor Klenilmar Lopes. A proposta é a medição do ganho de performance em uma Lan House após a implantação do squid, squidguard (com alguns filtros) e BIND9. 

Estou publicando-o em anexo a este post por 2 motivos. Primeiro, porque ele contém informações interessantes sobre caching (segundo a RFC2616 HTTP 1.1, disponível só em inglês). Segundo, porque é um modelo razoavelmente bom de TCC, e eu sofri que só pra achar um destes quando precisava. 

Sobre o conteúdo teórico

Há algumas informações muito interessantes no trabalho para quem quer aprender como o cache HTTP funciona (e não simplesmente botar o squid pra rodar). O apêndice A mostra os principais cabeçalhos HTTP sobre cache. 

É interessante notar que existem vários cabeçalhos redundantes. Isso ocorre em parte porque houve uma mudança de nomenclatura quando foi feita a especificação do HTTP 1.1 em relação à HTTP 1.0. Antes, apenas Pragma: no-cache que importava. Depois, foi criada uma série de diretivas aninhadas em torno do cabeçalho Cache-Control. Só que o pessoal achou que era importante manter a retrocompatibilidade. Ou seja, a evolução do protocolo foi feita com vários remendos (como é comum na história da informática).

Achamos algumas curiosidades interessantes que não couberam no trabalho. Uma delas é a diferença entre URL (Uniform Resource Location) e URI (Uniform Resource Identification). A URL é uma identificação única baseada em uma localização. A URI é mais genérica, e pode ser baseada em localização (URL) ou nomenclatura (URN - Uniform Resource Name). Ou seja, toda URL é uma URI, mas nem toda URI é uma URL. Não entendeu? O melhor é um exemplo: um ISBN (uma espécie de nome único para cada livro registrado) é uma URN, mas não uma URL. Um endereço web é uma URL, mas não URN. Ambas são URI.

Mas pra que simplificar se se pode complicar? Inventaram que em uma mesma URL pode ser distribuído mais de um conteúdo. Por exemplo, se você digitar www.debian.org, verá uma página em português, se seu navegador estiver configurado para português. Se estiver configurado para inglês, verá a página em inglês. Como eles fazem isso? Redirecionamento via script? Não. Através dos cabeçalhos Accept (na requisição) e Vary (na resposta). Ou seja, pra um mesmo endereço, há mais de um conteúdo; uma URL HTTP pode não ser uma URL no sentido estrito. Isso porque um recurso HTTP é definido pelo endereço requisitado, o cabeçalho Vary e uma Etag (porque também o conteúdo do endereço pode ter mudado, situação em que é gerada uma nova ETag). Existem várias RFC só tratando de URI.

Quanto ao cache, descobrimos que o Squid não segue direitinho as recomendações do cache. Em tese, ele poderia guardar todo conteúdo, menos os que possuem o cabeçalho Cache-Control: no-store (e algumas outras poucas exceções). E então, poderia somente validar este conteúdo quando requisitado. Na prática, ele possui uma espécie de tempo médio para deleção do conteúdo (leia mais sobre LRU threshold aqui). Isso explica por que na prática o cache nunca fica cheio e ele pede objetos que já tinha e você sabe que não mudaram. 

Além disso, veja na seção 3.2 outros recursos não oficiais do squid, incluindo uma forma de divulgar o IP interno da rede na Internet (e como não fazer isso). 

Sobre os experimentos

Nós fizemos 3 implementações: cache com squid, filtro de URL com squidguard e cache DNS com BIND.

O cache com squid deu um resultado de 20% de eficiência. Menor do que esperávamos, explicado pelo perfil dos usuários (diferente do perfil de uma empresa, que fica em torno dos 30%). Uma dificuldade inicial era definir o que era desempenho. Tem uma fórmula no livro do Luiz Fernando Soares (Redes de Computadores) relacionada ao tempo, mas preferimos não usá-la. Ao invés disso, definimos desempenho como diminuição de consumo do link externo. Com isso, o método ficou muito mais simples e abrangente.

Usando o Calamaris (item Bandwidth savings in Percent (Byte hit rate) ), pudemos obter o ganho de desempenho. Com o famoso sarg, pudemos ver as URL baixadas e assim fazer ajustes finos. A diferença entre um programa e outro é que o Calamaris é voltado para o desempenho e estatísticas do proxy, e o SARG é voltado para o gerenciamento do acesso. O Calamaris mostra, por exemplo, o tempo que o proxy leva pra entregar o conteúdo. Pra que isso? Lembre-se de que existem proxies configurados em hierarquia nas WANs espalhadas pelo país todo.

O filtro de URL feito com o squidGuard se mostrou, com grande surpresa, muito mais eficaz que o cache em si. Isso porque após instalar o proxy verificamos que as máquinas estavam tentando atualizar um software. Acontece que o software era o Windows Live Messenger e a atualização tinha 32 MB. Agora, imagine ligar a lan house pela manhã e todas as máquinas tentarem atualizar o programa. O primeiro usuário já chegava concorrendo com o link no gargalo. Isso sem falar que o squid não gerenciava muito bem o download (não reaproveitava os pedaços, como se faz com um torrent e como é especificado na RFC 2616). Todo dia, todas as máquinas tentavam baixar novamente o mesmo programa, já que o link só tinha 256K e todo dia caia a conexão antes do fim.

Outra surpresa que ocorreu foi com o cache DNS. Descobrimos que o squid já fazia este cache, desde que o proxy fosse não transparente. Então não havia muita necessidade do BIND. Além disso, na prática, o cache DNS do BIND parecia não ser muito bom (ou pelo menos não melhor que o do Squid), uma vez que sempre que o squid precisava (sempre que expirava seu próprio cache DNS), o BIND reencaminhava o pedido.

Sobre a formatação do TCC

As normas ABNT que regem a apresentação do trabalho são as NBR 6022, 6023, 6024, 6027, 6028, 6029, 6034, 10520, 10719, 12225, 14724 (a principal) e 15287. No site da ABNT, você só vai encontrar as referências. O conteúdo é pago, por mais ridículo que isso seja.

Quando me diziam que eu não encontraria um modelo pronto de TCC, eu não conseguia me conformar. Eu pensava que, se havia as normas, alguém poderia tê-las compilado e criado um modelinho de acordo com elas. Bem, a coisa não é bem assim. Há muitas lacunas na norma. É vaga, por exemplo, a definição de formatação (espaçamento e fonte) do sumário. E as próprias regras das faculdades completam estas lacunas.

Ainda assim, achei que um modelo seria um bom ponto de partida. Todos os que vi, porém, eram em PDF, continham muitos erros ou eram apenas um modelo em branco. Também por isso resolvi publicar o meu em ODT. Dá um pouco de dor de cabeça colocar a numeração correta no BROffice. Claro que depois de aprender como fazer (inserir » quebra manual » quebra de página » alterar o número da página) fica fácil. Com o documento, você já pega tudo pronto.

Procuramos seguir ao máximo as normas NBR, contrariando em alguns pontos a norma da própria faculdade. Ainda assim, alguns pontos ficaram de fora - acabei de ver que a expressão Palavras-Chave: está grafada incorretamente. O certo é Palavras-chave:.

Ainda tivemos outros pequenos problemas. Algumas figuras foram criadas por nós. Nas NBR, diz-se que deve ser citada a fonte da figura. Não achamos um modelo para dizer que a imagem era ilustração/criação/captura própria.

Também não achamos um modelo para fontes monoespaçadas, coisa comum em trabalhos de informática. 

E, acredite em mim, por mais formatos de referências bibliográficas que você já tenha visto, você ainda não viu todos. Imagine só: referenciamos a descrição de um programa a partir daquela atualização do Synaptic no Ubuntu em um determinado dia, mas não usamos a original do inglês, e sim a tradução em português de um determinado mirror. Agora, como informar isso? 

A Defesa

Se for lá na faculdade, você não vai encontrar o trabalho impresso encapado na biblioteca. Isso porque a apresentação não foi muito boa... Eu ia publicar uns detalhes da defesa, mas acabei de apagar o texto. Em vez disso, prefiro deixar o conselho de que não se deixem perder a paciência com questionamentos nonsense da banca porque, sendo por ignorância, arrogância ou provocação, são eles que dão a sua nota. 8-|

Pedidos finais 

Peço que se você encontrar mais erros por favor deixe nos comentários, para que os próximos que pegarem o documento não cometam os mesmo erros que eu.

E se o trabalho lhe ajudar na construção do seu, peço também que por favor você publique seu trabalho na Internet.

Anexo

Está no 4shared:

http://www.4shared.com/file/228378162/c34feb40/tcc-2009.html