Descripción general

Propósito

Este componente simula un nodo edge CDN para entornos de laboratorio y demostración. Representa el papel que desempeñan proveedores como Akamai, Cloudflare, Amazon CloudFront o Fastly en la arquitectura de red de un cliente: la capa de caché más cercana a los usuarios finales que se sitúa frente a un servidor de origen.

En arquitecturas de producción multifabricante, los clientes suelen combinar un CDN de terceros con F5 Distributed Cloud:

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

Este simulador reemplaza el CDN comercial por un nodo edge basado en NGINX para que la integración pueda demostrarse y probarse sin contratos con proveedores ni infraestructura de producción.

Arquitectura

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

El nodo edge NGINX:

Termina TLS en el edge (autofirmado o Let’s Encrypt)
Almacena respuestas en caché en disco mediante proxy_cache_path
Reenvía los fallos de caché a un servidor de origen configurable (el VIP del balanceador de carga HTTP de F5 XC)
Reporta el estado de la caché mediante la cabecera de respuesta X-Cache-Status (HIT, MISS, BYPASS, EXPIRED)

Qué simula este componente

Función CDN	Implementación en NGINX
Caché en el edge	`proxy_cache` con almacenamiento en disco
Generación de clave de caché	`proxy_cache_key` basada en esquema, host y URI
Extracción desde el origen	`proxy_pass` al balanceador de carga HTTP de F5 XC
Terminación TLS	Directiva `ssl_certificate` de NGINX
Respeto a Cache-Control	`proxy_cache_valid` con reenvío de cabeceras del origen
Reporte del estado de caché	`add_header X-Cache-Status $upstream_cache_status`
Endpoint de salud	Localización `/health` que devuelve 200 OK

Endpoints y comportamiento de solicitudes/respuestas

Verificación de salud

GET /health

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

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

Proxy CDN (todas las demás rutas)

GET /<any-path>

Cabeceras de solicitud inyectadas hacia el origen (más de 67 cabeceras de 5 proveedores):

Categoría	Cabeceras añadidas
IP del cliente	`True-Client-IP`, `CF-Connecting-IP`, `Fastly-Client-IP`, `X-Azure-ClientIP`, `CloudFront-Viewer-Address`, `X-Forwarded-For`, `X-Real-IP`
Geolocalización	`X-Akamai-Edgescape` (compuesta), `CF-IPCountry`, `cf-ipcity`, `cf-iplatitude/longitude`, `CloudFront-Viewer-Country/City/Latitude/Longitude`, `X-Geo-Country-Code/City/Region`
Detección de dispositivo	`CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Tablet-Viewer`, `X-Akamai-Device-Characteristics`
TLS/Huella digital	`CloudFront-Viewer-TLS`, `cf-ja3-hash`, `cf-ja4`, `CloudFront-Viewer-JA3-Fingerprint`
Detección de bots	`cf-bot-score` (85 = probablemente humano), `cf-verified-bot`
Trazado de solicitudes	`Cf-Ray`, `X-Akamai-Request-ID`, `X-Amz-Cf-Id`, `X-Azure-Ref`
Identidad del edge	`X-CDN-Edge`, `X-CDN-POP`, `X-Served-By`, `Fastly-FF`, `X-Azure-FDID`
Estándar	`Via`, `Forwarded`, `CDN-Loop`, `X-Forwarded-Proto/Host/Port`

Cabeceras de respuesta añadidas a cada respuesta proxificada:

Cabecera	Valores	Propósito
`X-Cache-Status`	`HIT`, `MISS`, `BYPASS`, `EXPIRED`, `STALE`	Comportamiento de la caché para esta solicitud
`X-CDN-Edge`	`cdn-simulator`	Identifica este nodo edge
`X-CDN-POP`	`SJC`	Código IATA del punto de presencia simulado
`X-Served-By`	`cache-sjc3120-SJC`	Nodo de caché simulado en formato Fastly
`X-Request-ID`	UUID (por solicitud)	Identificador único de solicitud

Comportamiento de la caché

Primera solicitud a cualquier ruta: X-Cache-Status: MISS (obtenida desde el origen y almacenada en caché)
Solicitudes idénticas posteriores: X-Cache-Status: HIT (servida desde la caché en disco)
Clave de caché: $scheme$host$request_uri (esquema + nombre de host + ruta completa + cadena de consulta)
TTL de caché: 10 minutos para 200/301/302, 1 minuto para 404
Servicio desde caché obsoleta: devuelve contenido en caché ante errores del origen (500/502/503/504)

Acceso a la VM

Método de acceso	Comando/Ruta
SSH	`ssh azureuser@<PUBLIC_IP>`
Configuración de NGINX	`/etc/nginx/conf.d/cdn-edge.conf`
Registros de NGINX	`/var/log/nginx/access.log` y `/var/log/nginx/error.log`
Directorio de caché	`/var/cache/nginx/cdn/`
Registro de cloud-init	`/var/log/cloud-init-output.log`

Diseño modular de componentes

Este es uno de los elementos de un entorno de laboratorio más amplio. Cada componente es autónomo y se despliega de forma independiente:

Este componente proporciona el edge CDN (NGINX en una VM de Azure)
Otros componentes proporcionan la aplicación de origen, la configuración de F5 XC, DNS, políticas WAF, etc.

El operador humano añade componentes de uno en uno. La documentación de cada componente está redactada para que un asistente de IA pueda leerla y desplegar la infraestructura de forma autónoma.

Por qué NGINX

NGINX fue seleccionado como motor de simulación CDN porque:

Producto F5 — F5 adquirió NGINX Inc. en 2019; forma parte del portafolio de F5
Probado en la industria — Cloudflare ejecutó su CDN completo sobre NGINX durante más de una década antes de migrar a Pingora; Netflix utiliza NGINX para su CDN Open Connect
Proceso único — gestiona la terminación TLS y el almacenamiento en caché en un único binario, a diferencia de Varnish, que requiere un proxy TLS separado
Despliegue sencillo — apt install nginx en Ubuntu 24.04; dos directivas habilitan el almacenamiento en caché
Bien documentado — extensa documentación oficial sobre caché de contenido y configuración de proxy inverso