Visão Geral

Propósito

Este componente simula um nó de borda CDN para ambientes de laboratório e demonstração. Ele representa o papel que fornecedores como Akamai, Cloudflare, Amazon CloudFront ou Fastly desempenham na arquitetura de rede de um cliente — a camada de cache mais próxima dos usuários finais, situada na frente de um servidor de origem.

Em arquiteturas de múltiplos fornecedores em produção, os clientes comumente combinam um CDN de terceiros com o F5 Distributed Cloud:

End User → CDN Edge (Akamai/Cloudflare/etc.) → F5 XC HTTP LB → Origin App

Este simulador substitui o CDN comercial por um nó de borda baseado em NGINX, permitindo que a integração seja demonstrada e testada sem contratos com fornecedores ou infraestrutura de produção.

Arquitetura

┌─────────┐     ┌──────────────────────┐     ┌─────────────────┐     ┌────────────┐
│  Client  │────▶│  CDN Edge (NGINX)    │────▶│  F5 XC HTTP LB  │────▶│ Origin App │
│          │     │  Ubuntu 24.04 Azure  │     │  (Origin Server) │     │            │
└─────────┘     │  - TLS termination   │     └─────────────────┘     └────────────┘
                │  - Disk-based cache  │
                │  - X-Cache-Status    │
                └──────────────────────┘

O nó de borda NGINX:

Encerra o TLS na borda (autoassinado ou Let’s Encrypt)
Armazena respostas em cache no disco utilizando proxy_cache_path
Encaminha erros de cache para um servidor de origem configurável (o VIP do balanceador de carga HTTP F5 XC)
Reporta o status do cache por meio do cabeçalho de resposta X-Cache-Status (HIT, MISS, BYPASS, EXPIRED)

O Que Este Componente Simula

Função CDN	Implementação NGINX
Cache de borda	`proxy_cache` com armazenamento em disco
Geração de chave de cache	`proxy_cache_key` baseada em esquema, host e URI
Busca na origem	`proxy_pass` para o balanceador de carga HTTP F5 XC
Encerramento de TLS	Diretiva NGINX `ssl_certificate`
Respeito ao Cache-Control	`proxy_cache_valid` com passagem dos cabeçalhos de origem
Relatório de status do cache	`add_header X-Cache-Status $upstream_cache_status`
Endpoint de saúde	Localização `/health` retornando 200 OK

Endpoints e Comportamento de Requisição/Resposta

Verificação de Saúde

GET /health

Resposta (200 OK, Content-Type: application/json):

{
  "status": "healthy",
  "component": "cdn-edge",
  "engine": "nginx",
  "vendor_profiles": ["akamai", "cloudflare", "cloudfront", "fastly", "azure-front-door"]
}

Proxy CDN (Todos os Outros Caminhos)

GET /<any-path>

Cabeçalhos de requisição injetados em direção à origem (mais de 67 cabeçalhos de 5 fornecedores):

Categoria	Cabeçalhos Adicionados
IP do Cliente	`True-Client-IP`, `CF-Connecting-IP`, `Fastly-Client-IP`, `X-Azure-ClientIP`, `CloudFront-Viewer-Address`, `X-Forwarded-For`, `X-Real-IP`
Geolocalização	`X-Akamai-Edgescape` (composto), `CF-IPCountry`, `cf-ipcity`, `cf-iplatitude/longitude`, `CloudFront-Viewer-Country/City/Latitude/Longitude`, `X-Geo-Country-Code/City/Region`
Detecção de Dispositivo	`CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Tablet-Viewer`, `X-Akamai-Device-Characteristics`
TLS/Fingerprint	`CloudFront-Viewer-TLS`, `cf-ja3-hash`, `cf-ja4`, `CloudFront-Viewer-JA3-Fingerprint`
Detecção de Bot	`cf-bot-score` (85 = provavelmente humano), `cf-verified-bot`
Rastreamento de Requisição	`Cf-Ray`, `X-Akamai-Request-ID`, `X-Amz-Cf-Id`, `X-Azure-Ref`
Identidade de Borda	`X-CDN-Edge`, `X-CDN-POP`, `X-Served-By`, `Fastly-FF`, `X-Azure-FDID`
Padrão	`Via`, `Forwarded`, `CDN-Loop`, `X-Forwarded-Proto/Host/Port`

Cabeçalhos de resposta adicionados a cada resposta intermediada:

Cabeçalho	Valores	Finalidade
`X-Cache-Status`	`HIT`, `MISS`, `BYPASS`, `EXPIRED`, `STALE`	Comportamento do cache para esta requisição
`X-CDN-Edge`	`cdn-simulator`	Identifica este nó de borda
`X-CDN-POP`	`SJC`	Código IATA do Ponto de Presença simulado
`X-Served-By`	`cache-sjc3120-SJC`	Nó de cache simulado no formato Fastly
`X-Request-ID`	UUID (por requisição)	Identificador único da requisição

Comportamento do Cache

Primeira requisição a qualquer caminho: X-Cache-Status: MISS (buscado na origem, agora em cache)
Requisições idênticas subsequentes: X-Cache-Status: HIT (servido a partir do cache em disco)
Chave de cache: $scheme$host$request_uri (esquema + hostname + caminho completo + query string)
TTL do cache: 10 minutos para 200/301/302, 1 minuto para 404
Entrega de conteúdo desatualizado: retorna conteúdo em cache em caso de erros na origem (500/502/503/504)

Acesso à VM

Método de Acesso	Comando/Caminho
SSH	`ssh azureuser@<PUBLIC_IP>`
Configuração do NGINX	`/etc/nginx/conf.d/cdn-edge.conf`
Logs do NGINX	`/var/log/nginx/access.log` e `/var/log/nginx/error.log`
Diretório de cache	`/var/cache/nginx/cdn/`
Log do Cloud-init	`/var/log/cloud-init-output.log`

Design de Componente Modular

Este é um componente de um ambiente de laboratório maior. Cada componente é independente e implantado separadamente:

Este componente fornece a borda CDN (NGINX em VM do Azure)
Outros componentes fornecem a aplicação de origem, a configuração do F5 XC, DNS, políticas de WAF, etc.

O operador humano adiciona componentes um por vez. A documentação de cada componente é escrita de forma que um assistente de IA possa lê-la e implantar a infraestrutura de forma autônoma.

Por Que NGINX

O NGINX foi selecionado como motor de simulação de CDN porque:

Produto F5 — a F5 adquiriu a NGINX Inc. em 2019; ele faz parte do portfólio da F5
Comprovado pela indústria — o Cloudflare operou todo o seu CDN com NGINX por mais de uma década antes de migrar para o Pingora; a Netflix utiliza NGINX para seu CDN Open Connect
Processo único — lida com encerramento de TLS e cache em um único binário, ao contrário do Varnish, que requer um proxy TLS separado
Implantação simples — apt install nginx no Ubuntu 24.04, duas diretivas habilitam o cache
Bem documentado — documentação oficial abrangente para cache de conteúdo e configuração de proxy reverso