⏱️ Lectura: 14 min
Netflix no manda cada serie desde un data center en California: la copia miles de veces dentro de cajas metálicas instaladas directamente en los routers de tu proveedor de internet, un proyecto que la empresa llama Open Connect. Eso es, en esencia, un CDN: una red de servidores que acerca el contenido al usuario en lugar de hacer viajar cada bit desde un único origen.
📑 En este artículo
- TL;DR
- Qué es un CDN y por qué importa
- Cómo funciona un CDN por dentro
- Anycast: cómo el mismo IP responde desde el lugar correcto
- Ejemplos prácticos
- Cómo empezar paso a paso
- Casos de uso reales
- Errores comunes y buenas prácticas
- Comparativa con alternativas
- Profundizando (avanzado)
- Preguntas frecuentes
- Referencias
Cuando entendés cómo funciona un CDN (qué guarda en caché, cómo decide desde qué servidor responder y cuándo esa copia caduca) podés acelerar cualquier sitio, sea un blog personal o una aplicación con millones de usuarios. Esta nota explica el mecanismo completo, con comandos y configuración real para probarlo hoy mismo.
TL;DR
- Vas a entender qué pasa cuando pedís una página: cache hit, cache miss y TTL explicados paso a paso.
- Vas a poder leer las cabeceras Cache-Control, Age y X-Cache-Status de cualquier sitio con curl.
- Vas a saber configurar proxy_cache en Nginx para servir contenido cacheado desde tu propio proxy.
- Vas a entender por qué anycast permite que una misma IP responda desde el punto más cercano al usuario.
- Vas a poder escribir un Cloudflare Worker que cachea respuestas manualmente con la Cache API.
- Vas a identificar y evitar un cache stampede cuando muchos usuarios piden el mismo recurso vencido.
- Vas a saber elegir entre Cloudflare, CloudFront, Fastly o un proxy propio según tu presupuesto y escala.
Qué es un CDN y por qué importa
Un CDN (red de distribución de contenido, del inglés Content Delivery Network) es un conjunto de servidores distribuidos geográficamente que guardan copias de un mismo contenido y lo entregan desde el punto más cercano a quien lo pide. En vez de que cada visita viaje hasta el servidor original (el origen), la mayoría de las peticiones se resuelven en un servidor intermedio llamado edge o punto de presencia (PoP).
La razón de existir de un CDN es física: la luz tarda un tiempo mínimo en recorrer un cable de fibra óptica, y ese tiempo se multiplica por la cantidad de saltos de red entre el usuario y el servidor. Un usuario en Buenos Aires pidiendo un archivo alojado en Virginia atraviesa varios proveedores de tránsito antes de recibir respuesta. Si ese mismo archivo está cacheado en un PoP más cercano, la distancia (y la latencia) se reduce drásticamente.
Pero un CDN no es solo velocidad. También absorbe picos de tráfico: si diez mil usuarios piden la misma imagen, el edge la sirve desde caché sin tocar el origen ni una vez. Además reduce el ancho de banda que pagás en tu servidor de origen y actúa como primera línea de defensa contra ataques de denegación de servicio, porque el tráfico se filtra antes de llegar al backend real.
Cómo funciona un CDN por dentro
El mecanismo central es el caché HTTP. Cuando un navegador pide un recurso, el servidor puede responder con la cabecera Cache-Control, que le dice a cualquier intermediario (el navegador mismo, un proxy o el edge del CDN) cuánto tiempo puede guardar esa respuesta antes de volver a pedirla. Ese tiempo se llama TTL (time to live).
La primera vez que un edge recibe una petición para un recurso que no tiene guardado ocurre un cache miss: el edge repite la petición contra el origen, guarda la respuesta según el TTL indicado y se la entrega al usuario. La segunda vez que alguien pide lo mismo, mientras el TTL no haya vencido, ocurre un cache hit: el edge responde directamente desde su copia local, sin contactar al origen.
sequenceDiagram
participant U as Usuario
participant E as Edge CDN
participant O as Origen
U->>E: pide /imagen.jpg
alt cache miss
E->>O: solicita el recurso
O-->>E: responde con el archivo
E-->>U: entrega y guarda copia en cache
else cache hit
E-->>U: responde desde cache local
endEl diagrama muestra ambos caminos. En el primero, el edge actúa de intermediario transparente y paga el costo de latencia una sola vez por todos los usuarios que pidan ese recurso mientras dure el TTL. En el segundo, el edge resuelve todo localmente, sin ida y vuelta al origen.
Anycast: cómo el mismo IP responde desde el lugar correcto
Un CDN grande no tiene una sola dirección IP por servidor: usa anycast, una técnica de enrutamiento en la que la misma dirección IP se anuncia desde decenas o cientos de ubicaciones distintas mediante el protocolo BGP. La red de routers de internet decide, en cada momento, cuál de esos anuncios queda más cerca en términos de saltos de red, y enruta la petición del usuario hacia ese punto.
Esto es lo que permite que una IP como 1.1.1.1 responda en milisegundos sea cual sea el país desde el que se la consulte: no hay un solo servidor con esa dirección, hay cientos, y BGP elige el camino más corto en cada caso sin que la aplicación cliente tenga que saber nada al respecto.
flowchart TD
A["Usuario en Lima"] --> B["PoP mas cercano: Bogota"]
C["Usuario en Madrid"] --> D["PoP mas cercano: Madrid"]
B --> E[("Origen: servidor central")]
D --> E
subgraph "Red CDN"
B
D
endEjemplos prácticos
Estos cuatro ejemplos van de lo más simple (inspeccionar cabeceras con curl) a un caso real de caché programable en el edge.
El primero no requiere instalar nada: sirve para ver el caché en acción en cualquier sitio que ya use un CDN.
curl -I https://developer.mozilla.org/El flag -I pide solo las cabeceras. Buscá cache-control, age (segundos desde que el edge guardó la copia) y, si el sitio usa Cloudflare o Fastly, cf-cache-status o x-cache con valores como HIT o MISS.
El segundo ejemplo controla el TTL desde tu propio servidor de origen, algo que cualquier CDN respeta:
const express = require('express');
const app = express();
app.use('/static', express.static('public', {
maxAge: '7d',
setHeaders: (res) => {
res.setHeader('Cache-Control', 'public, max-age=604800, immutable');
}
}));
app.listen(3000);Este código sirve la carpeta public con un Cache-Control de siete días y la directiva immutable, que le dice al navegador y al CDN que ese archivo nunca va a cambiar mientras tenga ese nombre (útil para assets con hash en el nombre, como app.a1b2c3.js).
El tercer ejemplo levanta un proxy con caché propio usando Nginx:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m max_size=1g inactive=60m use_temp_path=off;
server {
listen 80;
location / {
proxy_cache static_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_pass http://origin_backend;
add_header X-Cache-Status $upstream_cache_status;
}
}Esta configuración cachea respuestas 200 y 302 durante 10 minutos, y errores 404 durante 1 minuto (para no volver a pegarle al origen constantemente por una URL rota). La cabecera X-Cache-Status expone el resultado en cada respuesta.
El cuarto ejemplo va un paso más allá: caché programable en el edge con un Cloudflare Worker:
addEventListener('fetch', (event) => {
event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
const cache = caches.default;
let response = await cache.match(request);
if (!response) {
response = await fetch(request);
response = new Response(response.body, response);
response.headers.append('Cache-Control', 'max-age=3600');
event.waitUntil(cache.put(request, response.clone()));
}
return response;
}Acá el propio código decide qué cachear y por cuánto tiempo, algo imposible con un CDN tradicional configurado solo por cabeceras. Es la base de lo que se conoce como edge compute.
Cómo empezar paso a paso
Podés reproducir el comportamiento de un CDN en tu máquina con dos contenedores: uno que simula el origen y otro que simula el edge con caché.
docker run -d --name origin -p 8080:80 nginx
docker run -d --name cdn-cache -p 80:80 -v $(pwd)/nginx-cache.conf:/etc/nginx/conf.d/default.conf nginx
curl -I http://localhost/index.html
curl -I http://localhost/index.htmlEl archivo nginx-cache.conf es la configuración de proxy_cache del ejemplo anterior, apuntando proxy_pass a http://origin:80. La primera llamada a curl va a mostrar X-Cache-Status: MISS (fue al origen). La segunda va a mostrar HIT, servida enteramente desde el contenedor cdn-cache sin tocar el origen. Esa es la comprobación concreta de que el caché está activo: no hace falta creerlo, se verifica en la cabecera.
Casos de uso reales
Los sitios estáticos (blogs, documentación, landing pages) son el caso más simple: casi todo el contenido puede tener un TTL largo porque cambia poco. El streaming de video, como el caso de Netflix mencionado al inicio, usa el mismo principio a otra escala: los episodios más vistos se replican en miles de appliances dentro de redes de proveedores de internet para no saturar los enlaces troncales.
Las APIs también se benefician, aunque con cuidado: respuestas públicas y no personalizadas (un catálogo de productos, tipos de cambio) pueden cachearse por segundos o minutos, mientras que respuestas con datos de sesión nunca deberían pasar por caché compartido. Los repositorios de paquetes (registries de npm, imágenes de Docker Hub) también dependen de CDNs para no colapsar cuando miles de builds de CI descargan la misma dependencia al mismo tiempo.
Errores comunes y buenas prácticas
El error más peligroso es cachear una respuesta que depende de datos del usuario (una cookie de sesión, un token) sin declararlo. Si el edge no sabe que la respuesta varía según esos datos, puede servirle a un usuario el contenido personalizado de otro: eso se conoce como cache poisoning por cabeceras no consideradas en la clave de caché.
⚠️ Ojo: si tu respuesta cambia según una cookie o un header de autorización, agregá ese header a la directiva Vary o excluí la ruta del caché por completo. De lo contrario, el primer usuario que pida esa URL define lo que ven todos los demás mientras dure el TTL.
Otro problema clásico es el cache stampede: cuando el TTL de un recurso muy popular vence, decenas de peticiones simultáneas llegan al edge, todas encuentran un miss a la vez y todas golpean el origen al mismo tiempo, como si el caché no existiera. La solución habitual es request coalescing: el edge deja pasar una sola petición al origen y hace esperar (o sirve una copia vieja) al resto hasta que llegue la respuesta fresca.
💡 Tip: la directiva stale-while-revalidate de Cache-Control resuelve esto de forma declarativa: el edge sirve la copia vencida al instante mientras revalida en segundo plano, en vez de dejar a todos esperando.
Por último, un olvido frecuente en despliegues: cambiar el contenido del origen sin purgar el caché del CDN. Si el HTML tiene un TTL de una hora y hacés un deploy urgente, esa hora corre igual salvo que dispares una purga manual vía la API del proveedor.
Comparativa con alternativas
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Cloudflare (plan free) | Blogs y sitios pequeños o medianos | Gratis, red anycast global, protección DDoS básica incluida | Purga y reglas de caché avanzadas requieren plan pago |
| AWS CloudFront | Apps que ya viven en AWS | Integración directa con S3 y Lambda@Edge | Facturación por región y por función más compleja de estimar |
| Fastly | Alto tráfico con necesidad de purga instantánea | Purga en milisegundos, VCL configurable a bajo nivel | Curva de aprendizaje de VCL más pronunciada |
| Nginx o Varnish propio | Control total, sin depender de un SaaS | Sin vendor lock-in, config 100% en tus manos | Vos operás la infraestructura, sin red global real |
| Sin CDN (solo origen) | Apps internas o de tráfico muy bajo | Simplicidad, un solo punto que mantener | Latencia alta para usuarios lejanos, sin resiliencia ante picos |
Profundizando (avanzado)
La composición de la clave de caché (cache key) es lo que más rompe en producción. Por defecto, muchos CDNs cachean por URL completa incluyendo query strings, lo que significa que /producto?ref=twitter y /producto?ref=facebook generan dos entradas distintas del mismo contenido. Ajustar la clave para ignorar parámetros de tracking es una optimización habitual que multiplica el ratio de hits sin cambiar una línea del backend.
El negative caching (guardar en caché también las respuestas de error, como se ve en el ejemplo de Nginx con los 404 a 1 minuto) evita que un recurso inexistente genere una tormenta de peticiones al origen cada vez que alguien lo pide por error o por un bot mal configurado.
Los CDNs más grandes usan además una arquitectura de múltiples capas: un PoP de borde cerca del usuario, y detrás un nivel intermedio llamado origin shield que agrupa los misses de muchos PoPs distintos antes de llegar al origen real. Así, aunque haya cien puntos de presencia en el mundo, el origen solo ve una fracción del tráfico total de misses.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: levantá los dos contenedores del ejemplo de Docker, hacé el curl dos veces seguidas y confirmá con tus propios ojos el cambio de MISS a HIT en X-Cache-Status.
Preguntas frecuentes
¿Un CDN sirve solo para archivos estáticos?
No. Aunque los estáticos son el caso más simple, un CDN también puede cachear respuestas de API públicas, hacer edge compute con Workers o Lambda@Edge, y actuar como proxy inverso para todo el tráfico, incluido el contenido dinámico que decidís no cachear.
¿Qué diferencia hay entre un CDN y un proxy inverso?
Un proxy inverso (como Nginx sin más configuración) reenvía peticiones a un backend. Un CDN es una red de muchos proxies inversos con caché, distribuidos geográficamente y con ruteo anycast, pensados específicamente para acercar contenido al usuario final.
¿Cómo invalido el caché cuando actualizo contenido?
Con la API de purga del proveedor (por URL, por tag o total), o diseñando URLs versionadas (con hash en el nombre del archivo) que nunca necesitan purgarse porque cada versión tiene su propia dirección.
¿Un CDN mejora el SEO?
Indirectamente sí: los motores de búsqueda consideran la velocidad de carga como factor de ranking, y reducir la latencia con un CDN suele mejorar métricas como el Largest Contentful Paint.
¿Necesito un CDN si mi sitio es pequeño?
No es obligatorio, pero incluso planes gratuitos de Cloudflare aportan protección básica contra picos de tráfico y ataques, además de la mejora de latencia, sin costo de infraestructura adicional.
¿Qué es un cache stampede y cómo se evita?
Es cuando muchas peticiones simultáneas encuentran el mismo recurso vencido y todas golpean el origen a la vez. Se evita con request coalescing (una sola petición pasa, el resto espera) o con la directiva stale-while-revalidate.
Referencias
- Cloudflare Cache docs: referencia oficial de cómo Cloudflare cachea y purga contenido en el edge.
- MDN: Cache-Control: especificación completa de la cabecera HTTP y sus directivas.
- Nginx: Reverse Proxy Caching Example: guía oficial para configurar proxy_cache.
- Netflix Open Connect: descripción del programa de CDN propio de Netflix.
- Wikipedia: Content delivery network: contexto histórico y arquitectura general de los CDN.
- Wikipedia: Border Gateway Protocol: cómo funciona el protocolo de ruteo que hace posible anycast.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios