Verstehen Sie die Cache-Richtlinien - Amazon CloudFront

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verstehen Sie die Cache-Richtlinien

Sie können eine Cache-Richtlinie verwenden, um Ihre Cache-Trefferquote zu verbessern, indem Sie die Werte (URL-Abfragezeichenfolgen, HTTP-Header und Cookies) kontrollieren, die im Cache-Schlüssel enthalten sind. CloudFrontbietet einige vordefinierte Cache-Richtlinien, die als verwaltete Richtlinien bezeichnet werden, für allgemeine Anwendungsfälle. Sie können diese verwalteten Richtlinien verwenden oder eine eigene Cache-Richtlinie erstellen, die speziell auf Ihre Anforderungen zugeschnitten ist. Weitere Informationen zu verwalteten Richtlinien finden Sie unter Verwaltete Cache-Richtlinien verwenden.

Eine Cache-Richtlinie enthält die folgenden Einstellungen, die in Richtlinieninformationen, Einstellungen für Time to Live (TTL, Gültigkeitsdauer der Verbindung) und Cache-Schlüssel-Einstellungen unterteilt sind.

Richtlinieninformationen

Name

Ein Name zur Identifizierung der Cache-Richtlinie. Verwenden Sie den Namen in der Konsole, um die Cache-Richtlinie einem Cache-Verhalten anzufügen.

Beschreibung

Ein Kommentar zur Beschreibung der Cache-Richtlinie. Dies ist optional, kann Ihnen jedoch helfen, den Zweck der Cache-Richtlinie zu identifizieren.

Einstellungen für Time to Live (TTL, Gültigkeitsdauer der Verbindung)

Die TTL-Einstellungen (Time to Live) bestimmen zusammen mit den Headern Cache-Control und den Expires HTTP-Headern (sofern sie in der ursprünglichen Antwort enthalten sind), wie lange Objekte im CloudFront Cache gültig bleiben.

Mindest-TTL

Die Mindestdauer in Sekunden, für die Objekte im CloudFront Cache verbleiben sollen, bevor beim Ursprung CloudFront überprüft wird, ob das Objekt aktualisiert wurde. Weitere Informationen finden Sie unter Verwalten Sie, wie lange Inhalte im Cache verbleiben (Ablauf).

Höchst-TTL

Die maximale Zeit in Sekunden, für die Objekte im CloudFront Cache verbleiben, bevor CloudFront beim Ursprung überprüft wird, ob das Objekt aktualisiert wurde. CloudFront verwendet diese Einstellung nur, wenn der Ursprung das Objekt sendet Cache-Control oder den Expires Header mit dem Objekt teilt. Weitere Informationen finden Sie unter Verwalten Sie, wie lange Inhalte im Cache verbleiben (Ablauf).

Standard-TTL

Die Standarddauer in Sekunden, für die Objekte im CloudFront Cache bleiben sollen, bevor beim Ursprung CloudFront überprüft wird, ob das Objekt aktualisiert wurde. CloudFront verwendet den Wert dieser Einstellung nur dann als TTL des Objekts, wenn der Ursprung keine Expires Kopfzeilen mit dem Objekt sendetCache-Control. Weitere Informationen finden Sie unter Verwalten Sie, wie lange Inhalte im Cache verbleiben (Ablauf).

Anmerkung

Wenn die Einstellungen Minimale TTL, Maximale TTL und Standard-TTL alle auf 0 gesetzt sind, wird das Caching deaktiviert. CloudFront

Cache-Schlüssel-Einstellungen

Die Cache-Schlüsseleinstellungen geben die Werte in Viewer-Anfragen an, die im Cache-Schlüssel CloudFront enthalten sind. Bei den Werten kann es sich um URL-Abfragezeichenfolgen, HTTP-Header und Cookies handeln. Die Werte, die Sie in den Cache-Schlüssel aufnehmen, sind automatisch in Anfragen enthalten, die CloudFront an den Ursprung gesendet werden, die als Ursprungsanfragen bezeichnet werden. Informationen zum Kontrollieren von Ursprungsanforderungen ohne Auswirkungen auf den Cache-Schlüssel finden Sie unter Kontrollieren Sie Herkunftsanfragen mit einer Richtlinie.

Zu den Cache-Schlüssel-Einstellungen gehören:

Header

Die HTTP-Header in Viewer-Anfragen, die im Cache-Schlüssel CloudFront enthalten sind, und in ursprünglichen Anfragen. Sie können für Header eine der folgenden Einstellungen auswählen:

  • None (Keine) – Die HTTP-Header in Viewer-Anforderungen sind nicht im Cache-Schlüssel enthalten und werden nicht automatisch in Ursprungsanforderungen eingeschlossen.

  • Folgende Header einschließen – Sie geben an, welche der HTTP-Header in Viewer-Anforderungen im Cache-Schlüssel enthalten sind und automatisch in Ursprungsanforderungen eingeschlossen werden.

Wenn Sie die Einstellung Folgende Header einschließen verwenden, geben Sie HTTP-Header nach ihrem Namen und nicht nach ihrem Wert an. Betrachten Sie beispielsweise den folgenden HTTP-Header:

Accept-Language: en-US,en;q=0.5

In diesem Fall geben Sie den Header als Accept-Language an, nicht als Accept-Language: en-US,en;q=0.5 an. CloudFrontSchließt jedoch den vollständigen Header, einschließlich seines Werts, in den Cache-Schlüssel und in Ursprungsanfragen ein.

Sie können auch bestimmte Header, die von generiert wurden, CloudFront in den Cache-Schlüssel aufnehmen. Weitere Informationen finden Sie unter CloudFront Anforderungsheader hinzufügen.

Cookies

Die Cookies in Viewer-Anfragen, die im Cache-Schlüssel CloudFront enthalten sind, und in Ursprungsanfragen. Für Cookies können Sie eine der folgenden Einstellungen auswählen:

  • None (Keine) – Die Cookies in Viewer-Anforderungen sind nicht im Cache-Schlüssel enthalten und werden nicht automatisch in Ursprungsanforderungen aufgenommen.

  • All (Alle) – Alle Cookies in Viewer-Anforderungen sind im Cache-Schlüssel enthalten und werden automatisch in Ursprungsanforderungen aufgenommen.

  • Angegebene Cookies einschließen – Sie geben an, welche der Cookies in Viewer-Anforderungen im Cache-Schlüssel enthalten sind und automatisch in Ursprungsanforderungen eingeschlossen werden.

  • Alle Cookies einschließen außer – Sie geben an, welche der Cookies in Viewer-Anforderungen nicht im Cache-Schlüssel enthalten sind und nicht automatisch in Ursprungsanforderungen enthalten sind. Alle anderen Cookies, mit Ausnahme der von ihnen angegebenen, sind im Cache-Schlüssel und automatisch in Ursprungsanforderungen enthalten.

Wenn Sie die Einstellung Angegebene Cookies einschließen oder Alle Cookies einschließen außer verwenden verwenden, geben Sie Cookies nach ihrem Namen und nicht nach ihrem Wert an. Betrachten Sie beispielsweise den folgenden Cookie-Header:

Cookie: session_ID=abcd1234

In diesem Fall geben Sie das Cookie als session_ID, nicht als session_ID=abcd1234 an. CloudFront Schließt jedoch das vollständige Cookie, einschließlich seines Werts, in den Cache-Schlüssel und in Ursprungsanfragen ein.

Abfragezeichenfolgen

Die URL-Abfragezeichenfolgen in Viewer-Anfragen, die im Cache-Schlüssel CloudFront enthalten sind, und in ursprünglichen Anfragen. Für Abfragezeichenfolgen können Sie eine der folgenden Einstellungen auswählen:

  • None (Keine) – Abfragezeichenfolgen in Viewer-Anforderungen sind nicht im Cache-Schlüssel enthalten und sind nicht automatisch in Ursprungsanforderungen enthalten.

  • All (Alle) – Alle Abfragezeichenfolgen in Viewer-Anforderungen sind im Cache-Schlüssel enthalten und sind auch automatisch in Ursprungsanforderungen enthalten.

  • Angegebene Abfragezeichenfolgen einschließne – Sie geben an, welche der Abfragezeichenfolgen in Viewer-Anforderungen im Cache-Schlüssel enthalten sind und automatisch in Ursprungsanforderungen eingeschlossen werden.

  • Alle Abfragezeichenfolgen einschließen außer – Sie geben an, welche der Abfragezeichenfolgen in Viewer-Anforderungen nicht im Cache-Schlüssel enthalten sind und nicht automatisch in Ursprungsanforderungen eingeschlossen werden. Alle anderen Abfragezeichenfolgen außer denen, die Sie angegeben haben, sind im Cache-Schlüssel und automatisch in Ursprungsanforderungen enthalten.

Wenn Sie die Einstellung Angegebene Abfragezeichenfolgen einschließen oder Alle Abfragezeichenfolgen einschließen außer verwenden, geben Sie Abfragezeichenfolgen nach ihrem Namen und nicht nach ihrem Wert an. Betrachten Sie beispielsweise den folgenden URL-Pfad:

/content/stories/example-story.html?split-pages=false

In diesem Fall geben Sie die Abfragezeichenfolge als split-pages, nicht als split-pages=false an. CloudFront Schließt jedoch die vollständige Abfragezeichenfolge, einschließlich ihres Werts, in den Cache-Schlüssel und in Ursprungsanfragen ein.

Komprimierungsunterstützung

Diese Einstellungen CloudFront ermöglichen das Anfordern und Zwischenspeichern von Objekten, die im Gzip- oder Brotli-Komprimierungsformat komprimiert sind, sofern der Viewer dies unterstützt. Mit diesen Einstellungen funktioniert auch die CloudFront Komprimierung. Viewer geben ihre Unterstützung für diese Komprimierungsformate mit dem Accept-Encoding-HTTP-Header an.

Anmerkung

Die Webbrowser Chrome und Firefox unterstützen die Brotli-Komprimierung nur, wenn die Anforderung über HTTPS gesendet wird. Diese Browser unterstützen Brotli mit HTTP-Anforderungen nicht.

Aktivieren Sie diese Einstellungen, wenn eine der folgenden Bedingungen zutrifft:

  • Ihr Ursprung gibt mit Gzip komprimierte Objekte zurück, wenn Viewer diese unterstützen (Anforderungen enthalten den Accept-Encoding-HTTP-Header mit gzip als Wert). Verwenden Sie in diesem Fall die Einstellung „Gzip aktiviert“ (truein der CloudFront API, den AWS SDKs oder AWS CloudFormation auf eingestelltEnableAcceptEncodingGzip). AWS CLI

  • Ihr Ursprung gibt mit Brotli komprimierte Objekte zurück, wenn Viewer diese unterstützen (Anforderungen enthalten den Accept-Encoding-HTTP-Header mit br als Wert). Verwenden Sie in diesem Fall die Einstellung Brotli enabled (truein der CloudFront API, den AWS SDKs oder EnableAcceptEncodingBrotli auf eingestellt). AWS CLI AWS CloudFormation

  • Das Cache-Verhalten, an das diese Cache-Richtlinie angehängt ist, ist mit Komprimierung konfiguriert. CloudFront In diesem Fall können Sie die Zwischenspeicherung für Gzip oder Brotli oder beides aktivieren. Wenn die CloudFront Komprimierung aktiviert ist, kann die Aktivierung des Zwischenspeichers für beide Formate dazu beitragen, Ihre Kosten für die Datenübertragung ins Internet zu senken.

Anmerkung

Wenn Sie das Caching für eines oder beide dieser Komprimierungsformate aktivieren, sollten Sie den Accept-Encoding Header nicht in eine Quellanforderungsrichtlinie aufnehmen, die demselben Cache-Verhalten zugeordnet ist. CloudFrontbezieht diesen Header immer in ursprüngliche Anfragen ein, wenn das Caching für eines dieser Formate aktiviert ist, sodass die Aufnahme Accept-Encoding in eine Richtlinie für ursprüngliche Anfragen keine Auswirkung hat.

Wenn Ihr Ursprungsserver keine mit Gzip oder Brotli komprimierten Objekte zurückgibt oder das Cache-Verhalten nicht mit CloudFront Komprimierung konfiguriert ist, aktivieren Sie das Caching für komprimierte Objekte nicht. Wenn Sie dies dennoch tun, kann dies zu einer Verringerung der Cache-Trefferquote führen.

Im Folgenden wird erklärt, wie sich diese Einstellungen auf eine Verteilung auswirken. CloudFront In allen folgenden Szenarien wird davon ausgegangen, dass die Viewer-Anforderung den Accept-Encoding-Header enthält. Wenn die Viewer-Anfrage den Accept-Encoding Header nicht enthält, CloudFront nimmt sie diesen Header nicht in den Cache-Schlüssel auf und nimmt ihn nicht in die entsprechende ursprüngliche Anfrage auf.

Wenn das Zwischenspeichern komprimierter Objekte für beide Komprimierungsformate aktiviert ist

Wenn der Viewer sowohl Gzip als auch Brotli unterstützt — das heißt, wenn sich die br Werte gzip und beide im Accept-Encoding Header der Viewer-Anfrage befinden — wird wie folgt vorgegangen: CloudFront

  • Sie normalisiert den Header zu Accept-Encoding: br,gzip und schließt den normalisierten Header in den Cache-Schlüssel ein. Der Cache-Schlüssel enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

  • Wenn der Edge-Standort ein mit Brotli oder Gzip komprimiertes Objekt im Cache enthält, das der Anforderung entspricht und nicht abgelaufen ist, gibt der Edge-Standort das Objekt an den Viewer zurück.

  • Wenn der Edge-Standort kein komprimiertes Brotli- oder Gzip-Objekt im Cache hat, das der Anfrage entspricht und nicht abgelaufen ist, nimmt er den normalisierten Header () in die CloudFront entsprechende ursprüngliche Anfrage auf. Accept-Encoding: br,gzip Die Ursprungsanforderung enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

Wenn der Viewer ein Komprimierungsformat unterstützt, das andere aber nicht — zum Beispiel, wenn es sich um einen Wert im Accept-Encoding Header der Viewer-Anfrage gzip handelt, dies aber nicht br ist —, wird wie folgt vorgegangen: CloudFront

  • Sie normalisiert den Header zu Accept-Encoding: gzip und schließt den normalisierten Header in den Cache-Schlüssel ein. Der Cache-Schlüssel enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

  • Wenn der Edge-Standort ein mit Gzip komprimiertes Objekt im Cache enthält, das der Anforderung entspricht und nicht abgelaufen ist, gibt der Edge-Standort das Objekt an den Viewer zurück.

  • Wenn der Edge-Standort kein Gzip-komprimiertes Objekt im Cache hat, das der Anfrage entspricht und nicht abgelaufen ist, CloudFront nimmt er den normalisierten Header (Accept-Encoding: gzip) in die entsprechende Ursprungsanforderung auf. Die Ursprungsanforderung enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

Um zu verstehen, was CloudFront passiert, wenn der Viewer Brotli, aber nicht Gzip unterstützt, ersetzen Sie die beiden Komprimierungsformate im vorherigen Beispiel miteinander.

Falls der Viewer Brotli oder GZip nicht unterstützt — das heißt, der Accept-Encoding Header in der Viewer-Anfrage enthält keine Werte oder als Werte —: br gzip CloudFront

  • Schließt den Accept-Encoding-Header nicht in den Cache-Schlüssel ein.

  • Schließt Accept-Encoding: identity in die entsprechende Ursprungsanforderung ein. Die Ursprungsanforderung enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

Wenn die Zwischenspeicherung komprimierter Objekte für ein Komprimierungsformat aktiviert ist, aber nicht für das andere

Wenn der Viewer das Format unterstützt, für das das Caching aktiviert ist — zum Beispiel, wenn das Zwischenspeichern komprimierter Objekte für Gzip aktiviert ist und der Viewer Gzip unterstützt (gzipist einer der Werte im Header der Viewer-Anfrage) — geht Folgendes vor: Accept-Encoding CloudFront

  • Sie normalisiert den Header zu Accept-Encoding: gzip und schließt den normalisierten Header in den Cache-Schlüssel ein.

  • Wenn der Edge-Standort ein mit Gzip komprimiertes Objekt im Cache enthält, das der Anforderung entspricht und nicht abgelaufen ist, gibt der Edge-Standort das Objekt an den Viewer zurück.

  • Wenn der Edge-Standort kein Gzip-komprimiertes Objekt im Cache hat, das der Anfrage entspricht und nicht abgelaufen ist, wird der normalisierte Header () in die entsprechende CloudFront Ursprungsanforderung aufgenommen. Accept-Encoding: gzip Die Ursprungsanforderung enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

Dieses Verhalten ist identisch, wenn der Viewer sowohl Gzip als auch Brotli unterstützt (der Accept-Encoding-Header in der Viewer-Anforderung enthält gzip und br als Werte), da in diesem Szenario das Zwischenspeichern komprimierter Objekte für Brotli nicht aktiviert ist.

Um zu verstehen, was CloudFront passiert, wenn das Zwischenspeichern komprimierter Objekte für Brotli, aber nicht für Gzip aktiviert ist, ersetzen Sie die beiden Komprimierungsformate im vorherigen Beispiel durch einander.

Falls der Viewer das Komprimierungsformat, für das das Caching aktiviert ist, nicht unterstützt (der Accept-Encoding Header in der Viewer-Anfrage enthält nicht den Wert für dieses Format), gilt Folgendes: CloudFront

  • Schließt den Accept-Encoding-Header nicht in den Cache-Schlüssel ein.

  • Schließt Accept-Encoding: identity in die entsprechende Ursprungsanforderung ein. Die Ursprungsanforderung enthält keine anderen Werte, die sich in dem vom Viewer gesendeten Accept-Encoding-Header befanden.

Wenn das Zwischenspeichern komprimierter Objekte für beide Komprimierungsformate deaktiviert ist

Wenn das Zwischenspeichern komprimierter Objekte für beide Komprimierungsformate deaktiviert ist, wird der Accept-Encoding Header genauso CloudFront behandelt wie jeder andere HTTP-Header in der Viewer-Anforderung. Standardmäßig ist dieser nicht im Cache-Schlüssel und nicht in Ursprungsanforderungen enthalten. Sie können diesen wie jeden anderen HTTP-Header in eine Cache-Richtlinie oder eine Ursprungsanforderungsrichtlinie in die Header-Liste einfügen.