Problem
Warum laufen Bilder in einem Browser sofort ab?
Lösung
CDN-Zwischenspeicherung und TTL (Time-To-Live)
Mit Adobe Scene7 könne Sie verschiedene Ablaufzeiten für spezifische Bilder festlegen. Beispiel: Das Standardbild, das angezeigt wird, wenn ein Bild nicht gefunden wird, wird automatisch so konfiguriert, dass es eine kürzere Ablaufzeit hat.
Time-To-Live (TTL) ist ein Mechanismus, um die Lebensdauer von Daten in einem Netzwerk zu beschränken. Diese Konfiguration wird von unseren Content Delivery Network (CDN)-Providern angeboten. Wenn die Lebenszeit vergangen ist, löst eine GET-Anfrage für ein Objekt eine IMS (If-Modified-Since)-Anfrage an den Herkunftsort in Scene7 aus. Wenn unser CDN-Provider eine 304-Antwort (Not-Modified - nicht verändert) von unseren Herkunftsservern erhält, wird das Objekt gemeinsam mit einer aktualisierten Expires-Kopfzeile aktualisiert, wenn es sich verändert hat.
Vor einigen Jahren hatten wir eine TTL von zehn Stunden, die maßgeblich war und die Expires-Kopfzeile hatte keinen Einfluss auf unsere CDN-Zwischenspeicherung. Diese Einstellung wurde geändert, sodass beim Ablauf eines Objekts mit der CDN-TTL oder auf der Basis der Kopfzeile „Expires:“ das Objekt bei der nächsten „GET“-Abfrage aktualisiert wurde. Dieser Prozess aktualisiert auch die Kopfzeilen. Kurz gesagt haben wir die TTL des CDN überschrieben, wenn die Expires-Kopfzeile kürzer als die konfigurierte TTL ist.
Die obige Bedingung gilt, wenn das Objekt auf Akamai „in-cache“ - im Zwischenspeicher - ist. Wenn Akamai eine If-Modified-Since (IMS)-Abfrage an den Herkunftsort sendet, hat dies kein hohes Datenaufkommen, da nur HTTP-Kopfzeilen ausgetauscht werden. Das Objekt wird nicht erneut heruntergeladen. Unser CDN prüft nur, ob das Objekt unverändert ist und aktualisiert die TTL dieses Objekts im Zwischenspeicher.
Die Auswirkung dieser Veränderung der CDN-Konfiguration war, dass jetzt häufiger IMS-Abfragen an die Herkunftsserver für Inhalte mit niedriger Ablaufzeit durchgeführt werden.
Die CDN-Konfiguration verändert sich, warum würde ein Bild in einem Browser sofort ablaufen?
Beispiel:
Antwort-Kopfzeilen:
Content-Type[image/jpeg]
Last-Modified[Wed, 20 Jun 2007 21:29:20 GMT]
Etag["0b3a49e639331555ba959a9f1e332c2f"]
Expires[Mon, 13 Aug 2007 02:00:28 GMT]
Date[Mon, 13 Aug 2007 02:00:28 GMT]
Connection[keep-alive]
Vor einigen Jahren wurde dieses Objekt im Zwischenspeicher mit einer Expires-Kopfzeile mit Ablaufdatum in der Vergangenheit gespeichert:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Expires: Mon, 13 Aug 2007 16:53:16 GMT
Last-Modified: Thu, 19 Jul 2007 21:42:18 GMT
ETag: "ebb5a6db6c4e78a15db53a29d9d0b9d2"
Content-Type: image/jpeg
Content-Length: 14141
Date: Mon, 13 Aug 2007 06:53:15 GMT
Age: 0
X-Akamai-Purge-Seq-Num: 1336350
Connection: keep-alive
Mit unseren früheren Konfigurationseinstellungen von Content Delivery Network (CDN) war dieses Verhalten beabsichtigt. Ein Objekt, das im Zwischenspeicher mit einer Expires-Kopfzeile mit Ablaufdatum in der Vergangenheit gespeichert wurde, resultierte in einer nachgeschalteten Expires-Kopfzeile von „now“ - jetzt. Das Datum für „Last-modified“ wurde nicht geändert. Eine HTTP-304-Antwort vom Herkunftsort für eine If-Modified-Since (IMS)-Anfrage aktualisierte daher nicht die Kopfzeilen von mit Akamai zwischengespeicherten Objekten. Wenn ein Objekt zwischengespeichert und abgelaufen war, sendete unser CDN-Provider immer eine „If-Modified-Since“ (IMS)-Abfrage an den Herkunftsort. Da das „Last Modified“-Datum dasselbe ist, erhielt unser CDN-Provider eine HTTP-304-Antwort. Dann wurde die Time-To-Live (TTL) des Objektzwischenspeichers auf zehn Stunden, basierend auf der Konfiguration, aktualisiert. Das Objekt und die Kopfzeilen blieben aber unverändert.
An diesem Punkt haben wir die Metadaten aktualisiert, um das Update der zwischengespeicherten Kopfzeilen zu kontrollieren.
Der Tag, der es uns erlaubte, die Kopfzeilen zur Zwischenspeicherung auf eine 304-Antwort vom Herkunftsserver zu ändern, war:
<cache:header-update.allow>on</cache:header-update.allow>
Standardmäßig aktualisiert unser CDN-Provider die Kopfzeilen in einem zwischengespeicherten Objekt nicht mit den in einer 304-Antwort erhaltenen Kopfzeilen. Wenn die angegebene Ablaufzeit vergangen ist, blieb das Objekt daher im CDN-Speicher (und für jeden Endbenutzer) abgelaufen, bis der Herkunftsort eine 200-Antwort mit einem neuen Objekt zurückgab. Sobald die angegebene Ablaufzeit erreicht wurde, fuhr der CDN-Server damit fort, bei jeder Anfrage erneut mit dem Herkunftsort zu validieren, wenn der Herkunftsort eine 304-Antwort zurückgab. Er gab auch dem Client-Browser ein Objekt, das bereits abgelaufen war. Der Browser musste beim nächsten Ladevorgang erneut validieren.
Als wir den „cache:head-update.allow“-Tag aktivierten, beauftragte dies die CDN-Server, die Kopfzeilen maßgeblich für die Zwischenspeicherung in der zwischengespeicherten Antwort zu aktualisieren, wenn sie in der 304-Antwort anders waren. Kopfzeilen, die als maßgeblich für die Zwischenspeicherung gelten, sind für diese Funktion: Expires, Cache-Control, Edge-Control (und indirekt Surrogate-Control).
Es gibt auch ein zugehöriges Steuerelement zur Festlegung, wie oft die Kopfzeilen im Zwischenspeicher aktualisiert werden. Dieses Steuerelement ist nur vorhanden, um eine Situation zu verhindern, in der der CDN-Server bei jeder Antwort Kopfzeilen zum Zwischenspeichern schreiben muss, da der Herkunftssender mit jeder Antwort eine neue Expires-Kopfzeile festlegt (nicht der Fall mit Adobe Scene7-Antworten). Die Standardeinstellung für die Häufigkeit der Kopfzeilenaktualisierung ist eine Minute. Dieser Wert kann jedoch mit dem Metdaten-Tag geändert werden:
<cache:header-update.max-frequency>1m</cache:header-update.max-frequency>
Wenn die TTL erreicht ist, wird das Objekt auf EdgeServers als abgelaufen betrachtet. Eine IMS-Anfrage wird immer an den Herkunftsort gesendet, um die Zeit der letzten Veränderung dieses Objekts zu überprüfen.
Diese Metadaten-Veränderung erlaubt das Aktualisieren der Kopfzeilen gemeinsam mit der 304-Antwort vom Herkunftsort. Diese Änderung führte nicht zu einem vollständigen Download dieses Objekts, wenn es nicht geändert wurde.
Die If-Modified-Since-Anfrage an die Herkunftsserver wird nur erstellt, wenn der Inhalt abgelaufen ist. Das bedeutet, dass die Kopfzeilen nach Ablauf der TTL nur selten aktualisiert werden.
Bei Ihrem Konto anmelden