CDN:Configure CDN cache expiration time

Cómo funciona

Cuando una solicitud llega a un punto de presencia (POP) de CDN, el sistema decide si entrega una copia almacenada en la caché o si recupera el contenido más reciente del servidor de origen. A continuación se evalúan los siguientes pasos por orden de prioridad. Un número menor indica una prioridad más alta.

1. Directivas no-cache del origen: CDN no almacena un recurso en la caché si el servidor de origen responde con Pragma: no-cache, Cache-Control: no-cache, Cache-Control: no-store o Cache-Control: max-age=0. Para forzar el almacenamiento en caché de estos recursos, seleccione Ignore Origin No-Cache Header al configurar la regla de expiración de la caché.

2. Reglas de caché configuradas en la consola: Las reglas configuradas en la consola de CDN tienen prioridad, salvo que el servidor de origen envíe explícitamente una directiva no-cache como se describe en el paso 1. Cuando varias reglas de la consola coinciden con una solicitud, prevalece la que tiene mayor peso. Si el peso es igual, se resuelve según el orden de creación. Una vez que una solicitud coincide con una regla de caché, no se evalúa ninguna otra.

3. Encabezados de respuesta del origen: CDN respeta los encabezados de respuesta HTTP del servidor de origen si la solicitud no coincide con ninguna regla de la consola de CDN, o si la regla coincidente tiene habilitada la opción Honor Origin TTL. La prioridad de los encabezados, de mayor a menor, es la siguiente: Cache-Control > Expires > Last-Modified > ETag.

4. Política predeterminada sin caché: Si una solicitud no coincide con ninguna regla de caché en la consola de CDN y el servidor de origen no devuelve encabezados de respuesta de caché como Cache-Control, CDN aplica una política sin caché.

5. CDN DCDN aplica políticas de caché únicamente a las solicitudes cuyo servidor de origen devuelve un código de estado 200, 203, 206, 300, 301, 308 o 410. Para configurar el tiempo de expiración de códigos de estado como 404, utilice la página Cache Settings > Status Code TTL.

La siguiente tabla describe la lógica de prioridad cuando varias reglas de caché de la consola coinciden con una solicitud:

La siguiente tabla describe cómo se procesa cada encabezado de respuesta del origen:

Lógica de coincidencia de reglas de caché

Las reglas de expiración de la caché de CDN admiten dos tipos de reglas con comportamientos de coincidencia distintos:

• Directory: Utiliza coincidencia por prefijo de ruta. Por ejemplo, al configurar /static/ se incluyen todos los recursos dentro de ese directorio (como /static/image/1.jpg y /static/css/style.css). Al configurar / se incluyen todas las rutas. La ruta del directorio debe comenzar con una barra diagonal (/). Cada regla admite un solo directorio.

• File Extension: Utiliza una coincidencia exacta con la extensión. Introduzca las extensiones sin puntos y separe varias extensiones con comas (por ejemplo, jpg,css,js). Las extensiones solo admiten caracteres alfanuméricos y no hay restricciones sobre tipos específicos. Se pueden configurar los siguientes tipos:

  • Extensiones comunes de recursos estáticos: jpg, png, gif, css, js, html

  • Extensiones de archivos de fuentes: ttf, otf, woff, woff2, eot

  • Extensiones de páginas dinámicas: php, aspx, jsp

  • Cualquier otra extensión alfanumérica

Tenga en cuenta lo siguiente sobre la coincidencia de reglas de caché:

• Cuando varias reglas de caché coinciden con la misma solicitud (por ejemplo, una regla de directorio y una de extensión de archivo), prevalece la que tiene el Weight más alto. Si los pesos son iguales, se resuelve según el orden de creación (gana la regla anterior). Para obtener más información, consulte Cómo funciona.

• Si asocia una condición de regla (configurada en Rule Engine) con una regla de caché, varias condiciones utilizan lógica AND. La solicitud debe cumplir todas las condiciones para que haya coincidencia.

• Si establece una regla general sin caché para todas las extensiones dinámicas (como aspx), compruebe que no afecte a los recursos estáticos que desea almacenar en la caché. Para almacenar archivos de fuentes en la caché, agregue una regla específica con extensiones como ttf,otf,woff,woff2,eot.

Procedimiento

Aplicar cambios de reglas de inmediato

Para aplicar reglas nuevas en toda la red de inmediato, debe borrar manualmente la caché existente. Si modifica una regla, purgue la caché existente mediante la función Purge and prefetch resources. Si agrega una regla nueva, precargue el recurso mediante la función prefetch resource.

Comprobación

Una vez completada la configuración, utilice el comando curl o las herramientas de desarrollo del navegador para inspeccionar los encabezados de respuesta HTTP de un recurso y comprobar que la caché funciona como se espera. Para obtener detalles sobre cuándo entra en vigor un cambio de regla, consulte Aplicar cambios de reglas de inmediato.

curl -I "https://your.domain.com/path/to/file.jpg"

Prácticas recomendadas

• Utilizar nombres de archivo con versiones (recomendado): Cuando actualice un recurso estático como style.css, utilice un nombre de archivo nuevo con una versión o un hash, como style-v2.css o style-a1b2c3d.css, y actualice la referencia en su HTML. Este método garantiza que los usuarios reciban el contenido más reciente de inmediato sin necesidad de purgar manualmente la caché de CDN. Es la forma recomendada de actualizar contenido almacenado en caché.

• Aprovechar la caché del navegador: Habilite Follow POP Cache Policy para reducir las solicitudes repetidas a CDN, mejorar la velocidad de carga y ahorrar tráfico de CDN.

• Evitar duraciones de caché demasiado cortas: Una duración de caché corta provoca que CDN ejecute recuperaciones frecuentes desde el origen. Esto anula los beneficios de la aceleración y aumenta el tráfico y los costos de su servidor de origen.

• Tener precaución con duraciones de caché largas: Una duración de caché larga puede impedir que los clientes reciban actualizaciones de contenido oportunas. Para el contenido que requiere actualizaciones frecuentes, asegúrese de purgar la caché o utilizar nombres de archivo con versiones.

• Sector de videojuegos y escenarios de archivos pequeños: Para recursos de archivos pequeños en el sector de videojuegos (como archivos de configuración y paquetes de recursos) que se actualizan con poca frecuencia (por ejemplo, semanal o quincenalmente), establezca el tiempo de expiración de la caché en 15 días o ajústelo al ciclo real de actualización del recurso. Esto equilibra la velocidad de actualización y el rendimiento de la aceleración. Una duración de caché demasiado corta genera recuperaciones frecuentes desde el origen y reduce los beneficios de la aceleración; una demasiado larga podría entregar contenido obsoleto a los jugadores. (Recomendado) Utilice la función purge and prefetch para actualizar proactivamente la caché cuando se modifique el contenido.

• robots.txt y sitemap.xml: Estos archivos afectan directamente el rastreo de los motores de búsqueda. Configure su duración de caché por separado para evitar que coincidan con una regla de extensión amplia que los almacene en la caché por demasiado tiempo, lo cual retrasaría las actualizaciones. (Recomendado) Para dirigirse únicamente a estos dos archivos, seleccione Directory como tipo, introduzca la ruta específica del archivo (como /robots.txt) en el campo Object y luego establezca un peso alto para anular las reglas de extensión amplias. Si prefiere configurar por extensión de archivo, establezca una duración de caché de 1 hora a 1 día para las extensiones txt,xml. Una regla de extensión se aplica a todos los recursos con esas extensiones, no solo a robots.txt y sitemap.xml. Para sitemaps que se actualizan con frecuencia, establezca la duración de la caché en no más de 1 hora.

Solución de problemas

Para saber cómo solucionar problemas cuando la caché no surte efecto, hay fallos de caché, la tasa de aciertos es baja o el contenido no se actualiza, consulte Troubleshoot cache issues.

Apéndice: Mecanismos de control de caché HTTP

Esta sección proporciona contexto sobre el protocolo. Para conocer el comportamiento de caché correspondiente en los POP, consulte Cómo funciona. El protocolo HTTP utiliza tres tipos de encabezados para el control de la caché:

1. Validación del tiempo de expiración

   Cuando un cliente solicita un recurso a un servidor, ambas partes acuerdan un tiempo de expiración para el recurso. Antes de ese momento, la copia almacenada en la caché se considera válida. Después, la copia almacenada en la caché deja de ser válida.

   En HTTP, se suelen utilizar los siguientes encabezados para controlar la expiración de la caché:

   Encabezado	Versión del protocolo	Descripción	Ejemplo	Tipo
   Pragma	HTTP/1.0	Indica si el contenido debe almacenarse en la caché. Su valor suele ser no-cache, lo que significa que el archivo no debe almacenarse en la caché. Se usa frecuentemente para mantener la compatibilidad con servidores que solo admiten el protocolo HTTP/1.0.	Pragma: no-cache	Solicitud/Respuesta
   Expires	HTTP/1.0	El encabezado de respuesta Expires especifica la fecha y hora en que el contenido almacenado en la caché queda obsoleto. Si se utiliza una fecha no válida, como 0, significa que el recurso ya expiró.	Expires: Wed, 21 Oct 2022 07:28:00 GMT	Respuesta
   Cache-Control	HTTP/1.1	El encabezado de respuesta Cache-Control ofrece un control flexible de la caché mediante diversas directivas. Es el encabezado principal que utilizan los clientes modernos, como los navegadores, para este fin.	Los siguientes tres ejemplos indican que el archivo no debe almacenarse en la caché: Cache-Control: no-cache; Cache-Control: no-store; Cache-Control: max-age=0. Ejemplo de un periodo de validez de caché de 1 hora: Cache-Control: max-age=3600.	Solicitud/Respuesta

2. Validación de etiquetas de recursos

   El servidor incluye una etiqueta de recurso (como un ETag) en su respuesta inicial. Cuando el cliente vuelve a solicitar el mismo recurso, envía esta etiqueta de vuelta al servidor para su validación. Si el recurso no ha cambiado, el servidor responde con un código de estado HTTP 304, lo que permite al cliente usar su copia almacenada en la caché. Si el recurso cambió, el servidor envía el contenido nuevo.

   En HTTP, se suelen utilizar los siguientes encabezados para controlar las versiones de la caché:

   Encabezado	Versión del protocolo	Descripción	Ejemplo	Tipo
   Last-Modified	HTTP/1.0	Indica la hora de la última modificación del recurso.	Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT	Respuesta
   ETag	HTTP/1.1	Proporciona un identificador único para una versión específica de un recurso. La comparación de ETags permite determinar si un recurso cambió. Si no cambió, el servidor de origen no necesita enviar una respuesta completa.	ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"	Respuesta

3. Negociación de contenido

   El software de almacenamiento en caché utiliza una palabra clave para indexar los objetos almacenados en disco. En HTTP/1.0, se usa la URL del recurso como palabra clave. Sin embargo, pueden existir distintas representaciones de un recurso en la misma URL. Para distinguirlas, se requiere más información del cliente, como los encabezados Accept-Language y Accept-Charset. Para admitir la negociación de contenido, HTTP/1.1 introdujo el encabezado Vary en el mensaje de respuesta. Este encabezado enumera qué encabezados de solicitud son obligatorios para la negociación de contenido.

   La negociación de contenido suele utilizar el encabezado HTTP Vary para diferenciar entre distintas copias almacenadas en la caché. Esto permite que diferentes clientes reciban copias distintas al solicitar el mismo recurso: