Qué es un CDN y cómo funciona

Si tu servidor está en Nueva York y el visitante en Tokio, cada solicitud cruza el planeta dos veces: de ida y de vuelta. La luz en la fibra tiene una velocidad finita, así que la distancia se convierte en tiempo de espera. Una página con 40 archivos sufre ese retraso muchas veces.

El CDN ataca ese problema poniendo copias del contenido cerca de quien lo pide. El resultado es un sitio más rápido, un servidor menos presionado y menos daño cuando el tráfico se dispara de golpe.

¿Qué es un CDN?#

CDN significa Content Delivery Network, o red de distribución de contenido. Según la definición de MDN, es un grupo de servidores repartidos en muchos lugares que guardan copias de los datos para que cada solicitud la atienda el servidor más cercano al usuario.

Tres términos aparecen siempre:

• Origen: tu propio servidor, donde vive el contenido original.
• Punto de presencia (PoP): una ubicación física del CDN, en un centro de datos, con varios servidores.
• Edge (borde): los servidores del CDN más cercanos al visitante.

El CDN actúa como intermediario: el visitante habla con él, y él solo habla con el origen cuando hace falta.

¿Cómo funciona un CDN?#

El camino de una solicitud tiene cuatro pasos:

1. El visitante pide https://www.ejemplo.com/logo.png. El DNS devuelve una dirección del CDN, no la de tu origen.
2. La solicitud llega al PoP más cercano. Muchos CDN usan anycast: la misma dirección IP se anuncia desde varios PoP, y el propio enrutamiento de internet lleva al visitante al más cercano.
3. Si el PoP ya tiene una copia válida del archivo, responde al instante. Eso es un cache hit.
4. Si no la tiene, la pide al origen, responde al visitante y guarda la copia para los siguientes. Eso es un cache miss.

Solo el primer visitante de cada PoP paga el costo de ir hasta el origen, hasta que la copia vence. Los siguientes reciben la copia guardada. Por eso el origen recibe una fracción de las solicitudes, aunque el sitio tenga mucho tráfico.

¿Qué guarda un CDN en caché?#

Lo que más conviene cachear es el contenido igual para todos los visitantes:

• Archivos estáticos: CSS, JavaScript, fuentes, imágenes, videos y descargas.
• Páginas estáticas: los sitios generados (HTML ya listo) pueden servirse enteros desde el CDN.
• Respuestas públicas de API: una lista de productos igual para todos puede quedar en caché unos segundos.

Lo que no debe cachearse: respuestas personalizadas, como el panel de un usuario autenticado o un carrito de compras. Si una respuesta así se guardara en una caché compartida, otro visitante podría recibirla.

¿Cómo sabe el CDN cuánto tiempo guardar una copia?#

Lo decide tu origen, mediante la cabecera Cache-Control de la respuesta. Los valores que más importan para un CDN:

Un ejemplo práctico: los archivos con hash en el nombre cambian de URL cuando cambia su contenido, así que pueden guardarse un año. El HTML necesita caché corta en el navegador, pero puede quedarse más tiempo en el CDN.

Para /assets/app.3f9a1c.js:

Cache-Control: public, max-age=31536000, immutable

Para /index.html:

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60

Los detalles de cada directiva están en qué es Cache-Control. La semántica de la caché compartida se define en la RFC 9111, y stale-while-revalidate en la RFC 5861.

¿Cómo saber si la respuesta vino de la caché?#

Pide solo las cabeceras con curl y ejecuta el comando dos veces:

curl -sI https://www.ejemplo.com/assets/app.3f9a1c.js

Busca Age, que indica hace cuántos segundos está guardada la copia. Si aparece con un valor mayor que cero, la respuesta vino de una caché intermedia. Age: 0, o su ausencia, no prueba que haya venido del origen. Muchos CDN también envían una cabecera propia con HIT o MISS, pero el nombre varía según el proveedor (consulta la documentación del tuyo). En la primera llamada suele ser MISS; en la segunda, HIT.

¿Cuándo no ayuda un CDN?#

• Contenido personalizado o en tiempo real: sin caché, cada solicitud sigue yendo al origen. El CDN puede acortar el handshake TLS, pero la distancia hasta el origen permanece.
• Público concentrado cerca del origen: si todos los visitantes están en la misma ciudad que el servidor, casi no hay latencia que ahorrar.
• Caché mal configurada: sin un Cache-Control claro, cada CDN aplica sus propias reglas por defecto, y puedes servir un archivo viejo o no aprovechar nunca la caché.
• Dependencia de terceros: si cargas librerías desde un CDN público y este cae o es bloqueado, tu sitio se rompe. Si se ve comprometido, puede entregar código malicioso. Usa Subresource Integrity (el atributo integrity, con crossorigin="anonymous", en <script>) para que el navegador rechace un archivo alterado.

CDN, balanceador de carga y proxy inverso: ¿en qué se diferencian?#

Los tres están entre el visitante y la aplicación, y por eso se confunden. El balanceador de carga reparte solicitudes entre varios servidores tuyos. El CDN guarda copias en muchos lugares del mundo. En la práctica, un CDN es un proxy inverso distribuido con caché, y muchos incluyen también balanceo, WAF y protección contra DDoS.

Cómo hacerlo en Square Cloud#

Todos los planes de Square Cloud incluyen CDN global, tráfico ilimitado (sin cobro por ancho de banda ni por solicitud, bajo una política de uso justo), TLS automático, WAF y protección DDoS L3/L4/L7. Tu aplicación web recibe un subdominio *.squareweb.app con HTTPS y, desde el plan Standard, puedes usar un dominio personalizado.

La red es un CDN Anycast con más de 200 puntos de presencia, HTTP/3 y WebSockets. El CDN guarda en caché según el Cache-Control de tu aplicación, y hay purga de caché tanto en el subdominio squareweb.app como en el dominio propio. Para usar tu dominio propio, creas en tu registrador los registros DNS que te muestra el panel.

Mira los detalles de la red en Red y CDN de Square Cloud.