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.

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 S3-Ursprung weiter

Erfahren Sie, wie Zuschaueranfragen CloudFront verarbeitet und die Anfragen an Ihren Amazon S3 S3-Ursprung weiterleitet.

Dauer und Mindestdauer des Zwischenspeichers TTL

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

Weitere Informationen finden Sie unter Verwalten Sie, wie lange Inhalte im Cache verbleiben (Ablauf).

Client-IP-Adressen

Wenn ein Betrachter eine Anfrage an sendet CloudFront und keinen X-Forwarded-For Anforderungsheader enthält, CloudFront ruft er die IP-Adresse des Betrachters aus 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 er beispielsweise die IP-Adresse 192.0.2.2 von der TCP Verbindung erhält, leitet er den folgenden Header an den Ursprung weiter:

X-Forwarded-For: 192.0.2.2

Wenn ein Betrachter eine Anfrage an sendet CloudFront und einen X-Forwarded-For Anforderungsheader einfügt, CloudFront ruft er die IP-Adresse des Betrachters aus 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 192.0.2.2 aus der TCP Verbindung enthält X-Forwarded-For: 192.0.2.4,192.0.2.3 und diese 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

Bedingte Anfragen GET

Wenn eine Anfrage für ein Objekt CloudFront empfangen wird, das aus einem Edge-Cache abgelaufen ist, leitet es die Anfrage an den Amazon S3-Ursprung weiter, um die neueste Version des Objekts abzurufen oder um 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 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:

Amazon S3 verwendet diese Informationen, um festzustellen, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt CloudFront oder nur der Statuscode HTTP 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 CloudFront , werden die Cookies weitergeleitet, 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.

Quellenübergreifende gemeinsame Nutzung von Ressourcen () CORS

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

GETAnfragen, die einen Hauptteil beinhalten

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

HTTPMethoden

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

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 Antworten auf Anfragen, die die anderen Methoden verwenden, nicht im Cache.

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

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

HTTPAnforderungsheader, die CloudFront entfernt oder aktualisiert werden

CloudFront entfernt oder aktualisiert einige Header, bevor Anfragen an Ihren Amazon S3 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. HTTPAnforderungsheader und CloudFront Verhalten (benutzerdefiniert und Amazon S3 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 konstruiert a URL aus der Anfrage. Die maximale Länge URL beträgt 8192 Byte.

Wenn eine Anfrage oder eine die maximale Länge URL überschreitet, wird der HTTP Statuscode 413 (Request Entity Too Large) an den Viewer CloudFront zurückgegeben und anschließend die TCP Verbindung zum Viewer beendet.

OCSPHeften

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. OCSPStapling beschleunigt die Zertifikatsvalidierung CloudFront , da das Zertifikat validiert und die Antwort von der CA zwischengespeichert werden kann, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.

Die Leistungsverbesserung durch OCSP Heften ist ausgeprägter, wenn CloudFront viele HTTPS Anfragen nach Objekten in derselben Domäne eingehen. Jeder Server an einem CloudFront Edge-Standort muss eine separate Überprüfungsanforderung einreichen. Wenn viele HTTPS Anfragen für dieselbe Domäne eingehen, CloudFront erhält jeder Server am Edge-Standort bald eine Antwort von der CA, die er im SSL Handshake an ein Paket heften kann. Wenn der Betrachter davon überzeugt ist, dass das Zertifikat gültig ist, CloudFront kann er das angeforderte Objekt bereitstellen. Wenn Ihre Distribution an einem CloudFront Edge-Standort nicht viel Traffic erhält, ist es wahrscheinlicher, dass neue Anfragen an einen Server weitergeleitet werden, 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 Überprüfungsanfrage 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 HTTPS Anfragen HTTP oder Anfragen auf der Grundlage des Protokolls der Viewer-Anfrage an den Ursprungsserver weiter, entweder oderHTTP. HTTPS

Abfragezeichenfolgen

Sie können konfigurieren, ob CloudFront Abfragezeichenfolgenparameter an Ihren Amazon S3-Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter Cache-Inhalt auf der Grundlage von Abfragezeichenfolgenparametern.

Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

Das Timeout für die Origin-Verbindung ist die Anzahl der Sekunden, die beim Versuch, eine Verbindung zum CloudFront Ursprung herzustellen, gewartet wird.

Die Anzahl der Versuche, eine Verbindung zum Ursprung herzustellen, gibt an, wie oft CloudFront versucht wird, 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 à 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 Kontrolliere Timeouts und Versuche bei der Herkunft.

Ursprungs-Reaktions-Timeout

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

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

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 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 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 reduzieren. CloudFront sendet die Antwort der ursprünglichen Anfrage auf alle Anfragen, die während der Pause eingegangen sind. Dies wird als Request Collapsing (Zusammenfassung von Anfragen) bezeichnet. In den CloudFront Protokollen wird die erste Anfrage Miss im x-edge-result-type Feld als eine identifiziert, und die ausgeblendeten Anfragen werden als a gekennzeichnet. Hit Weitere Hinweise zu CloudFront Protokollen finden Sie unterCloudFront und Edge-Funktionsprotokollierung.

CloudFront reduziert nur Anfragen, die sich einen Cache-Schlüssel teilen. Wenn die zusätzlichen Anfragen nicht denselben Cache-Schlüssel verwenden, weil Sie beispielsweise so konfiguriert haben, dass der Cache CloudFront auf der Grundlage von Anforderungsheadern, Cookies oder Abfragezeichenfolgen gespeichert wird, werden alle Anfragen mit einem eindeutigen Cache-Schlüssel an Ihren Ursprung CloudFront weitergeleitet.

Wenn Sie verhindern möchten, dass alle Anfragen kollabiert werden, können Sie die verwaltete Cache-Richtlinie verwendenCachingDisabled, die auch das Zwischenspeichern verhindert. Weitere Informationen finden Sie unter Verwaltete Cache-Richtlinien verwenden.

Wenn Sie verhindern möchten, dass Anfragen für bestimmte Objekte reduziert werden, können Sie das Minimum TTL für das Cache-Verhalten auf 0 setzen und den Ursprung so konfigurieren, dass erCache-Control: private,, Cache-Control: no-storeCache-Control: no-cache, Cache-Control: max-age=0 oder sendet. Cache-Control: s-maxage=0 Diese Konfigurationen erhöhen die Belastung Ihres Ursprungs und führen zu zusätzlicher Latenz für gleichzeitige Anfragen, die angehalten werden, während auf die Antwort auf die CloudFront erste Anfrage gewartet wird.

So CloudFront werden Antworten von Ihrem Amazon S3 S3-Absender verarbeitet

Erfahren Sie, wie Antworten von Ihrem Amazon S3 S3-Absender CloudFront verarbeitet werden.

Abgebrochene Anfragen

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

HTTPAntwortheader, die CloudFront entfernt oder aktualisiert werden

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

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 S3-Bucket so konfigurieren, dass alle Anfragen an einen anderen Hostnamen umgeleitet werden. Dabei kann es sich um einen anderen Amazon S3 S3-Bucket oder einen HTTP Server handeln. Wenn Sie einen Bucket so konfigurieren, dass er alle Anfragen umleitet, und wenn der Bucket der Ursprung für eine CloudFront Distribution ist, empfehlen wir, den Bucket so zu konfigurieren, dass er alle Anfragen entweder mit dem Domainnamen für die Distribution (z. B. d111111abcdef8.cloudfront.net) oder einem alternativen Domainnamen (aCNAME), der einer Distribution zugeordnet ist (z. B. example.com), umleitet. CloudFront Andernfalls werden Viewer-Anfragen umgangen CloudFront und die Objekte werden direkt vom neuen Ursprung aus bedient.

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