Verhalten von Anfragen und Antworten für benutzerdefinierte Ursprungsserver - Amazon CloudFront

Verhalten von Anfragen und Antworten für benutzerdefinierte Ursprungsserver

So verarbeitet CloudFront Anfragen und leitet sie an Ihren benutzerdefinierten Ursprung weiter

Dieses Thema enthält Informationen darüber, wie CloudFront Viewer-Anforderungen verarbeitet und an Ihren benutzerdefinierten Ursprung weiterleitet.

Authentication

Wenn Sie CloudFront für DELETE-, GET-, HEAD-, PATCH-, POST- und PUT-Anforderungen so konfigurieren, dass der Authorization-Header an Ihren Ursprung weitergeleitet wird, können Sie Ihren Ursprungsserver so konfigurieren, dass eine Client-Authentifizierung angefordert wird.

Für OPTIONS-Anfragen können Sie Ihren Ursprungs-Server so konfigurieren, dass eine Client-Authentifizierung nur dann angefordert wird, wenn Sie die folgenden CloudFront-Einstellungen verwenden:

Sie können CloudFront so konfigurieren, dass Anfragen an Ihren Ursprungs-Server entweder über HTTP oder über HTTPS weitergeleitet werden. Weitere Informationen finden Sie unter Verwenden von HTTPS mit CloudFront.

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

Manche Anwendungen wie Load Balancer (einschließlich Elastic Load Balancing), Firewalls für Webanwendungen, Reverse Proxys, Intrusion-Prevention-Systeme und API-Gateways hängen die IP-Adresse des CloudFront-Edge-Servers, der die Anfrage weitergeleitet hat, an den X-Forwarded-For-Header (am Ende) an. Wenn CloudFront z. B. X-Forwarded-For: 192.0.2.2 in einer Anfrage an ELB weiterleitet und die IP-Adresse des CloudFront-Edge-Servers 192.0.2.199 lautet, enthält die Anfrage, die Ihre EC2-Instance empfängt, den folgenden Header:

X-Forwarded-For: 192.0.2.2,192.0.2.199

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.

Clientseitige SSL-Authentifizierung

CloudFront unterstützt keine Client-Authentifizierung mit SSL-Zertifikaten auf Client-Seite. Wenn ein Ursprungs-Server ein clientseitiges Zertifikat anfordert, verwirft CloudFront die Anfrage.

Compression

Weitere Informationen finden Sie unter Bereitstellen von komprimierten Dateien.

Bedingte Anforderungen

Wenn CloudFront eine Anfrage für ein Objekt erhält, das in einem Edge-Cache abgelaufen ist, wird die Anfrage an den Ursprungs-Server weitergeleitet, um die neueste Version des Objekts oder eine Bestätigung vom Ursprungs-Server zu erhalten, dass im CloudFront-Edge-Cache bereits die aktuelle Version enthalten ist. Als der Ursprungs-Server das Objekt das letzte Mal an CloudFront gesendet hatte, waren in der Regel ein ETag-Wert, ein LastModified-Wert oder beide Werte in der Antwort enthalten. In der neuen Anfrage, die CloudFront an den Ursprung weiterleitet, fügt CloudFront mindestens einen der folgenden Einträge 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

Der Ursprungs-Server 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

Sie können CloudFront so konfigurieren, dass Cookies an Ihren Ursprungs-Server weitergeleitet werden. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

Cross-Origin Resource Sharing (CORS)

Wenn Sie möchten, dass CloudFront die Einstellungen zur ursprungsübergreifenden gemeinsamen Nutzung von Ressourcen berücksichtigt, konfigurieren Sie CloudFront so, dass der Origin-Header an Ihren Ursprungs-Server weitergeleitet wird. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anfrage-Headern.

Encryption

Sie können festlegen, dass Viewer Anfragen an CloudFront nur über HTTPS senden können und dass CloudFront Anfragen an Ihren benutzerdefinierten Ursprungs-Server nur über das Protokoll weiterleiten kann, das vom jeweiligen Viewer verwendet wurde. Weitere Informationen finden Sie in den folgenden Verteilungseinstellungen:

CloudFront leitet HTTPS-Anfragen an den Ursprungs-Server über die Protokolle SSLv3, TLSv1.0, TLSv1.1 und TLSv1.2 weiter. Für benutzerdefinierte Ursprünge können Sie die SSL-Protokolle festlegen, die CloudFront bei der Kommunikation mit Ihrem Ursprungs-Server verwenden soll:

  • Wenn Sie die CloudFront-Konsole verwenden, wählen Sie die Protokolle über die Kontrollkästchen zu Origin SSL Protocols aus. Weitere Informationen finden Sie unter Erstellen einer Verteilung.

  • Wenn Sie die CloudFront-API verwenden, geben Sie die Protokolle mithilfe des OriginSslProtocols-Elements an. Weitere Informationen finden Sie unter OriginSsLProtocols und DistributionConfig in der Amazon CloudFront-API-Referenz.

Wenn der Ursprung ein Amazon S3-Bucket ist, verwendet CloudFront immer TLSv1.2.

Wichtig

Andere Versionen von SSL und TLS werden nicht unterstützt.

Weitere Informationen zum Verwenden von HTTPS mit CloudFront finden Sie unter Verwenden von HTTPS mit CloudFront. Listen der Verschlüsselungen, die CloudFront für die HTTPS-Kommunikation zwischen Viewern und CloudFront sowie zwischen CloudFront und Ihrem Ursprung unterstützt, finden Sie unter Unterstützte Protokolle und Verschlüsselungen zwischen Betrachtern und CloudFront.

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

Informationen zur Konfiguration Ihres benutzerdefinierten Ursprungsservers für die Verarbeitung dieser Methoden finden Sie in der Dokumentation zu Ihrem Ursprungsserver.

Wichtig

Wenn Sie CloudFront so konfigurieren, dass alle von CloudFront unterstützten HTTP-Methoden akzeptiert und an Ihren Ursprungs-Server weitergeleitet werden, dann konfigurieren Sie auch Ihren Ursprungs-Server so, dass alle Methoden verarbeitet werden. Wenn Sie CloudFront beispielsweise so konfigurieren, dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie die POST-Methode verwenden möchten, müssen Sie Ihren Ursprungs-Server 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 in der Dokumentation zu Ihrem HTTP-Server.

HTTP-Anfrage-Header und CloudFront-Verhalten (benutzerdefinierte und Amazon-S3-Ursprünge)

In der folgenden Tabelle sind HTTP-Anfrage-Header aufgelistet, die Sie sowohl an benutzerdefinierte als auch Amazon S3-Ursprünge weiterleiten können (mit Ausnahmen, auf die hingewiesen wird). Für jeden Header umfasst die Tabelle Informationen über Folgendes:

  • Das CloudFront-Verhalten, wenn Sie CloudFront nicht so konfigurieren, dass der Header an Ihren Ursprungs-Server weitergeleitet wird. Auf diese Weise werden Ihre Objekte von CloudFront basierend auf den Header-Werten im Cache gespeichert.

  • Ob Sie CloudFront so konfigurieren können, dass Objekte basierend auf den Header-Werten für diesen Header im Cache gespeichert werden

    Sie können CloudFront so konfigurieren, dass Objekte basierend auf den Werten in den Headern Date und User-Agent zwischengespeichert werden. Dies wird jedoch nicht empfohlen. Diese Header können eine Vielzahl möglicher Werte enthalten. Das Zwischenspeichern basierend auf diesen Werten würde dazu führen, dass wesentlich mehr Anfragen von CloudFront an Ihren Ursprung weitergeleitet werden.

Weitere Informationen zum Zwischenspeichern auf Basis von Header-Werten finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anfrage-Headern.

Header Das Verhalten, wenn Sie CloudFront nicht so konfigurieren, dass basierend auf Header-Werten zwischengespeichert wird Das Zwischenspeichern auf Basis von Header-Werten wird unterstützt

Anderweitig definierte Header

CloudFront leitet die Header an Ihren Ursprungsserver weiter.

Ja

Accept

CloudFront entfernt den Header.

Ja

Accept-Charset

CloudFront entfernt den Header.

Ja

Accept-Encoding

Wenn der Wert gzip oder br enthält, leitet CloudFront einen normalisierten Accept-Encoding-Header an Ihren Ursprung weiter.

Weitere Informationen erhalten Sie unter Komprimierungsunterstützung und Bereitstellen von komprimierten Dateien.

Ja

Accept-Language

CloudFront entfernt den Header.

Ja

Authorization

  • GET- und HEAD-Anfragen: CloudFront entfernt das Authorization-Header-Feld, bevor die Anfrage an Ihren Ursprungs-Server weitergeleitet wird.

  • OPTIONS-Anfragen: Wenn Sie CloudFront so konfigurieren, dass Antworten auf Authorization-Anfragen im Cache gespeichert werden, entfernt CloudFront das OPTIONS-Header-Feld, bevor die Anfrage an Ihren Ursprungs-Server weitergeleitet wird.

    CloudFront leitet das Authorization-Header-Feld an Ihren Ursprungs-Server weiter, wenn Sie CloudFront nicht so konfigurieren, dass Antworten auf OPTIONS-Anfragen im Cache gespeichert werden.

  • DELETE-, PATCH-, POST- und PUT-Anfragen: CloudFront entfernt das Header-Feld nicht, bevor die Anfrage an Ihren Ursprungs-Server weitergeleitet wird.

Ja

Cache-Control

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

CloudFront-Forwarded-Proto

CloudFront fügt den Header nicht hinzu, bevor die Anfrage an den Ursprungs-Server weitergeleitet wird.

Weitere Informationen finden Sie unter Konfigurieren der Zwischenspeicherung basierend auf dem Protokoll der Anfrage.

Ja

CloudFront-Is-Desktop-Viewer

CloudFront fügt den Header nicht hinzu, bevor die Anfrage an den Ursprungs-Server weitergeleitet wird.

Weitere Informationen finden Sie unter Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp.

Ja

CloudFront-Is-Mobile-Viewer

CloudFront fügt den Header nicht hinzu, bevor die Anfrage an den Ursprungs-Server weitergeleitet wird.

Weitere Informationen finden Sie unter Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp.

Ja

CloudFront-Is-Tablet-Viewer

CloudFront fügt den Header nicht hinzu, bevor die Anfrage an den Ursprungs-Server weitergeleitet wird.

Weitere Informationen finden Sie unter Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp.

Ja

CloudFront-Viewer-Country

CloudFront fügt den Header nicht hinzu, bevor die Anfrage an den Ursprungs-Server weitergeleitet wird.

Ja

Connection

CloudFront ersetzt diesen Header mit Connection: Keep-Alive, bevor die Anfrage an Ihren Ursprungs-Server weitergeleitet wird.

Nein

Content-Length

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

Content-MD5

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Content-Type

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Cookie

Wenn Sie CloudFront so konfigurieren, dass Cookies weitergeleitet werden, wird das Cookie-Header-Feld an Ihren Ursprungs-Server weitergeleitet. Andernfalls entfernt CloudFront das Cookie-Header-Feld. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

Nein

Date

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja, wird aber nicht empfohlen

Expect

CloudFront entfernt den Header.

Ja

From

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Host

CloudFront setzt den Wert auf den Domämennamen des Ursprungs-Servers, der dem angeforderten Objekt zugeordnet ist.

Sie können nicht basierend auf dem Host-Header für Amazon S3 oder MediaStore-Ursprünge zwischenspeichern.

Ja (benutzerdefiniert)

Nein (S3 und MediaStore)

If-Match

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

If-Modified-Since

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

If-None-Match

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

If-Range

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

If-Unmodified-Since

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Max-Forwards

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

Origin

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Pragma

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

Proxy-Authenticate

CloudFront entfernt den Header.

Nein

Proxy-Authorization

CloudFront entfernt den Header.

Nein

Proxy-Connection

CloudFront entfernt den Header.

Nein

Range

CloudFront leitet den Header an Ihren Ursprungs-Server weiter. Weitere Informationen finden Sie unter In diesem Abschnitt wird beschrieben, wie CloudFront-Teilanfragen für ein Objekt (Bereichs-GETs) verarbeitet.

Ja, standardmäßig

Referer

CloudFront entfernt den Header.

Ja

Request-Range

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

TE

CloudFront entfernt den Header.

Nein

Trailer

CloudFront entfernt den Header.

Nein

Transfer-Encoding

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Nein

Upgrade

Der Header wird in CloudFront entfernt, es sei denn, Sie haben eine WebSocket-Verbindung hergestellt.

No (Nein; außer bei WebSocket-Verbindungen)

User-Agent

CloudFront ersetzt den Wert in diesem Header-Feld durch Amazon CloudFront. Wenn Sie möchten, dass Ihre Inhalte von CloudFront basierend auf dem vom Benutzer verwendeten Gerät im Cache gespeichert werden, finden Sie weitere Informationen dazu unter Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp.

Ja, wird aber nicht empfohlen

Via

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

Warning

CloudFront leitet den Header an Ihren Ursprungs-Server weiter.

Ja

X-Amz-Cf-Id

CloudFront fügt den Header der Viewer-Anforderung hinzu, bevor die Anfrage an Ihren Ursprungs-Server weitergeleitet wird. Der Header-Wert enthält eine verschlüsselte Zeichenfolge, die die Anfrage eindeutig bezeichnet.

Nein

X-Edge-*

CloudFront entfernt alle X-Edge-*-Header.

Nein

X-Forwarded-For

CloudFront leitet den Header an Ihren Ursprungs-Server weiter. Weitere Informationen finden Sie unter Client-IP-Adressen.

Ja

X-Forwarded-Proto

CloudFront entfernt den Header.

Nein

X-HTTP-Method-Override

CloudFront entfernt den Header.

Ja

X-Real-IP

CloudFront entfernt den Header.

Nein

HTTP-Version

CloudFront leitet Anfragen an Ihren benutzerdefinierten Ursprungs-Server über HTTP/1.1 weiter.

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.

Persistente Verbindungen

Wenn CloudFront eine Antwort von Ihrem Ursprungs-Server erhält, wird die Verbindung (falls möglich) mehrere Sekunden lang aufrechterhalten – für den Fall, dass während dieses Zeitraums eine weitere Anfrage eingeht. Durch eine persistente Verbindung wird die Zeit gespart, die erforderlich ist, um die TCP-Verbindung erneut herzustellen und einen weiteren TLS-Handshake für nachfolgende Anforderungen durchzuführen.

Weitere Informationen, einschließlich solcher zur Konfiguration der Dauer ständiger Verbindungen, finden Sie Ursprungs-Keepalive-Timeout im Abschnitt Werte, die Sie beim Erstellen oder Aktualisieren einer Verteilung angeben.

Protocols

CloudFront leitet HTTP- oder HTTPS-Anfragen an den Ursprungs-Server basierend auf folgenden Faktoren weiter:

  • Das Protokoll der Anfrage, die der Viewer an CloudFront sendet – entweder HTTP oder HTTPS.

  • Der Wert des Felds Origin Protocol Policy in der CloudFront-Konsole oder, wenn Sie die CloudFront-API verwenden, das OriginProtocolPolicy-Element im komplexen Typ DistributionConfig. In der CloudFront-Konsole können Sie die Optionen HTTP Only, HTTPS Only und Match Viewer auswählen.

Wenn Sie HTTP Only oder HTTPS Only auswählen, leitet CloudFront Anfragen über das angegebene Protokoll an den Ursprungs-Server weiter, unabhängig vom Protokoll der Viewer-Anforderung.

Wenn Sie Match Viewer angeben, leitet CloudFront Anfragen über das Protokoll der Viewer-Anforderung an den Ursprungs-Server weiter. Beachten Sie, dass CloudFront das Objekt nur einmal zwischenspeichert, auch wenn Viewer ihre Anfragen sowohl über HTTP als auch über HTTPS stellen.

Wichtig

Wenn CloudFront eine Anfrage an den Ursprungs-Server über das HTTPS-Protokoll weiterleitet und der Ursprungs-Server ein ungültiges oder selbstsigniertes Zertifikat zurückgibt, verwirft CloudFront die TCP-Verbindung.

Informationen zum Aktualisieren einer Verteilung mithilfe der CloudFront-Konsole finden Sie unter Aktualisieren einer Verteilung. Informationen zum Aktualisieren einer Verteilung mit der CloudFront-API finden Sie unter UpdateDistribution in der Amazon CloudFront-API-Referenz.

Abfragezeichenfolgen

Sie können CloudFront so konfigurieren, dass Abfragezeichenfolgeparameter an Ihren Ursprungs-Server 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 des Reaktions-Timeouts reagiert oder 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.

Weitere Informationen, einschließlich Informationen zum Konfigurieren des Reaktions-Timeouts für den Ursprungs-Server, finden Sie unter Ursprungs-Reaktions-Timeout.

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 Ursprungs-Server. Wenn eine Datenverkehrsspitze vorliegt – also weitere Anfragen für dasselbe Objekt am Edge-Standort ankommen, bevor Ihr Ursprung 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 auf Ihrem Ursprungsserver 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 Cookies im Cache gespeichert werden, leitet CloudFront-Cache alle abweichenden Anfragen an Ihren Ursprungs-Server weiter.

User-Agent-Header

Wenn Sie möchten, dass CloudFront verschiedene Versionen Ihrer Objekte basierend auf dem Gerät zwischenspeichert, das ein Benutzer zum Anzeigen Ihrer Inhalte verwendet, empfehlen wir, CloudFront so zu konfigurieren, dass mindestens einer der folgenden Header an Ihren benutzerdefinierten Ursprung weitergeleitet wird:

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

Basierend auf dem Wert des User-Agent-Headers setzt CloudFront den Wert dieser Header auf true oder false, bevor die Anforderung an Ihren Ursprung weitergeleitet wird. Wenn ein Gerät in mehr als eine Kategorie fällt, können mehrere Werte sei true. Beispielsweise setzt CloudFront bei einigen Tablet-Geräten möglicherweise CloudFront-Is-Mobile-Viewer und CloudFront-Is-Tablet-Viewer auf true. Weitere Informationen über die Konfiguration von CloudFront für das Zwischenspeichern basierend auf Anfrage-Headern finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anfrage-Headern.

Sie können CloudFront so konfigurieren, dass Objekte basierend auf Werten im User-Agent-Header im Cache gespeichert werden. Dies wird jedoch nicht empfohlen. Der User-Agent-Header kann eine Vielzahl möglicher Werte enthalten. Das Zwischenspeichern basierend auf diesen Werten würde dazu führen, dass wesentlich mehr Anfragen von CloudFront an Ihren Ursprungs-Server weitergeleitet werden.

Wenn Sie CloudFront nicht so konfigurieren, dass Objekte basierend auf den Werten im User-Agent-Header im Cache gespeichert werden, fügt CloudFront einen User-Agent-Header mit dem folgenden Wert hinzu, bevor eine Anfrage an Ihren Ursprungs-Server weitergeleitet wird:

User-Agent = Amazon CloudFront

CloudFront fügt diesen Header unabhängig davon hinzu, ob die Viewer-Anforderung einen User-Agent-Header enthält oder nicht. Wenn in der Viewer-Anforderung ein User-Agent-Header enthalten ist, wird dieser von CloudFront entfernt.

So verarbeitet CloudFront Antworten von Ihrem benutzerdefinierten Ursprung

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

100 Continue Antworten

Ihr Ursprung kann nicht mehr als eine 100 continue-Antwort an CloudFront senden. Nach der ersten 100 continue-Antwort erwartet CloudFront eine 200 OK-HTTP-Antwort. Wenn Ihr Ursprung nach der ersten eine weitere 100 continue-Antwort sendet, gibt CloudFront einen Fehler zurück.

Caching

  • Stellen Sie sicher, dass der Ursprungsserver in den Header-Feldern Date und Last-Modified gültig und korrekte Werte einsetzt.

  • Wenn in den Anfragen von Viewern das Anfrage-Header-Feld If-Match oder If-None-Match enthalten ist, fügen Sie ein ETag-Antwort-Header-Feld ein. Wenn Sie keinen ETag-Wert angeben, ignoriert CloudFront die nachfolgenden If-Match- oder If-None-Match-Header.

  • In der Regel erkennt CloudFront einen Cache-Control: no-cache-Header in der Antwort des Ursprungs-Servers an. Eine Ausnahme von dieser Regel wird unter beschriebe Gleichzeitige Anfragen für dasselbe Objekt (Datenverkehrsspitzen).

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.

Inhaltsvereinbarung

Wenn Ihr Ursprungs-Server in der Antwort Vary:* zurückgibt und der Wert von Minimum TTL für das entsprechende Cache-Verhalten 0 ist, wird das Objekt von CloudFront im Cache gespeichert. Jede nachfolgende Anfrage für das Objekt wird aber dennoch an den Ursprungs-Server weitergeleitet, um sicherzustellen, dass die neueste Version des Objekts im Cache enthalten ist. CloudFront schließt keine bedingten Header wie z. B. If-None-Match oder If-Modified-Since mit ein. Dies hat zur Folge, dass Ihr Ursprung das Objekt bei jeder Anfrage an CloudFront zurückgibt.

Wenn Ihr Ursprungs-Server Vary:* in der Antwort zurückgibt und bei Minimum TTL für das entsprechende Cache-Verhalten ein anderer Wert angegeben ist, verarbeitet CloudFront den Vary-Header wie unter HTTP-Antwort-Header, die CloudFront entfernt oder ersetzt beschrieben.

Cookies

Wenn Sie Cookies für ein Cache-Verhalten aktivieren und der Ursprungs-Server die Cookies zusammen mit einem Objekt zurückgibt, speichert CloudFront das Objekt und die Cookies im Cache. Beachten Sie, dass diese Vorgehensweise die Zwischenspeicherbarkeit für ein Objekt reduziert. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

Verworfene TCP-Verbindungen

Wenn die TCP-Verbindung zwischen CloudFront und Ihrem Ursprungs-Server verworfen wird, während Ihr Ursprungs-Server ein Objekt an CloudFront sendet, ist das CloudFront-Verhalten davon abhängig, ob in der Antwort Ihres Ursprungs-Servers ein Content-Length-Header enthalten ist:

  • Content-Length Header: CloudFront gibt das Objekt an den Viewer zurück, sobald das Objekt von Ihrem Ursprungs-Server empfangen wird. Wenn der Wert des Content-Length-Headers jedoch nicht der tatsächlichen Größe des Objekts entspricht, speichert CloudFront das Objekt nicht im Cache.

  • Transfer-Encoding: Chunked: CloudFront gibt das Objekt an den Viewer zurück, sobald das Objekt von Ihrem Ursprungs-Server empfangen wird. Wenn die aufgeteilte Antwort jedoch nicht vollständig ist, speichert CloudFront das Objekt nicht im Cache.

  • No Content-Length Header: CloudFront gibt das Objekt an den Viewer zurück und speichert es im Cache, aber das Objekt ist möglicherweise nicht vollständig. Ohne einen Content-Length-Header kann CloudFront nicht bestimmen, ob die TCP-Verbindung versehentlich oder absichtlich verworfen wurde.

Wir empfehlen, dass Sie Ihren HTTP-Server so konfigurieren, dass ein Content-Length-Header hinzugefügt wird. So können Sie vermeiden, dass CloudFront unvollständige Objekte im Cache speichert.

HTTP-Antwort-Header, die CloudFront entfernt oder ersetzt

CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antworten von Ihrem 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 Ursprungs-Server dieses Header-Feld zurückgibt, setzt CloudFront den Wert auf chunked, bevor die Antwort an den Viewer weitergeleitet wird.

  • Upgrade

  • Vary – Beachten Sie Folgendes:

    • Wenn Sie CloudFront so konfigurieren, dass alle gerätespezifischen Header (CloudFront-Is-Desktop-Viewer, CloudFront-Is-Mobile-Viewer, CloudFront-Is-SmartTV-Viewer, CloudFront-Is-Tablet-Viewer) an Ihren Ursprungs-Server weitergeleitet werden, und Sie Ihren Ursprungs-Server so konfigurieren, dass Vary:User-Agent an CloudFront zurückgegeben wird, dann gibt CloudFront Vary:User-Agent an den Viewer zurück. Weitere Informationen finden Sie unter Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp.

    • Wenn Sie Ihren Ursprungs-Server so konfigurieren, dass entweder Accept-Encoding oder Cookie im Vary-Header enthalten ist, dann fügt CloudFront diese Werte in die Antwort an den Viewer ein.

    • Wenn Sie CloudFront so konfigurieren, dass eine Header-Whitelist an Ihren Ursprungs-Server weitergeleitet wird, und Sie Ihren Ursprungs-Server so konfigurieren, dass die Header-Namen im Vary-Header (z. B. Vary:Accept-Charset,Accept-Language) an CloudFront weitergeleitet werden, dann gibt CloudFront den Vary-Header mit diesen Werten an den Viewer zurück.

    • Informationen darüber, wie CloudFront einen *-Wert im Vary-Header verarbeitet, finden Sie unter Inhaltsvereinbarung.

    • Wenn Sie Ihren Ursprungs-Server so konfigurieren, dass andere Werte im Vary-Header enthalten sind, dann entfernt CloudFront diese Werte, bevor die Antwort an den Viewer zurückgegeben wird.

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

Ursprung nicht verfügbar

Wenn Ihr Ursprungs-Server nicht verfügbar ist und CloudFront eine Anfrage für ein Objekt erhält, das zwar im Edge-Cache vorhanden aber abgelaufen ist (z. B. da der in der Cache-Control max-age-Richtlinie angegebene Zeitraum verstrichen ist), gibt CloudFront entweder die abgelaufene Version des Objekts oder eine benutzerdefinierte Fehlerseite zurück. Weitere Informationen zum CloudFront-Verhalten bei der Konfiguration benutzerdefinierter Fehlerseiten finden Sie unter So verarbeitet CloudFront Fehler, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben.

In manchen Fällen wird ein selten angefordertes Objekt entfernt und ist nicht mehr im Edge-Cache verfügbar. CloudFront kann ein Objekt, das entfernt wurde, nicht bereitstellen.

Redirects

Wenn Sie den Speicherort eines Objekts auf dem Ursprungsserver ändern, können Sie Ihren Webserver so konfigurieren, dass Anfragen an den neuen Speicherort umgeleitet werden. Wenn ein Viewer nach der Einrichtung der Umleitung eine Anfrage für das Objekt sendet, leitet CloudFront die Anfrage an den Ursprungs-Server weiter und dieser antwortet mit einer Umleitung (z. B, 302 Moved Temporarily). CloudFront speichert die Umleitung im Cache und gibt sie an den Viewer zurück. CloudFront folgt der Umleitung nicht.

Sie können Ihren Webserver so konfigurieren, dass Anfragen an einen der folgenden Speicherorte umgeleitet werden:

  • Die neue URL des Objekts auf dem Ursprungsserver. Wenn der Viewer der Umleitung auf die neue URL folgt, umgeht er CloudFront und sendet die Anfrage direkt an den Ursprungs-Server. Daher empfehlen wir, dass Sie Anfragen nicht auf die neue URL des Objekts auf dem Ursprungsserver weiterleiten.

  • Die neue CloudFront-URL für das Objekt. Wenn der Viewer die Anfrage mit der neuen CloudFront-URL sendet, ruft CloudFront das Objekt vom neuen Speicherort auf Ihrem Ursprungs-Server ab, speichert es am Edge-Standort und gibt das Objekt an den Viewer zurück. Nachfolgende Anfragen für das Objekt werden von dem Edge-Standort bedient. Dadurch werden Latenzzeiten und Arbeitslasten vermieden, die bei Viewer-Anforderungen für das Objekt an den Ursprungsserver entstehen. Allerdings fallen bei jeder neuen Anfrage für das Objekt Gebühren für zwei Anfragen an CloudFront an.

Transfer-Encoding-Header

CloudFront unterstützt nur chunked als Wert für den Transfer-Encoding-Header. Wenn Ihr Ursprungs-Server Transfer-Encoding: chunked zurückgibt, sendet CloudFront das Objekt an den Client, sobald es am Edge-Standort empfangen wird, und speichert es im aufgeteilten Format für nachfolgende Anfragen.

Wenn der Viewer eine Range GET-Anfrage stellt und der Ursprung Transfer-Encoding: chunked zurückgibt, gibt CloudFront das gesamte Objekt anstelle des angefragten Bereichs an den Viewer zurück.

Wir empfehlen, dass Sie die Abschnittscodierung verwenden, wenn die Länge des Inhalts Ihrer Antwort nicht im Voraus ermittelt werden kann. Weitere Informationen finden Sie unter Verworfene TCP-Verbindungen.