Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Attribute für Ihren Application Load Balancer bearbeiten
Nachdem Sie einen Application Load Balancer erstellt haben, können Sie seine Attribute bearbeiten.
Load Balancer-Attribute
Zeitlimit für Verbindungsleerlauf
Das Timeout bei der Verbindungsinaktivität ist der Zeitraum, für den eine bestehende Client- oder Zielverbindung inaktiv bleiben kann, ohne dass Daten gesendet oder empfangen werden, bevor der Load Balancer die Verbindung schließt.
Um sicherzustellen, dass langwierige Vorgänge wie Datei-Uploads rechtzeitig abgeschlossen werden können, senden Sie vor Ablauf jedes Leerlauf-Timeouts mindestens 1 Byte an Daten und erhöhen Sie die Dauer des Leerlauf-Timeouts nach Bedarf. Wir empfehlen außerdem, das Leerlaufzeitlimit für Ihre Anwendung auf einen höheren Wert als das Leerlaufzeitlimit für den Load Balancer festzulegen. Andernfalls, wenn die Anwendung die TCP Verbindung zum Load Balancer fehlerhaft schließt, sendet der Load Balancer möglicherweise eine Anfrage an die Anwendung, bevor sie das Paket empfängt, das angibt, dass die Verbindung geschlossen ist. Wenn dies der Fall ist, sendet der Load Balancer einen HTTP 502 Bad Gateway-Fehler an den Client.
Standardmäßig legt Elastic Load Balancing den Leerlauf-Timeout-Wert für Ihren Load Balancer auf 60 Sekunden oder 1 Minute fest. Gehen Sie folgendermaßen vor, um einen anderen Leerlauf-Timeoutwert festzulegen.
Um den Wert für das Leerlauf-Timeout der Verbindung mithilfe der Konsole zu aktualisieren
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Wählen Sie im Navigationsbereich Load Balancers aus.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Geben Sie unter Verkehrskonfiguration einen Wert für das Timeout bei Verbindungsinaktivität ein. Der gültige Bereich liegt zwischen 1 und 4000 Sekunden.
-
Wählen Sie Änderungen speichern.
Um den Wert für das Leerlauf-Timeout mit dem AWS CLI
Verwenden Sie den modify-load-balancer-attributesBefehl mit dem idle_timeout.timeout_seconds
Attribut.
HTTPDauer des Client-Keepalive-Systems
Die HTTP Client-Keepalive-Dauer ist die maximale Zeitdauer, für die ein Application Load Balancer eine dauerhafte HTTP Verbindung zu einem Client aufrechterhält. Nach Ablauf der konfigurierten HTTP Client-Keepalive-Dauer akzeptiert der Application Load Balancer eine weitere Anfrage und gibt dann eine Antwort zurück, mit der die Verbindung ordnungsgemäß geschlossen wird.
Die Art der Antwort, die vom Load Balancer gesendet wird, hängt von der Version ab, die von der HTTP Client-Verbindung verwendet wird.
Für Clients, die über HTTP 1.x verbunden sind, sendet der Load Balancer einen HTTP Header, der das Feld enthält.
Connection: close
Für Clients, die mit HTTP /2 verbunden sind, sendet der Load Balancer einen Frame.
GOAWAY
Standardmäßig legt Application Load Balancer den Wert für die HTTP Client-Keepalive-Dauer für Load Balancer auf 3600 Sekunden oder 1 Stunde fest. Die HTTP Client-Keepalive-Dauer kann nicht ausgeschaltet oder unter die Mindestdauer von 60 Sekunden gesetzt werden. Sie können die Keepalive-Dauer des HTTP Clients jedoch auf maximal 604.800 Sekunden oder 7 Tage erhöhen. Ein Application Load Balancer beginnt mit der Dauer der HTTP Client-Keepalive-Dauer, wenn zum ersten HTTP Mal eine Verbindung zu einem Client hergestellt wird. Die Dauer wird fortgesetzt, wenn kein Verkehr vorhanden ist, und wird erst zurückgesetzt, wenn eine neue Verbindung hergestellt ist.
Wenn der Load Balancer-Verkehr mithilfe von Zonal Shift oder Zonal Autoshift von einer beeinträchtigten Availability Zone weg verlagert wird, stellen Clients mit bestehenden offenen Verbindungen möglicherweise weiterhin Anfragen an den beeinträchtigten Standort, bis die Clients wieder eine Verbindung herstellen. Um eine schnellere Wiederherstellung zu unterstützen, sollten Sie einen niedrigeren Wert für die Keepalive-Dauer festlegen, um die Dauer zu begrenzen, für die Clients mit einem Load Balancer verbunden bleiben. Weitere Informationen finden Sie unter Beschränken Sie die Zeit, in der Clients mit Ihren Endpunkten verbunden bleiben, im Amazon Application Recovery Controller (ARC) Developer Guide.
Anmerkung
Wenn der Load Balancer den IP-Adresstyp Ihres Application Load Balancer auf umstelltdualstack-without-public-ipv4
, wartet der Load Balancer, bis alle aktiven Verbindungen abgeschlossen sind. Um den Zeitaufwand für das Wechseln des IP-Adresstyps für Ihren Application Load Balancer zu verringern, sollten Sie die Dauer der HTTP Client-Keepalive-Dauer verringern.
Der Application Load Balancer weist dem HTTP Client bei der ersten Verbindung einen Wert für die Keepalive-Dauer zu. Wenn Sie die HTTP Client-Keepalive-Dauer aktualisieren, kann dies zu gleichzeitigen Verbindungen mit unterschiedlichen Werten für die HTTP Client-Keepalive-Dauer führen. Bei bestehenden Verbindungen wird der Wert für die Keepalive-Dauer des HTTP Clients beibehalten, der bei der ersten Verbindung angewendet wurde. Neue Verbindungen erhalten den aktualisierten Wert für die Keepalive-Dauer des HTTP Clients.
Um den Wert für die Keepalive-Dauer des Clients mithilfe der Konsole zu aktualisieren
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Wählen Sie im Navigationsbereich Load Balancers aus.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Geben Sie unter Datenverkehrskonfiguration einen Wert für die Dauer der HTTPClient-Keepalive-Dauer ein. Der gültige Bereich liegt zwischen 60 und 604800 Sekunden.
-
Wählen Sie Änderungen speichern.
Um den Wert für die Keepalive-Dauer des Clients zu aktualisieren, verwenden Sie AWS CLI
Verwenden Sie den modify-load-balancer-attributesBefehl mit dem client_keep_alive.seconds
Attribut.
Löschschutz
Um zu verhindern, dass der Load Balancer versehentlich gelöscht wird, können Sie den Löschschutz aktivieren. Standardmäßig ist der Löschschutz für Ihren Load Balancer deaktiviert.
Wenn Sie den Löschschutz für Ihren Load Balancer aktivieren, müssen Sie ihn deaktivieren, bevor Sie den Load Balancer löschen.
So aktivieren Sie mithilfe der Konsole den Löschschutz:
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Wählen Sie im Navigationsbereich Load Balancers aus.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Aktivieren Sie unter Konfiguration die Option Löschschutz.
-
Wählen Sie Änderungen speichern.
So deaktivieren Sie mithilfe der Konsole den Löschschutz:
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Wählen Sie im Navigationsbereich Load Balancers aus.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Schalten Sie auf der Seite Konfiguration den Löschschutz aus.
-
Wählen Sie Änderungen speichern.
Um den Löschschutz zu aktivieren oder zu deaktivieren, verwenden Sie AWS CLI
Verwenden Sie den modify-load-balancer-attributesBefehl mit dem deletion_protection.enabled
Attribut.
Desynchroner Mitigationsmodus
Der Desync-Minimationsmodus schützt Ihre Anwendung vor Problemen aufgrund von Desync. HTTP Der Load Balancer klassifiziert jede Anforderung anhand ihrer Bedrohungsstufe, lässt sichere Anforderungen zu und mindert dann das Risiko gemäß dem von Ihnen angegebenen Mitigationsmodus. Die desynchronen Mitigationsmodi lauten „Überwachen“, „Defensiv“ und „Am strengsten“. Der Standardmodus ist der Defensivmodus, der eine dauerhafte Abwehr gegen HTTP Desynchronisierung bietet und gleichzeitig die Verfügbarkeit Ihrer Anwendung gewährleistet. Sie können in den strengsten Modus wechseln, um sicherzustellen, dass Ihre Anwendung nur Anfragen empfängt, die 7230 entsprechen. RFC
Die Bibliothek http_desync_guardian analysiert Anfragen, um Desync-Angriffe zu verhindern. HTTP HTTP Weitere Informationen finden Sie unter Desync Guardian on. HTTP
Klassifizierungen
Diese Klassifizierungen lauten wie folgt:
-
Konform — Die Anfrage entspricht RFC 7230 und stellt keine bekannten Sicherheitsbedrohungen dar.
-
Akzeptabel — Die Anfrage entspricht nicht der Norm RFC 7230, stellt jedoch keine bekannten Sicherheitsbedrohungen dar.
-
Mehrdeutig — Die Anfrage entspricht nicht der Norm RFC 7230, stellt jedoch ein Risiko dar, da sie von verschiedenen Webservern und Proxys unterschiedlich behandelt werden kann.
-
Schwerwiegend – Die Anforderung stellt ein hohes Sicherheitsrisiko dar. Der Load Balancer blockiert die Anforderung, sendet dem Client eine 400-Antwort und schließt die Client-Verbindung.
Wenn eine Anfrage nicht RFC 7230 entspricht, erhöht der Load Balancer die Metrik. DesyncMitigationMode_NonCompliant_Request_Count
Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.
Die Klassifizierung für jede Anforderung ist in den Load-Balancer-Zugriffsprotokollen enthalten. Wenn die Anforderung nicht entspricht, enthalten die Zugriffsprotokolle einen Ursachencode für die Klassifizierung. Weitere Informationen finden Sie unter Gründe für die Klassifizierung.
Modi
In der folgenden Tabelle wird beschrieben, wie Application Load Balancer Anforderungen basierend auf Modus und Klassifizierung behandeln.
Klassifizierung | Modus „Überwachen“ | Modus „Defensiv“ | Modus „Am strengsten“ |
---|---|---|---|
Konform | Zulässig | Zulässig | Zulässig |
Akzeptabel | Zulässig | Zulässig | Blocked |
Mehrdeutig | Zulässig | Zulässig¹ | Blocked |
Schwerwiegend | Zulässig | Blocked | Blocked |
¹ Leitet die Anforderungen weiter, schließt aber die Client- und Zielverbindungen. Es können zusätzliche Gebühren anfallen, wenn Ihr Load Balancer im Modus „Defensiv“ eine große Anzahl von mehrdeutigen Anforderungen empfängt. Dies liegt daran, dass die erhöhte Anzahl neuer Verbindungen pro Sekunde dazu beiträgt, dass die Load Balancer-Kapazitätseinheiten (LCU) pro Stunde verwendet werden. Sie können die NewConnectionCount
-Metrik verwenden, um zu vergleichen, wie Ihr Load Balancer im Modus „Überwachen“ und im Modus „Defensiv“ neue Verbindungen herstellt.
So aktualisieren Sie den desynchronen Mitigationsmodus über die Konsole
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Wählen Sie im Navigationsbereich Load Balancers aus.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Wählen Sie unter Paketverarbeitung für Desynchroner Mitigationsmodus die Option Defensiv, Am strengsten oder Überwachen aus.
-
Wählen Sie Änderungen speichern.
Um den Desync-Minimationsmodus zu aktualisieren, verwenden Sie AWS CLI
Verwenden Sie den modify-load-balancer-attributesBefehl, wobei das routing.http.desync_mitigation_mode
Attribut aufmonitor
, defensive
oder gesetzt ist. strictest
Beibehalten der Host-Header
Wenn Sie das Host-Header-Attribut beibehalten aktivieren, behält der Application Load Balancer den Host
Header in der HTTP Anfrage bei und sendet den Header ohne Änderung an Ziele. Wenn der Application Load Balancer mehrere Host
-Header empfängt, behält er sie alle bei. Listener-Regeln werden nur auf den ersten empfangenen Host
-Header angewendet.
Wenn das Attribut Beibehalten des Host-Headers nicht aktiviert ist, ändert der Application Load Balancer den Host
-Header standardmäßig wie folgt:
Wenn „Beibehalten des Host-Headers“ nicht aktiviert ist und der Listener-Port kein Standardport ist: Wenn die Standardports (Port 80 oder 443) nicht verwendet werden, hängen wir die Portnummer an den Host-Header an, sofern sie nicht bereits vom Client hinzugefügt wurde. Beispielsweise Host:
www.example.com
würde der Host
Header in der HTTP Anfrage mit geändert werdenHost: www.example.com:8080
, wenn es sich bei dem Listener-Port um einen nicht standardmäßigen Port handelt, wie z. 8080
Wenn „Beibehalten des Host-Headers“ nicht aktiviert ist und der Listener-Port ein Standardport ist (Port 80 oder 443): Bei Standard-Listener-Ports (entweder Port 80 oder 443) fügen wir die Portnummer nicht an den ausgehenden Host-Header an. Jede Portnummer, die sich bereits im eingehenden Host-Header befand, wird entfernt.
Die folgende Tabelle zeigt weitere Beispiele dafür, wie Application Load Balancers Host-Header in der HTTP Anfrage basierend auf dem Listener-Port behandeln.
Listener-Port | Beispielanforderung | Host-Header der Anforderung | „Beibehaltung des Host-Headers“ ist deaktiviert (Standardverhalten) | „Beibehaltung des Host-Headers“ ist aktiviert |
---|---|---|---|---|
Die Anfrage wird standardmäßig HTTP mit dem /Listener gesendet. HTTPS | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com | example.com |
Die Anfrage wird über den HTTP Standard-Listener gesendet und der Host-Header hat einen Port (z. B. 80 oder 443). | GET /index.html HTTP/1.1 Host: example.com:80 |
example.com:80 | example.com | example.com:80 |
Die Anforderung hat einen absoluten Pfad. | GET https://dns_name/index.html HTTP/1.1 Host:
example.com |
example.com | dns_name | example.com |
Die Anfrage wird über einen nicht standardmäßigen Listener-Port gesendet (z. B. 8080) | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com:8080 | example.com |
Die Anforderung wird über einen nicht standardmäßigen Listener-Port gesendet und der Host-Header enthält einen Port (z. B. 8080). | GET /index.html HTTP/1.1 Host: example.com:8080 |
example.com:8080 | example.com:8080 | example.com:8080 |
Um die Aufbewahrung von Host-Headern mithilfe der Konsole zu aktivieren
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/
. -
Klicken Sie im Navigationsbereich auf Load Balancers.
-
Wählen Sie den Load Balancer aus.
-
Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.
-
Aktivieren Sie unter Paketverarbeitung die Option Beibehaltung des Host-Headers.
-
Wählen Sie Änderungen speichern.
Um die Aufbewahrung von Host-Headern zu aktivieren, verwenden Sie AWS CLI
Verwenden Sie den modify-load-balancer-attributesBefehl, bei dem das routing.http.preserve_host_header.enabled
Attribut auf gesetzt isttrue
.