Cómo utilizar el mecanismo de almacenamiento en caché http

La caché web se puede dividir aproximadamente en: caché de base de datos, caché del lado del servidor (caché del servidor proxy, caché de CDN), caché del navegador.

La caché del navegador también contiene una gran cantidad de contenido: caché HTTP, indexDB, cookies, almacenamiento local, etc. Aquí solo discutimos el contenido relacionado con el almacenamiento en caché HTTP.

Antes de aprender más sobre el almacenamiento en caché HTTP, aclaremos algunos términos:

• Proporción de aciertos de caché: la proporción entre el número de solicitudes que obtienen datos de la caché y el número de todas las solicitudes. El estado ideal es que cuanto más alto, mejor.

• Contenido caducado: contenido que se ha marcado como "obsoleto" después del tiempo de vigencia establecido. Por lo general, el contenido caducado no se puede utilizar para responder a las solicitudes de los clientes. Debe solicitar contenido nuevo al servidor de origen o verificar que el contenido en caché aún esté listo.

• Verificación: verifique si el contenido caducado en la caché sigue siendo válido y actualice el tiempo de caducidad si se pasa la verificación.

• Invalidación: la invalidación es la eliminación de contenido de la caché. Cuando cambia el contenido, se debe eliminar el contenido no válido.

El almacenamiento en caché del navegador es principalmente un mecanismo de almacenamiento en caché definido por el protocolo HTTP. Metaetiquetas HTML, por ejemplo

<META HTTP-EQUIV = "Pragma" CONTENT = "sin tienda">

El significado es permitir que el navegador no almacene en caché la página actual. Sin embargo, el servidor proxy no analiza el contenido HTML y generalmente se usa ampliamente para controlar el almacenamiento en caché con información de encabezado HTTP.

 

Clasificación de la caché del navegador

El almacenamiento en caché del navegador se divide en almacenamiento en caché fuerte y almacenamiento en caché de negociación. El proceso simple para que el navegador cargue una página es el siguiente:

1. El navegador primero juzga si llega a la caché segura en función de la información del encabezado http de este recurso. Si llega al recurso agregado directamente a la caché, la solicitud no se enviará al servidor.

2. Si se pierde el caché fuerte, el navegador enviará una solicitud de carga de recursos al servidor. El servidor determina si la caché local del navegador no es válida. Si se puede usar, el servidor no devolverá información sobre los recursos y el navegador continuará cargando recursos desde la caché.

3. Si se pierde el caché de negociación, el servidor devolverá el recurso completo al navegador, el navegador carga el nuevo recurso y actualiza el caché.

 

Caché fuerte

Cuando se alcanza un caché fuerte, el navegador no envía la solicitud al servidor. En las herramientas de desarrollo de Chrome, veo que el código de retorno de http es 200, pero se mostrará como (desde el caché) en la columna Tamaño.

El almacenamiento en caché fuerte se controla mediante los campos Expires o Cache-Control en el encabezado de retorno http para indicar el tiempo de caché de los recursos.

Expira

La hora de caducidad de la caché, que se utiliza para especificar la hora en que caduca el recurso, es un momento específico en el lado del servidor. En otras palabras, Expires = max-age + request time, que debe usarse junto con Last-modified. Pero como mencionamos anteriormente, el control de caché tiene una prioridad más alta. Caduca es el campo de encabezado del mensaje de respuesta del servidor web. Cuando responde a una solicitud http, le dice al navegador que el navegador puede obtener datos directamente de la caché del navegador antes de la fecha de caducidad sin tener que volver a solicitarlo.

 

Este campo devolverá una hora, como Expires: Thu, 31 Dec 2037 23:59:59 GMT. Este tiempo representa el tiempo de caducidad de este recurso, lo que significa que es válido hasta las 23:59:59 del 31 de diciembre de 2037, es decir, llega a la caché. Este método tiene una desventaja obvia: debido a que el tiempo de vencimiento es un tiempo absoluto, cuando se modifica la hora local del cliente, la desviación de tiempo entre el servidor y el cliente aumenta, lo que provocará confusión en la caché. Entonces se desarrolló Cache-Control.

Control de caché

Cache-Control es un tiempo relativo, como Cache-Control: 3600, lo que significa que el período de validez del recurso es 3600 segundos. Dado que es un tiempo relativo y se compara con el tiempo del cliente, la desviación de tiempo entre el servidor y el cliente no causará problemas.
Cache-Control y Expires se pueden habilitar o habilitar al mismo tiempo en la configuración del servidor. Cache-Control tiene una prioridad más alta cuando se habilita al mismo tiempo.

Cache-Control puede estar compuesto por varios campos, principalmente con los siguientes valores:

1.  max-age  especifica un período de tiempo durante el cual la caché es válida y la unidad es s. Por ejemplo, configure Cache-Control: max-age = 31536000, lo que significa que el período de validez de la caché es (31536000 / 24/60 * 60) días. Cuando se accede al recurso por primera vez, el servidor también devuelve el campo Expires, y el tiempo de expiración es un año después.

 

Si el caché no está deshabilitado y el tiempo válido no ha expirado, acceder al recurso nuevamente llegará al caché y no solicitará el recurso del servidor, sino que lo buscará directamente del caché del navegador.

2.  s-maxage es lo  mismo que max-age, que cubre max-age y Expires, pero solo se aplica a la caché compartida y se ignora en la caché privada.

3.  Público  indica que la respuesta puede ser almacenada en caché por cualquier objeto (el cliente solicitante, servidor proxy, etc.).

4.  Privado  indica que la respuesta solo puede ser almacenada en caché por un único usuario (pueden ser usuarios del sistema operativo, usuarios del navegador), no es compartida y no puede ser almacenada en caché por un servidor proxy.

5.  no-cache  obliga a todos los usuarios que han almacenado en caché la respuesta a enviar una solicitud con un validador al servidor antes de utilizar los datos almacenados en caché. No literalmente no almacenar en caché.

6.  No-store  prohíbe el almacenamiento en caché y vuelve a obtener datos del servidor para cada solicitud.

7. Must-revalidate especifica que si la página está desactualizada, vaya al servidor para obtenerla. Esta instrucción no se usa comúnmente, por lo que no la discutiré demasiado.

Caché de negociación

Si se pierde el caché fuerte, el navegador enviará la solicitud al servidor. El servidor determina si la caché de negociación se acierta de acuerdo con Last-Modify / If-Modify-Since o Etag / If-None-Match en la información del encabezado http. Si llega, el código de retorno http es 304 y el navegador carga el recurso desde la caché.

Última modificación / Si-Modificar desde

Cuando el navegador solicita un recurso por primera vez, Última modificación se agregará al encabezado devuelto por el servidor. Última modificación es un momento para identificar la última hora de modificación del recurso, por ejemplo, Última modificación: jueves, 31 de diciembre de 2037 23:59 : 59 GMT.

Cuando el navegador solicita el recurso nuevamente, el encabezado de la solicitud enviada contendrá If-Modify-Since, que es la última modificación devuelta antes del almacenamiento en caché. Después de recibir If-Modify-Since, el servidor juzga si llega al caché de acuerdo con la última hora de modificación del recurso.

Si llega al caché, se devuelve http304, no se devuelve el contenido del recurso y no se devuelve Last-Modify. Debido a la comparación de la hora del servidor, la brecha de tiempo entre el cliente y el servidor no causará problemas. Pero a veces no es muy preciso juzgar si el recurso ha sido modificado por la última hora de modificación (la última hora de modificación también puede ser la misma si el recurso cambia). Entonces apareció ETag / If-None-Match.

ETag / If-None-Match

A diferencia de Last-Modify / If-Modify-Since, Etag / If-None-Match devuelve un código de verificación (ETag: etiqueta de entidad). ETag puede garantizar que cada recurso sea único y los cambios de recursos provocarán cambios en ETag *. El cambio del valor de ETag indica que se ha modificado el estado del recurso. El servidor juzga si el caché se acierta de acuerdo con el valor If-None-Match enviado en el navegador.

 

 

Descripción ampliada de  ETag

Tenemos grandes esperanzas para ETag, esperando que genere un valor único para cada URL, y ETag cambie cuando cambien los recursos. ¿Cómo se genera el misterioso Etag? Tomando Apache como ejemplo, la generación de ETag depende de los siguientes factores

1. El número de i-nodo del archivo, este i-nodo no es el otro iNode. Es el número que utiliza Linux / Unix para identificar archivos. Sí, el nombre del archivo no se usa para identificar el archivo. Utilice el comando 's-I' para ver.

2. Hora de última modificación del archivo

3. Tamaño de archivo Al
   generar Etag, puede usar uno o más de estos factores y usar la función hash anticolisión para generar. Por lo tanto, en teoría, ETag se repetirá, pero la probabilidad es tan pequeña que puede ignorarse.

¿Cómo se puede producir la etiqueta Last-Modified existente?

Puede pensar que usar Last-Modified es suficiente para que el navegador sepa si la copia en caché local es lo suficientemente nueva, ¿por qué necesitamos Etag (identificación de entidad)? La aparición de Etag en HTTP1.1 es principalmente para resolver varios problemas que son difíciles de resolver en Last-Modified:

1. La última modificación marcada como Última modificación solo puede ser precisa hasta el segundo nivel. Si algunos archivos se modifican varias veces en 1 segundo, no podrá marcar con precisión la hora de modificación del archivo.

2. Si algunos archivos se generarán con regularidad, a veces el contenido no cambia, pero Last-Modified ha cambiado, lo que hace que el archivo no pueda usar la caché.

3. Puede haber situaciones en las que el servidor no obtenga con precisión la hora de modificación del archivo o no sea coherente con la hora del servidor proxy, etc.

Etag es el identificador único del lado del servidor del recurso correspondiente generado automáticamente por el servidor o generado por el desarrollador, que puede controlar la caché con mayor precisión. Last-Modified y ETag se pueden usar juntos. El servidor verificará la ETag primero. Si son consistentes, continuará comparando Last-Modified y finalmente decidirá si devolver 304.

Comportamiento del usuario y almacenamiento en caché

El comportamiento del almacenamiento en caché del navegador también está relacionado con el comportamiento del usuario. ! !

Acción del usuario	Caduca / Cache-Control	Última modificación / Etag
Entrar en la barra de direcciones	eficaz	eficaz
Salto de enlace de página	eficaz	eficaz
Nueva ventana	eficaz	eficaz
hacia adelante hacia atrás	eficaz	eficaz
F5 actualizar	inválido	eficaz
Ctrl + F5 actualizar	inválido	inválido

para resumir:

La primera solicitud del navegador:

 

Cuando el navegador vuelve a solicitar: