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

Themen

• So CloudFront verarbeitet HTTP- und HTTPS-Anforderungen
• So CloudFront verarbeitet Anfragen und leitet sie an Ihren Amazon S3-Ursprung weiter
• So CloudFront verarbeitet Antworten von Ihrem Amazon S3-Ursprung

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

Dieses Thema enthält Informationen darüber, wie Betrachteranfragen CloudFront verarbeitet und an Ihren Amazon S3-Ursprung weiterleitet.

Cache-Dauer und Mindest-TTL

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

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

• Geben Sie in CloudFront Cache-Verhaltensweisen einen Wert für Minimum TTL 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 sendet CloudFront und keinen X-Forwarded-For Anfrage-Header enthält, CloudFront ruft die IP-Adresse des Viewers von der TCP-Verbindung ab, fügt einen -X-Forwarded-ForHeader hinzu, der die IP-Adresse enthält, und leitet die Anfrage an den Ursprung weiter. Wenn beispielsweise die IP-Adresse 192.0.2.2 von der TCP-Verbindung CloudFront abruft, wird der folgende Header an den Ursprung weitergeleitet:

X-Forwarded-For: 192.0.2.2

Wenn ein Viewer eine Anforderung an sendet CloudFront und einen X-Forwarded-For Anforderungs-Header enthält, CloudFront ruft 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 Anforderung an den Ursprung weiter. Wenn die Viewer-Anforderung beispielsweise die IP-Adresse enthält X-Forwarded-For: 192.0.2.4,192.0.2.3 und 192.0.2.2 von der TCP-Verbindung CloudFront abruft, wird der folgende Header an den Ursprung weitergeleitet:

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).

Bedingte GET-Anfragen

Wenn eine Anfrage für ein Objekt CloudFront empfängt, das aus einem Edge-Cache abgelaufen ist, leitet es die Anfrage entweder an den Amazon S3-Ursprung weiter, um die neueste Version des Objekts abzurufen oder eine Bestätigung von Amazon S3 zu erhalten, dass der CloudFront Edge-Cache bereits über die neueste Version verfügt. Als Amazon S3 das Objekt ursprünglich an gesendet hat CloudFront, enthielt es einen -ETagWert und einen -LastModifiedWert in der Antwort. In der neuen Anforderung, die an Amazon S3 CloudFront weiterleitet, CloudFront fügt eine oder beide der folgenden Optionen 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 bestimmen, ob das Objekt aktualisiert wurde und ob das gesamte Objekt an CloudFront oder nur ein HTTP-Statuscode 304 (nicht geändert) 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, leitet die Cookies CloudFront 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 Resource Sharing (CORS)

Wenn Sie CloudFront die ursprungsübergreifenden Ressourcenfreigabeeinstellungen von Amazon S3 berücksichtigen möchten, konfigurieren Sie CloudFront so, dass ausgewählte Header an Amazon S3 weitergeleitet werden. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anfrage-Headern.

GET-Anfragen mit Anfragetext

Wenn eine Viewer-GETAnforderung einen Textkörper enthält, CloudFront gibt einen HTTP-Statuscode 403 (Forbidden) an den Viewer zurück.

HTTP-Methoden

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

• DELETE

• GET

• HEAD

• OPTIONS

• PATCH

• POST

• PUT

CloudFront speichert Antworten auf - GET und -HEADAnforderungen immer zwischen. Sie können auch so konfigurieren CloudFront , dass Antworten auf OPTIONS requests. CloudFront does nicht auf Anfragen zwischengespeichert werden, 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 Verteilung eine CloudFront Ursprungszugriffssteuerung (OAC) hinzufügen und der OAC die erforderlichen Berechtigungen erteilen. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf Amazon-S3-Inhalte.

Wichtig

Wenn Sie so konfigurieren CloudFront , dass CloudFront alle von unterstützten HTTP-Methoden akzeptiert und an Amazon S3 weitergeleitet werden, müssen Sie eine CloudFront Ursprungszugriffssteuerung (OAC) erstellen, um den Zugriff auf Ihre Amazon S3-Inhalte einzuschränken und der OAC die erforderlichen Berechtigungen zu erteilen. Wenn Sie beispielsweise CloudFront so konfigurieren, dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie verwenden möchtenPUT, müssen Sie Amazon S3-Bucket-Richtlinien konfigurieren, um -DELETEAnforderungen korrekt zu verarbeiten, damit Viewer keine Ressourcen löschen können, die sie nicht löschen sollen. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf Amazon-S3-Inhalte.

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

HTTP-Anforderungs-Header, die CloudFront entfernt oder aktualisiert

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-Anforderungs-Header und deren CloudFront Verarbeitung finden Sie unter HTTP-Anfrage-Header und - CloudFront Verhalten (benutzerdefinierte 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 20 480 Byte.

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

Wenn eine Anforderung oder eine URL diese Höchstwerte überschreitet, CloudFront gibt den HTTP-Statuscode 413, Request Entity Too Large, an den Viewer zurück und beendet dann die TCP-Verbindung zum Viewer.

OCSP-Stapling

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

Die Leistungssteigerung durch OCSP-Stapling ist deutlicher spürbar, wenn viele HTTPS-Anfragen für Objekte in derselben Domain CloudFront erhält. Jeder Server an einem CloudFront Edge-Standort muss eine separate Validierungsanforderung einreichen. Wenn viele HTTPS-Anfragen für dieselbe Domäne CloudFront erhält, hat jeder Server am Edge-Standort bald eine Antwort von der CA, die er an ein Paket im SSL-Handshake „stapeln“ kann. Wenn der Viewer mit der Gültigkeit des Zertifikats zufrieden ist, CloudFront kann das angeforderte Objekt bereitstellen. Wenn Ihre Verteilung nicht viel Datenverkehr an einem CloudFront Edge-Standort erhält, werden neue Anfragen eher 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 außerdem eine Validierungsanfrage an die CA; wenn er das nächste Mal eine Anfrage mit demselben Domain-Namen erhält, liegt bereits eine Validierungsantwort von der CA vor.

Protokolle

CloudFront leitet HTTP- oder HTTPS-Anfragen an den Ursprungs-Server 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 für die Verwendung von HTTPS für die Kommunikation mit Ihrem Ursprung konfigurieren CloudFront, da Amazon S3 keine HTTPS-Verbindungen in dieser Konfiguration unterstützt.

Abfragezeichenfolgen

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

Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

Ursprungsverbindungs-Timeout ist die Anzahl der Sekunden, die CloudFront wartet, wenn versucht wird, eine Verbindung zum Ursprung herzustellen.

Verbindungsversuche zum Ursprung gibt an, wie oft CloudFront versucht, eine Verbindung zum Ursprung herzustellen.

Zusammen bestimmen diese Einstellungen, wie lange CloudFront versucht, eine Verbindung zum Ursprung herzustellen, bevor ein Failover zum sekundären Ursprung (im Falle einer Ursprungsgruppe) oder eine Fehlerantwort an den Betrachter zurückgegeben wird. Standardmäßig CloudFront wartet bis zu 30 Sekunden (3 Versuche von jeweils 10 Sekunden), bevor versucht wird, eine Verbindung zum sekundären Ursprung herzustellen oder eine Fehlerantwort zurückzugeben. 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 Ursprungs-Timeouts und -Versuchen.

Ursprungs-Reaktions-Timeout

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

• Die Zeit in Sekunden, die nach der Weiterleitung einer Anfrage an den Ursprung auf eine Antwort CloudFront wartet.

• Die Zeit in Sekunden, die nach dem Empfang eines Antwortpakets vom Ursprung und vor dem Empfang des nächsten Pakets CloudFront wartet.

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

• GET - und -HEADAnfragen – Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert oder 30 Sekunden lang nicht mehr reagiert, CloudFront verwirft die Verbindung. Wenn die angegebene Anzahl von Verbindungsversuchen zum Ursprung mehr als 1 beträgt, CloudFront versucht erneut, eine vollständige Antwort zu erhalten. CloudFront versucht es bis zu 3 Mal, wie durch den Wert der Einstellung für Verbindungsversuche zum Ursprung bestimmt. Wenn der Ursprung beim letzten Versuch nicht reagiert, CloudFront versucht es erst erneut, wenn eine weitere Anfrage für Inhalte auf demselben Ursprung empfangen wird.

• DELETE-, -OPTIONS, -PUT, PATCH- und -POSTAnforderungen – Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert, CloudFront löscht die Verbindung und versucht nicht, den Ursprung erneut 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, sendet die Anfrage CloudFront sofort an den Ursprung. Wenn es jedoch gleichzeitige Anfragen für dasselbe Objekt gibt – d. h. wenn zusätzliche Anfragen für dasselbe Objekt (mit demselben Cache-Schlüssel) am Edge-Standort ankommen, bevor die Antwort auf die erste Anfrage CloudFront erhält – CloudFront pausiert, bevor die zusätzlichen Anfragen an den Ursprung weitergeleitet werden. Diese kurze Pause trägt dazu bei, die Belastung des Ursprungs zu reduzieren. CloudFront sendet die Antwort auf die ursprüngliche Anfrage an alle Anfragen, die es während der Pause erhalten hat. Dies wird als Request Collapsing (Zusammenfassung von Anfragen) bezeichnet. In - CloudFront Protokollen wird die erste Anforderung als Miss im -x-edge-result-typeFeld und die zusammengefassten Anforderungen als identifiziertHit. Weitere Informationen zu CloudFront Protokollen finden Sie unter CloudFront und Edge-Funktionsprotokollierung.

CloudFront reduziert nur Anforderungen, die einen Cache-Schlüssel gemeinsam nutzen. Wenn die zusätzlichen Anforderungen nicht denselben Cache-Schlüssel haben, da Sie beispielsweise so konfiguriert haben, CloudFront dass die Zwischenspeicherung auf der Grundlage von Anforderungsheadern oder Cookies oder Abfragezeichenfolgen erfolgt, CloudFront leitet alle Anforderungen mit einem eindeutigen Cache-Schlüssel an Ihren Ursprung weiter.

Wenn Sie verhindern möchten, dass alle Anfragen reduziert werden, können Sie die verwaltete Cache-Richtlinie verwendenCachingDisabled, wodurch auch das Caching verhindert wird. Weitere Informationen finden Sie unter Verwenden der verwalteten Cache-Richtlinien.

Wenn Sie eine Reduzierung von Anforderungen für bestimmte Objekte verhindern möchten, können Sie die minimale TTL für das Cache-Verhalten 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 sorgen für zusätzliche Latenz bei gleichzeitigen Anforderungen, die angehalten werden, während auf die Antwort auf die erste Anforderung CloudFront wartet.

So CloudFront verarbeitet Antworten von Ihrem Amazon S3-Ursprung

Dieses Thema enthält Informationen darüber, wie Antworten von Ihrem Amazon S3-Ursprung CloudFront verarbeitet.

Themen

• Abgebrochene Anfragen
• HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert
• 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 das Objekt von Ihrem Ursprungs-Server CloudFront erhalten hat, aber bevor es das CloudFront angeforderte Objekt bereitstellen kann, speichert das Objekt nicht am Edge-Standort.

HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert

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 so konfigurieren, dass Cookies weitergeleitet werden, wird das Set-Cookie Header-Feld an 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 setzt den Wert auf , chunked bevor die Antwort an den Viewer zurückgegeben wird.

• Upgrade

• Via – CloudFront setzt den Wert in der Antwort an den Viewer auf Folgendes:

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

  Beispiel: Wenn der Client eine Anfrage über HTTP/1.1 stellt, sieht der Wert in etwa wie folgt aus:

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

Maximale Dateigröße, die zwischengespeichert werden kann

Die maximale Größe eines Antworttexts, der in seinem Cache CloudFront speichert, 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 verwenden, CloudFront um ein Objekt zwischenzuspeichern, das größer als diese Größe ist, indem Sie Bereichsanforderungen verwenden, um die Objekte in Teilen anzufordern, die jeweils 50 GB oder kleiner sind. CloudFront speichert diese Teile zwischen, da jeder von ihnen 50 GB oder kleiner 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 alle Anforderungen umgeleitet werden, und der Bucket der Ursprung für eine CloudFront Verteilung ist, empfehlen wir, den Bucket so zu konfigurieren, dass alle Anforderungen an eine CloudFront Verteilung entweder über den Domänennamen für die Verteilung (z. B. d111111abcdef8.cloudfront.net) oder einen alternativen Domänennamen (einen CNAME), der einer Verteilung zugeordnet ist (z. B. example.com). Andernfalls umgehen Betrachteranfragen und CloudFrontdie Objekte werden direkt vom neuen Ursprung bereitgestellt.

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 alternativne Domänennamen (CNAMEs).

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

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

2. CloudFront leitet die Anforderung an den Amazon S3-Bucket weiter, der der Ursprung für Ihre Verteilung 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 Speicherort im Cache und gibt die Werte an den Viewer zurück. CloudFront folgt nicht der Umleitung, um das Objekt vom neuen Speicherort abzurufen.

5. Der Viewer sendet eine weitere Anfrage für das Objekt, aber dieses Mal gibt der Viewer den neuen Speicherort an, den er von erhalten hat CloudFront:

   • Wenn der Amazon S3-Bucket alle Anforderungen an eine CloudFront Verteilung umleitet, indem entweder der Domänenname für die Verteilung oder ein alternativer Domänenname verwendet wird, CloudFront fordert das Objekt aus dem Amazon S3-Bucket oder dem HTTP-Server am neuen Speicherort an. Wenn der neue Speicherort das Objekt zurückgibt, CloudFront gibt es an den Viewer zurück und speichert es an einem Edge-Standort zwischen.

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