Proxy reverso: o que é e como usar


Antes de começarmos a falar em proxy reverso, vale a pergunta: você sabe o que é proxy?

O proxy serve como um intermediário entre as máquinas de uma rede e a web.

Você pode utilizar as máquinas da rede com IP´s de uso interno (192.168.0.0/24) e possuir apenas um IP público válido, configurado no servidor de saída da sua rede:

proxy reverso

O servidor proxy serve para cache de páginas (poupando banda) e é um facilitador para bloquear endereços que o administrador de redes não queira que o resto da empresa acesse no horário de trabalho.

Legal, mas e o proxy reverso?

proxy reverso

Não, ele não é um proxy do mal, pelo contrário!

O proxy reverso fica mais próximo do servidor web, no qual estão alocados os arquivos do site. Ele recebe as requisições do cliente e pode assumir o papel de servidor (quando o objeto requisitado já está armazenado no proxy em cache) ou de cliente (quando o objeto não está em cache ou está expirado, de acordo com as configurações do proxy).

proxy reverso

O proxy reverso que utilizamos na KingHost é o Varnish Cache. Escrito em C e projetado por Poul-Henning Kamp (conhecido também por colaborar com o projeto do FreeBSD), é leve e fácil de utilizar, especialmente para o pessoal de infraestrutura que também trabalha com desenvolvimento.

O arquivo de configuração do serviço é configurado com a VCL, uma linguagem de domínio específico (é uma linguagem de programação dedicada a resolver um problema específico, neste caso, a configuração do Varnish).

No cenário abaixo, tenho o servidor varnish01 e o servidor apache01:

varnish01:
IP 192.168.0.108
hostname: varnish01.kinghost.net

apache01:
IP 192.168.0.106
hostname: apache01.kinghost.net

O servidor varnish01 receberá as requisições e redicionará (se necessário), para o apache01, então o apache01 será o backend do varnish01:

Conforme comentei, a VCL é muito intuitiva, usa regex para validar se a requisição recebida pelo varnish01 for para ^apache01.kinghost.net$, iniciando com qualquer coisa e finalizando com qualquer coisa, mas contiver apache01.kinghost.net, redireciona para nosso backend apache01, se não, redireciona para o backend default, nosso servidor varnish01.

Por lidar com paradigmas de programação, o varnish trata o que será cacheado como um objeto. Ele armazena um hash_data para cada backend:

A resposta do backend é configurada de acordo com o que o cliente solicita.
No exemplo abaixo, o TTL (time to live) padrão é de 1 hora (arquivos .php, .aspx…) mas se o arquivo for estático (como folhas de estilos, javascript) podemos deixar um tempo maior, certo? Afinal, não modificamos tão frequentemente esses arquivos como alteramos nossa página inicial. Então aqui configuramos a expiração do cache com 1 dia.

Se bereq(BackEndREQuest) contiver apache01.kinghost.net, configura o beresp.ttl (BackEndRESPonse) para 1 hora
Se bereq contiver as extensões js ou css, configura o beresp.ttl para um dia. Após estas configurações, return(deliver), ou seja, entregue o objeto, porém, se for obsoleto, uma busca em segundo plano para atualizá-lo será acionada.

Agora que você conhece mais dos bastidores do Varnish, você poderá testar o seu site com esse maravilhoso acelerador de requisições HTTP no site da KingHost, clicando aqui .

E eu preciso saber de tudo isso para usar o Varnish na KingHost? Claro que não! Todas essas configurações que mostrei, você poderá fazer pelo painel de controle, com alguns cliques, pois todo o processo de configuração é automatizado.

Gostou do post acima? Ficou com alguma dúvida? Deixe nos comentários, vou ficar super feliz em poder ajudá-los! Fique ligado também no nosso Blog da KingHost para mais conteúdos e novidades.

Vanessa de Oliveira Mello

Vanessa de Oliveira Mello

Analista de Infraestrutura Linux em KingHost
Cursando Análise e Desenvolvimento de Sistemas, trabalha há 9 anos com T.I. Apaixonada por infraestrutura, redes, programação e indie rock dos anos 90.
Vanessa de Oliveira Mello

Últimos posts por Vanessa de Oliveira Mello (exibir todos)

Comentários

comentário(s)