Arquitectura de software distribuida: caché de cliente

caché del cliente del navegador

Los mecanismos de almacenamiento en caché del navegador han existido prácticamente desde los albores de la World Wide Web. Al comienzo del diseño del protocolo HTTP, las personas determinaron el principio de interacción "sin estado" (Stateless) entre el servidor y el cliente, es decir, se requiere que cada solicitud del cliente sea independiente, y no se puede percibir ni confiar en cada solicitud. por otro cliente La existencia de una solicitud no solo simplifica el diseño del servidor HTTP, sino que también deja un amplio espacio para su capacidad de expansión horizontal.
Pero la apatridia no se trata solo del lado positivo. Debido a que cada solicitud del cliente es independiente, el servidor no guardará el estado y los recursos de la solicitud anterior, por lo que inevitablemente llevará datos duplicados, lo que provocará una disminución en el rendimiento de la red.
Entonces, la solución del protocolo HTTP a este problema es el almacenamiento en caché del lado del cliente. En la evolución de HTTP/1.0 a 1.1, y luego a la versión 2.0, tres tipos de cachés HTTP , que ahora se denominan " caché de estado ", " caché obligatoria " (o simplemente "caché fuerte") y " caché de negociación " mecanismo formado.

caché de estado

El caché de estado aquí significa que el cliente juzga directamente el estado del sitio web de destino en función de la información almacenada en caché sin pasar por el servidor. En el pasado, solo había 301/Movido permanentemente (redireccionamiento permanente). Más tarde, se agregó el mecanismo HSTS (HTTP Strict Transport Security) en RFC6797 para evitar el problema del secuestro degradado de intermediario que puede ocurrir cuando se confía en en 301/302 para saltar a HTTPS. Este es otro tipo de caché de estado.

El siguiente es www.hao123.comel código de estado del resultado de la redirección 302 al navegar,

La diferencia entre varios códigos de estado de redirección

• 301 Movido permanentemente: orientación permanente, este código de estado indica que al recurso solicitado se le ha asignado un nuevo URI, y el URI al que ahora se refiere el recurso debe usarse en el futuro;
• 302 Encontrado: Redirección temporal, este código de estado indica que al recurso solicitado se le ha asignado un nuevo URI, y el usuario puede usar temporalmente el URI para acceder esta vez;
• 303 Ver Otro, 307 Redirección Temporal, etc.;

Como escribir en un navegador web www.baidu.com/en lugar de http://www.baidu.com/. En este caso, el navegador asume que desea utilizar el protocolo HTTP, por lo que envía una solicitud HTTP en esta etapa www.baidu.com/y el servidor web devolverá una solicitud de código de estado 301 para redirigir al sitio HTTPS. A continuación, el navegador se conecta a www.baidu.com/(URL final https://www.baidu.com/) mediante HTTPS. En este punto, la protección de la política de seguridad de HSTS comienza a usar el encabezado de respuesta HTTP:

Strict-Transport-Security: max-age=172800; includeSubDomains; preload

El encabezado de respuesta Strict-Transport-Security proporciona instrucciones detalladas al navegador. A partir de ahora, cada conexión a este sitio web y sus subdominios durante el próximo año (172800 segundos) desde el momento en que se recibe este encabezado debe ser una conexión HTTPS. Las conexiones HTTP están completamente deshabilitadas. Si un navegador recibe una solicitud para cargar un recurso mediante HTTP, debe intentar una solicitud HTTPS en su lugar. Si HTTPS no está disponible, la conexión debe terminarse directamente.

Además, si el certificado no es válido, le impedirá establecer una conexión. En términos generales, si el certificado HTTPS no es válido (p. ej., caducado, autofirmado, firmado por una CA desconocida, etc.), el navegador mostrará una advertencia que se puede eludir. Sin embargo, el navegador no le permitirá pasar por alto la advertencia si el sitio tiene HSTS. Para acceder a este sitio, debe eliminarlo de la lista HSTS dentro de su navegador.

almacenamiento en caché obligatorio

Su estrategia para lidiar con los problemas de consistencia es muy sencilla: suponga que en un momento determinado, como dentro de los 10 minutos posteriores a que el servidor reciba la respuesta, el contenido y el estado del recurso no cambiarán, por lo que el cliente no necesita para pasar por cualquier solicitud, retenga y use una copia almacenada en caché local del recurso hasta ese momento.
De acuerdo con el acuerdo, el almacenamiento en caché obligatorio puede tener efecto durante la entrada de la dirección del navegador, el salto del enlace de la página, la apertura de una nueva ventana, hacia adelante y hacia atrás, pero debe invalidarse automáticamente cuando el usuario actualice activamente la página .
En el protocolo HTTP, se establecen dos tipos de encabezados que pueden implementar el almacenamiento en caché obligatorio: Expires y Cache-Control

Caduca

Es el encabezado proporcionado en el protocolo HTTP/1.0, seguido de un parámetro de fecha límite. Cuando el servidor devuelve un recurso, si contiene el encabezado, significa que el servidor promete que el recurso no cambiará antes de la fecha límite, y el navegador puede almacenar directamente los datos en caché sin reiniciar la solicitud. Por ejemplo,

HTTP/1.1 200 OK
Expires:Sun, 2 Jul 2023 11:26:15 GMT

Entonces el tiempo de caducidad es muy intuitivo, pero tiene los siguientes problemas

1. limitado por la hora local del cliente;
2. Incapaz de manejar recursos privados relacionados con la identidad del usuario;
3. No se puede describir la semántica de "no almacenar en caché";

Control de caché

Es el Header provisto en el protocolo HTTP/1.1, y su semántica es más rica. Si los dos existen al mismo tiempo, y hay un conflicto semántico, IETF estipula que debe prevalecer el control de caché. Tome el siguiente como ejemplo. El siguiente es el tiempo de caché de 600 segundos.

HTTP/1.1 200 OK
Cache-Control:max-age=600

Los parámetros del estándar Cache-Control incluyen lo siguiente:

• max-age: seguido de un número en segundos, que indica cuántos segundos en relación con el tiempo de solicitud (Fecha), el caché es válido;
• s-maxage: el tiempo efectivo del caché compartido, que recuerda a servidores como CDN cómo invalidar el caché;
• público: los recursos pueden ser almacenados en caché por proxies, CDN, etc.;
• privado: el almacenamiento en caché privado solo lo puede realizar el cliente del usuario;
• no-cache: no debe almacenarse en caché, incluso las solicitudes para la misma dirección URL en la misma sesión deben obtenerse del servidor, invalidando así por completo el caché obligatorio;
• no-store: no obliga a obtener el mismo recurso de URL repetidamente en la sesión, pero prohíbe que los navegadores, CDN, etc. retengan el recurso de cualquier forma;
• sin transformación: prohíbe que los recursos se modifiquen de cualquier forma;
• min-fresh: seguido de un número, en segundos, que se usa para sugerir que el servidor puede devolver un recurso de caché no menos de este tiempo;
• solo si está en caché: indica que el servidor espera que el cliente no envíe solicitudes, sino que solo use el caché para responder.Si no se puede acceder al caché, devolverá directamente un error 503/Servicio no disponible;
• must-revalidate: luego de indicar la bandera del recurso, se debe obtener del servidor, es decir, luego de superar el tiempo max-age, es equivalente a no-cache;
• proxy-revalidate: se utiliza para solicitar el comportamiento de caché de recursos como proxy y CDN después de la expiración Excepto por los diferentes objetos, la semántica es exactamente la misma que must-revalidate;

A continuación se muestra un ejemplo de sin caché,

caché de negociación

En HTTP, el almacenamiento en caché de negociación y el almacenamiento en caché obligatorio no se excluyen mutuamente, y los dos mecanismos pueden funcionar en paralelo. La caché de negociación tiene los siguientes dos mecanismos de verificación de cambios.

Comparar con el tiempo de modificación del recurso

• Last-Modified: El encabezado de respuesta del servidor, usado para decirle al cliente la hora de la última modificación de este recurso;
• If-Modified-Since: cuando el cliente solicite nuevamente, enviará la hora de la última modificación del recurso recibido previamente al servidor a través de If-Modified-Since; si en este momento, el servidor encuentra que el recurso no ha sido modificado después de ese
  tiempo, solo necesita devolver una respuesta 304/No modificada sin adjuntar un cuerpo de mensaje, para lograr el propósito de ahorrar tráfico.

Verifique en función de si la representación única del recurso ha cambiado

• Etag: el encabezado de respuesta del servidor, que se usa para decirle al cliente el identificador único de este recurso.
• If-None-Match: cuando el cliente solicita nuevamente, enviará el identificador único del recurso recibido previamente al servidor a través de If-None-Match;

Además, Etag es el mecanismo de almacenamiento en caché más consistente en HTTP. Last-Modified puede causar problemas de consistencia de recursos, pero Etag no lo hará. Sin embargo, la adquisición de Etag requiere que el servidor realice un cálculo de hash en el recurso (por ejemplo, el valor de Etag del servidor Apache tiene como valor predeterminado el nodo de índice, el tamaño y la hora de la última modificación del archivo), por lo que la sobrecarga será mucho mayor. más alto.

Mecanismo de negociación de contenido HTTP

El protocolo HTTP diseña los encabezados de respuesta de Accept* y Content-*, que se denominan mecanismos de negociación de contenido HTTP. El significado de estos recursos de caché de respuestas se basa en el tipo MINE y los recursos del navegador.

Enlace de referencia:
1. https://zhuanlan.zhihu.com/p/130946490