NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
30 de junho de 1997 | volume 1, número 2

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



Cache: Melhor Aproveitamento dos Recursos na Internet

Laszlo Pinto <>
Marcio Cesario <>
Murilo Monteiro <>

Rede Nacional de Ensino e Pesquisa (RNP)

Como Funciona
O Que é Necessario
Dificuldades
O Uso de Hierarquia
Referências

Com o crescimento da utilizacao da Internet e o surgimento de novas aplicacoes, cresce a cada dia a quantidade de dados a ser transmitida, tornando os meios de comunicacao disponiveis cada vez mais saturados. E, grande parte desse trafego e', muitas ve- zes, formado pela passagem de diversas copias da mesma informacao.

Neste ponto, entra o cache, cuja finalidade e' exatamente amenizar esse problema, fazendo uso de dados previamente consultados em vez de busca-los na origem sempre que requisitados.

^

Como Funciona

Servidores proxy sao instalados e as consultas, que antes eram feitas diretamente para os servidores de origem, passam a ser direcionadas a estes novos servidores. Assim, a primeira vez que uma pagina Web e' consultada, a requisicao e' encaminhada ao servidor proxy que a busca na origem, armazena-a localmente e a repassa ao cliente que fez o pedido. Para todas as outras consultas a essa mesma pagina, sera' apenas repassada a copia anteriormente gravada. E' um cache compartilhado por diversos usuarios.

Uma pagina Web e' formada por varios objetos, tais como textos, imagens e sons. O tempo em que um objeto sera' mantido em disco, depende de varios fatores: a frequencia dos acessos a essa pagina, o espaco disponivel em disco, a existencia de cabecalhos HTTP que definem datas de expiracao e de renovacao, entre outros. Quanto menos espaco tiver disponivel em disco, menor sera' o tempo de vida de cada pagina.

Atualmente, existem programas que fazem cache de dados de diversas aplicacoes, como por exemplo HTTP, FTP e GOPHER. Como a primeira e', sem duvida, a mais utilizada, as informacoes citadas daqui pra frente se referirao a ela.

A porcentagem das requisicoes que conseguem ser resolvidas pelo servidor cache apenas com os dados armazenados localmente (taxa de acerto, ou "hit ratio") varia de acordo com varios fatores, tais como: a capacidade de armazenamento de objetos, o ambiente e grupo de trabalho onde estamos. Por exemplo, e' provavel que, num determinado laboratorio, as pessoas procurem sempre pelos mesmos documentos, ao contrario do que pode acontecer numa grande universidade. Na pratica, pode-se conseguir taxas de acerto entre 30% e 60%.

Para se ter uma ideia de como isso pode economizar recursos da Internet, uma amostragem feita pelo "National Laboratory for Applied Network Research (NLANR)" num tronco OC-3 de um backbone dos Estados Unidos mostra que mais de 60% dos bytes em transito sao respostas de requisicoes HTTP. Se considerarmos que podemos ter em cache 60% das paginas Web, poderemos ter o equivalente a 3 Mbps de trafego com uma linha de 2 Mbps. Isto porque, segundo a amostragem feita, 60% destes 3 Mbps se referem a trafego HTTP, e um servidor de cache com tal taxa de acerto economizaria 1,08 Mbps (1,8 x 0,6) deste canal de 3 Mbps.

Alem disso, o uso do cache traz algumas outras vantagens. Uma delas e' o fato de o servidor cache ficar "mais proximo" da maquina que faz a requisicao. Isto pode trazer um ganho consideravel de desempenho para o usuario, mesmo em caso de linhas pouco congestionadas. Outra vantagem e' quando um site, por algum motivo, fica inacessivel. Usuarios que utilizam um servidor de cache continuarao podendo navegar e mesmo fazer FTP para este site, uma vez que os objetos tenham sido previamente armazenados no cache. Isto pode ser de grande utilidade no caso de quedas de linhas de dados, por exemplo.

^

O Que é Necessario

Para se instalar um servidor de cache e' necessario que se tenha, no minimo, uma maquina e um bom software de cache. De preferencia, esta ma- quina deve ficar dedicada a essa atividade.

Existem, atualmente, diversos programas para essa finalidade, entre eles o Squid, o NetApp, Apache, e muitos outros. Direcionaremos nossa atencao principalmente para o Squid, por ser o mais usado em todo o mundo, por ser freeware, por estar em constante atualizacao e por ter uma boa documentacao. O Squid esta' na versao 1.1.11 e funciona com HTTP, FTP, WAIS e GOPHER. O programa fonte do Squid, que ja' foi testado em praticamente todas as variacoes de UNIX, pode ser encontrado em [1].

O hardware necessario depende da utilizacao e da taxa de acerto desejadas. Com um Pentium 166 MHz, rodando FreeBSD ou Linux, 128 MB de RAM e 8 GB de disco SCSI, e' possivel atender a, no minimo, 55.000 conexoes por hora. A taxa de acerto e a quantidade de memoria necessaria sao proporcionais `a quantidade de espaco em disco disponivel para armazenar os objetos.

Na pratica, boas configuracoes em termos de memoria e capacidade de disco seriam 64MB/2GB, 64MB/4GB e 128Mb/8Gb. Isso porque o Squid mantem um indice de todos os objetos que se encontram armazenados em disco. Para cada requisicao feita ao servidor, ele faz uma pesquisa neste indice para saber se os objetos procurados estao no cache. Este indice cresce na mesma proporcao da quantidade de objetos armazenados e deve ficar, preferencialmen- te, todo em memoria principal. Alem disso, ter memoria disponivel para dedicar a objetos "em transito" e aos mais requisitados aumenta consideravelmente o desempenho.

^

Dificuldades

Uma das maiores dificuldades de se ter sucesso na implantacao de servidores de cache e', talvez, conscientizar o usuario da importancia do seu uso. Isto porque e' necessario que cada um configure o seu "browser" para que as consultas feitas por eles a sites diversos sejam redirecionadas a um determinado servidor de cache. Esta conscientizacao vem sendo feita atraves de campanhas e divulgacoes. Uma destas campanhas e' a "Cache Now!", que pode ser vista em [2].

Outra dificuldade e' manter o servidor funcionando 24 horas por dia, 7 dias por semana, e com niveis satisfatorios de desempenho. Note que o "browser" de um usuario, uma vez configurado para fazer uso do servidor de cache, nao conseguira' acessar nenhum site caso o servidor de cache pare de funcionar. Para tentar atender a estes requisitos, utilizam-se varios servidores interligados em rede local e configura-se o DNS de tal modo que ao se consultar o endereco IP do servidor de cache obtenha-se mais de um numero IP. Repare que isto ameniza o problema, mas nao resolve. Se um dos servidores de cache cair, o DNS vai continuar respondendo o nome da maquina na qual ele esta' rodando e o usuario vai continuar fora do ar. Na verdade, ter mais de um pai garante tolerancia a falhas pois, se um deles cair, o filho faz a requisicao a um dos outros pais (ou de um de seus irmaos). Mas, no caso do browser fazendo requisicoes ao proxy, nao tem como garantir funcionalidade o tempo todo. Se uma maquina cair o que pode ser feito e' alterar o DNS, manualmente, retirando da lista de proxys o nome desta maquina.

^

O Uso de Hierarquia

Para se ter um aproveitamento ainda maior dos recursos de maquinas que rodam servidores de cache, e' possivel que elas estejam conectadas em uma hierarquia. Os servidores se comunicam de modo que haja um "compartilhamento" dos objetos armazenados.

A comunicacao entre esses servidores pode se dar de duas formas: atraves de um protocolo proprio, o ICP (Internet Cache Protocol)[3], ou por multicast. O ICP e' baseado em UDP, e seu objetivo principal e' verificar se um outro servidor de cache possui uma determinada pagina. No caso do Squid, para se utilizar o ICP e' necessario configurar alguns servidores vizinhos. Assim, o servidor ao receber uma requisicao de uma determinada pagina envia pacotes ICP para seus vizinhos para saber se eles tem esta pagina armazenada em seu disco local. Se algum deles responder que a possui, o servidor a requisita deste, em vez de recuperar a pagina original, economizando um acesso mais demorado. Para evitar que vizinhos com problemas atrasem o processo, existe um "timed-out" (2s, em media) em que o servidor espera resposta dos vizinhos antes de recuperar a pagina direto na fonte.

Para flexibilizar mais essa hierarquia, existe uma maneira de configurar o que o servidor deve fazer se um vizinho requisitar uma pagina que ele nao possui. Se ele for configurado para apenas responder negativamente caso nao a possua, diz-se que ele e' irmao do outro servidor. Se, ao inves disso, ele tiver que recuperar a pagina da fonte original, e depois a repassar ao servidor que pediu, diz-se que ele e' pai desse servidor. Nesse caso a pagina estara' no banco de dados tanto do servidor a quem foi requisitado inicialmente, quanto no de seu pai. E' possivel tambem configurar diversos irmaos e pais para um servidor. Nesse caso, ele faz o pedido a todos eles, e pega a pagina daquele cuja resposta chegar primeiro.

A utilizacao de hierarquias aumenta muito o "hit ratio" combinado de diversos servidores. Se tres maquinas forem configuradas apenas para responder requisicoes de usuarios finais, sem comunicacao entre si, havera' uma grande probabilidade de uma delas estar buscado um objeto diretamente da origem que outro servidor acabou de buscar, e que poderia simplesmente ser repassada de um para outro servidor. Se um dos tres for colocado como pai dos outros dois, o pai, com o passar do tempo, tera' em seu banco de dados um grande numero de paginas que serao aproveitadas pelos dois filhos. Se, alem disso, o pai for irmao de outros servidores cache, em outros pontos da rede, esses servidores poderao trocar informacoes entre si, sem ter que recorrer aos sites originais das paginas.

No caso da RNP, a situacao ideal e' que cada provedor de acesso ou instituicao ligada a um POP tenha o seu servidor de cache para atender seus usuarios. O POP, por sua vez, mantem um ou mais servidores que funcionarao como pais dos servidores dos provedores. Para uma reducao ainda maior no trafego internacional, os servidores cache dos POPs deverao se interligar como irmaos. Nesse caso, se o usuario requisitar uma pagina ao servidor cache de seu provedor, existe uma chance bem grande dessa pagina estar em algum servidor dentro do Brasil. Isso, alem de poupar as linhas internacio- nais, ajuda a balancear o trafego no backbone, uma vez que um servidor sempre baixara' a pagina daquele que o respondeu mais rapido, ou seja, o tempo de resposta sera' influenciado nao so' pelo estado atual de carga do servidor, mas tambem pelo tempo gasto para trafegar pelas linhas do backbone.

^

Referências

[1] http://squid.nlanr.net

[2] http://www.pop-mg.rnp.br/portugues/servicos/cache/CacheNow

[3] http://www.nlanr.net/Cache/ICP/ICP-id.txt

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004