Proxy Reverso e Balanceamento de Carga: Roteamento de Borda, Algoritmos e Terminação TLS

Em qualquer arquitetura web corporativa de médio ou grande porte, expor servidores de aplicação diretamente à internet pública com endereços IP abertos é considerado um anti-padrão grave de segurança e escalabilidade. Cada máquina ficaria vulnerável a ataques de negação de serviço (DDoS), seria forçada a negociar certificados criptográficos caros e não teria como distribuir picos de tráfego de maneira equilibrada.

Para resolver essas demandas na borda da rede, combinam-se duas ferramentas fundamentais de infraestrutura: o Proxy Reverso (Reverse Proxy) e o Balanceador de Carga (Load Balancer). Embora muitas vezes implementados pela mesma solução de software (como NGINX, HAProxy, Envoy ou Traefik), seus papéis na entrega de aplicações possuem focos técnicos complementares.

A Função Protetora do Proxy Reverso

Um proxy reverso é um servidor intermediário posicionado à frente da infraestrutura privada. Ele recebe todas as requisições originadas pelos navegadores e aplicativos móveis, inspeciona e sanitiza os pacotes e os encaminha para os servidores de aplicação internos:

flowchart TD
    Clientes["<b>Clientes na Internet</b><br/>Web, Mobile, Integrações"]
    Proxy["<b>PROXY REVERSO</b><br/>• Terminação TLS / SSL (Porta 443)<br/>• Cache de borda & Compressão Brotli<br/>• Ocultação da topologia e IPs privados"]
    LB["<b>BALANCEADOR DE CARGA</b><br/>• Algoritmos de distribuição (Round Robin / Least Conn)<br/>• Health Checks contínuos (/healthz)<br/>• Roteamento L4 (TCP) ou L7 (HTTP / Paths)"]

    subgraph Pool["Pool de Servidores de Aplicação"]
        direction LR
        S1["<b>Servidor 1</b><br/>(Nó Ativo - 200 OK)"]
        S2["<b>Servidor 2</b><br/>(Nó Ativo - 200 OK)"]
        S3["<b>Servidor 3</b><br/>(Isolado por Falha de Saúde)"]
    end

    Clientes -->|"Requisição HTTPS pública"| Proxy
    Proxy -->|"Tráfego HTTP interno limpo"| LB
    LB --> S1
    LB --> S2
    LB -.->|"Tráfego bloqueado pelo Health Check"| S3

Principais Responsabilidades de Borda

1. Terminação TLS/SSL: A negociação criptográfica de chaves assimétricas consome ciclos valiosos de CPU. O proxy reverso descriptografa o tráfego HTTPS na borda e entrega conexões HTTP simples e rápidas aos servidores internos através da rede local privada, centralizando a renovação de certificados digitais.
2. Ocultação de Topologia: Para o usuário externo, o sistema resume-se a um único endereço IP público (api.exemplo.com.br). Ele desconhece se o backend possui dez ou cinquenta servidores, quais portas internas estão ativas ou qual distribuição Linux está sendo executada.
3. Cache de Borda e Aceleração: Conteúdos estáticos e respostas comuns de API podem ser cacheados diretamente na memória do proxy, devolvendo respostas em menos de 2 milissegundos sem acionar o runtime da aplicação.

Balanceamento de Carga: Camada 4 versus Camada 7

O balanceador de carga atua como um distribuidor inteligente de tráfego, operando em dois níveis do modelo de redes:

• Balanceamento em Camada 4 (Transporte - L4): Opera no nível de pacotes TCP/UDP puros. Ele toma decisões de roteamento baseando-se estritamente no endereço IP de origem e porta de destino, sem abrir nem inspecionar o conteúdo da mensagem. Entrega throughput massivo e latência próxima de zero, ideal para tráfego bruto de bancos de dados ou conexões de streaming.
• Balanceamento em Camada 7 (Aplicação - L7): Opera no nível do protocolo HTTP/HTTPS. Ele inspeciona cabeçalhos, cookies de sessão, métodos HTTP e rotas de URL. Isso permite decisões sofisticadas de roteamento: chamadas para /api/pagamentos são encaminhadas para um pool de servidores com alta memória, enquanto chamadas para /relatorios vão para instâncias dedicadas de processamento em lote.

Algoritmos de Distribuição de Carga

A forma como as conexões são fatiadas entre os nós do cluster depende do algoritmo escolhido pela equipe de infraestrutura:

Algoritmo	Como Funciona	Cenário de Uso Recomendado
Round Robin	Distribui as requisições sequencialmente em círculo (Nó 1, Nó 2, Nó 3, Nó 1...).	Servidores com hardware homogêneo e tarefas com tempo de execução similar.
Weighted Round Robin	Atribui pesos proporcionais à capacidade de cada máquina (um nó com o dobro de RAM recebe o dobro de chamadas).	Ambientes com máquinas de diferentes gerações ou tamanhos de instância.
Least Connections	Encaminha a nova requisição para o nó que possui a menor quantidade de conexões ativas no instante da chegada.	Aplicações com requisições longas ou conexões WebSocket persistentes.
IP Hash / Sticky Sessions	Gera um hash a partir do IP do cliente para garantir que ele converse sempre com o mesmo servidor.	Sistemas legados que ainda mantêm estado de sessão local na memória do servidor.

Verificação Ativa de Saúde (Health Checks)

Um balanceador de carga só é eficiente se souber com precisão quais servidores estão aptos a receber tráfego. Ele dispara verificações de integridade (Health Checks) periódicas (a cada 5 ou 10 segundos) em uma rota leve (como /healthz).

Se uma das instâncias do backend travar por vazamento de memória ou começar a responder com código HTTP 500, o balanceador detecta a anomalia instantaneamente e remove o nó do pool de roteamento em menos de um segundo. O usuário final não percebe a pane, pois todas as requisições seguintes são transparentemente redirecionadas para os servidores saudáveis remanescentes.