Proxies em CDN

Os proxies em uma Content Delivery Network (CDN) aceleram a entrega de conteúdo atuando como servidores intermediários que armazenam conteúdo em cache mais perto dos usuários finais, otimizam as requisições de rede e distribuem o tráfego de forma eficiente pela infraestrutura distribuída.

O papel dos proxies na arquitetura de CDN

Dentro de uma CDN, os proxies são componentes fundamentais e se manifestam principalmente como servidores de borda (edge) ou Points of Presence (PoPs). Esses servidores ficam distribuídos estrategicamente pelo mundo, formando uma camada de rede entre os servidores de origem do conteúdo e os usuários finais. Quando um usuário requisita conteúdo, a resolução de DNS normalmente o direciona ao proxy de borda da CDN mais próximo ou mais adequado, e não ao host original do conteúdo. Essa proximidade reduz bastante a latência e melhora os tempos de carregamento.

Proxies de borda e Points of Presence (PoPs)

Cada PoP contém um ou mais servidores proxy projetados para atender às requisições dos usuários. Esses proxies executam diversas funções além do simples encaminhamento, participando ativamente da cadeia de entrega de conteúdo para aumentar velocidade e confiabilidade. Seu objetivo principal é servir o conteúdo a partir da borda sempre que possível, minimizando a necessidade de buscar dados em servidores de origem distantes.

Mecanismos centrais de ganho de velocidade

Os proxies usam vários mecanismos para acelerar a entrega de conteúdo:

Cache de conteúdo na borda

O cache é o maior ganho de velocidade oferecido pelos proxies de CDN. Quando um proxy de borda recebe uma requisição de conteúdo que já buscou antes, ele pode servir esse conteúdo direto do armazenamento local, sem contatar o servidor de origem. Isso reduz:
* Round-Trip Time (RTT): o tempo que uma requisição leva para ir do usuário até a origem e voltar.
* Carga no servidor de origem: reduz o processamento na origem, evitando lentidão ou indisponibilidade.
* Consumo de banda: reduz os custos de transferência de dados do servidor de origem.

Cache hit vs. cache miss:
* Cache hit: o conteúdo requisitado está no cache do proxy. O proxy serve o conteúdo diretamente.
* Cache miss: o conteúdo requisitado não está no cache do proxy ou está expirado. O proxy busca o conteúdo na origem, entrega ao usuário e guarda uma cópia no cache para requisições futuras.

Invalidação de cache:
As CDNs gerenciam a validade do cache com várias estratégias:
* Time-To-Live (TTL): o conteúdo fica em cache por um período predefinido.
* Cabeçalhos de cache: cabeçalhos HTTP como Cache-Control e Expires determinam o comportamento do cache.
* Purga manual: administradores podem remover explicitamente o conteúdo do cache em toda a CDN.
* Invalidação via API: sistemas automatizados disparam purgas quando o conteúdo é atualizado.

Balanceamento de carga e distribuição de tráfego

Os proxies em uma CDN também atuam como balanceadores de carga, distribuindo as requisições recebidas entre vários recursos. Isso pode incluir:
* Distribuir requisições entre vários servidores dentro de um mesmo PoP: garante que nenhum servidor fique sobrecarregado.
* Distribuir requisições entre vários servidores de origem: caso a CDN esteja configurada para buscar conteúdo em várias origens.
* Direcionar o tráfego ao PoP menos utilizado ou geograficamente mais próximo: feito por roteamento baseado em DNS ou IP Anycast.

Os algoritmos de balanceamento garantem uso ótimo dos recursos e evitam gargalos, mantendo velocidades de entrega consistentes mesmo sob tráfego intenso. Algoritmos comuns incluem Round Robin, Least Connections e IP Hash.

Otimização e compressão de conteúdo

Os proxies de CDN podem otimizar e comprimir conteúdo em tempo real para reduzir o tamanho dos arquivos, o que se traduz diretamente em downloads mais rápidos.
* Compressão: os proxies podem aplicar compressão Gzip ou Brotli a recursos de texto (HTML, CSS, JavaScript) se a origem ainda não tiver feito isso.
* Otimização de imagens: algumas CDNs oferecem manipulação de imagens, como redimensionamento, conversão de formato (por exemplo, WebP) e redução de qualidade, executada pelo proxy de borda.
* Minificação: remoção de caracteres desnecessários do código sem alterar sua funcionalidade.

Exemplo de configuração de proxy Nginx para compressão Gzip:

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

Otimização de protocolo

Os proxies viabilizam o uso de protocolos de comunicação modernos e mais rápidos entre o usuário e a borda e, às vezes, entre a borda e a origem.
* HTTP/2 e HTTP/3 (QUIC): esses protocolos oferecem multiplexação (várias requisições em uma única conexão), compressão de cabeçalhos e server push, reduzindo bastante a latência em comparação com o HTTP/1.1. Os proxies de CDN costumam terminar as conexões dos usuários com esses protocolos mais novos, independentemente do que a origem suporta.
* Otimização de TCP: os proxies podem usar pilhas TCP otimizadas (por exemplo, BBR) e ajustes que aceleram o estabelecimento de conexões e a transferência de dados, especialmente em longas distâncias.

Roteamento otimizado

As CDNs usam mecanismos de roteamento sofisticados para direcionar as requisições ao proxy de borda mais eficiente. Isso costuma se basear em:
* Geolocalização: direcionar os usuários ao PoP mais próximo.
* Congestionamento de rede: desviar o tráfego de caminhos de rede sobrecarregados.
* Saúde dos servidores: evitar PoPs ou servidores com problemas.

Assim, mesmo que o usuário esteja geograficamente perto de um PoP, ele é roteado para uma alternativa se o caminho principal estiver congestionado, mantendo a velocidade ideal.

Segurança como viabilizadora de desempenho

Embora não seja um mecanismo direto de aceleração da transferência de dados, os recursos de segurança implementados no nível do proxy contribuem para a velocidade de entrega ao garantir disponibilidade e evitar degradação de desempenho.
* Mitigação de DDoS: os proxies absorvem e filtram tráfego malicioso, impedindo que ataques de negação de serviço sobrecarreguem a origem ou a infraestrutura da CDN, o que causaria lentidão severa ou indisponibilidade.
* Web Application Firewall (WAF): protege contra vulnerabilidades web comuns, garantindo a estabilidade da aplicação e evitando ataques que possam interromper o serviço e retardar a entrega de conteúdo.
* Offload de SSL/TLS: os proxies cuidam do handshake e da criptografia/descriptografia SSL/TLS, que exigem muito processamento, tirando essa tarefa do servidor de origem e muitas vezes usando hardware especializado para processar mais rápido.

Tipos de proxy no contexto de CDN

Proxies reversos

O principal tipo de proxy usado dentro de uma CDN é o proxy reverso. Um proxy reverso fica na frente de um ou mais servidores web e intercepta as requisições dos clientes. Ele encaminha as requisições ao servidor apropriado, recebe a resposta do servidor e a entrega ao cliente. Em uma CDN, o servidor de borda atua como proxy reverso do servidor de origem.

Características dos proxies reversos de CDN:
* Transparência para o cliente: os clientes percebem que estão se comunicando diretamente com a origem.
* Capacidade de cache: armazena cópias de conteúdo estático e dinâmico.
* Camada de segurança: oferece a primeira linha de defesa contra ataques.
* Balanceamento de carga: distribui as requisições entre os recursos internos.
* Terminação SSL/TLS: cuida da criptografia/descriptografia.

Implementação prática: exemplo de fluxo de requisição

Considere um usuário requisitando example.com/image.jpg:

1. Consulta DNS: o navegador do usuário faz uma resolução DNS de example.com. O serviço de DNS da CDN responde com o endereço IP do servidor proxy de borda mais próximo ou mais adequado.
2. Requisição ao proxy de borda: o navegador do usuário envia uma requisição HTTP de example.com/image.jpg diretamente ao proxy de borda da CDN.
3. Verificação de cache: o proxy de borda verifica seu cache local em busca de image.jpg.
   • Cache hit: se image.jpg for encontrado e estiver válido, o proxy entrega a imagem imediatamente ao usuário.
   • Cache miss: se image.jpg não for encontrado ou estiver expirado, o proxy encaminha a requisição ao servidor de origem (por exemplo, origin.example.com).
4. Busca na origem (em caso de cache miss): o servidor de origem processa a requisição e devolve image.jpg ao proxy de borda.
5. Cache e entrega: o proxy de borda recebe image.jpg, guarda uma cópia no cache e entrega ao usuário. Requisições futuras de image.jpg feitas por usuários roteados a esse PoP resultarão em cache hit, reduzindo bastante o tempo de entrega.

Exemplos de configuração de cache e otimização em proxies

Servidores proxy como Nginx ou Varnish costumam ser usados como componentes dentro dos PoPs de uma CDN. Suas configurações determinam diretamente como o conteúdo é armazenado em cache e otimizado.

Trecho de configuração de proxy cache no Nginx:
Este exemplo mostra uma configuração básica do Nginx para cachear respostas de um servidor upstream.

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
    proxy_cache_key "$scheme$request_method$host$request_uri";

    server {
        listen 80;
        server_name cdn.example.com;

        location / {
            proxy_pass http://origin.example.com;
            proxy_cache my_cache;
            proxy_cache_valid 200 302 10m;  # Cacheia respostas bem-sucedidas por 10 minutos
            proxy_cache_valid 404 1m;     # Cacheia erros 404 por 1 minuto
            add_header X-Cache-Status $upstream_cache_status; # Cabeçalho de depuração
            expires 30d; # Cache no navegador
        }
    }
}

Trecho de configuração do Varnish Cache (vcl_recv simplificado):
O Varnish Cache é um proxy reverso HTTP dedicado, focado em cache.

vcl 4.1;

backend default {
    .host = "origin.example.com";
    .port = "80";
}

sub vcl_recv {
    # Remove cookies dos arquivos estáticos para melhorar a cacheabilidade
    if (req.url ~ "(?i)\.(css|js|jpg|jpeg|png|gif|ico|svg|webp|woff|woff2|ttf|otf|eot)(\?.*)?$") {
        unset req.http.Cookie;
    }

    # Não cacheia requisições POST
    if (req.method == "POST") {
        return (pass);
    }

    # Consulta o cache
    return (hash);
}

sub vcl_backend_response {
    # Define um TTL padrão para todos os objetos se a origem não especificar um
    if (beresp.ttl <= 0s || beresp.http.Set-Cookie || beresp.http.Vary == "*") {
        set beresp.ttl = 1h; # Cacheia por 1 hora por padrão
    }
    return (deliver);
}