In den meisten Load-Balancing-Designs wird das Verbindungslimit als einzelnes Feld behandelt: Wie viele Verbindungen können gleichzeitig offen sein? Dieses Modell ist unvollständig. Zehntausend ausstehende Keep-Alive-Verbindungen können günstig sein, während 1.000 gleichzeitige neue SSL-Handshakes die Backend-CPU schnell erschöpfen können. Dieselbe Zahl erzeugt je nach Traffic-Typ völlig unterschiedliche Kosten.
Verbindungsanzahl und Verbindungsrate sind ebenfalls nicht dasselbe. „Bis zu 20.000 Verbindungen können gleichzeitig offen sein“ ist eine Kapazitätsobergrenze; „bis zu 10.000 neue Verbindungen können pro Sekunde geöffnet werden“ ist Burst- und Verbindungssturm-Kontrolle. Systeme, die diese beiden Werte nicht trennen, schränken entweder legitimen Nutzerverkehr unnötig ein oder schützen das Backend nicht vor einer plötzlichen Angriffswelle.
TLS-Traffic muss separat betrachtet werden. SSL/TLS-Handshake-Operationen sind CPU-intensiv, und wenn sie unter demselben Limit wie plain HTTP-Verbindungen verwaltet werden, bleibt die tatsächliche Last unsichtbar. Besonders bei öffentlichen Web-Diensten, API-Gateways und Kampagnenzeiträumen hält eine unabhängige Begrenzung der Handshake-Rate den Backend-CPU-Verbrauch unter Kontrolle.
Queue-Verhalten ist oft ebenfalls undurchsichtig. Wenn ein Limit überschritten wird: Wird die Verbindung still verworfen, läuft sie in einen Timeout, wartet sie in einer Queue, oder erhält der Client ein sauberes 503? Ohne Sichtbarkeit in dieses Verhalten ist die Root Cause bei einem Vorfall nicht klar — Benutzer sehen einen Timeout, und das Operations-Team identifiziert den eigentlichen Grund zu spät.
TR7 Pool-Verbindungslimits schützen Backend-Dienste durch vorhersehbares Kapazitätsmanagement statt stillem Overload, indem sie Gesamtverbindungen, Verbindungsrate, Sitzungsrate, SSL-Last, Pufferbudget und Retry-Verhalten unabhängig voneinander steuern.
TR7 verwaltet Pool-Kapazität nicht mit einem einzigen Feld, sondern mit einer Profilstruktur, die über Verbindungs-, Raten-, SSL-, Retry- und Puffer-Achsen aufgebaut ist.
Ein einzelnes Profil definiert maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate und maxBufferSize. Dadurch können die Verbindungs-, Raten-, TLS- und Speicherlimits des Backends unabhängig voneinander eingestellt werden.
Da TLS-Handshakes CPU-intensiv sind, verwaltet TR7 maxSslConn und maxSslRate als separate Werte. Diese Trennung verhindert, dass ein Handshake-Sturm das Backend erschöpft, selbst wenn die Gesamtverbindungsanzahl niedrig erscheint.
Ein Limit-Profil wird mit einem eindeutigen Namen definiert und kann an verschiedene Service-Pools angehängt werden. Produktions-, Staging-, Canary- oder per-Tenant-Kapazitätsrichtlinien können alle mit einem einzigen Profilmodell verwaltet werden.
maxRetries definiert, wie oft eine Verbindung zum Backend bei vorübergehenden Fehlern wiederholt wird. maxBufferSize steuert den Speicherverbrauch pro Verbindung in Szenarien mit langsamen Clients oder langsamen Backends.
TR7 Pool-Verbindungslimits schränken Backend-Dienste auf kontrollierte Weise gegen Verbindungsstürme, TLS-Last, Sitzungsbursts und Speicherdruck ein.
maxConn setzt die Obergrenze für gleichzeitig offene Verbindungen pro Pool mit einem Standardwert von 20.000 und einer Obergrenze von 1.000.000. Dieser Wert kodiert auf ADC-Ebene genau, wie viele Verbindungen das Backend gleichzeitig tragen kann. Wenn das Limit erreicht wird, unterliegen neue Verbindungen dem Queue-Verhalten oder einem Ablehnungsfluss.
maxConnRate begrenzt die Anzahl neuer TCP-Verbindungen, die pro Sekunde geöffnet werden können, mit einem Standardwert von 10.000. Im Gegensatz zu Gesamtverbindungen steuert dieses Feld die Rate, mit der Verbindungen geöffnet werden. Es verhindert, dass das Backend in einem einzigen Burst bei Verbindungsstürmen, aggressivem Scanning oder fehlerhaften Load-Tests überwältigt wird. Es ist eine kritische Burst-Schutzsteuerung für öffentlich zugängliche Dienste.
maxSessRate setzt eine Obergrenze pro Sekunde für neue Sitzungen mit einem Standardwert von 10.000. Die Wiederverwendung von Keep-Alive-Verbindungen und das wiederholte Öffnen neuer Sitzungen verursachen unterschiedliche Kosten. Diese Unterscheidung ist besonders nützlich gegen Cookie-basierte Sitzungsöffnungsstürme oder Bot-Verhalten, das Anwendungssitzungen erschöpft. Traffic wird nicht nur durch Verbindungsanzahl, sondern auch durch die Rate der Sitzungserzeugung eingeschränkt.
rateLimitSessions bietet eine separate Sekundensteuerung für die Zuweisung neuer Verbindungsslots mit einem Standardwert von 5.000. Es wird verwendet, um das Annahmeverhalten neuer Verbindungen mit feinerer Granularität zu verwalten. Es hilft dem Pool, bei plötzlichen Verbindungsbursts mit kontrollierter Kapazität voranzuschreiten. Die Beziehung zwischen Backend-Kapazität und ADC-Annahmerate wird präziser eingestellt.
maxSslConn definiert ein separates Limit für gleichzeitige SSL/TLS-Verbindungen mit einem Standardwert von 5.000. TLS-Verbindungen müssen aufgrund von CPU-, Speicher- und kryptografischen Verarbeitungskosten anders behandelt werden als Plain-Verbindungen. Dieses Limit spiegelt die tatsächliche Backend-Kapazität auf der TLS-Seite genauer wider. Es vereinfacht die SSL-Kapazitätsplanung, insbesondere für öffentliche Web- und API-Traffic-Szenarien.
maxSslRate begrenzt die Anzahl der SSL/TLS-Handshakes, die pro Sekunde initiiert werden können, mit einem Standardwert von 2.000. Handshake-Operationen können je nach RSA- oder ECDSA-Nutzung, Schlüsselgröße und CPU-Kapazität hohe Kosten verursachen. Dieses Feld verhindert, dass TLS-Handshake-Stürme die Backend-CPU erschöpfen. Es bietet sinnvolleren Schutz als ein Plain-Verbindungslimit bei DDoS- oder aggressivem Bot-Traffic.
maxBufferSize legt die verfügbare Puffergröße pro Verbindung in KB fest, mit einem Standardwert von 128 KB und einem Bereich von 16–256 KB. Der Speicherverbrauch wird durch diesen Wert für langsame Clients, langsame Leser oder Anfragen mit großen Inhalten gesteuert. Das Feld bietet operativen Schutz gegen Slowloris-ähnliches Verhalten und Speicherdruck.
maxRetries definiert, wie oft die Backend-Verbindung bei einem Fehler wiederholt wird, mit einem Standardwert von 3 und einer Obergrenze von 1.000. Ein niedrigerer Wert ermöglicht schnelle Fehlerrückgabe; ein höherer Wert kann die Resilienz bei vorübergehenden Netzwerkschwankungen verbessern. Übermäßige Retries können jedoch ein bereits überlastetes Backend zusätzlich belasten und müssen sorgfältig gewählt werden.
Ein Limit-Profil wird mit einem eindeutigen Namen definiert und kann mehreren Pools zugewiesen werden. Das Bearbeiten eines einzelnen Profils ändert das Verbindungsverhalten aller daran gebundenen Pools. Dieses Modell reduziert den Aufwand, jeden Service-Pool einzeln zu konfigurieren. Produktions-, Test-, Kampagnen- oder per-Tenant-Profile können jeweils unabhängig verwaltet werden.
Wenn ein Limit überschritten wird, können Verbindungen bis zu einer definierten Tiefe in einer Queue warten. Wenn die Queue voll ist, erhält der Client einen klaren Fehler statt eines stillen Timeouts. Operations-Teams können schneller erkennen, wenn eine Kapazitätsobergrenze erreicht wird, durch explizite Fehlersignale wie 503. Das Problem wird zu einem messbaren Kapazitätsereignis statt einer unklaren benutzerseitigen Wartezeit.
Pool-Verbindungslimits müssen gemeinsam mit Standardwerten, Zero-Deaktivierungsverhalten, globaler/Frontend/Pool-Generierung und Speicherbudget geplant werden.
Das Standardmodell verwendet maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K und maxBufferSize 128 KB. Dies sind Ausgangspunkte. Die tatsächliche Feinabstimmung muss entsprechend der Backend-Kapazität, TLS-Kosten und des Traffic-Musters erfolgen.
Alle Limit-Felder akzeptieren 0 als ihren Mindestwert. Dies kann für Szenarien verwendet werden, in denen eine bestimmte Steuerung deaktiviert werden soll oder unbegrenzt verhalten soll. In der Produktion sollte ein Wert von 0 bewusst gesetzt werden — andernfalls wird der erwartete Schutz entfernt.
maxConn kann auf bis zu 1.000.000 eingestellt werden. Dies bietet Flexibilität für sehr hochdichte Keep-Alive- oder Verbindungspool-Szenarien. Dennoch wird die tatsächliche Kapazität nicht allein durch diese Zahl bestimmt — Datei-Deskriptoren, Speicher, CPU, TLS-Kosten und Backend-Limits müssen alle zusammen berücksichtigt werden.
maxBufferSize beeinflusst direkt den Speicherverbrauch pro Verbindung. Ein niedrigerer Wert erhöht den Speicherschutz, kann aber bei Anwendungen mit großen Inhalten oder langsamen Streams Kompatibilitätsprobleme verursachen. Der Bereich von 16–256 KB ermöglicht einen kontrollierten Kompromiss zwischen Sicherheit und Anwendungsanforderungen.
Profilwerte werden über globale, Frontend- und Pool-Ebene-Verbindungsverhalten hinweg gespiegelt. Diese Trennung ermöglicht es, die Gesamtgerätekapazität und die Kapazität eines bestimmten Pools unabhängig voneinander zu verwalten. Bei großen Deployments dürfen Gesamt-ADC-Kapazität und Einzelpool-Kapazität nicht verwechselt werden.
SSL-Verbindungslimits sind mit dem TLS-Bind-Verhalten verknüpft. Werte wie maxSslConn ermöglichen es, TLS-Verbindungen separat von Plain-Verbindungen zu verwalten. Dies ist wichtig für den Schutz des CPU-Budgets bei öffentlich zugänglichen Diensten mit hohem TLS-Traffic.
Eine E-Commerce-Plattform, die an normalen Tagen mit einem 20K-Verbindungsprofil läuft, kann während eines Kampagnenzeitraums zu einem höheren Verbindungsprofil wechseln. Derselbe Pool wird beibehalten; nur das Limit-Profil wird geändert, um den Kampagnen-Traffic zu bewältigen.
Eine Bank kann auf ihrem internen API-Pool eine hohe Gesamtverbindungsanzahl erlauben, während sie die SSL-Verbindungs- und Handshake-Rate enger hält. Diese Struktur kontrolliert TLS-Kosten und schützt die Backend-CPU vor plötzlicher Handshake-Last.
Bei einer internetseitigen Webanwendung können Bot-Scanning oder fehlerhafte Clients in kurzer Zeit eine große Anzahl von Verbindungen öffnen. TR7 begrenzt die Rate neuer Verbindungen durch maxConnRate und rateLimitSessions und schützt das Backend vor einem Verbindungssturm.
Langsam lesende Clients können den Pufferverbrauch pro Verbindung erhöhen. TR7 begrenzt den Speicherverbrauch dieses Traffics mit einem niedrigeren maxBufferSize-Profil und ermöglicht es anderen Benutzern, weiterhin den Dienst zu empfangen.
8-achsige Verbindungslimit-Profile für Verbindungsstürme, TLS-Last und langsamen Client-Speicherdruck. Lassen Sie uns ein Live-Setup auf Ihren eigenen Diensten durchgehen.