¿Para qué sirve TTL 0 en CloudFront? Hace algunas semanas

Question

Amazon anunció que han bajado el periodo de caducidad del contenido:

Amazon CloudFront Lowers Minimum Content Expiration Period

Tanto es así que en realidad se puede configurar ahora TTL en CloudFront a 0. Así que mi pregunta es, ¿por qué no podía ser de utilidad para tener una distribución de CloudFront con TTL establecido en 0. Para mí esto significa que no hay almacenamiento en caché, por lo que cada solicitud que llegue a CloudFront terminará golpeando el origen.

¿Qué me estoy perdiendo?

Answer 1

Esta nueva característica de Amazon CloudFront es realmente muy útil para muchos casos de uso, porque golpear el origen funciona un poco diferente de lo que parece a primera vista y no es necesariamente un problema, por el contrario; si bien esta característica ya se lanzó anteriormente, todo viene junto con la publicación reciente de Amazon CloudFront - Support for Dynamic Content, p. para la cuestión que nos ocupa:

variable Time-To-Live (TTL) - En muchos casos, los contenidos dinámicos son bien no almacenar en caché o almacenar en caché durante un período muy corto de tiempo, tal vez sólo algunos segundos. En el pasado, el TTL mínimo de CloudFront era de 60 minutos, ya que todo el contenido se consideraba estático. El nuevo valor mínimo de TTL es 0 segundos. Si configura el TTL para un origen particular en 0, CloudFront aún almacenará en caché el contenido de ese origen. A continuación, realizar una solicitud GET con un If-Modified-Since encabezado, dando así origen la oportunidad de señal que CloudFront puede seguir utilizando el contenido almacenado en caché si no ha cambiado en el origen. [énfasis mío]

En otras palabras, utilizando un TTL de 0 significa sobre todo, que los delegados CloudFront la autoridad para el control de memoria caché para el origen, es decir, el servidor de origen decide si o no, y si por cuánto tiempo CloudFront almacena en caché los objetos; tenga en cuenta específicamente, que una solicitud GET con un If-Modified-Since encabezado no significa necesariamente que el objeto en sí mismo es recuperado desde el origen, en lugar del origen puede (y debe) devolver el HTTP status code 304 - Not Modified en su caso:

Indica que el recurso no se ha modificado desde la última solicitud. [...] El uso de este ahorra ancho de banda y el reprocesamiento tanto en el servidor y el cliente , ya que sólo los datos de cabecera deben ser enviados y recibidos en comparación con la totalidad de la página que se está re-procesados ​​por el servidor , luego enviado de nuevo usando más ancho de banda del servidor y el cliente. [el énfasis es mío]

Ver Marcos de excelente Caching Tutorial para obtener detalles sobre la mecánica y los beneficios de control de caché HTTP, una parte muy importante y eficaz de la arquitectura HTTP Nottingham.

La comprensión de cómo todas estas partes trabajan juntos pueden ser un poco difícil de hecho, de acuerdo con la tabla en la sección especificar el tiempo mínimo que CloudFront cachés Objetos para descargar Distribuciones dentro Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) intentos de resumir los efectos cuando se aplica en el contexto de CloudFront con o sin TTL = 0 específicamente.

Answer 2

Tenga en cuenta que Amazon no dice "TTL es 0", sino que dice "TTL mínimo es 0". y eso es muy diferente. La descripción anterior es muy deseable, pero no hay garantía de que Cloudfront realmente lo haga.

En mi experiencia en este momento, puedo ver una imagen almacenada en caché durante unos minutos en el borde, mientras que mi origen ya ha cambiado.

Creo que decir "TTL mínimo es 0" es probablemente más parecido a "Amazon no tiene la intención estricta de guardar esto en un caché", y tal vez "y se volverá a buscar con frecuencia".

Para aplicaciones como CMS, donde el usuario de la web publica contenido nuevo, creo que TTL-0 aún no es suficiente. Aún debe invocar invalidaciones del CMS o emplear rutas diferentes para diferentes números de versión.