‹ Zurück zu Anleitungen

Verstehen von Anforderung- und Antwortverhalten Ihrer Amazon Lightsail-Verteilung

Letzte Aktualisierung: 23. Juli 2020

In diesem Leitfaden beschreiben wir die Art und Weise, wie sich Ihre Amazon Lightsail-Verteilung verhält, wenn Anfragen an Ihren Ursprungsserver verarbeitet und weitergeleitet werden und Antworten von Ihrem Ursprungsserver verarbeitet werden. Weitere Informationen zu Verteilungen finden Sie unter Netzwerkverteilungen für die Bereitstellung von Inhalten in Amazon Lightsail.

Topics

Wie Ihre Verteilung Anfragen verarbeitet und an Ihren Ursprung weiterleitet

Dieser Abschnitt enthält Informationen darüber, wie Ihre Verteilung Viewer-Anfragen verarbeitet und Anfragen an Ihren Ursprung weiterleitet.

Inhalt

Authentifizierung

Wenn Sie Ihre Verteilung für Anfragen von DELETE, GET, HEAD, PATCH, POST, und PUT so konfigurieren, dass die Authorization-Kopfzeile an Ihren Ursprungsserver weitergeleitet wird, können Sie Ihren Ursprungsserver so konfigurieren, dass eine Client-Authentifizierung angefordert wird.

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

  • Konfigurieren Sie Ihre Verteilung ist so, dass die Authorization-Kopfzeile an den Ursprungsserver weitergeleitet wird.

  • Konfigurieren Sie Ihre Verteilung so, dass die Antwort auf OPTIONS-Anfragen nicht zwischengespeichert wird.

Sie können Ihre Verteilung so konfigurieren, dass Anfragen an Ihren Ursprungsserver entweder über HTTP oder über HTTPS weitergeleitet werden.

Caching-Dauer

Um zu steuern, wie lange Ihre Objekte in Ihrem Vereilungs-Cache zwischengespeichert bleiben, bevor Ihre Verteilung eine weitere Anfrage an Ihren Ursprungsserver weiterleitet, können Sie:

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

  • Verwenden Sie den Standardwert, also 1 Tag für die Cache-Lebensdauer (TTL).

Weitere Informationen finden Sie unter Erweiterte Verteilungseinstellungen.

Client-IP-Adressen

Wenn ein Viewer eine Anfrage an Ihre Verteilung sendet und keineX-Forwarded-For Anfrage-Kopfzeile enthält, erhält Ihre Verteilung die IP-Adresse des Viewers der TCP-Verbindung, fügt eine X-Forwarded-For Kopfzeile hinzu, die eine IP-Adreese enthält und leitet die Anfrage an den Ursprungsserver weiter. Wenn z. B. Ihre Verteilung die IP-Adresse 192.0.2.2 von der TCP-Verbindung abruft, wird die folgende Kopfzeile an den Ursprungsserver weitergeleitet:

X-Forwarded-For: 192.0.2.2

Wenn ein Viewer eine Anfrage an Ihre Verteilung sendet, die eine X-Forwarded-ForAnfrage-Kopfzeile enthält, ruft Ihre Verteilung die IP-Adresse des Viewers von der TCP-Verbindung ab, hängt diese an die X-Forwarded-ForKopfzeile an und leitet die Anfrage an den Ursprungsserver weiter. Wenn die Viewer-Anfrage z. B. X-Forwarded-For: 192.0.2.4,192.0.2.3 enthält und die IP-Adresse192.0.2.2 Ihrer Verteilung von der TCP-Verbindung abruft, wird die folgende Kopfzeile an den Ursprungsserver weitergeleitet:

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Manche Anwendungen wie Load Balancer, Firewalls für Webanwendungen, Reverse Proxys, Intrusion-Prevention-Systeme und API Gateway hängen die IP-Adresse des Verteilung-Edge-Servers, der die Anfrage weitergeleitet hat, an das Ende der X-Forwarded-For-Kopfzeile an. Wenn z. B. Ihre Verteilung X-Forwarded-For: 192.0.2.2 in einer Anfrage beinhaltet, an die ELB weiterleitet und die IP-Adresse des Verteilung-Edge-Servers 192.0.2.199 lautet, dann enthält die Anfrage, die Ihre Instance empfängt, die folgende Kopfzeile:

X-Forwarded-For: 192.0.2.2,192.0.2.199

Hinweis

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

Lightsail-Verteilungen unterstützen keine Client-Authentifizierung mit clientseitigen SSL-Zertifikaten. Wenn ein Ursprungsserver ein clientseitiges Zertifikat anfordert, verwirft Ihre Verteilung die Anfrage.

Komprimierung

Lightsail-Verteilungen leiten Anfragen weiter, welche die Accept-Encoding-Feldwerte "identity" und "gzip" enthalten.

Bedingte Anforderungen

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

Der Ursprungsserver verwendet diese Informationen, um zu ermitteln, ob das Objekt aktualisiert wurde bzw. ob das gesamte Objekt oder nur ein HTTP–304-Statuscode (nicht geändert) an Ihre Verteilung zurückgegeben werden muss.

Cookies

Sie können Ihre Verteilung so konfigurieren, dass Cookies an Ihren Ursprungsserver weitergeleitet werden. Weitere Informationen finden Sie unter Erweiterte Verteilungseinstellungen.

Cross-Origin Resource Sharing (CORS)

Wenn Sie möchten, dass Ihre Verteilung die Einstellungen zur ursprungsübergreifenden gemeinsamen Nutzung von Ressourcen respektiert, konfigurieren Sie Ihren Ursprungsserver so, dass dieOrigin-Kopfzeile an Ihren Ursprungsserver weitergeleitet wird.

Verschlüsselung

Sie können festlegen, dass Viewer über HTTPS eine Verbindung mit Ihrer Verteilung herstellen müssen und dass Ihre Verteilung Anforderungen mithilfe von HTTP oder HTTPS an Ihren Ursprungsserver weiterleitet.

Ihre Verteilung leitet HTTPS-Anfragen an Ihren Ursprungsserver über die Protokolle SSLv3, TLSv1.0, TLSv1.1 und TLSv1.2 weiter. Andere Versionen von SSL und TLS werden nicht unterstützt.

GET-Anfragen mit Anfragetext

Wenn eine GET-Viewer-Anfrage einen Anfragetext enthält, gibt Ihre Verteilung einen HTTP-Statuscode-403 (Unzulässig) an den Viewer zurück.

HTTP-Methoden

Wenn Sie Ihre Verteilung so konfigurieren, dass alle unterstützten HTTP-Methoden verarbeitet werden, akzeptiert Ihre Verteilung die folgenden Anfragen von Viewern und leitet sie an Ihren Ursprungsserver weiter:

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

Ihre Verteilung caches immer Antworten auf GET und HEAD-Anfragen. Sie können Ihre Verteilung auch so konfigurieren, dass Antworten auf OPTIONS-Anfragen gecached werden. Ihre Verteilung cached keine Antworten auf Anfragen, welche die andere Methoden verwenden.

Informationen zur Konfiguration Ihres Ursprungsservers für die Verarbeitung dieser Methoden finden Sie in den Unterlagen zu Ihrem Ursprungsserver.

Wichtig

Wenn Sie Ihre Verteilung so konfigurieren, dass alle unterstützten HTTP-Methoden akzeptiert und an Ihren Ursprungsserver weitergeleitet werden, dann konfigurieren Sie auch Ihren Ursprungsserver so, dass alle Methoden verarbeitet werden. Wenn Sie Ihre Verteilung beispielsweise so konfigurieren, dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie POST verwenden möchten, müssen Sie Ihren Ursprungsserver so konfigurieren, dass DELETE-Anfragen entsprechend 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-Kopfzeilen und Verteilungsverhalten

Die folgende Tabelle listet HTTP-Anfrage-Kopfzeilen auf, die Sie an Ihren Ursprungsserver weiterleiten können (mit Ausnahmen, auf die hingewiesen wird). Für jede Kopfzeile umfasst die Tabelle Informationen über Folgendes:

  • Unterstützt – Ob Sie Ihre Verteilung so konfigurieren können, dass Objekte auf Basis der Kopfzeilen-Werte für diese Kopfzeile im Cache gespeichert werden.

    Sie können Ihre Verteilung so konfigurieren, dass Objekte auf der Grundlage von Werten in den Date und User-Agent-Kopfzeilen gecached werden; dies wird jedoch nicht empfohlen. Diese Kopfzeilen können eine Vielzahl möglicher Werte enthalten; das Caching auf Basis dieser Werte würde dazu führen, dass wesentlich mehr Anfragen von Ihrer Verteilung an Ihren Ursprungsserver weitergeleitet werden.

  • Verhalten, wenn Sie nicht konfigurieren – Das Verhalten Ihrer Verteilung, wenn Sie diese nicht konfigurieren, um die Kopfzeile an Ihren Ursprungsserver weiterzuleiten, welches Ihre Verteilung dazu bringt, Ihre Objekte auf Basis der Kopfzeilen-Werten im Cache zu speichern.

  • Kopfzeile – Anderweitig definierte Kopfzeilen

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileAccept

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileAccept-Charset

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileAccept-Encoding

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Wenn der Wert gzip enthält, leitet Ihre Verteilung Accept-Encoding: gzip an Ihren Ursprungsserver weiter. Wenn der Wert gzip nicht enthält, entfernt Ihre Verteilung das Kopfzeilen-Feld Accept-Encoding, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird.

  • KopfzeileAccept-Language

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileAuthorization

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert:

    • GET- und HEAD-Anfragen – Ihre Verteilung entfernt das Authorization-Kopfzeilen-Feld, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird.

    • OPTIONS Anfragen – Ihre Verteilung entfernt dasAuthorization Kopfzeilen-Feld, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird, wenn Sie Ihre Verteilung so konfigurieren, dass Antworten auf OPTIONSAnfragen im Cache gespeichert werden.

      Ihre Verteilung leitet das Authorization Kopfzeilen-Feld an Ihren Ursprungsserver weiter, wenn Sie Ihre Verteilung nicht so konfigurieren, dass Antworten auf OPTIONS-Anfragen im Cache gespeichert werden.

    • DELETE-, PATCH-, POST- und PUT-Anfragen – Ihre Verteilung entfernt das Kopfzeilen-Feld nicht, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird.

  • KopfzeileCache-Control

    Unterstützt - Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileCloudFront-Forwarded-Proto

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile nicht hinzu, bevor die Anfrage an den Ursprungsserver weitergeleitet wird.

  • KopfzeileCloudFront-Is-Desktop-Viewer

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile nicht hinzu, bevor die Anfrage an den Ursprungsserver weitergeleitet wird.

  • KopfzeileCloudFront-Is-Mobile-Viewer

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile nicht hinzu, bevor die Anfrage an den Ursprungsserver weitergeleitet wird.

  • KopfzeileCloudFront-Is-Tablet-Viewer

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile nicht hinzu, bevor die Anfrage an den Ursprungsserver weitergeleitet wird.

  • KopfzeileCloudFront-Viewer-Country

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile nicht hinzu, bevor die Anfrage an den Ursprungsserver weitergeleitet wird.

  • KopfzeileConnection

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung ersetzt diese Kopfzeile durchConnection: Keep-Alive bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird.

  • KopfzeileContent-Length

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileContent-MD5

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileContent-Type

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileCookie

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Wenn Sie Ihre Verteilung so konfigurieren, dass Cookies weitergeleitet werden, wird die Cookie-Kopfzeile an Ihren Ursprungsserver weitergeleitet. Wenn Sie das nicht tun, entfernt Ihre Verteilung das CookieKopfzeilen-Feld.

  • KopfzeileDate

    Unterstützt – Ja, wird aber nicht empfohlen

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileExpect

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileFrom

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileHost

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung stellt den Wert auf den Domänennamen des Ursprungsservers ein, der dem angeforderten Objekt zugeordnet ist.

  • KopfzeileIf-Match

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileIf-Modified-Since

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileIf-None-Match

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileIf-Range

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileIf-Unmodified-Since

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileMax-Forwards

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileOrigin

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeilePragma

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileProxy-Authenticate

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileProxy-Authorization

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileProxy-Connection

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileRange

    Unterstützt- Ja, standardmäßig

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileReferer

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileRequest-Range

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – >Ihre Verteilung leitet die Kopfzeile an Ihren Ursprungsserver weiter.

  • KopfzeileTE

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileTrailer

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileTransfer-Encoding

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileUpgrade

    Unterstützt – Nein (außer bei WebSocket-Verbindungen)

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile, es sei denn, Sie haben eine WebSocket-Verbindung hergestellt.

  • KopfzeileUser-Agent

    Unterstützt – Ja, wird aber nicht empfohlen

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung ersetzt den Wert dieses Kopfzeilen-Felds durchAmazon CloudFront.

  • KopfzeileVia

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileWarning

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileX-Amz-Cf-Id

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung fügt die Kopfzeile der Viewer-Anfrage hinzu, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird. Der Header-Wert enthält eine verschlüsselte Zeichenfolge, die die Anfrage eindeutig bezeichnet.

  • KopfzeileX-Edge-*

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt alle X-Edge-*-Kopfzeilen.

  • KopfzeileX-Forwarded-For

    Unterstützt – Ja

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung leitet die Kopfzeilen an Ihren Ursprungsserver weiter.

  • KopfzeileX-Forwarded-Proto

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

  • KopfzeileX-Real-IP

    Unterstützt – Nein

    Verhalten, wenn nicht konfiguriert – Ihre Verteilung entfernt die Kopfzeile.

HTTP-Version

Ihre Verteilung leitet Anfragen an Ihren Ursprungsserver ü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.

Die Verteilung erstellt eine URL auf Grundlage der Anfrage. Die maximale Länge dieser URL beträgt 8 192 Byte.

Wenn eine Anfrage oder eine URL diese Höchstwerte überschreitet, gibt Ihre Verteilung einen HTTP-Statuscode-413, Request Entity Too Large, an den Viewer zurück; anschließend wird die TCP-Verbindung mit dem Viewer beendet.

OCSP-Stapling

Wenn ein Viewer eine HTTPS-Anfrage für ein Objekt sendet, muss entweder Ihre Verteilung oder der Viewer bei der Zertifizierungsstelle (CA) bestätigen, dass das SSL-Zertifikat für die Domäne nicht widerrufen wurde. OCSP-Stapling beschleunigt die Validierung des Zertifikats, indem Ihrer Verteilung gestattet wird, das Zertifikat zu validieren 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 Ihre Verteilung viele HTTPS-Anfragen für Objekte in derselben Domäne erhält. Jeder Server an einem Verteilung-Edge-Standort muss eine separate Validierungsanfrage senden. Wenn Ihre Verteilung viele HTTPS-Anfragen für dieselbe Domäne erhält, hat jeder Server an dem Edge-Standort nach kurzer Zeit eine Antwort von der CA vorliegen, die er an ein Paket im SSL-Handshake „stapeln“ kann; wenn der Viewer mit der Gültigkeit des Zertifikats zufrieden ist, kann Ihre Verteilung das angeforderte Objekt bereitstellen. Wenn Ihre Verteilung nicht viel Datenverkehr an einem 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 -Server überträgt das Objekt. Dieser Verteilungsserver sendet außerdem eine Validierungsanfrage an die CA; wenn er das nächste Mal eine Anfrage mit demselben Domänenamen erhält, liegt bereits eine Validierungsantwort von der CA vor.

Persistente Verbindungen

Wenn Ihre Verteilung eine Antwort von Ihrem Ursprungsserver erhält, wird dieser versuchen, die Verbindung mehrere Sekunden lang aufrechtzuerhalten – für den Fall, dass während dieses Zeitraums eine weitere Anfrage eingeht. Durch eine persistente Verbindung wird Zeit gespart, die erforderlich ist, um die TCP-Verbindung erneut herzustellen und einen weiteren TLS-Handshake für nachfolgende Anforderungen durchzuführen.

Protokolle

Ihre Verteilung leitet HTTP- oder HTTPS-Anfragen an den Ursprungsserver basierend auf dem Wert des Felds Ursprungsprotokollrichtlinie in der Lightsail-Konsole weiter. In der Lightsail-Konsole können Sie die Optionen Nur HTTP und Nur HTTPS auswählen.

Wenn Sie Nur HTTP oder Nur HTTPS angeben, leitet Ihre Verteilung Anfragen an Ihren Ursprungsserver weiter, unabhängig vom Protokoll der Viewer-Anfrage.

Wichtig

Wenn Ihre Verteilung eine Anfrage an Ihren Ursprungsserver über das HTTPS-Protokoll weiterleitet und der Ursprungsserver ein ungültiges oder selbstsigniertes Zertifikat zurückgibt, verwirft Ihre Verteilung die TCP-Verbindung.

Abfragezeichenfolgen

Sie können konfigurieren, ob Ihre Verteilung Abfragezeichenfolgeparameter an Ihren Ursprungsserver weiterleitet.

Timeout der Ursprungsverbindung und Versuche

Ihre Verteilung wartet standardmäßig bis zu 30 Sekunden (3 Versuche à 10 Sekunden), bevor eine Fehlermeldung an den Viewer zurückgegeben wird.

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 Ihre Verteilung nach der Weiterleitung einer Anforderung an den Ursprungsserver auf eine Antwort wartet.

  • Die Zeit in Sekunden, die Ihre Verteilung nach dem Erhalt eines Antwortpakets vom Ursprungsserver und vor dem Empfang des nächsten Pakets wartet.

Das Verhalten Ihrer Verteilung ist von der HTTP-Methode der Viewer-Anfrage abhängig:

  • GET- und HEAD-Anfragen – Wenn der Ursprungsserver nicht innerhalb der Dauer des Reaktions-Timeouts reagiert oder nicht mehr reagiert, verwirft Ihre Verteilung die Verbindung. Wenn die angegebene Anzahl von Verbindungsversuchen zum Ursprung mehr als 1 beträgt, versucht Ihre Verteilung erneut, eine vollständige Antwort zu erhalten. Ihre Verteilung versucht dies bis zu 3 Mal, wie im Wert der Einstellung Verbindungsversuche zum Ursprungsserver festgelegt. Wenn der Ursprungsserver beim letzten Versuch keine Antwort sendet, unternimmt Ihre Verteilung erst dann einen weiteren Versuch, wenn die nächste Anfrage für Inhalte auf demselben Ursprungsserver empfangen wird.

  • DELETE-, OPTIONS-, PATCH-, PUT- und POST-Anfragen – Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert, verwirft Ihre Verteilung die Verbindung und versucht nicht, den Ursprung erneut zu kontaktieren. Der Client kann die Anfrage erneut senden, falls erforderlich.

Gleichzeitige Anfragen für dasselbe Objekt (Datenverkehrsspitzen)

Wenn ein Verteilung-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 Ihre Verteilung die Anfrage sofort an Ihren Ursprungsserver. Wenn eine Datenverkehrsspitze— vorliegt, also weitere Anfragen für dasselbe Objekt an dem Edge-Standort ankommen, bevor Ihr Ursprung auf die erste Anfrage geantwortet hat, — legt Ihre Verteilung eine kurze Pause ein, bevor die weiteren Anfragen für das Objekt an Ihren Ursprungsserver weitergeleitet werden. In der Regel erreicht die Antwort auf die erste Anfrage den Verteilung-Edge-Standort vor der Antwort 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 Ihre Verteilung z. B. so konfiguriert haben, dass Objekte auf Basis der Anfrage-Kopfzeilen oder Cookies im Cache gespeichert werden, leitet Ihre Verteilung alle eindeutigen Anfragen an Ihren Ursprungsserver weiter.

Benutzer-Agent-Kopfzeile

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

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

Auf der Grundlage des Werts der User-Agent-Kopfzeile stellt Ihre Verteilung den Wert dieser Kopfzeilen auf true oder false ein, bevor die Anfrage an Ihren Ursprungsserver weitergeleitet wird. Wenn ein Gerät in mehr als eine Kategorie fällt, können mehrere Werte sei true. Beispielsweise stellt Ihre Verteilung bei einigen Tablet-Geräten möglicherweise beide CloudFront-Is-Mobile-Viewer und CloudFront-Is-Tablet-Viewer auf true ein.

Sie können Ihre Verteilung so konfigurieren, dass Objekte auf der Grundlage von Werten in der User-Agent-Kopfzeile gecached werden; dies wird jedoch nicht empfohlen. Die User-Agent-Kopfzeile kann eine Vielzahl möglicher Werte enthalten; das Caching auf Basis dieser Werte würde dazu führen, dass wesentlich mehr Anfragen von Ihrer Verteilung an Ihren Ursprungsserver weitergeleitet werden.

Wenn Sie Ihre Verteilung nicht so konfigurieren, dass Objekte auf Basis der Werte in der User-Agent-Kopfzeile im Cache gespeichert werden, wird in Ihrer Verteilung eine User-Agent-Kopfzeile mit dem folgenden Wert hinzugefügt, bevor eine Anfrage an Ihren Ursprungsserver weitergeleitet wird:

User-Agent = Amazon CloudFront

Ihre Verteilung fügt diese Kopfzeile unabhängig davon hinzu, ob die Anfrage vom Viewer eine User-Agent-Kopfzeile enthält. Wenn in der Anfrage vom Viewer eine User-Agent-Kopfzeile enthalten ist, wird dieser von Ihrer Verteilung entfernt.

Wie Ihre Verteilung Antworten von Ihrem Ursprungsserver verarbeitet

Dieser Abschnitt enthält Informationen darüber, wie Ihre Verteilung Antworten von Ihrem Ursprung verarbeitet.

Inhalt

100 Continue-Antworten

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

Caching

  • Stellen Sie sicher, dass Ihr Ursprungsserver in den Kopfzeilen-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 Ihre Verteilung die nachfolgenden If-Match oder If-None-Match-Kopfzeilen.

  • In der Regel respektiert Ihre Verteilung eine Cache-Control: no-cache-Kopfzeile in der Antwort des Ursprungsservers. Eine Ausnahme von dieser Regel finden Sie unterGleichzeitige Anfragen für dasselbe Objekt (Verkehrsspitzen).

Abgebrochene Anfragen

Wenn sich ein Objekt nicht im Edge-Cache befindet und der Viewer die Sitzung beendet (z.B. einen Browser schließt), nachdem das Objekt von Ihrem Ursprungsserver an Ihre Verteilung gesendet wurde aber noch bevor das angeforderte Objekt übertragen werden konnte, wird das Objekt von Ihrer Verteilung nicht an dem Edge-Standort zwischengespeichert.

Inhaltsvereinbarung

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

Wenn Ihr Ursprungsserver Vary:* in der Antwort zurückgibt und der Wert von Minimum TTL für das entsprechende Cache-Verhalten ein anderer Wert ist, CloudFront arbeitet die Vary-Kopfzeile wie unter HTTP-Antwort-Kopfzeilen, die Ihre Verteilung entfernt oder ersetzt, beschrieben.

Cookies

Wenn Sie Cookies für ein Cache-Verhalten aktivieren und der Ursprungsserver die Cookies zusammen mit einem Objekt zurückgibt, speichert Ihre Verteilung das Objekt und die Cookies im Cache. Beachten Sie, dass diese Vorgehensweise die Zwischenspeicherbarkeit für ein Objekt reduziert.

Verworfene TCP-Verbindungen

Wenn die TCP-Verbindung zwischen Ihrer Verteilung und Ihrem Ursprungsserver verworfen wird, während Ihr Ursprungsserver ein Objekt an Ihre Verteilung sendet, ist das Verhalten Ihrer Verteilung davon abhängig, ob in der Antwort Ihres Ursprungsservers eine Content-Length-Kopfzeile enthalten ist:

  • Content-Length-Kopfzeile – Ihre Verteilung gibt das Objekt an den Viewer zurück, wenn das Objekt von Ihrem Ursprungsserver empfangen wird. Wenn der Wert der Content-Length-Kopfzeile jedoch nicht der tatsächlichen Größe des Objekts entspricht, speichert Ihre Verteilung das Objekt nicht im Cache.

  • Übertragungsverschlüsselung: Gestückelt – Ihre Verteilung gibt das Objekt an den Viewer zurück, wenn das Objekt von Ihrem Ursprungsserver empfangen wird. Wenn die gestückelte Antwort jedoch nicht vollständig ist, speichert Ihre Verteilung das Objekt nicht im Cache.

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

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

HTTP-Antwort-Kopfzeilen, die von Ihrer Verteilung entfernt oder ersetzt werden

Ihre Verteilung entfernt oder aktualisiert die folgenden Kopfzeilen-Felder, bevor die Antworten von Ihrem Ursprungsserver an den Viewer weitergeleitet werden:

  • Set-Cookie–Wenn Sie Ihre Verteilung so konfigurieren, dass Cookies weitergeleitet werden, wird das Set-Cookie-Kopfzeilen-Feld an den Client weitergeleitet.

  • Trailer

  • Transfer-Encoding– Wenn Ihr Ursprungsserver dieses Kopfzeilen-Feld zurückgibt, setzt Ihre Verteilung den Wert auf chunked, bevor die Antwort an den Viewer zurückgegeben wird.

  • Upgrade

  • Vary – Beachten Sie Folgendes:

    • Wenn Sie Ihre Verteilung so konfigurieren, dass alle gerätespezifischen Kopfzeilen an Ihren Ursprungsserver (CloudFront-Is-Desktop-Viewer, CloudFront-Is-Mobile-Viewer, CloudFront-Is-SmartTV-Viewer, CloudFront-Is-Tablet-Viewer) weitergeleitet werden, und Sie Ihren Ursprungsserver so konfigurieren, dass Vary:User-Agent an Ihre Verteilung zurückgegeben wird, dann gibt Ihre Verteilung Vary:User-Agent an den Viewer zurück.

    • Wenn Sie Ihren Ursprungsserver so konfigurieren, dass entweder Accept-Encoding oder Cookie in der Vary-Kopfzeile enthalten ist, dann fügt Ihre Verteilung diese Werte in die Antwort an den Viewer ein.

    • Wenn Sie Ihre Verteilung so konfigurieren, dass eine Kopfzeilen-Whitelist an Ihren Ursprungsserver weitergeleitet wird, und Sie Ihren Ursprungsserver so konfigurieren, dass die Kopfzeilennamen in der Vary-Kopfzeile (z. B. Vary:Accept-Charset,Accept-Language) an Ihre Verteilung weitergeleitet werden, dann gibt Ihre Verteilung die Vary-Kopfzeile mit diesen Werten an den Viewer zurück.

    • Informationen darüber, wie Ihre Verteilung einen Wert von* in der Vary-Kopfzeile verarbeitet, sieheInhaltsverhandlung.

    • Wenn Sie Ihren Ursprungsserver so konfigurieren, dass andere Werte in der Vary Kopfzeile enthalten sind, dann entfernt Ihre Verteilung diese Werte, bevor die Antwort an den Viewer zurückgegeben wird.

  • Via – Ihre Verteilung legt bei der Antwort an den Viewer den Wert wie folgt fest:

    Via: http-versionalphanumeric-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 Inhalts einer Antwort, die Ihre Verteilung an den Viewer zurückgibt, beträgt 20 GB. Dazu gehören auch Antworten für aufgeteilte Übertragungen, in denen kein Wert für die Content-Length-Kopfzeile angegeben wurde.

Ursprung nicht verfügbar

Wenn Ihr Ursprungsserver nicht verfügbar ist und Ihre Verteilung 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), stellt Ihre Verteilung entweder die abgelaufene Version des Objekts oder eine benutzerdefinierte Fehlerseite bereit.

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

Umleitungen

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 zum ersten Mal eine Objektanforderung sendet, leitet Ihre Verteilung die Anfrage an den Ursprungsserver weiter und dieser antwortet mit einer Umleitung (z. B. 302 Moved Temporarily). Ihre Verteilung speichert die Umleitung im Cache und gibt sie an den Viewer zurück. Ihre Verteilung 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 der Viewer Ihre Verteilung und geht direkt an den Ursprungsserver. Daher empfehlen wir, dass Sie Anfragen nicht auf die neue URL des Objekts auf dem Ursprungsserver weiterleiten.

  • Die neue Verteilung-URL für das Objekt. Wenn der Viewer die Anfrage mit der neuen Verteilung-URL sendet, ruft Ihre Verteilung das Objekt von dem neuen Speicherort auf Ihrem Ursprungsserver ab, speichert es am Edge-Standort zwischen und gibt das Objekt an den Viewert 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 werden bei jeder neuen Anfrage für das Objekt Gebühren für zwei Anfragen an Ihre Verteilung berechnet.

Übertragungsverschlüsselungen

Lightsail Verteilungen unterstützen nur chunked als Wert der Transfer-Encoding-Kopfzeile. Wenn Ihr Ursprungsserver Transfer-Encoding: chunked zurückgibt, sendet Ihre Verteilung das Objekt an den Client, sobald es am Edge-Standort empfangen wird, und speichert das Objekt im aufgeteilten Format für nachfolgende Anfragen zwischen.

Wenn der Viewer eine Range GET-Anfrage stellt und der Ursprungsserver Transfer-Encoding: chunked zurückgibt, gibt Ihre Verteilung 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 unterVerworfene TCP-Verbindungen.

Zusätzliche Informationen

Hier finden Sie einige Artikel, die Ihnen bei der Verwaltung von Verteilungen in Lightsail helfen: