Im unternehmensweiten Verkehrsmanagement sind HTTP-, TCP- und Layer4-Services nicht dasselbe. Bei HTTP-Verkehr sind Header, Cookies, Pfade, WAAP-Scores und Inhaltsregeln relevant. Bei TCP dominieren Verbindungshandling, SSL-Terminierung und SNI. Bei Layer4 sind Protokoll auf Kernel-Ebene, Algorithmus und Persistenzverhalten entscheidend. Wenn diese Unterschiede nicht explizit modelliert werden, stoßen Operatoren auf Einstellungen, die in ihrem aktuellen Kontext nicht funktionieren können.
Bei traditionellen Ansätzen ist der Service-Typ oft über separate Objekte, Profile, Bildschirme oder manuelle Konfigurationsblöcke verstreut. Operatoren müssen auswendig lernen, welche Features für welchen Verkehrstyp gelten. Eine Header-Regel am falschen Ort, eine WAAP-Einstellung am falschen Service oder eine Layer-7-Erwartung an einem Layer4-Flow führen alle zu Laufzeitfehlern und Zeitverlust.
Ein zweites Problem ist die Verwaltung mehrerer Backend-Gruppen unter einem einzigen Service. Lese- und Schreibanfragen an verschiedene Ziele zu senden, Mobile- und Desktop-Verkehr zu trennen oder regionale Service-Gruppen unter einem einzigen Einstiegspunkt zu betreiben, wird auf den meisten Plattformen als separates Feature behandelt — was einem simplen Routing-Bedarf konzeptionelles Gewicht verleiht.
Der richtige Ansatz besteht darin, den Service-Typ explizit in einem einzigen Pool-Objekt zu deklarieren und die Feature-Matrix sich automatisch filtern zu lassen. Mehrere Backend-Gruppen sollten unter demselben Pool unterstützt werden, während Operatoren nur die relevanten Optionen sehen, ohne mit unnötigen technischen Details überflutet zu werden.
Das TR7 Drei-Service-Typen-Modell reduziert diese Komplexität: Der Service-Typ wird vorab gewählt, die entsprechenden Features erscheinen automatisch, und Backend-Gruppen werden innerhalb desselben Konfigurationsmodells verwaltet.
TR7 macht den Service-Typ zum zentralen Schalter der Konfiguration und organisiert die gesamte Feature-Sichtbarkeit um diese architektonische Entscheidung herum.
Der Operator erstellt einen Pool, indem er HTTP, TCP oder Layer4 wählt. Diese einzelne Auswahl bestimmt, welche Aktionen, Health Checks und Traffic-Features künftig verfügbar sein werden.
Die zentrale Feature-Matrix definiert, welche Aktionen für welchen Service-Typ gültig sind. Die Benutzeroberfläche zeigt nur Einstellungen an, die für den ausgewählten Pool-Typ sinnvoll sind; technisch ungültige Optionen erscheinen nie vor dem Operator.
Jeder Pool beginnt mit einer Standard-Backend-Gruppe, und zusätzliche Gruppen können bei Bedarf hinzugefügt werden. Verkehr wird über ACL- und Regellogik an die entsprechende Gruppe weitergeleitet.
Der Service-Typ ist die architektonische Entscheidung, die die gesamte Feature-Matrix des Pools beeinflusst. Anstatt einen bestehenden Pool in einen anderen Typ umzuwandeln, ist der empfohlene Weg, einen neuen Pool zu erstellen und eine kontrollierte Migration durchzuführen.
Das Drei-Service-Typen-Modell liefert die richtigen Fähigkeiten am richtigen Ort für HTTP-, TCP- und Layer4-Verkehr.
Der HTTP-Typ wird für vollständiges Layer-7-Proxy-Verhalten verwendet. WAAP, inhaltsbewusste Regeln, Header- und Cookie-Manipulation, Redirect, CAPTCHA, Response-Cache, Komprimierung und AAM-Integration sind in diesem Typ sinnvoll. ALPN h2- und http/1.1-Optionen können im HTTP-Service-Verhalten einbezogen werden. HTTP ist die richtige Wahl, wenn detaillierte Entscheidungsfindung, Transformation und Sicherheitsrichtlinien über Anwendungs- und API-Verkehr hinweg erforderlich sind.
Der TCP-Typ wird für Services verwendet, die SSL-Terminierung oder Passthrough über einen Layer-4-Verbindungsflow benötigen. SNI-basiertes Routing, TLS-Hello-Inspektion und TCP-Verbindungsmanagement stehen hier im Vordergrund. TCP-spezifische Persistenzanforderungen wie RDP-Cookie-Persistenz können in diesem Typ abgedeckt werden. Protokollfunktionen wie MQTT und FIX können ebenfalls die Entscheidungslogik auf TCP-Ebene stärken.
Der Layer4-Typ wird für das Hochleistungsverteilungsmodell auf Kernel-Ebene verwendet. IPVS-Algorithmen, NAT-, DR- und TUN-Modi können auf TCP-, UDP- oder protokollunabhängige Flows angewendet werden. In diesem Typ wird keine Layer-7-Inspektion durchgeführt; Entscheidungen basieren auf IP, Port, Protokoll und Persistenzlogik. Dies ist die richtige Architektur für DNS, Telekommunikation oder reine Layer-4-Services, bei denen niedrige Latenz entscheidend ist.
Jeder Pool hat mindestens eine Standard-Backend-Gruppe. Diese Gruppe trägt den primären Ziel-Set des Service und den Lastverteilungsalgorithmus. Wenn keine zusätzliche Routing-Regel geschrieben wird, wird Verkehr an diese Standardgruppe weitergeleitet. Das Modell hält einfache Services übersichtlich und ermöglicht gleichzeitig die Erweiterung für fortgeschrittene Szenarien.
Gruppen wie `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` oder `be-writes` können unter einem einzigen Pool erstellt werden. Jede Gruppe kann ihren eigenen Ziel-Set, Health-Check-Profil und Verkehrsverhalten haben. ACL- und Regelbedingungen steuern Anfragen zur entsprechenden Gruppe. Dies macht eine Multi-Target-Architektur unter einem einzigen Einstiegspunkt verwaltbar.
Regeln können nur auf der Backend-Gruppe, auf beiden Seiten (Frontend und Gruppe) oder auf einer bestimmten benannten Gruppe angewendet werden. Dieses Targeting-Modell macht den Geltungsbereich jeder Regel explizit. Beispielsweise kann eine Header-Transformation, ein Health-Verhalten oder eine Routing-Bedingung ausschließlich für eine Gruppe definiert werden. Der Operator trennt verschiedene Verkehrs-Slices innerhalb desselben Service auf kontrollierte Weise.
CORS, Cookie-Verschlüsselung, Header hinzufügen, Header löschen, Pfad-Umschreibung, URI-Normalisierung und Autorisierung sind HTTP-exklusive Aktionen. TCP-Verbindungsmanagement und TCP-spezifische Persistenzoptionen erscheinen nur im TCP-Typ. Aktionen wie Silent-Log, manuelle Regel, Quarantäne-Tabelle, Deny und IP-Maskierung können in mehreren Typen verwendet werden. Da die Benutzeroberfläche diese Trennung automatisch erzwingt, haben Operatoren nie Probleme mit der falschen Aktion am falschen Service-Typ.
Maximale Verbindungsanzahl und Verbindungsraten-Limits können auf Pool-Ebene definiert werden. Individuelle Verbindungsobergrenzen können auch pro Backend-Ziel angewendet werden. Dieses Modell hilft, sowohl den gesamten Service als auch einzelne Ziele unter hohem Verkehr zu schützen. Kapazitätseinstellungen werden entsprechend Service-Typ, Verkehrsverhalten und Hardware-Ressourcen geplant.
Das Drei-Service-Typen-Modell wird zusammen mit Typ-Änderungsbeschränkungen, Konfigurationsgenerierung, Health Monitoring, Statistikpfaden und Audit-Verhalten betrachtet.
Der Service-Typ kann nach der Erstellung nicht als einfache Einstellung geändert werden. HTTP-, TCP- und Layer4-Typen erfordern jeweils eine andere Feature-Matrix, einen anderen Verarbeitungspfad und eine andere Konfigurationsgenerierung. Wenn eine Typ-Änderung notwendig ist, besteht der richtige Ansatz darin, einen neuen Pool zu erstellen und eine kontrollierte Migration durchzuführen.
Ob eine ACL in einer Backend-Gruppen-Regel auf der Frontend-Seite oder der Gruppen-Seite definiert wird, hängt vom beabsichtigten Ziel ab. Diese Unterscheidung klärt, in welcher Phase der Verkehrsverarbeitung die Regel ausgelöst wird. Sie verhindert, dass an der falschen Stelle platzierte Bedingungen das Service-Verhalten stören.
Jede Backend-Gruppe wird als separater Konfigurationsblock ausgegeben. Die Standardgruppe wird separat von zusätzlichen Gruppen definiert, und Regeln werden an ihre jeweiligen Ziele gebunden. Diese Struktur kommt sowohl der Konfigurationslesbarkeit als auch Rollback-Szenarien zugute.
Wenn die entsprechende Einstellung im HTTP-Typ aktiviert ist, können h2- und http/1.1-ALPN-Optionen für serverseitige Verbindungen verwendet werden. Diese Einstellung ist nur in einem HTTP-Service-Kontext sinnvoll. Layer-7-HTTP-Verhalten sollte von TCP- oder Layer4-Typen nicht erwartet werden.
Im TCP-Typ kann eine Routing-Entscheidung durch Inspektion des SNI-Feldes in der TLS-Hello-Nachricht getroffen werden. Dies wird verwendet, um TLS-Services ohne vollständiges HTTP-Parsing an verschiedene Ziele zu leiten. SNI-basierte Entscheidungen müssen je nach Passthrough- oder Terminierungsanforderungen sorgfältig geplant werden.
Im Layer4-Typ stammen Statistiken aus Kernel-Level-Verteilungsmechanismen und nicht aus dem Layer-7-Proxy-Pfad. Identisches Verhalten wie HTTP- oder TCP-Proxy-Statistiken sollte nicht angenommen werden. Operatoren, die Layer4-Services überwachen, müssen die entsprechende Statistikquelle verwenden.
SaaS-Teams können API-Verkehr unter voller Layer-7-Sichtbarkeit mit dem HTTP-Typ verwalten. WAAP, JWT-Validierung, inhaltsbewusste Regeln und pfadbasiertes Routing werden innerhalb desselben Service-Modells angewendet.
Unternehmens-Teams können verbindungsorientierte Services, die SSL-Terminierung, Passthrough oder Source-IP-Persistenz benötigen, mit dem TCP-Typ verwalten. Services, die keine Layer-7-HTTP-Features benötigen, werden mit einem einfacheren Modell bedient.
Telekommunikations- und Infrastruktur-Teams können UDP-Verkehr mit dem Layer4-Typ auf Kernel-Ebene verteilen. IPVS-Algorithmen und Persistenzoptionen ermöglichen eine latenzarme, protokollfokussierte Service-Bereitstellung.
E-Commerce-Teams können Gruppen wie `be-variant-a` und `be-variant-b` unter demselben HTTP-Service erstellen. ACL- oder Hash-basierte Bedingungen steuern Verkehr auf kontrollierte Weise zu verschiedenen Erfahrungen.
HTTP-, TCP- und Layer4-Verkehr in einem einzigen Konfigurationsmodell verwalten — eine flexible Zielarchitektur mit Backend-Gruppen aufbauen. Wir führen Sie durch eine Live-Einrichtung in Ihrer eigenen Umgebung.