Una cache es un componente de hardware o software que almacena datos para que las solicitudes futuras de esos datos se puedan atender con mayor rapidez, los datos almacenados en un cache pueden ser el resultado de un calculo anterior o el duplicado de datos almacenados en otro lugar, generalmente, de velocidad de acceso mas rápido.
CDN
Una cdn (content delivery network) es un conjunto de ubicaciones en el mundo, que redistribuyen localmente el contenido de los servidores y guardan en cache los archivos que no necesitan actualización permanente, según las reglas personalizables.
Encabezados de cache
Cache-control: Cada recurso puede definir su propia política de almacenamiento en cache mediante el encabezado cache-control. Las directivas cache-control controla quien guarda la respuesta en cache, en que condiciones y durante cuanto tiempo.
Las solicitudes que no necesitan comunicación con el servidor se consideran las mejores: las copias locales de las respuestas permiten la eliminación de latencia de red, así como los cargos de datos resultantes de las transferencias de datos. La especificación HTTP permite al servidor enviar varias directivas diferentes de control de cache que controlan como y durante cuanto tiempo los navegadores guardan en cache las respuestas individuales, entre otros cache intermedios, como un CDN.
Public vs Private
una respuesta marcada como "public" se puede almacenar en cache incluso en los casos en que esta asociada a una autenticacion HTTP o el código de estado de la respuesta HTTP no se puede almacenar en el cache normalmente. En la mayoría de los casos, una respuesta marcada como "public" no es necesaria, ya que la información de almacenamiento en cache explicita (por ejemplo: "max-age") muestra que una respuesta es almacenable de todos modos.
Por el contrario, una respuesta marcada como "privada" puede almacenarse en cache (por el navegador), pero dichas respuestas suelen estar destinadas a usuarios únicos, por lo tanto, no son almacenables, en cache intermedios (por ejemplo las paginas HTML con información de usuario privada pueden almacenarse en cache del navegador pero no en CDN).
no-cache y no-store
"no-cache" muestra que las respuestas devueltas no se pueden usar para solicitudes posteriores a la misma URL antes de verificar si las respuestas del servidor han cambiado. Si un Etag apropiado (token de validación) esta presente como resultado, no-cache incurre en una ida y vuelta en un esfuerzo por validar las respuestas cache. Sin embargo, los caches pueden eliminar peticiones si los recursos no han cambiado.En otras palabras, los navegadores web pueden almacenar en cache los recursos, pero deben verificar cada solicitud si los recursos han cambiado (respuesta 304 si nada ha cambiado).
Por el contrario, "no-store" es mas simple. Este es el caso por que no permite que los navegadores intermedios y todas las caches intermedias, almacenen ninguna versión de respuesta devuelta, es decir, respuestas que contienen información privada/ personal o datos bancarios. Cada vez que los usuarios soliciten este activo, las solicitudes se envían al servidor. Los recursos se descargan todo el tiempo.
max-age
La directiva max-age establece la cantidad máxima de tiempo en segundos que las respuestas recuperadas pueden volver a utilizarse (desde el momento en que se realiza la solicitud). Por ejemplo, "max-age : 90" indica que un recurso puede reutilizarse (permanece en el cache del navegador)durante los siguientes 90 segundos.
s-maxage
La "s" significa como en "cache compartido". Esta directiva es explicitamente para los CDNs entre otras cache intermedias. Esta directiva prevalece sobre la directiva max-age y expira el encabezado cuando esta presente.
must-revalidate
la directiva must-revalidate se usa para indicar a un cache que primero debe revalidar un recurso con el origen después de que se vuelva obsoleto. El recurso no se debe entregar al cliente sin realizar una revalidacion de extremo a extremo. En resumen, los recursos obsoletos deben verificarse primero y los recursos caducados no deben utilizarse.
proxy-revalidate
Es la misma que la directiva must-revalidate, sin embargo, solo se aplica a los caches compartidos, como los proxies. Es útil en caso de que un proxy preste servicios a muchos usuarios que necesitan ser autenticados uno a uno. Una respuesta a una solicitud autenticada se puede almacenar en la memoria cache del usuario sin necesidad de volver a validarla cada vez que se conocen y ya se han autenticado. Sin embargo proxy-revalidate permite que los proxies se revaliden para usuarios nuevos que aun no se han autenticado.
no-transform
La directiva no-transform le dice a cualquier intermediario como un proxy o servidor de cache que no haga ninguna modificación al recurso original. Los encabezados Content-Encoding, Content-Range y Content-Type no deben modificarse. Esto puede ocurrir si un proxy no transparente decide realizar modificaciones en los recursos para ahorrar espacio. Sin embargo, esto puede causar serios problemas en el caso de que el recurso deba permanecer idéntico al cuerpo-entidad original aunque también debe pasarse a través del proxy.
Según Google, el encabezado cache-control es todo lo que se necesita en términos de especificar políticas de almacenamiento cache. Hay otros métodos que veremos sin embargo no son necesarios para un rendimiento optimo.
El encabezado Cache-control se define como parte de las especificaciones HTTP /1.1 y reemplaza los encabezados anteriores (es decir, caduca) utilizados para especificar las politicas de cache de respuesta. Cache-control es compatible con todos los navegadores modernos, asi que eso es todo lo que necesitamos.
Pragma
El viejo encabezado "pragma" logra muchas cosas, la mayoría de ellas caracterizadas por las implementaciones mas nuevas. Sin embargo, estamos mas preocupados con la directiva pragma:no-cache que se interpreta mediante implementaciones mas nuevas como cache-control:no-cache.
Expires
Hace un par de años, esta era la principal forma de especificar cuando vencían los recursos. Expires es simple y básico fecha y hora. Es bastante útil para agentes de usuarios antiguos que aun recorren territorios desconocidos. Sin embargo, es importante tener en cuenta que los encabezados de control de cache, max-age y s-maxage siguen teniendo prioridad en la mayoría de los sistemas modernos. Sin embargo, es una buena practica establecer valores de coincidencia aquí por razones de compatibilidad. También es importante de asegurarse de formatear la fecha correctamente o se puede considerar que ha expirado.
Validadores
Etag
Este tipo de token de validación (el estándar en HTTP /1.1):
* se comunica a través del encabezado Etag HTTP (por el servidor)
* permite actualizaciones de recursos eficientes, es decir, no se realiza transferencia de datos si el recurso no cambia.
El siguiente ejemplo ilustrara esto:
90 segundos después de la recuperación inicial de un recurso, inicia el navegador una nueva solicitud (el mismo recurso exacto). El navegador busca la memoria cache local y encuentra la respuesta previamente en cache pero no puede usarla por que ha caducado. Este es el punto donde el navegador solicita contenido completo del servidor. El problema con esto es que si el recurso no ha cambiado, no hay absolutamente ninguna razón para descargar el mismo activo que ya esta en el cache CDN.
Los tokens de validación solucionan este problema. El servidor perimetral crea y devuelve tokens arbitrarios, que se almacenan en el campo de encabezado Etag, que generalmente son un hash u otras huellas dactilares del contenido de los archivos existentes. Los clientes no necesitan saber como se generan los tokens, pero deben enviarlos al servidor en las solicitudes posteriores. Si los tokens son iguales, los recursos no han cambiado, por lo que se puede omitir la nueva solicitud.
El navegador web proporciona el token Etag automáticamente dentro del encabezado de solicitud HTTP "If-None-Match". El servidor luego verifica los tokens contra los recursos actuales en el cache. Una respuesta 304 Not Modified le dirá al navegador si un recurso en la memoria cache no ha sido modificado y, por lo tanto, permite una renovación por otros 90 segundos. Es importante tener en cuenta que estos recursos no necesitan ser pedidos nuevamente lo que ahorra ancho de banda y tiempo.
No hay comentarios:
Publicar un comentario