TCP-Zurücksetzung und Leerlauftimeout für Load Balancer

Sie können Load Balancer Standard verwenden, um ein besser vorhersagbares Anwendungsverhalten für Ihre Szenarien zu erzielen, indem Sie für eine bestimmte Regel die TCP-Rücksetzung bei Leerlauf aktivieren. Das Standardverhalten von Load Balancer besteht darin, Flows ohne Rückmeldung zu verwerfen, wenn das Leerlauftimeout eines Flows erreicht ist. Durch Aktivieren der TCP-Zurücksetzung wird der Load Balancer dazu veranlasst, bei einem Leerlauftimeout bidirektionale TCP-Zurücksetzungen (TCP-Zurücksetzungspakete) zu senden, um Ihre Anwendungsendpunkte darüber zu informieren, dass während der Verbindung ein Timeout aufgetreten ist und sie nicht mehr verwendet werden kann. Die Endpunkte können dann bei Bedarf sofort eine neue Verbindung herstellen.

Diagramm zum Standardverhalten der TCP-Rücksetzung von Netzwerkknoten.

TCP-Zurücksetzung

Sie ändern dieses Standardverhalten und ermöglichen das Senden von TCP-Rücksetzungen bei Leerlauftimeout in NAT-Regeln für eingehenden Datenverkehr, Lastenausgleichsregeln und Ausgangsregeln. Wenn dies durch eine Regel aktiviert ist, sendet Load Balancer zum Zeitpunkt des Leerlauftimeouts für alle passenden Flows bidirektionale TCP-Rücksetzungen (TCP-RST-Pakete) sowohl an den Client- als auch an den Serverendpunkt.

Endpunkte, die TCP RST-Pakete empfangen, schließen den entsprechenden Socket sofort. Damit werden Endpunkte sofort darüber benachrichtigt, dass die Verbindung getrennt wurde und jegliche weitere Kommunikation über die gleiche TCP-Verbindung zu einem Fehler führt. Anwendungen können Verbindungen bereinigen, wenn der Socket geschlossen wird, und Verbindungen bei Bedarf erneut herstellen, ohne auf das Timeout der TCP-Verbindung zu warten.

In vielen Szenarien müssen mit einer TCP-Zurücksetzung weniger TCP-Keepalives (bzw. Keepalives auf der Anwendungsschicht) gesendet werden, um das Leerlauftimeout eines Flows zu aktualisieren.

Wähle zwischen TCP-Reset und Keepalives

Verwenden Sie die folgenden Kriterien, um zu entscheiden, welchen Mechanismus Ihr Szenario benötigt:

  • Aktivieren Sie den TCP-Reset, wenn Sie möchten, dass Endpunkte sofort benachrichtigt werden, dass ein Leerlauf geschlossen wird, damit Anwendungen die Verbindungen löschen und wiederherstellen können, anstatt auf ihren eigenen TCP-Timeout zu warten.
  • Verwenden Sie TCP-Keepalives, wenn Ihre Leerlaufzeiten den konfigurierbaren Bereich für Leerlauf-Timeouts überschreiten oder wenn sich Ihre Anwendung bei aktivierten TCP-Resets unerwartet verhält. Keepalives werden für mobile Anwendungen nicht empfohlen, da sie den Akku der Geräte schneller entladen.
  • Verwenden Sie Keepalives auf Anwendungsebene, wenn die Verbindung irgendwo entlang des Pfads über einen Proxy geleitet wird, da ein Proxy die TCP-Verbindung beenden kann, die durch Keepalives der Transportschicht aufrechterhalten wird.

Durch die sorgfältige Untersuchung des gesamten End-to-End-Szenarios können Sie die Vorteile des Aktivierens von TCP-Resets und der Anpassung des Idle-Timeouts ermitteln. Dann entscheiden Sie, ob weitere Schritte erforderlich sind, um das gewünschte Anwendungsverhalten sicherzustellen.

Konfigurierbares TCP-Leerlauftimeout

Azure Load Balancer Standard unterstützt für Load Balancer-Regeln und NAT-Eingangsregeln einen Timeoutbereich von 4 bis 100 Minuten. Outbound-Regeln haben einen konfigurierbaren Bereich von 4 bis 120 Minuten. Standardmäßig sind 4 Minuten für alle Regeltypen. Wenn die Dauer einer Inaktivitätsperiode den Timeoutwert überschreitet, gibt es keine Garantie dafür, dass die TCP- oder HTTP-Sitzung zwischen dem Client und Ihrem Clouddienst aufrechterhalten wird. Azure Load Balancer Basic (eingestellt) hatte eine Zeitüberschreitung von bis zu 60 Minuten.

Wenn die Verbindung geschlossen wird, erscheint in der Clientanwendung unter Umständen eine Fehlermeldung wie die folgende: „Die zugrunde liegende Verbindung wurde geschlossen: Eine Verbindung, deren Aufrechterhaltung erwartet wurde, ist vom Server geschlossen worden.“

Wenn TCP-Zurücksetzungen aktiviert sind und aus irgendeinem Grund übergangen werden, erfolgen Zurücksetzungen für alle nachfolgenden Pakete. Wenn die TCP-Zurücksetzungsoption nicht aktiviert ist, werden Pakete ohne Benachrichtigung ignoriert.

Eine gängige Methode zur Aufrechterhaltung von Verbindungen ist TCP-Keep-Alive. Dadurch bleibt die Verbindung länger aktiv. Weitere Informationen finden Sie in diesen .NET-Beispielen. Bei aktivierter Keep-Alive-Funktion werden während inaktiver Phasen Pakete über die Verbindung gesendet. Keep-Alive-Pakete sorgen dafür, dass der Wert für das Leerlauftimeout nicht erreicht und die Verbindung über einen langen Zeitraum aufrechterhalten wird.

Das in diesem Abschnitt beschriebene TCP-Keep-alive gilt nur für eingehende Verbindungen. TCP-Reset und konfigurierbarer Idle-Timeout werden separat bei ausgehenden Regeln unterstützt. Um den Verlust der Verbindung zu vermeiden, konfigurieren Sie ein TCP-Keep-Alive-Intervall, das kürzer ist als das Leerlauftimeout, oder erhöhen Sie den Leerlauftimeout-Wert. Für diese Szenarios ist Unterstützung für konfigurierbare Leerlauftimeouts verfügbar.

TCP-Keep-Alive eignet sich für Szenarien, in denen die Akkulaufzeit keine Einschränkung darstellt. Bei mobilen Anwendungen ist die Verwendung dieser Funktion hingegen nicht empfehlenswert. TCP-Keep-Alive kann bei mobilen Anwendungen zu einer schnelleren Entladung des Geräteakkus führen.

Reihenfolge der Rangfolge

Es ist wichtig zu berücksichtigen, wie sich die für verschiedene IP-Adressen festgelegten Leerlauftimeoutwerte möglicherweise gegenseitig beeinflussen können.

Eingehend

  • Wenn eine (eingehende) Lastenausgleichsregel vorhanden ist, deren Leerlauftimeout auf einen anderen Wert als das Leerlauftimeout der Front-End-IP-Adresse, auf die verwiesen wird, festgelegt ist, hat das Leerlauftimeout der Front-End-IP-Adresse des Lastenausgleichs Vorrang.
  • Wenn eine NAT-Regel für eingehenden Datenverkehr vorhanden ist, deren Leerlauftimeout auf einen anderen Wert als das Leerlauftimeout der Front-End-IP-Adresse, auf die verwiesen wird, festgelegt ist, hat das Leerlauftimeout des der Front-End-IP-Adresse des Lastenausgleichs Vorrang.

Ausgehend

  • Wenn es eine Ausgangsregel mit einem Leerlauftimeoutwert gibt, der nicht 4 Minuten ist (Timeout für ausgehende öffentliche IP-Adressen im Leerlauf), hat das Leerlauftimeout der Ausgangsregel Vorrang.
  • Da ein NAT-Gateway immer Vorrang vor Ausgangsregeln für den Lastenausgleich hat (und vor öffentlichen IP-Adressen, die VMs direkt zugewiesen sind), wird der Leerlauftimeoutwert verwendet, der dem NAT-Gateway zugewiesen ist. (Ebenso wird der Timeoutwert für öffentliche IP-Adressen im Leerlauf von 4 Minuten für alle IP-Adressen, die dem NAT-Gateway zugewiesen sind, nicht berücksichtigt.)

Einschränkungen

Diese Einschränkungen gelten für TCP-Reset und Idle-Timeout auf Azure Load Balancer:

  • Der TCP-Reset wird nur während einer TCP-Verbindung im ETABLIERTEN Zustand gesendet.
  • Leerlauftimeout wird für UDP-Lastverteilungsregeln nicht unterstützt.
  • TCP-Reset wird für Regeln für interne Load-Balancer-HA-Ports (Hochverfügbarkeitsports) nicht unterstützt, wenn sich eine virtuelle Netzwerkappliance (NVA) im Pfad befindet. Verwenden Sie als Problemumgehung eine ausgehende Regel mit TCP-Reset von der virtuellen Netzwerkappliance.
  • TCP-Leerlauftimeout wird für interne Load-Balancer-HA-Portregeln nicht unterstützt, wenn eine benutzerdefinierte Route (UDR) den Datenverkehr an den internen Load Balancer weiterleitet.

Nächste Schritte

  • Last updated on