¿Qué es el almacenamiento en caché de CDN?
El almacenamiento en caché en una CDN guarda copias del contenido en ubicaciones perimetrales distribuidas geográficamente. Las solicitudes pueden atenderse cerca de sus destinatarios sin recuperar repetidamente la misma representación del origen.
Cómo funciona el almacenamiento en caché de CDN
Una CDN asigna una solicitud a una ubicación perimetral e intenta reutilizar un objeto almacenado allí o en un nodo de protección intermedio. Si no lo encuentra en caché, la red recupera la representación de una caché anterior o del origen y luego la almacena según las reglas de vigencia y elegibilidad. Cada ubicación llena su propia caché, por lo que un objeto ya disponible en caché en una región puede no encontrarse en la de otra, y un objeto poco solicitado puede expulsarse antes de que caduque. En el caso del contenido multimedia, los segmentos inmutables y los derivados pueden tener tiempos de vida prolongados, mientras que los manifiestos y las respuestas que dependen de la autorización suelen requerir plazos más cortos o un tratamiento más selectivo.
Datos clave
- El manifiesto de un flujo y sus segmentos multimedia necesitan tiempos de vida distintos. En HLS, una lista de reproducción multimedia en directo se sustituye por una versión nueva con al menos un segmento nuevo aproximadamente una vez por cada duración objetivo (la RFC 8216 exige que esto ocurra no antes de la mitad ni después de una vez y media esa duración), por lo que un nodo perimetral que conserve la lista de reproducción durante más tiempo oculta los segmentos nuevos a los reproductores. Una lista de reproducción marcada con
VODno debe cambiar y puede almacenarse en caché como un archivo estático. Los segmentos se obtienen por separado de la lista de reproducción, cada uno con su propia URL o como un rango de bytes de un archivo más grande, y pueden tener tiempos de vida prolongados siempre que el empaquetador nunca cambie los bytes asociados a una URL publicada, algo que la especificación no garantiza por sí misma. El borrador de la segunda edición de HLS de Apple recomienda, en su perfil de servidor de baja latencia, almacenar las respuestas de listas de reproducción normales en caché durante la mitad de la duración objetivo y usarCache-Controlpara comunicar ese tiempo de vida. - La clave de caché determina qué solicitudes comparten una entrada, y su valor predeterminado varía según la CDN. La clave predeterminada de Amazon CloudFront consta del nombre de dominio de la distribución y la ruta de la URL, sin cadenas de consulta, encabezados ni cookies. La de Cloudflare incluye el esquema, el host y la ruta con la cadena de consulta, además del encabezado
Originde la solicitud, por lo que la misma URL se almacena por separado según se obtenga con o sinOrigin. Google Cloud CDN utiliza la URI completa de la solicitud para los servicios de backend. Las solicitudes comparten una entrada siempre que sus claves sean idénticas, algo que ya puede ocurrir con una configuración predeterminada: con la de CloudFront, las URL que solo difieren en la cadena de consulta reciben la misma respuesta almacenada en caché. Incluye en la clave todos los valores de la solicitud que cambien la respuesta y excluye los demás, porque un componente que varía entre solicitudes sin cambiar la respuesta fragmenta la caché y reduce la proporción de aciertos. - Para archivos grandes, averigua cómo gestiona la CDN las solicitudes
Range, porque esto modifica la carga del origen y el comportamiento al desplazarse por la línea de tiempo del contenido multimedia. CloudFront reenvía al origen los rangos que no tiene almacenados, posiblemente solicitando un rango mayor, y almacena en caché la parte devuelta; si el origen no admite rangos, CloudFront recibe y almacena en caché el objeto completo. Google Cloud CDN llena su caché mediante sus propias solicitudes de rangos de bytes una vez que ha registrado que el origen las admite, lo que requiereAccept-Ranges: bytes, una longitud total conocida y tantoLast-Modifiedcomo unETagfuerte. Cuando el origen no ofrece esa compatibilidad, aplica un tamaño máximo de almacenamiento en caché mucho menor. Fastly almacena en caché los objetos grandes por partes solo cuando la caché segmentada está habilitada. Por tanto, que el origen responda correctamente a las solicitudes de rango es un requisito previo para almacenar en caché contenido multimedia de gran tamaño por partes. - La decisión de si una respuesta puede almacenarse en caché se toma por separado del tiempo durante el que se mantiene fresca, y la regla depende del proveedor. De forma predeterminada, Cloudflare almacena en caché según la extensión del archivo y no almacena HTML ni JSON sin una regla. El modo predeterminado de Google Cloud CDN almacena en caché tipos de contenido estático según
Content-Typey necesita directivas explícitas para HTML y JSON. Google Cloud CDN no almacena en caché las respuestas que establecen una cookie; Cloudflare, según su configuración, las deja sin almacenar en caché o elimina la cookie y las almacena. Cuando no se produce un acierto esperado, consulta el estado de caché que informa la CDN: en Cloudflare, el encabezado de respuestaCF-Cache-StatusmuestraMISScuando la respuesta cumplía los requisitos, pero no estaba en esa caché;BYPASScuando la respuesta del origen no podía almacenarse en caché; yDYNAMICcuando la solicitud nunca cumplió los requisitos para usar la caché.
Cuándo es importante el almacenamiento en caché de CDN
Configura el almacenamiento en caché de CDN para reducir la latencia del contenido multimedia, disminuir la carga del origen y absorber los picos de tráfico. Las claves de caché o las reglas de frescura inadecuadas pueden hacer que se sirvan variantes incorrectas o que los usuarios reciban contenido desactualizado.
Cómo ayuda Transloadit con el almacenamiento en caché de CDN
Smart CDN de Transloadit sitúa una caché de CDN delante del procesamiento bajo demanda. Las solicitudes a una URL tlcdn.com se atienden mediante el Robot /tlcdn/deliver, que almacena los resultados en caché y los sirve desde ubicaciones perimetrales. Cuando se produce un fallo de caché, se ejecuta la Assembly del Template; cuando hay un acierto, el nodo perimetral responde sin ejecutar nada. Los valores de Cache-Control enviados por el Robot /file/serve establecen durante cuánto tiempo se mantiene fresco un resultado almacenado en caché.
La primera solicitud de una URL que no está en caché incluye el tiempo de obtención y procesamiento del contenido de origen. Los tiempos de vida predeterminados actuales se indican en la página de /file/serve y no se repiten aquí porque pueden cambiar.
Fuentes
- RFC 9111: almacenamiento en caché HTTP (claves de caché, almacenamiento de respuestas parciales, frescura)
- RFC 8216: HTTP Live Streaming, sección 6.2 (cómo actualizan los servidores las listas de reproducción)
- HTTP Live Streaming, edición 2 (Internet-Draft 22), apéndice B, apartado 1: tiempos de vida recomendados para la caché
- Amazon CloudFront: comprende la clave de caché
- Amazon CloudFront: cómo procesa CloudFront las solicitudes parciales de un objeto (solicitudes GET de rango)
- Cloudflare: claves de caché
- Cloudflare: comportamiento predeterminado de la caché (requisitos para almacenar en caché, extensiones de archivo predeterminadas, agrupación de solicitudes)
- Cloudflare: respuestas de la caché (valores de CF-Cache-Status)
- Cloudflare: solicitudes HEAD y encabezados Set-Cookie (cuándo se almacena en caché una respuesta que establece una cookie)
- Google Cloud CDN: descripción general del almacenamiento en caché (contenido que puede almacenarse en caché, claves de caché, solicitudes de rangos de bytes)
- Fastly: caché segmentada