Verhalten von Anfragen und Antworten für Amazon-S3-Ursprünge - Amazon CloudFront
Wie CloudFront verarbeitet und leitet Anfragen an Ihren Amazon S3 S3-Ursprung weiterSo CloudFront werden Antworten von Ihrem Amazon S3 S3-Absender verarbeitet

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.

Cache-Dauer und Mindest-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:

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

  • Geben Sie einen Wert für Minimale TTL in CloudFront Cache-Verhalten an.

  • Den Standardwert von 24 Stunden verwenden

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

Client-IP-Adressen

Wenn ein Viewer eine Anfrage an sendet CloudFront und keinen 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. X-Forwarded-For 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 Betrachter eine Anfrage an den Anforderungsheader sendet CloudFront und diesen einschließt, CloudFront ruft er die IP-Adresse des Viewers 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. X-Forwarded-For 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 diese CloudFront 192.0.2.2 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 (wie 192.0.2.44) und IPv6 Adressen (wie 2001:0 db 8:85 a3: :8a2e: 0370:7334).

Bedingte GET-Anfragen

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:

  • 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 festzustellen, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt an CloudFront oder nur ein HTTP-304-Statuscode (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.

Cross-Origin Resource Sharing (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.

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 so konfigurieren CloudFront , dass alle HTTP-Methoden verarbeitet werden, die es unterstützt, CloudFront akzeptiert es die folgenden Anfragen von Zuschauern und leitet sie an Ihren Amazon S3 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 S3-Bucket hinzuzufügen, müssen Sie Ihrer Distribution eine CloudFront Origin-Zugriffskontrolle (OAC) hinzufügen und dem OAC die erforderlichen Berechtigungen erteilen. Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf einen Amazon Simple Storage Service-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 S3-Inhalte einzuschränken und dem OAC die erforderlichen Berechtigungen zu 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 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 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.

HTTP-Anforderungsheader, 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. Header und CloudFront Verhalten von HTTP-Anfragen (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 aus der Anfrage eine URL. Die maximale Länge dieser URL beträgt 8 192 Byte.

Wenn eine Anfrage oder eine URL die maximale Länge überschreitet, CloudFront gibt es 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 Betrachter eine HTTPS-Anfrage für ein Objekt sendet 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, da CloudFront 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 von OCSP-Stapling ist ausgeprägter, wenn CloudFront viele HTTPS-Anfragen für Objekte in derselben Domäne 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 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 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 Betrachter 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 HTTP- oder HTTPS-Anfragen auf der Grundlage des Protokolls der Viewer-Anfrage, entweder HTTP oder HTTPS, an den Ursprungsserver weiter.

Wichtig

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

Abfragezeichenfolgen

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

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:

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

  • Die Zeitspanne in Sekunden, die nach dem Empfang eines Antwortpakets 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 Ursprung nicht innerhalb von 30 Sekunden reagiert oder 30 Sekunden lang nicht mehr reagiert, wird CloudFront die Verbindung unterbrochen. Wenn die angegebene Anzahl der ursprünglichen Verbindungsversuche mehr als 1 beträgt, wird erneut CloudFront versucht, eine vollständige Antwort zu erhalten. CloudFront versucht bis zu 3 Mal, je nach dem Wert der Einstellung für ursprüngliche 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 CloudFront Verbindung unterbrochen und es wird nicht erneut versucht, den Ursprung 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 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 die Mindest-TTL für das Cache-Verhalten auf 0 setzen und den Ursprung so konfigurieren, dass erCache-Control: private,,Cache-Control: no-store, Cache-Control: no-cache oder sendet. Cache-Control: max-age=0 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.

Wichtig

Unterstützt derzeit CloudFront nicht das Zusammenklappen von Anfragen, wenn Sie die Cookie-Weiterleitung in der Cache-Richtlinie, der ursprünglichen Anforderungsrichtlinie oder den Legacy-Cache-Einstellungen aktivieren.

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.

HTTP-Antwort-Header, 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:

  • 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 Clients weitergeleitet. Weitere Informationen finden Sie unter Auf Cookies basierender Inhalt zwischenspeichern.

  • Trailer

  • Transfer-Encoding— Wenn Ihr Amazon S3 S3-Ursprung dieses Header-Feld zurückgibt, CloudFront setzt er den Wert auf, chunked bevor die Antwort an den Betrachter zurückgesendet 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 in etwa 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 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 (einem CNAME), 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.

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 Sie Benutzerdefiniert, URLs indem Sie alternative Domainnamen hinzufügen () 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 Anfrage an den Amazon S3 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 Betrachter zurück. CloudFront folgt nicht der Weiterleitung, um das Objekt vom neuen Standort abzurufen.

  5. Der Betrachter sendet eine weitere Anfrage für das Objekt, aber diesmal gibt der Betrachter den neuen Speicherort an, von dem es abgerufen wurde CloudFront:

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

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