Compartir a través de

Cómo funciona el almacenamiento en caché

  • Artículo

Importante

Azure CDN Estándar de Microsoft (clásico) se retirará el 30 de septiembre de 2027. Para evitar interrupciones del servicio, es importante que migre los perfiles de Azure CDN Estándar de Microsoft (clásico) a los nivel Estándar o Prémium de Azure Front Door antes del 30 de septiembre de 2027. Para más información, consulte Retirada de Azure CDN Estándar de Microsoft (clásico).

Azure CDN de Edgio se retirará el 4 de noviembre de 2025 . Debe migrar la carga de trabajo a Azure Front Door antes de esta fecha para evitar interrupciones del servicio. Para más información, consulte Azure CDN de Edgio retirada de Preguntas frecuentes.

En este artículo se proporciona información general acerca de conceptos generales del almacenamiento en caché y cómo Azure Content Delivery Network usa este almacenamiento en caché para mejorar el rendimiento. Si desea obtener información sobre cómo personalizar el comportamiento de almacenamiento en caché en el punto de conexión de red de entrega de contenido, consulte Control del comportamiento del almacenamiento en caché de Azure Content Delivery Network con reglas de almacenamiento en caché y Control del comportamiento de almacenamiento en caché de Azure Content Delivery Network con cadenas de consulta.

Introducción al almacenamiento en caché

El almacenamiento en caché es el proceso de almacenar datos localmente para que se pueda tener acceso a las futuras solicitudes de esos datos más rápidamente. En el tipo más común de almacenamiento en caché, el almacenamiento en caché del explorador web, un explorador web almacena copias de datos estáticos localmente en una unidad de disco duro local. Mediante el uso del almacenamiento en caché, el explorador web puede evitar la realización de varias ida y vuelta al servidor y, en su lugar, obtener acceso a los mismos datos localmente, lo que permite ahorrar tiempo y recursos. El almacenamiento en caché es ideal para administrar localmente datos pequeños y estáticos como imágenes estáticas, archivos CSS y archivos de JavaScript.

De forma similar, una red de entrega de contenido utiliza el almacenamiento en caché en los servidores perimetrales más cercanos al usuario para evitar que las solicitudes vayan hasta el origen y reducir la latencia del usuario final. A diferencia de una caché del explorador web, que solo se usa para un solo usuario, la red de entrega de contenido tiene una caché compartida. En una caché compartida de la red de entrega de contenido, otro usuario puede usar una solicitud de archivo, lo que reduce considerablemente el número de solicitudes al servidor de origen.

No se almacenan en caché los recursos dinámicos que cambian con frecuencia o son únicos para un usuario individual. Sin embargo, esos tipos de recursos pueden aprovechar la optimización de la aceleración dinámica de sitios (DSA) en la red de entrega de contenido de Azure para mejorar el rendimiento.

El almacenamiento en caché puede producirse en varios niveles entre el servidor de origen y el usuario final:

  • Servidor web: utiliza una caché compartida (para varios usuarios).
  • Red de entrega de contenido: utiliza una caché compartida (para varios usuarios).
  • Proveedor de servicios de Internet (ISP): utiliza una caché compartida (para varios usuarios).
  • Explorador web: utiliza una memoria caché privada (para un usuario).

Cada almacenamiento en caché normalmente administra su propia actualización de recursos y realiza la validación cuando un archivo está obsoleto. Este comportamiento se define en la especificación de almacenamiento en caché de HTTP, RFC 7234.

Actualización de recursos

Dado que un recurso almacenado en caché podría estar obsoleto (en comparación con el recurso correspondiente en el servidor de origen), es importante que cualquier mecanismo de almacenamiento en caché controle cuándo se actualiza el contenido. Para ahorrar en tiempo y ancho de banda consumidos, un recurso en caché no se compara con la versión en el servidor de origen cada vez que se accede a él. En su lugar, siempre que se considere que un recurso en caché está actualizado, se supone que es la versión más reciente y se envía directamente al cliente. Se considera que un recurso almacenado en caché está actualizado cuando su antigüedad es menor que el tiempo o el período definido por una configuración de caché. Por ejemplo, cuando un explorador vuelve a cargar una página web, comprueba que cada recurso almacenado en caché en el disco duro está actualizado y lo carga. Si el recurso no está actualizado (obsoleto), se carga una copia actualizada desde el servidor.

Validation

Si un recurso se considera obsoleto, se le pide al servidor de origen que lo valide para determinar si los datos en el caché aún coinciden con los que hay en el servidor de origen. Si el archivo se ha modificado en el servidor de origen, el almacenamiento en caché actualiza su versión del recurso. En caso contrario, si el recurso está actualizado, los datos se entregan directamente desde la memoria caché sin validarlos primero.

Almacenamiento en caché de la red de entrega de contenido

El almacenamiento en caché es integral a la forma en que funciona una red de entrega de contenido para acelerar la entrega y reducir la carga de origen de recursos estáticos, como imágenes, fuentes y vídeos. En el almacenamiento en caché de la red de entrega de contenido, los recursos estáticos se almacenan de forma selectiva en servidores colocados estratégicamente que son más locales para un usuario y ofrecen las siguientes ventajas:

  • Dado que la mayoría del tráfico web es estático (por ejemplo, imágenes, fuentes y vídeos), el almacenamiento en caché de la red de entrega de contenido reduce la latencia de red moviendo el contenido más cerca del usuario, lo que reduce la distancia que viajan los datos.

  • Al descargar el trabajo en una red de entrega de contenido, el almacenamiento en caché puede reducir el tráfico de red y la carga en el servidor de origen. De este modo se reducen los requisitos de recursos y el costo de la aplicación, incluso si existen grandes cantidades de usuarios.

De forma similar a cómo se implementa el almacenamiento en caché en un explorador web, puede controlar cómo se realiza el almacenamiento en caché en una red de entrega de contenido mediante el envío de encabezados de directiva de caché. Los encabezados de directiva de caché son encabezados HTTP, normalmente agregados por el servidor de origen. Aunque la mayoría de estos encabezados se diseñaron originalmente para abordar el almacenamiento en caché en exploradores cliente, ahora también se usan en todas las memorias caché intermedias, como las redes de entrega de contenido.

Se pueden utilizar dos encabezados para definir la actualización del almacenamiento en caché: Cache-Control y Expires. Cache-Control es más reciente y tiene prioridad sobre Expires, si ambos existen. También hay dos tipos de encabezados que se utilizan para la validación (llamados validadores): ETag y Last-Modified. ETag es más reciente y tiene prioridad sobre Last-Modified, si ambos están definidos.

Encabezados de la directiva de caché

Importante

De forma predeterminada, un punto de conexión de Azure Content Delivery Network que está optimizado para DSA omite los encabezados de directiva de caché y omite el almacenamiento en caché. Para Azure CDN Estándar de perfiles de Edgio, puede ajustar cómo un punto de conexión de Azure Content Delivery Network trata estos encabezados mediante reglas de almacenamiento en caché de red de entrega de contenido para habilitar el almacenamiento en caché. Si son solo perfiles de Azure CDN Premium de Edgio, use el motor de reglas para habilitar el almacenamiento en caché.

Azure Content Delivery Network admite los siguientes encabezados de directiva de caché HTTP, que definen la duración de la caché y el uso compartido de caché.

Cache-Control:

  • Incorporado en HTTP 1.1 para conceder a los editores web más control sobre su contenido y para resolver las limitaciones del encabezado Expires.
  • Invalida el encabezado Expires si este y Cache-Control están definidos.
  • Cuando se usa en una solicitud HTTP del cliente al POP de la red de entrega de contenido, Cache-Control se omite en todos los perfiles de Azure Content Delivery Network de forma predeterminada.
  • Cuando se usa en una respuesta HTTP del servidor de origen al POP de la red de entrega de contenido:

Expira:

  • Encabezado heredado introducido en HTTP 1.0; compatible con versiones anteriores.
  • Usa un tiempo de expiración basado en fechas con precisión de segundos.
  • Similar a Cache-Control: max-age.
  • Se usa cuando no existe Cache-Control.

Pragma:

  • Azure Content Delivery Network no lo respeta de forma predeterminada.
  • Encabezado heredado introducido en HTTP 1.0; compatible con versiones anteriores.
  • Utilizado como un encabezado de solicitud de cliente con la siguiente directiva: no-cache. Esta directiva indica al servidor que debe entregar una versión actualizada del recurso.
  • Pragma: no-cache equivale a Cache-Control: no-cache.

Validadores

Cuando la memoria caché está obsoleta, los validadores de almacenamiento en caché HTTP se utilizan para comparar la versión en caché de un archivo con la versión en el servidor de origen. Azure CDN Standard/Premium de Edgio admite los validadores ETag y Last-Modified de forma predeterminada, mientras que Azure CDN Standard de Microsoft solo admite Last-Modified.

ETag:

  • Azure CDN Standard/Premium de Edgio admite ETag de forma predeterminada, mientras que Azure CDN Estándar de Microsoft no lo admite.
  • ETag define una cadena que es única para cada archivo y versión de un archivo. Por ejemplo, ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Incorporado en HTTP 1.1, es más reciente que Last-Modified. Resulta útil cuando es difícil determinar la fecha de última modificación.
  • Admite la validación sólida y la validación débil; Sin embargo, Azure Content Delivery Network solo admite una validación segura. Para la validación segura, las representaciones de dos recursos deben ser idénticas byte a byte.
  • Una memoria caché valida un archivo que usa ETag mediante el envío de un encabezado If-None-Match con uno o varios validadores ETag en la solicitud. Por ejemplo, If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Si la versión del servidor coincide con un validador de ETag en la lista, envía el código de estado 304 (no modificado) en su respuesta. Si la versión es diferente, el servidor responde con el código de estado 200 (OK) y el recurso actualizado.

Last-Modified:

  • Solo con Azure CDN Estándar/Premium de Edgio, se usa Last-Modified si ETag no forma parte de la respuesta HTTP.
  • Especifica la fecha y hora en la que el servidor de origen determina que se modificó por última vez el recurso. Por ejemplo, Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • En el caso del contenido superior a 8 MB, los servidores back-end de origen deben mantener marcas de tiempo Last-Modified coherentes por recurso. Si se devuelven tiempos Last-Modified incoherentes desde servidores back-end, se producirán errores de coincidencia del validador y errores HTTP 5XX. Es posible que Azure Storage no admita marcas de tiempo Last-Modified coherentes entre réplicas, lo que puede provocar errores de coincidencia del validador similares.
  • Una memoria caché valida un archivo mediante Last-Modified enviando un encabezado If-Modified-Since con una fecha y hora en la solicitud. El servidor de origen compara esa fecha con el encabezado Last-Modified del recurso más reciente. Si el recurso no se ha modificado desde la hora especificada, el servidor devuelve el código de estado 304 (no modificado) en la respuesta. Si se ha modificado el recurso, el servidor devuelve el código de estado 200 (OK) y el recurso actualizado.

Determinación de los archivos que pueden almacenarse en caché

No todos los recursos se pueden almacenar en caché. La siguiente tabla muestra los recursos que pueden almacenarse en caché, según el tipo de respuesta HTTP. No se almacenarán en caché los recursos entregados con respuestas HTTP que no cumplen todas estas condiciones. Solo con Azure CDN Premium de Edgio, puede usar el motor de reglas para personalizar algunas de estas condiciones.

Azure Content Delivery Network de Microsoft Azure Content Delivery Network de Edgio
Códigos de estado HTTP 200, 203, 206, 300, 301, 410, 416 200
Métodos HTTP GET, HEAD OBTENER
Límites de tamaño de archivo 300 GB 300 GB

Para que el almacenamiento en caché de Azure CDN Estándar de Microsoft funcione en un recurso, el servidor de origen debe admitir cualquier solicitud HTTP HEAD y GET y los valores de longitud de contenido deben ser los mismos para cualquier respuesta HTTP HEAD y GET en el recurso. En una solicitud HEAD, el servidor de origen debe admitir la solicitud HEAD y debe responder con los mismos encabezados que si recibiera una solicitud GET.

Nota:

Las solicitudes que incluyen el encabezado de autorización no se almacenarán en caché.

Comportamiento predeterminado del almacenamiento en caché

En la tabla siguiente se describe el comportamiento de almacenamiento en caché predeterminado para los productos de Azure Content Delivery Network y sus optimizaciones.

Microsoft: Entrega web general Edgio: mediante entrega web general Edgio: DSA
Respetar origen Sí Sí No
duración de la caché de red de entrega de contenido Dos días Siete días None

Respetar origen: especifica si se respetan los encabezados de la directiva de caché admitidos, en caso de que existan en la respuesta HTTP del servidor de origen.

Duración de la caché de CDN: especifica la cantidad de tiempo para la que un recurso se almacena en caché en la red de entrega de contenido de Azure. Sin embargo, si Respetar origen es "Sí" y la respuesta HTTP del servidor de origen incluye el encabezado de la directiva de caché Expires o Cache-Control: max-age, Azure CDN usa el valor de duración especificado por el encabezado en su lugar.

Nota:

Azure Content Delivery Network no garantiza la cantidad mínima de tiempo que el objeto se almacenará en la memoria caché. Es posible que el contenido almacenado en caché se expulse de la caché de red de entrega de contenido antes de que expiren si el contenido no se solicita con tanta frecuencia para hacer espacio para el contenido solicitado con más frecuencia.

Pasos siguientes