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

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

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

Dieses Thema enthält Informationen darüber, wie CloudFront Viewer-Anforderungen 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 CloudFront die nächste Anfrage an Ihren Ursprung weiterleitet, können Sie:

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

  • Beim CloudFront-Cache-Verhalten einen Wert für die Mindest-TTL angeben

  • 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 CloudFront sendet, die keinen X-Forwarded-For-Anfrage-Header enthält, ruft CloudFront die IP-Adresse des Viewers von der TCP-Verbindung ab, fügt einen X-Forwarded-For-Header inklusive IP-Adresse hinzu und leitet die Anfrage an den Ursprungs-Server 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 CloudFront sendet, die einen X-Forwarded-For-Anfrage-Header enthält, ruft CloudFront die IP-Adresse des Viewers von der TCP-Verbindung ab, hängt diese an den X-Forwarded-For-Header (am Ende) an und leitet die Anfrage an den Ursprungs-Server weiter. Wenn die Viewer-Anforderung z. B. den Eintrag X-Forwarded-For: 192.0.2.4,192.0.2.3 enthält und CloudFront 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.4,192.0.2.3,192.0.2.2

Anmerkung

Der X-Forwarded-For-Header kann IPv4-Adressen (z. B. 192.0.2.44) oder IPv6-Adressen (z. B. 2001:0db8:85a3:0000:0000:8a2e:0370:7334) enthalten.

Bedingte GET-Anfragen

Wenn CloudFront eine Anfrage für ein Objekt erhält, das in einem Edge-Cache abgelaufen ist, wird die Anfrage an den Amazon S3-Ursprungs-Server weitergeleitet, um die neueste Version des Objekts oder eine Bestätigung von Amazon S3 zu erhalten, dass im CloudFront-Edge-Cache bereits die aktuelle Version enthalten ist. Wenn Amazon S3 ein Objekt an CloudFront sendet, ist immer ein ETag- und ein LastModified-Wert in der Antwort enthalten. In der neuen Anfrage, die CloudFront an Amazon S3 weiterleitet, fügt CloudFront 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 ermitteln, ob das Objekt aktualisiert wurde bzw. ob das gesamte Objekt oder nur ein HTTP-Statuscode 304 (nicht geändert) an CloudFront zurückgegeben werden muss.

Cookies

Amazon S3 verarbeitet keine Cookies. Wenn Sie ein Cache-Verhalten so konfigurieren, dass Cookies an einen Amazon S3-Ursprung weitergeleitet werden, leitet CloudFront 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 Resource Sharing (CORS)

Wenn Sie möchten, dass CloudFront die Einstellungen für die übergreifende Ressourcenfreigabe von Amazon S3 berücksichtigt, 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 GET-Viewer-Anforderung einen Anfragetext enthält, gibt CloudFront einen HTTP-Statuscode 403 (Unzulässig) an den Viewer zurück.

HTTP-Methoden

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

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront speichert Antworten auf GET- und HEAD-Anfragen immer im Cache. Sie können CloudFront auch so konfigurieren, dass Antworten auf OPTIONS-Anfragen ebenfalls im Cache gespeichert werden. CloudFront speichert keine Antworten auf Anfragen im Cache, in denen die anderen Methoden verwendet werden.

Wenn Sie einen Amazon S3-Bucket als Ursprung für Ihre Verteilung und CloudFront-Ursprungszugriffsidentitäten verwenden, werden POST-Anforderungen in einigen Amazon S3-Regionen nicht unterstützt. PUT-Anforderungen in diesen Regionen erfordern einen zusätzlichen Header. Weitere Informationen finden Sie unter Verwenden einer OAI in Amazon-S3-Regionen, die nur die Authentifizierung von Signaturen der Version 4 unterstützen.

Wenn Sie mehrteilige Uploads zum Hinzufügen von Objekten in einen Amazon S3-Bucket verwenden, müssen Sie Ihrer Verteilung eine CloudFront-Ursprungszugriffsidentität hinzufügen und dieser Ursprungszugriffsidentität die benötigten Berechtigungen erteilen. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf Amazon-S3-Inhalte durch Verwenden einer Ursprungszugriffsidentität.

Wichtig

Wenn Sie CloudFront so konfigurieren, dass alle von CloudFront unterstützten HTTP-Methoden akzeptiert und an Amazon S3 weitergeleitet werden, müssen Sie eine CloudFront-Ursprungszugriffsidentität erstellen, um den Zugriff auf Ihre Amazon S3-Inhalte zu beschränken und der Ursprungszugriffsidentität die erforderlichen Berechtigungen zu erteilen. Wenn Sie CloudFront beispielsweise so konfigurieren, dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie die PUT-Methode verwenden möchten, müssen Sie Amazon S3-Bucket-Richtlinien oder ACLs so konfigurieren, dass DELETE-Anfragen korrekt verarbeitet werden, 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 durch Verwenden einer Ursprungszugriffsidentität.

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-Anfrage-Header und Informationen dazu, wie CloudFront diese verarbeitet, 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 auf Basis der Anfrage. Die maximale Länge dieser URL beträgt 8 192 Byte.

Wenn eine Anfrage oder eine URL diese Höchstwerte überschreitet, gibt CloudFront einen HTTP-Statuscode 413 (Request Entity Too Large) an den Viewer zurück. Anschließend wird die TCP-Verbindung mit dem Viewer getrennt.

OCSP-Stapling

Wenn ein Viewer eine HTTPS-Anfrage für ein Objekt sendet, muss entweder CloudFront oder der Viewer bei der Zertifizierungsstelle (Certificate Authority, CA) sicherstellen, dass das SSL-Zertifikat für die Domäne nicht gesperrt wurde. OCSP-Stapling beschleunigt die Validierung des Zertifikats, indem CloudFront gestattet wird, das Zertifikat zu überprüfen und die Antwort von der CA im Cache zu speichern, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.

Die Leistungssteigerung durch OCSP-Stapling ist deutlicher spürbar, wenn CloudFront viele HTTPS-Anfragen für Objekte in derselben Domäne erhält. Jeder Server an einem CloudFront-Edge-Standort muss eine separate Validierungsanfrage senden. Wenn CloudFront viele HTTPS-Anfragen für dieselbe Domäne erhält, hat jeder Server am Edge-Standort nach kurzer Zeit hat eine Antwort von der CA vorliegen, die er an ein Paket im SSL-Handshake anhängen kann. Wenn der Viewer von der Gültigkeit des Zertifikats überzeugt ist, kann CloudFront das angeforderte Objekt übertragen. 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 selbst aus und der CloudFront-Server überträgt das Objekt. Dieser CloudFront-Server sendet außerdem eine Validierungsanfrage an die CA. Wenn er das nächste Mal eine Anfrage mit demselben Domänennamen erhält, liegt bereits eine Validierungsantwort von der CA vor.

Protocols

CloudFront leitet HTTP- oder HTTPS-Anforderungen basierend auf dem Protokoll der Anforderung (HTTP oder HTTPS) an den Ursprungs-Server weiter.

Wichtig

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

Abfragezeichenfolgen

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

Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

Timeout der Ursprungsverbindung ist die Anzahl der Sekunden, die CloudFront bei dem Versuch wartet, eine Verbindung zum Ursprung herzustellen.

Verbindungsversuche zum Ursprung gibt die Anzahl der Versuche von CloudFront an, eine Verbindung mit dem Ursprung herzustellen.

Zusammen legen diese Einstellungen fest, wie lange CloudFront versucht, eine Verbindung mit dem Ursprung herzustellen, bevor ein Failover zum sekundären Ursprung (im Fall einer Ursprungsgruppe) oder eine Fehlerantwort 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 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 CloudFront nach der Weiterleitung einer Anforderung an den Ursprungs-Server auf eine Antwort wartet

  • Die Zeit (in Sekunden), die CloudFront nach dem Erhalt eines Antwortpakets vom Ursprungs-Server und vor dem Empfang des nächsten Pakets wartet

Das CloudFront-Verhalten ist von der HTTP-Methode der Viewer-Anforderung abhängig:

  • GET- und HEAD-Anfragen: Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert oder 30 Sekunden lang nicht mehr reagiert, verwirft CloudFront die Verbindung. Wenn die angegebene Anzahl von Verbindungsversuchen zum Ursprung mehr als 1 beträgt, versucht CloudFront erneut, eine vollständige Antwort zu erhalten. CloudFront versucht dies bis zu 3 Mal, wie in der Einstellung der Verbindungsversuche zum Ursprung festgelegt. 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-, PATCH-, PUT- und POST-Anfragen: Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert, verwirft CloudFront 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 (Datenverkehrsspitzen)

Wenn ein CloudFront-Edge-Standort eine Anfrage für ein Objekt erhält und sich das Objekt zu dem Zeitpunkt entweder nicht im Cache befindet oder bereits abgelaufen ist, sendet CloudFront die Anfrage sofort an Ihren Amazon S3-Ursprungs-Server. Wenn eine Datenverkehrsspitze vorliegt – also wenn weitere Anfragen für dasselbe Objekt an dem Edge-Standort ankommen, bevor Amazon S3 auf die erste Anfrage geantwortet hat – legt CloudFront eine kurze Pause ein, bevor die weiteren Anfragen für das Objekt an Ihren Ursprungs-Server weitergeleitet werden. In der Regel erreicht die Antwort auf die erste Anfrage den CloudFront-Edge-Standort vor den Antworten auf die nachfolgenden Anfragen. Diese kurze Pause trägt dazu bei, unnötige Arbeitslasten in Amazon S3 zu vermeiden. Wenn die weiteren Anfragen nicht identisch sind, da Sie CloudFront z. B. so konfiguriert haben, dass Objekte auf Basis der Anfrage-Header oder Abfragezeichenfolgen im Cache gespeichert werden, leitet CloudFront alle abweichenden Anfragen an Ihren Ursprungs-Server weiter.

Wenn die Antwort vom Ursprungs-Server einen Cache-Control: no-cache-Header enthält, leitet CloudFront die nächste Anfrage für dasselbe Objekt in der Regel an den Ursprungs-Server weiter, um zu ermitteln, ob das Objekt aktualisiert wurde. Wenn jedoch eine Datenverkehrsspitze vorliegt und CloudFront nach der Weiterleitung der ersten Anfrage eine Pause eingelegt hat, kann es sein, dass mehrere Viewer-Anforderung empfangen werden, bevor CloudFront eine Antwort vom Ursprungs-Server erhalten hat. Wenn CloudFront eine Antwort mit einem Cache-Control: no-cache-Header erhält, wird das Objekt in der Antwort an den Viewer gesendet, von dem die ursprüngliche Anfrage stammt, sowie an alle Viewer, die das Objekt während der Pause angefordert haben. Nachdem die Antwort vom Ursprungs-Server eingetroffen ist, leitet CloudFront die nächste Viewer-Anforderung für dasselbe Objekt an den Ursprungs-Server weiter. In den CloudFront-Zugriffsprotokollen wird die erste Anfrage in der Spalte Miss als x-edge-result-type aufgeführt. Alle nachfolgenden Anfragen, die CloudFront während der Pause empfangen hat, werden als Hit gelistet. Weitere Informationen zu dem Dateiformat in Zugriffsprotokollen finden Sie unter Felder der Standardprotokolldatei.

So verarbeitet CloudFront Antworten von Ihrem Amazon-S3-Ursprung

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

Abgebrochene Anfragen

Wenn sich ein Objekt nicht im Edge-Cache befindet und der Viewer die Sitzung beendet (z. B. den Browser schließt), nachdem das Objekt von Ihrem Ursprungs-Server an CloudFront gesendet wurde, aber noch bevor CloudFront das angeforderte Objekt übertragen konnte, wird das Objekt an dem jeweiligen Edge-Standort nicht im Cache gespeichert.

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

CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antworten von Ihrem Amazon S3-Ursprungs-Server an den Viewer weitergeleitet werden:

  • Set-Cookie: Wenn Sie CloudFront so konfigurieren, dass Cookies weitergeleitet werden, wird das Set-Cookie-Header-Feld an den Client weitergeleitet. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

  • Trailer

  • Transfer-Encoding: Wenn Ihr Amazon S3-Ursprungs-Server dieses Header-Feld zurückgibt, setzt CloudFront den Wert auf chunked, bevor die Antwort an den Viewer weitergeleitet wird.

  • Upgrade

  • Via:CloudFront legt bei der Antwort an den Viewer den Wert wie folgt fest:

    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 maximale Größe des Antworttext, den CloudFront im Cache speichert, beträgt 30 GB. Dazu gehören auch Antworten für aufgeteilte Übertragungen, in denen kein Wert für den Content-Length-Header angegeben wurde.

Wenn das Caching deaktiviert ist, kann CloudFront ein Objekt, das größer als 30 GB ist, vom Ursprung abrufen und an den Viewer weitergeben. Das Objekt wird jedoch von CloudFront nicht zwischengespeichert.

Sie können CloudFront verwenden, um ein Objekt zwischenzuspeichern, das größer als 30 GB ist, indem Sie Bereichsanforderungen verwenden, um die Objekte in Teilen anzufordern, die jeweils 30 GB oder kleiner sind. Diese Teile werden von CloudFront zwischengespeichert, da sie jeweils 30 GB oder kleiner sind. 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.

Redirects

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 der Bucket gleichzeitig Ursprungs-Server für eine CloudFront-Verteilung ist, empfehlen wir, dass Sie den Bucket so konfigurieren, dass alle Anfragen an eine CloudFront-Verteilung umgeleitet werden. Dabei soll für die Verteilung entweder der Domänenname (z. B. d111111abcdef8.cloudfront.net) verwendet werden, oder ein alternativer, der Verteilung zugeordneter Domänenname (CNAME)(z. B. example.com). Andernfalls umgehen die Viewer-Anforderungen CloudFront und die Objekte werden direkt vom neuen Ursprungs-Server 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 Viewer (z. B. ein Browser) fordert ein Objekt von CloudFront an.

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

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

    • Wenn der Amazon S3-Bucket alle Anfragen an eine CloudFront-Verteilung umleitet, und zwar entweder über den Domänennamen für die neue Verteilung oder über einen alternativen Domänennamen, dann fordert CloudFront das Objekt vom Amazon S3-Bucket oder HTTP-Server am neuen Speicherort an. Wenn der neue Speicherort das Objekt zurückgibt, leitet CloudFront das Objekt an den Viewer weiter und speichert es im Cache eines Edge-Standorts.

    • Wenn der Amazon S3-Bucket Anfragen an einen anderen Standort umleitet, umgeht die zweite Anfrage CloudFront. Der Amazon S3-Bucket oder HTTP-Server am neuen Speicherort gibt das Objekt direkt an den Viewer zurück, ohne dass es in einem CloudFront-Edge-Cache gespeichert wird.