Bei modernen Anwendungen werden Kapazitätsprobleme nicht allein durch die Anfragezahl gemessen. Große Datei-Downloads, Video-Streaming, API-Exporte, Backup-Traffic oder bot-gesteuerte Massendaten-Pulls können hohe Bandbreite selbst bei niedrigen Anfrageraten verbrauchen. In diesen Fällen ist ein Anfrage-Rate-Limit allein nicht ausreichend.
In Multi-Mandanten-Umgebungen wird das Problem sichtbarer. Wenn ein Mandant eine umfangreiche Datenübertragung durchführt, kann die Latenz für andere Mandanten zunehmen. Ohne eine Kapazitätsgrenze zwischen Kunden, die denselben vService nutzen, kann eine Fair-Use-Richtlinie technisch nicht durchgesetzt werden.
Konventionelles Traffic-Shaping erfordert typischerweise komplexe Queuing- und Klassen-Strukturen auf Netzwerkebene. Dieses Modell ist leistungsstark, aber das direkte Arbeiten mit L7-Signalen wie Pfad, Mandant, Benutzer, JWT-Claims oder Quell-IP auf der Anwendungslieferungsschicht ist schwierig. Debug und Change-Management für Betriebsteams wird ebenfalls schwerer.
Der richtige Ansatz besteht darin, eine verbindungs- und schlüsselbasierte Bandbreitengrenze auf ADC-Ebene anzuwenden. Verschiedene Limits sollten für einen vService, Benutzer, Mandanten oder riskante Verkehrsgruppe definierbar sein, und die Upload- und Download-Richtungen sollten unabhängig verwaltbar sein.
TR7 Traffic-Shaping und QoS pro vService steuert den Bandbreitenverbrauch auf der Anwendungslieferungsschicht mit Stream-, Per-Key- und Shared-Modi.
TR7 wendet Bandbreitenkontrolle als Drei-Modus-Richtlinie über vService, Verkehrsschlüssel und Hochverfügbarkeitssharing an.
Upload-Traffic von Clients zum Backend und Download-Traffic vom Backend zu Clients können für jeden vService separat begrenzt werden. Dies stellt die Anwendungskapazität unter Service-Level-Kontrolle.
Im Stream-Modus operiert jede Verbindung unter ihrer eigenen Bandbreitengrenze. Der Ressourcenverbrauch einer einzelnen Verbindung kann bei langandauernden Downloads, Uploads oder WebSocket-ähnlichen Streams begrenzt werden.
Im Per-Key-Modus wird das Limit gemäß einem durch einen FX-Ausdruck erzeugten Schlüssel angewendet. Quell-IP, Benutzer, Mandanten-ID oder ein JWT-Claim-Wert können alle als Bandbreitenschlüssel dienen.
Im Shared-Modus ist das Bandbreitenbudget in einem Zwei-Knoten-Setup nicht auf ein einzelnes Gerät beschränkt. Ein Gesamtlimit für denselben Mandanten oder Service kann auf Cluster-Ebene konsistenter angewendet werden.
Traffic-Shaping macht per-Verbindungs-, per-Key- und gemeinsame Bandbreitenlimits zu einer vService-Level-Richtlinie.
Stream-Modus wendet eine separate Grenze auf jede Verbindung an. Per-Key-Modus wendet ein gemeinsames Limit über eine IP, einen Benutzer, einen Mandanten oder einen anderen FX-Schlüssel an. Shared-Modus hilft dabei, dasselbe Limit in einem Hochverfügbarkeits-Setup über Knoten zu verteilen. Eine einzige Funktion deckt daher einfaches Verbindungslimiting, Mandantenquoten-Management und clusterweite gemeinsame Kapazitätskontrolle ab.
Bei einigen Services dominiert Download-Traffic; bei anderen verbraucht Upload kritische Kapazität. TR7 kann die Upload-Richtung von Clients zum Backend und die Download-Richtung vom Backend zu Clients separat begrenzen. Beispielsweise kann Upload bei einem Datei-Upload-Service enger kontrolliert werden, während Download bei einem Video-Service enger ist. Diese Trennung passt die Bandbreitenrichtlinie an das tatsächliche Verkehrsverhalten an.
Im Per-Key-Modus wird der Bandbreitenschlüssel mit der FX-Ausdrucks-Engine aufgebaut. Quell-IP, JWT-Benutzerinformationen, Mandanten-ID, ein Header-Wert oder eine beliebige Kombination davon können als Schlüssel dienen. Beispielsweise können alle Benutzer, die zum selben Mandanten gehören, eine gemeinsame Kapazitätsgrenze teilen. Dies ist ein leistungsstarker Mechanismus zur Fair-Use-Durchsetzung in Multi-Mandanten-SaaS-Modellen.
Im Per-Key-Modus wird jeder Schlüssel als separater Nutzungszustand verfolgt. Schlüssel, die für einen definierten Zeitraum inaktiv waren, werden entfernt; aktive Schlüssel bleiben der Limit-Richtlinie unterworfen. Dieses Modell bietet zentralisierte Kapazitätskontrolle für Tausende von Benutzern oder Mandanten. Der Operator wendet Limits gegen einen logischen Traffic-Eigentümer an, nicht gegen individuelle Verbindungen.
In aktiv-aktiv- oder aktiv-passiv-Setups kann Traffic zwischen zwei Knoten verteilt werden. Shared-Modus hilft dabei, das Bandbreitenbudget als gemeinsames Service-Verhalten angewendet zu werden, anstatt auf einen einzelnen Knoten beschränkt zu sein. Wenn ein Mandant von einem Knoten zum anderen wechselt, wird die Limit-Logik nicht gestört. Dies ist besonders wichtig für Unternehmens-SLA- und Quotenszenarien.
Traffic-Shaping-Regeln können bedingt operieren. Ein Premium-Mandant kann unbegrenzt sein, ein kostenloser Mandant auf 100 Kbps begrenzt und eine verdächtige IP auf 1 Mbps eingeschränkt. Bedingungen können aus Pfad, Benutzer, Header, JWT-Claim, Quell-IP oder einem beliebigen FX-Ausdruck aufgebaut werden. Bandbreitenrichtlinie ist nicht mehr eine einzige globale Einstellung.
Verschiedene Verkehrssegmente innerhalb desselben vService können unterschiedliche Limit-Regeln haben. Beispielsweise kann der `/download`-Pfad sein eigenes Limit haben, `/api/export` ein anderes und Standard-API-Aufrufe wieder ein anderes. Dies teilt Kapazitätskontrolle in Segmente auf, die mit dem Anwendungsverhalten ausgerichtet sind. Der Operator wendet kontextsensitives Shaping an, anstatt einer einzigen undifferenzierten Grenze.
WebSocket-, großer-Datei-Download- oder langandauernde Streaming-Verbindungen können klassische anfragenbasierte Limits umgehen. Stream-Modus wendet eine Bandbreitengrenze auf jeden solchen Flow an. Eine einzige lange Verbindung wird daran gehindert, Servicekapazität zu erschöpfen. Dieses Modell ist wichtig für Medien-, Dateiübertragungs- und Echtzeit-Streaming-Szenarien.
Bandbreitenlimits können durch eine Konfigurationsänderung aktualisiert werden. Neue Limits werden auf kontrollierte Weise auf Produktions-Traffic angewendet. Dies ermöglicht eine schnelle Reaktion während Kampagnen, vermuteten DDoS-Ereignissen, Mandantenquoten-Änderungen oder temporären Kapazitätseinschränkungen. Betriebsteams müssen nicht auf eine separate Netzwerkgeräteänderung warten.
Im Per-Key-Modus kann der Nutzungszustand für jeden Benutzer, jede IP oder jeden Mandanten beobachtet werden. Der Operator kann sehen, welcher Schlüssel sich seiner Quotengrenze nähert. Diese Information ist wertvoll für Kundensupport, Sicherheitsanalyse und Kapazitätsplanung. Limit-Verletzungsereignisse können mit Logs und SIEM-Pipelines verbunden werden.
Nicht jeder verdächtige Flow muss sofort blockiert werden. TR7 kann ein niedriges Bandbreitenlimit auf riskante IPs, ASNs, Pfade oder Verhaltensgruppen anwenden. Dies reduziert die Auswirkungen eines Angriffs, während eine vollständige Trennung legitimer Benutzer in False-Positive-Situationen vermieden wird. Der Ansatz passt zu einem abgestuften Verteidigungsmodell.
Diese Funktion ist kein komplexes Queuing-System auf Netzwerkebene oder Hardware-QoS-Mechanismus. TR7 wendet eine Bandbreitengrenze auf Verbindungs- und Flow-Ebene an. Diese Grenze ist unkompliziert auf vService-, Schlüssel- und Bedingungsebene zu verwalten. Der Operator definiert klar, wie viel Kapazität jeder Service oder Benutzer erhält.
Traffic-Shaping sollte zusammen mit Limit-Modus, Schlüsseldesign, Upload- und Download-Richtung, langlebigen Flows, Cluster-Sharing und Audit-Sichtbarkeit geplant werden.
Stream-Modus eignet sich für per-Verbindungs-Limits, Per-Key-Modus für per-Benutzer- oder per-Mandanten-Limits und Shared-Modus für ein gemeinsames Limit im Cluster. Die Wahl des falschen Modus kann das erwartete Kapazitätsverhalten brechen. Das Richtlinienziel sollte zuerst geklärt werden.
Der im Per-Key-Modus verwendete Schlüssel bestimmt, wem das Limit tatsächlich gehört. Quell-IP ist in einigen Umgebungen ausreichend; Mandanten- oder Benutzerinformationen können ein genaueres Quotenmodell liefern. Bei mehreren Benutzern hinter NAT kann IP allein nicht fair sein.
Upload- und Download-Richtungen haben unterschiedliche Ressourcenauswirkungen. Große Datei-Uploads verbrauchen Backend-Ingress-Kapazität; Downloads verbrauchen Egress-Kapazität. Diese beiden Richtungen sollten separat begrenzt werden.
WebSocket-, Stream- und Dateiübertragungs-Verbindungen können für einen längeren Zeitraum offen bleiben. Per-Verbindungs-Limits machen den Ressourcenverbrauch in diesen Flows vorhersehbarer. Timeout- und Bandbreitenlimit-Einstellungen sollten zusammen bewertet werden.
Shared-Modus kann für gemeinsames Budget-Verhalten in Zwei-Knoten-Setups verwendet werden. Das Ziel ist, dass die Limit-Richtlinie konsistent bleibt, wenn sich die Traffic-Verteilung zwischen Knoten verschiebt. Dieses Verhalten ist für kritische Mandanten-SLAs wichtig.
Schlüssel, die einen Limit-Schwellenwert erreichen, können protokolliert werden. SIEM-seitige Alarmierung kann für pro-Mandanten-, pro-Benutzer- oder pro-IP-Quotenverletzungen konfiguriert werden. Diese Information ist sowohl für Sicherheitsbetrieb als auch für Kundensupport nützlich.
In einer Multi-Mandanten-SaaS-Umgebung kann eine separate Kapazitätsgrenze für jeden Mandanten definiert werden. Die Mandanten-ID wird als Schlüssel verwendet, und alle Benutzer, die zum selben Mandanten gehören, teilen das gemeinsame Limit.
Premium-Kunden kann ein höheres Bandbreitenlimit gegeben werden und kostenlosen Benutzern ein niedrigeres. Der Tarifunterschied wird in der ADC-Richtlinie verwaltet, ohne Logik in Anwendungscode einzubetten.
Verschiedene Qualitätsstufen bei Video- oder Media-Services erfordern unterschiedliche Bandbreiten. TR7 kann eine Download-Grenze basierend auf Pfad oder Benutzer-Abo-Tarif anwenden.
Während eines vermuteten DDoS- oder Bot-Ereignisses kann Traffic unter ein niedriges Rate-Limit gestellt werden, anstatt vollständig abgeschnitten zu werden. Dies reduziert den Angriffseinfluß, während eine vollständige Trennung für echte Benutzer in False-Positive-Fällen vermieden wird.
Interne API-Aufrufe können unbegrenzt bleiben, während Traffic aus dem Internet begrenzt wird. Die Trennung wird zentral mit Quell-IP-, Pfad- oder Header-Bedingungen vorgenommen.
Bestimmte Endpoints können während E-Commerce-Kampagnen plötzliche Traffic-Spitzen erhalten. TR7 wendet eine temporäre Bandbreitengrenze auf Checkout- oder Kampagnen-APIs an, um die Service-Stabilität zu erhalten.
Bandbreitenmanagement auf den ADC verlagern. Kapazitätsrichtlinien mit Stream-, Per-Key- und Shared-Modi einrichten — kein separates Netzwerkgerät oder komplexe Queuing-Architektur erforderlich.