Verhalten von Anfragen und Antworten für Amazon-S3-Ursprünge

In den folgenden Abschnitten erfahren Sie, wie Anfragen und Antworten CloudFront verarbeitet werden, wenn Sie Amazon S3 als Ausgangspunkt verwenden:

Wie CloudFront verarbeitet und leitet Anfragen an Ihren Amazon S3-Ursprung weiter

Erfahren Sie, wie Viewer-Anfragen CloudFront verarbeitet und die Anfragen an Ihren Amazon S3-Ursprung weitergeleitet werden.

Inhalt

• Cache-Dauer und Mindest-TTL

• Client-IP-Adressen

• Bedingte GET-Anforderungen

• Cookies

• Cross-origin gemeinsame Nutzung von Ressourcen (CORS)

• GET-Anfragen mit Anfragetext

• HTTP-Methoden

• HTTP-Anforderungsheader, die CloudFront entfernt oder aktualisiert werden

• Maximale Länge einer Anfrage und maximale Länge einer URL

• OCSP-Stapling

• Protokolle

• Abfragezeichenfolgen

• Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

• Ursprungs-Reaktions-Timeout

• Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)

Cache-Dauer und Mindest-TTL

Um zu steuern, wie lange Ihre Objekte in einem CloudFront Cache bleiben, bevor sie CloudFront eine weitere Anfrage an Ihren Ursprung weiterleiten, können Sie:

• Ihren Ursprungsserver so konfigurieren, dass jedem Objekt ein Cache-Control- oder Expires-Header-Feld hinzugefügt wird

• Geben Sie einen Wert für die Mindest-TTL im CloudFront Cache-Verhalten an.

• Den Standardwert von 24 Stunden verwenden

Weitere Informationen finden Sie unter Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf).

Client-IP-Adressen

Wenn ein Viewer eine Anfrage an einen Anforderungsheader sendet CloudFront und keinen X-Forwarded-For Anforderungsheader enthält, CloudFront ruft er die IP-Adresse des Viewers von der TCP-Verbindung ab, fügt einen X-Forwarded-For Header hinzu, der die IP-Adresse enthält, und leitet die Anfrage an den Ursprung weiter. Wenn CloudFront z. B. die IP-Adresse 192.0.2.2 von der TCP-Verbindung abruft, wird der folgende Header an den Ursprungs-Server weitergeleitet:

X-Forwarded-For: 192.0.2.2

Wenn ein Viewer eine Anfrage an einen Request-Header sendet CloudFront und einen X-Forwarded-For Request-Header einschließt, CloudFront ruft er die IP-Adresse des Viewers von der TCP-Verbindung ab, hängt sie an das Ende des X-Forwarded-For Headers an und leitet die Anfrage an den Ursprung weiter. Wenn die Viewer-Anfrage beispielsweise die IP-Adresse der TCP-Verbindung enthält X-Forwarded-For: 192.0.2.4,192.0.2.3 und 192.0.2.2 von ihr CloudFront abruft, leitet sie den folgenden Header an den Ursprung weiter:

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Anmerkung

Der X-Forwarded-For-Header enthält IPv4-Adressen (z. B. 192.0.2.44) und IPv6-Adressen (z. B. 2001:0db8:85a3::8a2e:0370:7334).

Verwenden Sie beim Analysieren von IPv6-Adressen im X-Forwarded-For Header Standardbibliotheken zum Analysieren von IP-Adressen, die jedes gültige RFC 4291-IPv6-Format verarbeiten können.

Bedingte GET-Anforderungen

Wenn eine CloudFront Anfrage für ein Objekt aus einem Edge-Cache eingeht, das abgelaufen ist, leitet es die Anfrage an den Amazon S3-Ursprung weiter, um die neueste Version des Objekts abzurufen oder um von Amazon S3 eine Bestätigung zu erhalten, dass der CloudFront Edge-Cache bereits über die neueste Version verfügt. Als Amazon S3 das Objekt ursprünglich an sendete CloudFront, enthielt es einen ETag Wert und einen LastModified Wert in der Antwort. Fügt in der neuen Anfrage CloudFront , die an Amazon S3 weitergeleitet wird, einen oder beide der folgenden Header CloudFront hinzu:

• Einen If-Match- oder If-None-Match-Header mit dem ETag-Wert für die abgelaufene Version des Objekts

• Einen If-Modified-Since-Header mit dem LastModified-Wert für die abgelaufene Version des Objekts

Amazon S3 verwendet diese Informationen, um zu ermitteln, ob das Objekt aktualisiert wurde und daher, ob das gesamte Objekt an einen HTTP 304-Statuscode (nicht geändert) zurückgegeben werden soll CloudFront oder nur an einen HTTP 304-Statuscode zurückgegeben werden soll.

Cookies

Amazon S3 verarbeitet keine Cookies. Wenn Sie ein Cache-Verhalten so konfigurieren, dass Cookies an einen Amazon S3-Ursprung weitergeleitet werden, CloudFront leitet es die Cookies weiter, Amazon S3 ignoriert sie jedoch. Alle zukünftigen Anfragen zu demselben Objekt werden mithilfe des im Cache vorhandenen Objekts bedient – unabhängig davon, ob Sie Änderungen an den Cookies vornehmen.

Cross-origin gemeinsame Nutzung von Ressourcen (CORS)

Wenn Sie CloudFront die Amazon S3-Einstellungen für die ursprungsübergreifende gemeinsame Nutzung von Ressourcen respektieren möchten, konfigurieren Sie, dass ausgewählte Header CloudFront an Amazon S3 weitergeleitet werden. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern.

GET-Anfragen mit Anfragetext

Wenn eine GET Viewer-Anfrage einen Text enthält, wird der HTTP-Statuscode 403 (Forbidden) an den Betrachter CloudFront zurückgegeben.

HTTP-Methoden

Wenn Sie die Konfiguration so konfigurieren CloudFront , dass alle unterstützten HTTP-Methoden verarbeitet werden, CloudFront akzeptiert es die folgenden Anfragen von Viewern und leitet sie an Ihren Amazon S3-Ursprung weiter:

• DELETE

• GET

• HEAD

• OPTIONS

• PATCH

• POST

• PUT

CloudFront speichert Antworten auf GET und HEAD Anfragen immer im Cache. Sie können auch so konfigurieren CloudFront , dass Antworten auf OPTIONS Anfragen zwischengespeichert werden. CloudFront speichert keine Antworten auf Anfragen, die die anderen Methoden verwenden.

Wenn Sie mehrteilige Uploads verwenden möchten, um Objekte zu einem Amazon S3-Bucket hinzuzufügen, müssen Sie Ihrer Distribution eine CloudFront Origin Access Control (OAC) hinzufügen und dem OAC die erforderlichen Berechtigungen erteilen. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf einen Amazon-S3-Ursprung.

Wichtig

Wenn Sie so konfigurieren CloudFront , dass alle CloudFront unterstützten HTTP-Methoden akzeptiert und an Amazon S3 weitergeleitet werden, müssen Sie ein CloudFront OAC erstellen, um den Zugriff auf Ihre Amazon S3-Inhalte einzuschränken, und dem OAC die erforderlichen Berechtigungen erteilen. Wenn Sie beispielsweise so konfigurieren CloudFront , dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie die PUT Methode verwenden möchten, müssen Sie die Amazon S3-Bucket-Richtlinien so konfigurieren, dass DELETE Anfragen angemessen behandelt werden, sodass Zuschauer keine Ressourcen löschen können, die Sie nicht möchten. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf einen Amazon-S3-Ursprung.

Informationen zu den von Amazon S3 unterstützten Operationen finden Sie in der Amazon S3-Dokumentation.

HTTP-Anforderungsheader, die CloudFront entfernt oder aktualisiert werden

CloudFront entfernt oder aktualisiert einige Header, bevor Anfragen an Ihren Amazon S3-Ursprung weitergeleitet werden. Für die meisten Header ist dieses Verhalten dasselbe wie für benutzerdefinierte Ursprünge. Eine vollständige Liste der HTTP-Anforderungsheader und deren Verarbeitung finden CloudFront Sie unter. Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3-Ursprünge)

Maximale Länge einer Anfrage und maximale Länge einer URL

Die maximale Länge einer Anfrage, einschließlich des Pfads, der Abfragezeichenfolge (falls vorhanden) und der Header, beträgt 32.768 Byte.

CloudFront erstellt eine URL aus der Anfrage. Die maximale Länge dieser URL beträgt 8 192 Byte.

Wenn eine URL die maximale Länge überschreitet, wird der HTTP-Statuscode 414 (URI Too Long) an den Viewer CloudFront zurückgegeben. Wenn eine Anforderung die maximale Länge überschreitet, weil die Header-Größe überschritten wird, wird der HTTP-Statuscode 494 an den Viewer CloudFront zurückgegeben. In beiden Fällen CloudFront wird dann die TCP-Verbindung zum Viewer beendet.

OCSP-Stapling

Wenn ein Betrachter eine HTTPS-Anfrage für ein Objekt einreicht CloudFront oder der Betrachter bei der Zertifizierungsstelle (CA) bestätigen muss, dass das SSL-Zertifikat für die Domain nicht gesperrt wurde. OCSP-Stapling beschleunigt die Zertifikatsvalidierung, indem es ermöglicht CloudFront , das Zertifikat zu validieren und die Antwort von der CA zwischenzuspeichern, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.

Die Leistungsverbesserung durch OCSP-Stapling ist ausgeprägter, wenn CloudFront viele HTTPS-Anfragen für Objekte in derselben Domain eingehen. Jeder Server an einem CloudFront -Edge-Standort muss eine separate Validierungsanfrage senden. Wenn viele HTTPS-Anfragen für dieselbe Domain eingehen, CloudFront erhält jeder Server am Edge-Standort bald eine Antwort von der CA, die er an ein Paket im SSL-Handshake heften kann. Wenn der Betrachter davon überzeugt ist, dass das Zertifikat gültig ist, CloudFront kann er das angeforderte Objekt bereitstellen. Wenn Ihre Verteilung nicht viel Datenverkehr an einem CloudFront -Edge-Standort generiert, werden neue Anfragen mit einer höheren Wahrscheinlichkeit an einen Server weitergeleitet, der das Zertifikat noch nicht bei der CA validiert hat. In diesem Fall führt der Viewer den Validierungsschritt separat durch und der CloudFront Server stellt das Objekt bereit. Dieser CloudFront Server sendet auch eine Validierungsanforderung an die CA. Wenn er also das nächste Mal eine Anfrage erhält, die denselben Domainnamen enthält, erhält er eine Validierungsantwort von der CA.

Protokolle

CloudFront leitet HTTP- oder HTTPS-Anfragen an den Ursprungsserver weiter, basierend auf dem Protokoll der Viewer-Anfrage, entweder HTTP oder HTTPS.

Wichtig

Wenn Ihr Amazon S3-Bucket als Website-Endpunkt konfiguriert ist, können Sie nicht so konfigurieren CloudFront , dass HTTPS für die Kommunikation mit Ihrem Ursprung verwendet wird, da Amazon S3 in dieser Konfiguration keine HTTPS-Verbindungen unterstützt.

Abfragezeichenfolgen

Sie können konfigurieren, ob Abfragezeichenfolgenparameter an Ihren Amazon S3-Ursprung CloudFront weitergeleitet werden sollen. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern.

Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

Das Timeout der Ursprungsverbindung ist die Anzahl der Sekunden, die CloudFront beim Versuch, eine Verbindung zum Ursprung herzustellen, vergeht.

Die Anzahl der Versuche, eine Verbindung zum Ursprung herzustellen, gibt an, wie oft CloudFront versucht wurde, eine Verbindung zum Ursprung herzustellen.

Zusammen bestimmen diese Einstellungen, wie lange CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen, bevor ein Failover zum sekundären Ursprung erfolgt (im Fall einer Ursprungsgruppe) oder eine Fehlermeldung an den Viewer zurückgegeben wird. CloudFront Wartet standardmäßig bis zu 30 Sekunden (3 Versuche von jeweils 10 Sekunden), bevor versucht wird, eine Verbindung zum sekundären Ursprung herzustellen, oder eine Fehlermeldung zurückgegeben wird. Sie können diese Zeit reduzieren, indem Sie ein kürzeres Verbindungs-Timeout, weniger Versuche oder beides angeben.

Weitere Informationen finden Sie unter Steuern von Timeouts und Verbindungsversuchen für Ursprünge.

Ursprungs-Reaktions-Timeout

Das Ursprungs-Reaktions-Timeout, das auch als Ursprungs-Lese-Timeout oder Ursprungs-Anforderungs-Timeout bezeichnet wird, gilt für Folgendes:

• Die Zeitspanne in Sekunden, die auf eine Antwort CloudFront wartet, nachdem eine Anfrage an den Ursprung weitergeleitet wurde.

• Die Zeitdauer in Sekunden, die nach dem Empfang eines Pakets mit einer Antwort vom Ursprung und vor dem Empfang des nächsten Pakets CloudFront gewartet wird.

CloudFront Das Verhalten hängt von der HTTP-Methode der Viewer-Anfrage ab:

• GETund HEAD Anfragen — Wenn der Absender nicht innerhalb von 30 Sekunden reagiert oder für 30 Sekunden nicht mehr reagiert, wird CloudFront die Verbindung unterbrochen. Wenn die angegebene Anzahl von Ursprungsverbindungsversuchen mehr als 1 ist, versuchen CloudFront Sie erneut, eine vollständige Antwort zu erhalten. CloudFront versucht es bis zu dreimal, abhängig vom Wert der Einstellung für die ursprünglichen Verbindungsversuche. Wenn der Ursprung beim letzten Versuch keine Antwort sendet, unternimmt CloudFront erst dann einen weiteren Versuch, wenn die nächste Anfrage für Inhalte auf demselben Ursprung empfangen wird.

• DELETE, OPTIONS PATCHPUT, und POST Anfragen — Wenn der Absender nicht innerhalb von 30 Sekunden antwortet, wird die Verbindung CloudFront unterbrochen und es wird nicht erneut versucht, den Absender zu kontaktieren. Der Client kann die Anfrage erneut senden, falls erforderlich.

Sie können das Reaktions-Timeout für einen Amazon S3-Ursprung (ein S3-Bucket, der nicht mit statischem Website-Hosting konfiguriert ist) nicht ändern.

Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)

Wenn ein CloudFront Edge-Standort eine Anfrage für ein Objekt erhält und sich das Objekt nicht im Cache befindet oder das zwischengespeicherte Objekt abgelaufen ist, wird die Anfrage CloudFront sofort an den Ursprung gesendet. Wenn jedoch gleichzeitig Anfragen für dasselbe Objekt eingehen — das heißt, wenn zusätzliche Anfragen für dasselbe Objekt (mit demselben Cacheschlüssel) an der Edge-Position ankommen, bevor die Antwort auf die erste Anfrage CloudFront empfangen wird — wird eine CloudFront Pause eingelegt, bevor die zusätzlichen Anfragen an den Ursprung weitergeleitet werden. Diese kurze Pause trägt dazu bei, die Belastung des Ursprungs zu verringern. CloudFront sendet die Antwort von der ursprünglichen Anfrage auf alle Anfragen, die während der Pause eingegangen sind. Dies wird als Request Collapsing (Zusammenfassung von Anfragen) bezeichnet. In CloudFront Protokollen wird die erste Anfrage Miss im x-edge-result-type Feld als a identifiziert, und die reduzierten Anfragen werden als a identifiziert. Hit Weitere Hinweise zu CloudFront Protokollen finden Sie unterCloudFront und Edge-Funktionsprotokollierung.

CloudFront blendet nur Anfragen aus, die einen Cacheschlüssel gemeinsam verwenden. Wenn die zusätzlichen Anfragen nicht denselben Cacheschlüssel verwenden, weil Sie beispielsweise so konfiguriert CloudFront haben, dass das Zwischenspeichern auf der Grundlage von Anforderungsheadern, Cookies oder Abfragezeichenfolgen erfolgt, CloudFront leitet alle Anfragen mit einem eindeutigen Cacheschlüssel an Ihren Ursprung weiter.

Um die Reduzierung von Anforderungen insgesamt zu verhindern, können Sie die verwaltete Cache-Richtlinie CachingDisabled verwenden, die auch das Caching verhindert. Weitere Informationen finden Sie unter Verwenden verwalteter Cache-Richtlinien.

Wenn Sie eine Reduzierung von Anforderungen für bestimmte Objekte verhindern möchten, können Sie die minimale TTL für das Cacheverhalten auf 0 setzen und den Ursprung so konfigurieren, dass Cache-Control: private, Cache-Control: no-store, Cache-Control: no-cache, Cache-Control: max-age=0 oder Cache-Control: s-maxage=0 gesendet wird. Diese Konfigurationen erhöhen die Belastung Ihres Ursprungs und führen zu zusätzlicher Latenz für die gleichzeitigen Anfragen, die unterbrochen werden, während auf die Antwort auf die CloudFront erste Anfrage gewartet wird.

Wie CloudFront verarbeitet Antworten von Ihrem Amazon S3-Ursprung

Erfahren Sie, wie Antworten aus Ihrem Amazon S3-Ursprung CloudFront verarbeitet werden.

Inhalt

• Abgebrochene Anfragen

• HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert werden

• Maximale Dateigröße, die zwischengespeichert werden kann

• Umleitungen

Abgebrochene Anfragen

Wenn sich ein Objekt nicht im Edge-Cache befindet und ein Viewer eine Sitzung beendet (z. B. einen Browser schließt), nachdem CloudFront er das Objekt von Ihrem Ursprung abgerufen hat, aber bevor er das angeforderte Objekt bereitstellen kann, wird das Objekt CloudFront nicht am Edge-Standort zwischengespeichert.

HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert werden

CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antwort von Ihrem Amazon S3-Ursprung an den Viewer weitergeleitet wird:

• X-Amz-Id-2

• X-Amz-Request-Id

• Set-Cookie— Wenn Sie CloudFront die Weiterleitung von Cookies konfigurieren, wird das Set-Cookie Header-Feld an die Clients weitergeleitet. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

• Trailer

• Transfer-Encoding— Wenn Ihr Amazon S3-Ursprung dieses Header-Feld zurückgibt, CloudFront wird der Wert auf gesetzt, chunked bevor die Antwort an den Viewer zurückgegeben wird.

• Upgrade

• Via— CloudFront setzt den Wert in der Antwort an den Zuschauer auf den folgenden Wert:

  Via: http-version alphanumeric-string.cloudfront.net (CloudFront)

  Der Wert ist beispielsweise wie folgt:

  Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

Maximale Dateigröße, die zwischengespeichert werden kann

Die maximale Größe eines Antworttextes, der in seinem Cache CloudFront gespeichert wird, beträgt 50 GB. Dazu gehören auch Antworten für aufgeteilte Übertragungen, in denen kein Wert für die Content-Length-Kopfzeile angegeben wurde.

Sie können ein Objekt zwischenspeichern, das größer als diese Größe ist, indem Sie Bereichsanforderungen verwenden, um die Objekte in Teilen anzufordern, die jeweils 50 GB oder weniger groß sind. CloudFront CloudFrontspeichert diese Teile im Cache, da jeder von ihnen 50 GB oder weniger groß ist. Nachdem der Viewer alle Teile des Objekts abgerufen hat, kann er das ursprüngliche, größere Objekt rekonstruieren. Weitere Informationen finden Sie unter Verwenden von Bereichsanforderungen zum Zwischenspeichern großer Objekte.

Umleitungen

Sie können einen Amazon S3-Bucket so konfigurieren, dass alle Anfragen an einen anderen Host-Namen umgeleitet werden. Dabei kann es sich um einen anderen Amazon S3-Bucket oder um einen HTTP-Server handeln. Wenn Sie einen Bucket so konfigurieren, dass er alle Anfragen umleitet, und wenn der Bucket der Ursprung einer CloudFront Verteilung ist, empfehlen wir, dass Sie den Bucket so konfigurieren, dass alle Anfragen an eine CloudFront Distribution umgeleitet werden, indem Sie entweder den Domainnamen für die Verteilung (z. B. d111111abcdef8.cloudfront.net) oder einen alternativen Domainnamen (ein CNAME) verwenden, der einer Distribution zugeordnet ist (z. B. example.com). Andernfalls werden Viewer-Anfragen umgangen CloudFront und die Objekte werden direkt vom neuen Ursprung aus bedient.

Anmerkung

Wenn Sie Viewer-Anforderungen an einen alternativen Domain-Namen umleiten, müssen Sie auch den DNS-Service für Ihre Domain aktualisieren, indem Sie einen CNAME-Datensatz hinzufügen. Weitere Informationen finden Sie unter Verwenden von benutzerdefinierten URLs durch Hinzufügen von alternativen Domainnamen (CNAMEs).

Wenn Sie einen Bucket so konfigurieren, dass er alle Anfragen umleitet, geschieht Folgendes:

1. Ein Viewer (z. B. ein Browser) fordert ein Objekt von an CloudFront.

2. CloudFront leitet die Anfrage an den Amazon S3-Bucket weiter, der der Ursprung Ihrer Distribution ist.

3. Amazon S3 gibt einen HTTP-Statuscode 301 (dauerhaft verschoben) sowie den neuen Speicherort zurück.

4. CloudFront speichert den Umleitungsstatuscode und den neuen Standort im Cache und gibt die Werte an den Viewer zurück. CloudFront folgt nicht der Weiterleitung, um das Objekt vom neuen Standort abzurufen.

5. Der Viewer sendet eine weitere Anfrage für das Objekt, aber dieses Mal gibt der Viewer den neuen Standort an, von dem es stammt CloudFront:

   • Wenn der Amazon S3-Bucket alle Anfragen an eine CloudFront Distribution umleitet und dabei entweder den Domainnamen für die Verteilung oder einen alternativen Domainnamen verwendet, CloudFront fordert er das Objekt vom Amazon S3-Bucket oder vom HTTP-Server am neuen Standort an. Wenn der neue Standort das Objekt zurückgibt, wird es an den Viewer CloudFront zurückgegeben und an einem Edge-Standort zwischengespeichert.

   • Wenn der Amazon S3-Bucket Anfragen an einen anderen Standort umleitet, wird die zweite Anfrage umgangen. CloudFront Der Amazon S3-Bucket oder der HTTP-Server am neuen Standort gibt das Objekt direkt an den Viewer zurück, sodass das Objekt niemals in einem Edge-Cache zwischengespeichert wird. CloudFront