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.
Bearbeiten Sie die Attribute für Ihren Application Load Balancer
Nachdem Sie einen Application Load Balancer erstellt haben, können Sie seine Attribute bearbeiten.
Load Balancer-Attribute
Zeitlimit für Verbindungsleerlauf
Der Timeout im Leerlauf der Verbindung ist der Zeitraum, in dem 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 das Hochladen von Dateien genügend Zeit zum Abschluss haben, senden Sie mindestens 1 Byte an Daten, bevor die Zeitüberschreitung im Leerlauf abläuft, und verlängern Sie die Zeitüberschreitung im Leerlauf 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 könnte der Load Balancer, wenn die Anwendung die TCP-Verbindung zum Load Balancer nicht ordnungsgemäß schließt, eine Anforderung an die Anwendung senden, bevor er das Paket empfängt, um anzugeben, dass die Verbindung geschlossen ist. Wenn dies der Fall ist, sendet der Load Balancer einen HTTP-502-Bad-Gateway-Fehler an den Client.
Application Load Balancer unterstützen keine PING-Frames. HTTP/2 Diese setzen den Timeout im Leerlauf der Verbindung nicht zurück.
Elastic Load Balancing setzt den Timeoutwert für die Leerlaufzeit für Ihren Load Balancer standardmäßig auf 60 Sekunden.
Keepalive-Dauer des HTTP-Clients
Die Keepalive-Dauer des HTTP-Clients ist die maximale Zeitdauer, für die ein Application Load Balancer eine persistente HTTP-Verbindung zu einem Client aufrechterhält. Nach Ablauf der konfigurierten Keepalive-Dauer des HTTP-Clients akzeptiert der Application Load Balancer eine weitere Anfrage und gibt dann eine Antwort zurück, die die Verbindung ordnungsgemäß schließt.
Die Art der vom Load Balancer gesendeten Antwort hängt von der HTTP-Version ab, die von der 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: closeFür Clients, die über eine Verbindung hergestellt HTTP/2 wurden, sendet der Load Balancer einen Frame.
GOAWAY
Standardmäßig legt Application Load Balancer den Wert für die Keepalive-Dauer des HTTP-Clients für Load Balancer auf 3600 Sekunden oder 1 Stunde fest. Die Keepalive-Dauer des HTTP-Clients kann nicht ausgeschaltet oder auf einen Wert unter das Minimum von 60 Sekunden eingestellt werden. Sie können die Keepalive-Dauer des HTTP-Clients jedoch auf maximal 604800 Sekunden oder 7 Tage erhöhen. Ein Application Load Balancer beginnt mit der Keepalive-Dauer des HTTP-Clients, wenn zum ersten Mal eine HTTP-Verbindung zu einem Client hergestellt wird. Die Dauer wird fortgesetzt, wenn kein Verkehr stattfindet, und wird erst zurückgesetzt, wenn eine neue Verbindung hergestellt wird.
Wenn der Load Balancer-Verkehr mithilfe von zonaler Verschiebung oder zonaler Autoshift von einer beeinträchtigten Availability Zone wegverlagert wird, senden Clients mit bestehenden offenen Verbindungen möglicherweise weiterhin Anfragen an den beeinträchtigten Standort, bis die Clients erneut eine Verbindung herstellen. Um eine schnellere Wiederherstellung zu ermöglichen, sollten Sie erwägen, einen niedrigeren Wert für die Keepalive-Dauer festzulegen, um die Zeit zu begrenzen, die Clients mit einem Load Balancer verbunden bleiben. Weitere Informationen finden Sie im Amazon Application Recovery Controller (ARC) Developer Guide im Amazon Application Recovery Controller (ARC) Developer Guide unter Begrenzen Sie die Zeit, in der Kunden mit Ihren Endpunkten verbunden bleiben.
Anmerkung
Wenn der Load Balancer den IP-Adresstyp Ihres Application Load Balancers auf umstelltdualstack-without-public-ipv4, wartet der Load Balancer darauf, dass alle aktiven Verbindungen abgeschlossen sind. Um die Zeit zu verkürzen, die für die Umstellung des IP-Adresstyps für Ihren Application Load Balancer benötigt wird, sollten Sie erwägen, die Keepalive-Dauer des HTTP-Clients zu verkürzen.
Der Application Load Balancer weist während der ersten Verbindung den Wert für die Keepalive-Dauer des HTTP-Clients zu. Wenn Sie die Keepalive-Dauer des HTTP-Clients aktualisieren, kann dies zu gleichzeitigen Verbindungen mit unterschiedlichen Werten für die Keepalive-Dauer des HTTP-Clients führen. Bestehende Verbindungen behalten den Wert für die Keepalive-Dauer des HTTP-Clients bei, der bei der ersten Verbindung angewendet wurde. Neue Verbindungen erhalten den aktualisierten Wert für die Keepalive-Dauer des HTTP-Clients.
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.
Desynchroner Mitigationsmodus
Der desynchrone Mitigationsmodus schützt Ihre Anwendung vor Problemen aufgrund von HTTP-Desync-Angriffen. 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 „Defensiv“, der eine dauerhafte Abwehr gegen HTTP-Desync-Angriffe bietet und gleichzeitig die Verfügbarkeit Ihrer Anwendung gewährleistet. Sie können in den Modus „Am strengsten“ wechseln, um sicherzustellen, dass Ihre Anwendung nur Anforderungen empfängt, die RFC 7230
Die Bibliothek „http_desync_guardian“ analysiert HTTP-Anforderungen, um HTTP-Desync-Angriffe zu verhindern. Weitere Informationen finden Sie unter HTTP Desync Guardian
Klassifizierungen
Diese Klassifizierungen lauten wie folgt:
-
Konform – Die Anforderung entspricht RFC 7230 und stellt keine bekannten Sicherheitsbedrohungen dar.
-
Akzeptabel – Die Anforderung entspricht nicht RFC 7230, stellt jedoch keine bekannten Sicherheitsbedrohungen dar.
-
Mehrdeutig – Die Anforderung entspricht nicht RFC 7230, stellt jedoch ein Risiko dar, da verschiedene Webserver und Proxys sie unterschiedlich behandeln könnten.
-
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 Anforderung nicht RFC 7230 entspricht, erhöht der Load Balancer die DesyncMitigationMode_NonCompliant_Request_Count-Metrik. 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.
Beibehalten der Host-Header
Wenn Sie das Attribut Beibehalten des Host-Headers aktivieren, behält Application Load Balancer den Host-Header der HTTP-Anforderung 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. Zum Beispiel würde der Host-Header in der HTTP-Anforderung mit Host:
www.example.com in Host: www.example.com:8080 geändert werden, wenn der Listener-Port ein nicht standardmäßiger Port ist, wie z. B. 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 Balancer die Host-Header in der HTTP-Anforderung auf der Grundlage des Listener-Ports behandeln.
| Listener-Port | Beispielanforderung | Host-Header der Anforderung | „Beibehaltung des Host-Headers“ ist deaktiviert (Standardverhalten) | „Beibehaltung des Host-Headers“ ist aktiviert |
|---|---|---|---|---|
| Die Anfrage wird über den HTTP/HTTPS Standard-Listener gesendet. | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com | example.com |
| Die Anfrage wird auf dem Standard-HTTP-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 an einem 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 |
