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 denExpires
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 alsAccept-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.
-
-
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 alssession_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 alssplit-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 mitgzip
als Wert). Verwenden Sie in diesem Fall die Einstellung „Gzip aktiviert“ (true
in 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 mitbr
als Wert). Verwenden Sie in diesem Fall die Einstellung Brotli enabled (true
in der CloudFront API, den AWS SDKs oderEnableAcceptEncodingBrotli
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 AufnahmeAccept-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 denAccept-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
Wertegzip
und beide imAccept-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 gesendetenAccept-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 gesendetenAccept-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-Anfragegzip
handelt, dies aber nichtbr
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 gesendetenAccept-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 gesendetenAccept-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 gesendetenAccept-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 (
gzip
ist 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 gesendetenAccept-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ältgzip
undbr
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 gesendetenAccept-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.
-