Vor einigen Wochen gab Amazon bekannt, dass die Ablauffrist für Inhalte verkürzt wurde:
Amazon CloudFront senkt den Mindestablaufzeitraum für Inhalte
So viel, dass Sie jetzt tatsächlich TTL in CloudFront auf 0 setzen können. Meine Frage ist also, warum es nützlich sein könnte, eine CloudFront-Distribution mit TTL auf 0 zu setzen. Für mich bedeutet dies überhaupt kein Caching, also jede Anfrage, die an CloudFront geht wird am Ende den Ursprung treffen.
Was vermisse ich?
Antworten:
Diese neue Funktion von Amazon CloudFront ist für viele Anwendungsfälle äußerst nützlich, da das Schlagen des Ursprungs etwas anders funktioniert als auf den ersten Blick und im Gegenteil nicht unbedingt ein Problem darstellt. Obwohl diese Funktion bereits früher veröffentlicht wurde, wird sie zusammen mit der kürzlich veröffentlichten Version von Amazon CloudFront - Unterstützung für dynamische Inhalte bereitgestellt , z. B. für die folgende Frage:
Variable Time-to-Live (TTL) - In vielen Fällen können dynamische Inhalte entweder nicht oder nur für einen sehr kurzen Zeitraum, möglicherweise nur für einige Sekunden, zwischengespeichert werden. In der Vergangenheit betrug die minimale TTL von CloudFront 60 Minuten, da der gesamte Inhalt als statisch angesehen wurde. Der neue minimale TTL-Wert beträgt 0 Sekunden. Wenn Sie die TTL für einen bestimmten Ursprung auf 0 setzen, speichert CloudFront den Inhalt dieses Ursprungs weiterhin zwischen. Anschließend wird eine GET-Anforderung mit einem If-Modified-Since-Header gesendet, wodurch der Ursprung die Möglichkeit erhält, zu signalisieren, dass CloudFront den zwischengespeicherten Inhalt weiterhin verwenden kann, wenn er sich am Ursprung nicht geändert hat . [Hervorhebung von mir]
Mit anderen Worten bedeutet die Verwendung einer TTL von 0 in erster Linie, dass CloudFront die Berechtigung zur Cache-Steuerung an den Ursprung delegiert, dh der Ursprungsserver entscheidet, ob und wie lange CloudFront die Objekte zwischenspeichert. Bitte beachten Sie insbesondere, dass eine GET - Anforderung mit einer If-Modified-Since Header nicht notwendigerweise bedeutet , dass das Objekt selbst vom Ursprung abgerufen wird, vielmehr kann der Ursprung (und sollten) die Rückkehr 304 HTTP - Statuscode - Modifizierte nicht soweit erhoben ::
Gibt an, dass die Ressource seit der letzten Anforderung nicht geändert wurde. [...] Dies spart Bandbreite und Wiederaufbereitung sowohl auf dem Server als auch auf dem Client, da nur die Header-Daten gesendet und empfangen werden müssen, verglichen mit der gesamten Seite, die vom Server erneut verarbeitet und dann mit mehr Bandbreite erneut gesendet wird des Servers und Clients. [Hervorhebung von mir]
Siehe Mark Nottinghams exzellentes Caching-Tutorial Informationen zu den Mechanismen und Vorteilen der HTTP-Cache-Steuerung, einem wirklich wichtigen und effektiven Teil der HTTP-Architektur, finden .
Das Verständnis, wie all diese Teile zusammenarbeiten, kann in der Tat etwas schwierig sein. Dementsprechend versucht die Tabelle im Abschnitt Festlegen der Mindestzeit, in der CloudFront Objekte für Download-Verteilungen zwischenspeichert, innerhalb der Angabe, wie lange Objekte in einem CloudFront-Edge-Cache verbleiben (Objektablauf) , die Auswirkungen zusammenzufassen bei Anwendung im Kontext von CloudFront mit oder ohne TTL = 0.
Beachten Sie, dass Amazon nicht "TTL ist 0" sagt, sondern "Minimum TTL ist 0". und das ist ganz anders. Die obige Beschreibung ist sehr wünschenswert, es gibt jedoch keine Garantie dafür, dass Cloudfront dies tatsächlich tut.
Nach meinen derzeitigen Erfahrungen kann ich sehen, dass ein zwischengespeichertes Bild einige Minuten am Rand bleibt, während sich mein Ursprung bereits geändert hat.
Ich denke also, dass "Minimum TTL is 0" wahrscheinlich eher "Amazon hat nicht die strikte Absicht, dies in einem Cache zu behalten" und vielleicht "und es wird oft neu abgerufen".
Für Anwendungen wie CMS, bei denen der Webbenutzer neue Inhalte veröffentlicht, reicht TTL-0 meiner Meinung nach immer noch nicht aus. Sie müssen weiterhin entweder Ungültigmachungen vom CMS aus aufrufen oder unterschiedliche Pfade für unterschiedliche Versionsnummern verwenden.
CloudFront kann in Kombination mit dem Zertifikatmanager verwendet werden, um S3-Websites HTTPS-Unterstützung hinzuzufügen. Vielleicht möchten Sie dies, aber kein Caching.
Ein weiterer Anwendungsfall hierfür ist, wenn Sie die Header der Anforderung für nicht zwischenspeicherbaren Inhalt mithilfe von Lambda Edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge bearbeiten möchten . html . Beispiel x-api-key.