Tipo de caché del navegador

Caché del navegador

Para almacenar en caché estas cosas, debe obtener el recurso por primera vez y luego indicar cómo almacenar en caché el recurso de acuerdo con la información devuelta. Puede usar una memoria caché fuerte o puede indicarle al navegador del cliente que negocie la memoria caché, que debe basarse en el contenido del encabezado de la respuesta. Para decidir

Cuando el navegador solicita por primera vez:

Cuando el navegador posteriormente realiza una solicitud:

Como se puede ver en la figura anterior, el caché del navegador contiene dos tipos, a saber, el caché fuerte (también llamado caché local) y el caché negociado. Cuando el navegador solicita nuevamente después de que se produce la primera solicitud:

• Cuando el navegador solicita un recurso, primero obtendrá la información del encabezado del caché de recursos y determinará si alcanza un caché fuerte (control de caché y expira información). Si el hit obtiene directamente la información del recurso del caché, incluida la información del encabezado del caché; esta vez La solicitud no se comunicará con el servidor en absoluto; bajo firebug, puede ver la información devuelta por un recurso con un caché fuerte, como un archivo js de caché fuerte visto por firebug local

• Si no hay un impacto fuerte en la memoria caché, el navegador enviará una solicitud al servidor, la solicitud llevará la información del campo de encabezado sobre la memoria caché devuelta por la primera solicitud (Última modificación / If-Modified-Since y Etag / If-None-Match), por El servidor compara si el resultado es un acierto de caché de acuerdo con la información de encabezado relevante en la solicitud; si acierta, el servidor devuelve una nueva información de encabezado de respuesta para actualizar la información de encabezado correspondiente en el caché, pero no devuelve el contenido del recurso, informará al navegador que puede directamente Obtener de la memoria caché; de lo contrario, devolver el último contenido de recursos

La siguiente tabla puede describir la diferencia entre el almacenamiento en caché fuerte y el almacenamiento en caché negociado:

 

Campos de encabezado relacionados con caché fuerte

 

El almacenamiento en caché fuerte se ha introducido anteriormente, para obtener recursos directamente del caché sin pasar por el servidor; hay dos campos de encabezado relacionados con el almacenamiento en caché fuerte:

 

1. caduca , que es la especificación en http1.0; su valor es una cadena de tiempo de formato GMT de tiempo absoluto, como Mon, 10 de junio de 2015 21:31:12 GMT, si el tiempo para enviar la solicitud es antes de que caduque, entonces local El caché siempre es válido, de lo contrario enviará una solicitud al servidor para obtener recursos
2. control de caché: max-age = number , esta es la información de encabezado que aparece en http1.1, utiliza principalmente el valor de max-age de este campo para juzgar, es un valor relativo; el primer tiempo de solicitud del recurso y Caché -El período de validez establecido por Control calcula un tiempo de vencimiento del recurso, y luego compara este tiempo de vencimiento con el tiempo de solicitud actual. Si el tiempo de solicitud es anterior al tiempo de vencimiento, puede llegar a la memoria caché, de lo contrario no funcionará; el control de memoria caché excepto este campo , Y las siguientes configuraciones más utilizadas:
   
   
sin caché: no use caché local. Debe utilizar la negociación de caché para confirmar con el servidor si se ha cambiado la respuesta devuelta. Si hay una ETag en la respuesta anterior, la solicitud se verificará con el servidor. Si el recurso no se ha cambiado, puede evitar volver a descargarlo.

no-store: prohíbe directamente que el navegador almacene datos en caché. Cada vez que el usuario solicita el recurso, se enviará una solicitud al servidor y el recurso completo se descargará cada vez.

public: todos los usuarios pueden almacenarlos en caché, incluidos los servidores proxy intermedios, como los usuarios finales y los CDN.

privado: solo puede ser almacenado en caché por el navegador del usuario final, y los servidores de caché de retransmisión como los CDN no pueden almacenarlo en caché.

 

　　Nota: Si el control de caché y el vencimiento existen al mismo tiempo, la prioridad del control de caché es mayor que el vencimiento

? Campo de encabezado de caché de negociación

 

El servidor determina la caché de negociación para determinar si los recursos de caché están disponibles, por lo que el cliente y el servidor deben comunicarse a través de un determinado identificador para permitir que el servidor determine si el caché puede acceder al recurso solicitado. Esto implica principalmente los siguientes dos campos de encabezado. Estos dos conjuntos de socios aparecen en pares, es decir, el encabezado de respuesta de la primera solicitud lleva un cierto campo (Última modificación o Etag), y las solicitudes posteriores traerán el campo de solicitud correspondiente (If-Modified-Since o If-None-Match), si el encabezado de respuesta no tiene un campo Last-Modified o Etag , el encabezado de solicitud no tendrá un campo correspondiente .

Última modificación / If-Modified-Since

• Ambos valores son cadenas de tiempo en formato GMT, el proceso específico:
• El navegador solicita un recurso del servidor por primera vez. Cuando el servidor devuelve este recurso, agrega el encabezado Última modificación al encabezado de la respuesta. Este encabezado indica la última hora de modificación de este recurso en el servidor.
• Cuando el navegador vuelva a solicitar este recurso al servidor, agregue el encabezado If-Modified-Since al encabezado de la solicitud. El valor de este encabezado es el valor de Última modificación devuelto durante la solicitud anterior.
• Cuando el servidor recibe nuevamente la solicitud de recurso, juzga si el recurso ha cambiado de acuerdo con el If-Modified-Since transmitido por el navegador y la última hora de modificación del recurso en el servidor. Si no hay cambio, devuelve 304 No modificado, pero el contenido del recurso no se devolverá; Si hay un cambio, el contenido del recurso se devolverá normalmente. Cuando el servidor devuelve una respuesta 304 No modificada, el encabezado Última modificación no se agregará al encabezado de respuesta, porque dado que el recurso no ha cambiado, el Último modificado no cambiará, este es el encabezado de respuesta cuando el servidor devuelve 304
• Después de que el navegador recibe la respuesta 304, cargará el recurso de la memoria caché
• Si el caché de negociación no alcanza, cuando el navegador carga el recurso directamente desde el servidor, el encabezado Last-Modified se actualizará cuando se vuelva a cargar. Cuando se realiza la siguiente solicitud, If-Modified-Since habilitará el valor Last-Modified devuelto la última vez

Etag / If-None-Match

• Estos dos valores son la cadena de identificación única de cada recurso generado por el servidor. Este valor cambiará mientras el recurso cambie; el proceso de evaluación es similar a Última modificación / If-Modified-Since , no es lo mismo que Last-Modified Además, cuando el servidor devuelve una respuesta 304 No modificada, porque el ETag se ha regenerado, el ETag también se devolverá en el encabezado de respuesta, incluso si el ETag no ha cambiado desde el anterior.

Última etiqueta 与 Etag

 

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é necesita Etag? La aparición de Etag en HTTP1.1 es principalmente para resolver varios problemas que son difíciles de resolver en Last-Modified:

 

• Algunos archivos pueden cambiarse periódicamente, pero su contenido no cambia (solo se cambia el tiempo de modificación). En este momento, no queremos que el cliente piense que este archivo ha sido modificado y que se vuelve a OBTENER;

• Algunos archivos se modifican con mucha frecuencia, por ejemplo, en un segundo o menos (por ejemplo, N veces modificado en 1s), If-Modified-Since puede verificar que la granularidad esté a nivel, esta modificación no puede juzgarse (o Dijo que el registro UNIX MTIME solo puede ser exacto al segundo);

• Algunos servidores no pueden obtener la última hora de modificación del archivo con precisión.

 

En este momento, el uso de Etag puede controlar el caché con mayor precisión, porque Etag es un identificador único en el lado del servidor del recurso correspondiente generado automáticamente por el servidor o generado por el desarrollador.

 

Last-Modified y ETag se pueden usar juntos. El servidor primero verificará el ETag . Si son consistentes, continuarán comparando Last-Modified y finalmente decidirán si devolver 304 .

Impacto del comportamiento del usuario en la memoria caché

 

 

Referencias: https://www.cnblogs.com/mq0036/p/7090635.html