Almacenamiento en caché con Azure Front Door

  • Artículo

Importante

Azure Front Door (clásico) se retirará el 31 de marzo de 2027. Para evitar cualquier interrupción del servicio, es importante migrar los perfiles de Azure Front Door (clásico) al nivel Estándar o Premium de Azure Front Door en marzo de 2027. Para más información, consulte retirada de Azure Front Door (clásico).

Azure Front Door es una red de entrega de contenido (CDN) moderna con funcionalidades de aceleración dinámica de sitios y equilibrio de carga. Cuando el almacenamiento en caché se configura en la ruta, el sitio perimetral que recibe cada solicitud comprueba su caché para obtener una respuesta válida. El almacenamiento en caché ayuda a reducir la cantidad de tráfico enviado al servidor de origen. Si no hay ninguna respuesta en caché disponible, la solicitud se reenvía al origen.

Cada sitio perimetral de Front Door gestiona su propia caché, y las solicitudes pueden ser atendidas por diferentes sitios perimetrales. Como resultado, es posible que siga viendo que parte del tráfico llega a su origen, aunque haya servido respuestas en caché.

El almacenamiento en caché puede reducir significativamente la latencia y reducir la carga en los servidores de origen. Sin embargo, no todos los tipos de tráfico pueden beneficiarse del almacenamiento en caché. Los recursos estáticos, como imágenes, CSS y archivos JavaScript, son ideales para el almacenamiento en caché. Mientras que los recursos dinámicos, como los puntos de conexión de API autenticados, no deben almacenarse en caché para evitar la pérdida de información personal. Se recomienda tener rutas independientes para recursos estáticos y dinámicos, con el almacenamiento en caché deshabilitado para estos últimos.

Advertencia

Antes de habilitar el almacenamiento en caché, revise exhaustivamente la documentación pública y pruebe todos los escenarios posibles antes de habilitar el almacenamiento en caché. Como se ha indicado anteriormente, con una configuración incorrecta se pueden almacenar accidentalmente en caché datos específicos del usuario que pueden compartir varios usuarios, lo que da lugar a incidentes de privacidad.

Métodos de solicitud

Solo se pueden almacenar en caché las solicitudes que usan el método de solicitud GET. Los demás métodos de solicitud siempre los procesa el proxy mediante la red.

Suministro de archivos grandes

Azure Front Door proporciona archivos grandes sin un límite en el tamaño de los archivos. Si el almacenamiento en caché está habilitado, Front Door usa una técnica denominada object chunking (fragmentación de objetos). Cuando se solicita un archivo grande, Front Door recupera partes más pequeñas del archivo del origen. Después de que Front Door recibe una solicitud de un archivo completo o de intervalos de bytes, el entorno de Front Door solicita el archivo desde el origen en fragmentos de 8 MB.

Una vez que el fragmento llega al entorno de Azure Front Door, se almacena en caché y se sirve inmediatamente al usuario. Después, Front Door realiza una captura previa del siguiente fragmento en paralelo. Este captura previa garantiza que el contenido sigue estando un fragmento por delante del usuario, lo que reduce la latencia. Este proceso continúa hasta que se descarga todo el archivo (si se ha solicitado) o el cliente termina la conexión. Para más información sobre la solicitud de intervalo de bytes, vea RFC 7233.

Front Door almacena en caché los fragmentos cuando se reciben, por lo que no es necesario poner todo el archivo en la caché de Front Door. Las solicitudes posteriores para el archivo o los intervalos de bytes se sirven desde la caché. Si no se almacenan en caché todos los fragmentos, se usa la captura previa para solicitar fragmentos del origen.

Esta optimización se basa en la capacidad del origen para admitir solicitudes de intervalos de bytes. Si el origen no admite solicitudes de intervalo de bytes o si no controla correctamente las solicitudes de intervalo, esta optimización no es eficaz.

Cuando el origen responde a una solicitud con un encabezado Range, debe responder de una de las siguientes maneras:

  • Devuelve una respuesta con intervalos. La respuesta debe usar el código de estado HTTP 206. Además, el encabezado de respuesta Content-Range debe estar presente y debe coincidir con la longitud real del contenido que devuelve el origen. Si el origen no envía los encabezados de respuesta correctos con valores válidos, Azure Front Door no almacena en caché la respuesta y es posible que vea un comportamiento incoherente.

    Sugerencia

    Si el origen comprime la respuesta, asegúrese de que el valor del encabezado Content-Range coincida con la longitud real de la respuesta comprimida.

  • Devuelve una respuesta sin intervalos. Si el origen no puede controlar las solicitudes de intervalo, puede omitir el encabezado Range y devolver una respuesta sin intervalos. Asegúrese de que el origen devuelva un código de estado de respuesta distinto de 206. Por ejemplo, el origen podría devolver una respuesta 200 OK.

Si el origen usa la codificación de transferencia fragmentada (CTE) para enviar datos al POP de Azure Front Door, no se admitirán los tamaños de respuesta superiores a 8 MB.

Compresión de archivos

Consulte cómo mejorar el rendimiento con la compresión de archivos en Azure Front Door.

Azure Front Door (clásico) comprime dinámicamente el contenido en el borde, lo que genera un tiempo de respuesta menor y más rápido para los clientes. Para que un archivo sea válido para la compresión, el almacenamiento en caché debe estar habilitado y el archivo debe ser de un tipo MIME para ser válido para la compresión. Actualmente, Front Door (clásico) no permite cambiar esta lista. La lista actual es:

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-THF"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-THF"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Además, el tamaño del archivo debe estar entre 1 KB y 8 MB, ambos inclusive.

Estos perfiles admiten las codificaciones de compresión siguientes:

Si una solicitud admite la compresión gzip y Brotli, la compresión Brotli tiene prioridad.

Cuando una solicitud de un recurso especifica la compresión y la solicitud genera un error de caché, Azure Front Door (clásico) realiza la compresión del recurso directamente en el servidor POP. Después, el archivo comprimido se envía desde la caché. El elemento resultante se devuelve con un encabezado de respuesta Transfer-Encoding: chunked.

Si el origen usa la codificación de transferencia fragmentada (CTE) para enviar datos comprimidos al PoP de Azure Front Door, no se admitirán los tamaños de respuesta superiores a 8 MB.

Nota

Las solicitudes de rango se pueden comprimir en tamaños diferentes. En Azure Front Door es necesario que los valores de longitud del contenido sean los mismos para cualquier solicitud HTTP GET. Si los clientes envían solicitudes de rango de bytes con el encabezado Accept-Encoding que provoca que el origen responda con diferentes longitudes de contenido, Azure Front Door devolverá un error 503. Puede deshabilitar la compresión en el origen o crear una regla de motor de reglas para quitar el encabezado Accept-Encoding de la solicitud para las solicitudes de rango de bytes.

Comportamiento de las cadenas de consulta

Azure Front Door permite controlar cómo se almacenan los archivos en caché para una solicitud web que contiene una cadena de consulta.

En una solicitud web con una cadena de consulta, esta última es la parte de la solicitud que hay después del signo de interrogación (?). Una cadena de consulta puede contener uno o más pares clave-valor, en los cuales el nombre de campo y su valor están separados por un signo igual (=). Los pares clave-valor están separados entre ellos por una Y comercial (&).

Por ejemplo, la dirección URL http://www.contoso.com/content.mov?field1=value1&field2=value2 contiene dos cadenas de consulta:

  • field1, con un valor de value1.
  • field2, con un valor de value2.

Si hay más de un par clave-valor en una cadena de consulta de una solicitud, no importa el orden en el que se especifiquen.

Al configurar el almacenamiento en caché, se especifica cómo debe controlar la memoria caché las cadenas de consulta. Se admiten estos comportamientos:

  • Ignorar cadena de consulta: en este modo, Azure Front Door pasa las cadenas de consulta del cliente al origen en la primera solicitud y almacena en caché el recurso. Las siguientes solicitudes del recurso que se ofrecen desde el entorno de Front Door omiten las cadenas de consulta hasta que expira el recurso almacenado en caché.

  • Usar cadena de consulta: en este modo, cada solicitud con una dirección URL única, incluida la cadena de consulta, se trata como un recurso único con su propia memoria caché. Por ejemplo, la respuesta desde el origen de una solicitud a www.example.ashx?q=test1 se almacena en caché en el entorno de Front Door y se devuelve en las cachés subsiguientes con la misma cadena de consulta. Se almacena en caché una solicitud de www.example.ashx?q=test2 como un recurso independiente con su propia configuración de período de vida.

    No importa el orden de los parámetros de la cadena de consulta. Por ejemplo, si el entorno de Azure Front Door incluye una respuesta almacenada en caché para la dirección URL www.example.ashx?q=test1&r=test2, también se atiende una solicitud para www.example.ashx?r=test2&q=test1 desde la memoria caché.

  • Omitir las cadenas de consulta especificadas e Incluir las cadenas de consulta especificadas: en este modo, puede configurar Azure Front Door para incluir o excluir los parámetros especificados cuando se genera la clave de caché.

    Por ejemplo, supongamos que la clave de caché predeterminada es /foo/image/asset.html y se realiza una solicitud a la dirección URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Si hay una regla del motor de reglas para excluir el parámetro de cadena de consulta userid, la clave de caché de cadenas de consulta sería /foo/image/asset.html?language=EN&sessionid=200.

Configure el comportamiento de la cadena de consulta en la ruta de Front Door.

Purga de la memoria caché

Consulte Purga de caché en Azure Front Door para obtener información sobre cómo configurar la purga de caché.

Azure Front Door almacena en caché los recursos hasta que el período de vida de dichos recursos (TTL) expira. Siempre que un cliente solicita un recurso con un período de vida expirado, el entorno de Front Door recupera una nueva copia actualizada de este para atender la solicitud y almacena en caché la versión actualizada.

El procedimiento recomendado para asegurarse de que los usuarios siempre obtengan la copia más reciente de los recursos es crear versiones correspondientes a cada actualización y publicarlos como nuevas URL. Front Door recuperará inmediatamente los nuevos recursos en las siguientes solicitudes de los clientes. A veces puede que quiera purgar contenido almacenado en caché de todos los nodos perimetrales y forzarlos todos para recuperar nuevos activos actualizados. Esto puede deberse a actualizaciones de la aplicación web o a actualizaciones rápidas de los recursos que contienen información incorrecta.

Captura de pantalla que muestra el botón y la página de purga de la memoria caché.

Seleccione los recursos que quiere purgar de los nodos perimetrales. Para borrar todos los recursos, seleccione Purgar todo. De lo contrario, en Ruta de acceso, escriba la ruta de acceso de cada recurso que quiera purgar.

Estos formatos se admiten en las listas de rutas de acceso que se van a purgar:

  • Purga de ruta de acceso única Purgue recursos concretos mediante la especificación de la ruta de acceso completa del recurso (sin el protocolo y el dominio) con la extensión de archivo, por ejemplo, /pictures/strasbourg.png;
  • Purga con carácter comodín: se puede usar el asterisco (*) como carácter comodín. Purgue todas las carpetas, subcarpetas y archivos de un punto de conexión con /* en la ruta de acceso o purgue todas las subcarpetas y archivos de una carpeta concreta especificando la carpeta seguido de /*; por ejemplo, /pictures/*.
  • Purga de dominio raíz: purgue la raíz del punto de conexión con "/" en la ruta de acceso.

Nota

Depuración de dominios con caracteres comodín: la especificación de rutas de acceso en caché para la purga como se describe en esta sección no se aplica a ningún dominio con caracteres comodín que esté asociado a Front Door. Actualmente, no se admite la purga directa de dominios con caracteres comodín. Puede purgar las rutas de acceso de subdominios específicos especificando ese subdominio concreto y la ruta de acceso de purga. Por ejemplo, si Front Door tiene *.contoso.com, puedo purgar los recursos de mi subdominio foo.contoso.com escribiendo foo.contoso.com/path/*. Actualmente, la especificación de los nombres de host en la ruta de acceso del contenido de purga se limita a los subdominios de dominios con caracteres comodín, si procede.

La purga de la memoria caché en Front Door distingue mayúsculas de minúsculas. Además, son independientes de la cadena de consulta, lo que significa que, al purgar una dirección URL, se purgan todas las variaciones de cadena de consulta.

Expiración de la caché

El siguiente orden de encabezados se usa para determinar cuánto tiempo se almacena un elemento en la memoria caché:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Algunos valores de encabezado de respuesta Cache-Control indican que la respuesta no se puede almacenar en caché. Entre estos valores se incluyen private, no-cache y no-store. Front Door respeta estos valores de encabezado y no almacena en caché las respuestas, aunque invalide el comportamiento de almacenamiento en caché mediante el motor de reglas.

Si el encabezado Cache-Control no está presente en la respuesta del origen, Front Door determina aleatoriamente y de manera predeterminada una duración de caché entre uno y tres días.

Nota

La expiración de la memoria caché no puede ser superior a 366 días.

Es posible que vea REVALIDATED_HIT en el encabezado de respuesta Cache-Control. Esto indica que el contenido almacenado en caché en Azure Front Door se revalidó con el servidor de origen antes de servirse al cliente. Esto puede ocurrir cuando el contenido almacenado en caché ha expirado, pero el servidor de origen indica que el contenido no ha cambiado. En este caso, el contenido almacenado en caché se sirve al cliente y se restablece la expiración de la caché.

Encabezados de solicitud

Los siguientes encabezados de solicitud no se reenvían al origen cuando se habilita el almacenamiento en caché:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Encabezados de respuesta

Si la respuesta de origen se puede almacenar en caché, el encabezado Set-Cookie se quita antes de enviar la respuesta al cliente. Si una respuesta de origen no se puede almacenar en caché, Front Door no quita el encabezado. Por ejemplo, si la respuesta de origen incluye un encabezado Cache-Control con un valor max-age, esto indica a Front Door que la respuesta se puede almacenar en caché y se quita el encabezado Set-Cookie.

Además, Front Door adjunta el encabezado X-Cache a todas las respuestas. El encabezado de respuesta X-Cache incluye uno de los siguientes valores:

  • TCP_HIT o TCP_REMOTE_HIT: el primer fragmento de 8 MB de la respuesta es un acierto de caché y el contenido se sirve desde la caché de Front Door.
  • TCP_MISS: el primer fragmento de 8 MB de la respuesta es un error de caché y el contenido se captura del origen.
  • PRIVATE_NOSTORE: la solicitud no se puede almacenar en caché, ya que el encabezado de respuesta Cache-Control está establecido en privado o sin almacén.
  • CONFIG_NOCACHE: la solicitud está configurada para no almacenarse en caché en el perfil de Front Door.

Registros e informes

El registro de acceso incluye el estado de la caché de cada solicitud. Además, los informes incluyen información sobre cómo se usa la caché de Azure Front Door en la aplicación.

El registro de acceso incluye el estado de la caché de cada solicitud.

Duración y comportamiento de la caché

El comportamiento y la duración de la caché se pueden configurar en el Motor de reglas. La configuración del almacenamiento en caché del motor de reglas siempre invalida a la configuración de ruta.

  • Cuando el almacenamiento en caché está deshabilitado, Azure Front Door no almacena en caché los contenidos de la respuesta, independientemente de las directivas de respuesta de origen.

  • Cuando se habilita el almacenamiento en caché, el comportamiento de la caché varía en función del valor de comportamiento de caché aplicado por el motor de reglas:

    • Respetar el origen: Azure Front Door siempre respeta la directiva de encabezado de respuesta de origen. Si falta la directiva de origen, Azure Front Door almacena en caché el contenido entre uno y tres días.
    • Siempre invalidar: Azure Front Door siempre invalida con la duración de la caché, lo que significa que almacena en caché el contenido durante la duración de la caché y omite los valores de las directivas de respuesta de origen. Este comportamiento solo se aplica si la respuesta se puede almacenar en caché.
    • Invalidar si falta el origen: si el origen no devuelve valores de TTL de almacenamiento en caché, Azure Front Door usa la duración de caché especificada. Este comportamiento solo se aplica si la respuesta se puede almacenar en caché.

Nota

  • Azure Front Door no garantiza la cantidad de tiempo que el contenido se almacenará en la caché. El contenido en caché se puede quitar de la caché perimetral antes de su expiración si no se usa con frecuencia. Es posible que Front Door sirva datos desde la caché incluso si los datos almacenados en caché han expirado. Este comportamiento puede ayudar al sitio a permanecer parcialmente disponible cuando los orígenes están sin conexión.
  • Los orígenes pueden especificar no almacenar en caché respuestas específicas mediante el encabezado Control-Caché con un valor de no-cache, private o no-store. Cuando se usa en una respuesta HTTP del servidor de origen a los POP de Azure Front Door, Azure Front Door admite las directivas de control de caché y respeta los comportamientos de almacenamiento en caché para las directivas de control de caché en RFC 7234: Protocolo de transferencia de hipertexto (HTTP/1.1): almacenamiento en caché (ietf.org).

La duración y el comportamiento de la caché se pueden configurar tanto en la regla de enrutamiento del diseñador de Front Door como en el motor de reglas. La configuración del almacenamiento en caché del motor de reglas siempre invalida a la de la regla de enrutamiento del diseñador de Front Door.

  • Cuando el almacenamiento en caché está deshabilitado, Azure Front Door (clásico) no almacena en caché los contenidos de la respuesta, independientemente de las directivas de respuesta de origen.

  • Cuando el almacenamiento en caché está habilitado, el comportamiento de la caché es diferente según los distintos valores de Usar duración de caché predeterminada.

    • Cuando Usar duración de caché predeterminada está establecido en Sí, Azure Front Door (clásico) siempre respeta la directiva de encabezado de respuesta de origen. Si falta la directiva de origen, Front Door almacena en caché el contenido entre uno y tres días.
    • Cuando Usar duración de caché predeterminada está establecido en No, Azure Front Door (clásico) siempre invalida con la duración de la caché (campos obligatorios), lo que significa que almacena en caché el contenido durante la duración de la caché y omite los valores de las directivas de respuesta de origen.

Nota

  • Azure Front Door (clásico) no garantiza la cantidad de tiempo que el contenido se almacenará en la caché. El contenido en caché se puede quitar de la caché perimetral antes de su expiración si no se usa con frecuencia. Es posible que Azure Front Door (clásico) sirva datos desde la caché incluso si los datos almacenados en caché han expirado. Este comportamiento puede ayudar al sitio a permanecer parcialmente disponible cuando los orígenes están sin conexión.
  • La duración de la caché establecida en la regla de enrutamiento del diseñador de Front Door es la duración de la caché mínima. Esta invalidación no funciona si el encabezado de control de la caché del origen tiene un TTL mayor que el valor de invalidación.

Pasos siguientes