Dans la gestion du trafic d'entreprise, les services HTTP, TCP et Layer4 ne sont pas la même chose. Pour le trafic HTTP, les headers, cookies, chemins, scores WAAP et règles de contenu sont importants. Pour TCP, la gestion des connexions, la terminaison SSL et SNI dominent. En Layer4, le protocole au niveau kernel, l'algorithme et le comportement de persistance sont ce qui dirige les décisions. Si ces différences ne sont pas modélisées explicitement, les opérateurs rencontrent des paramètres qui ne peuvent pas fonctionner dans leur contexte actuel.
Dans les approches traditionnelles, le type de service est souvent dispersé entre des objets séparés, des profils, des écrans ou des blocs de configuration manuels. Les opérateurs doivent mémoriser quelles fonctionnalités s'appliquent à quel type de trafic. Une règle de header au mauvais endroit, un paramètre WAAP sur le mauvais service, ou une attente Layer 7 sur un flux Layer4 se traduisent tous par des erreurs d'exécution et du temps perdu.
Un second problème est la gestion de plusieurs groupes de backends sous un seul service. Envoyer les requêtes de lecture et d'écriture vers des cibles différentes, séparer le trafic mobile et bureau, ou gérer des groupes de service régionaux sous un seul point d'entrée est traité comme une fonctionnalité séparée sur la plupart des plateformes — ajoutant un poids conceptuel à ce qui devrait être une exigence de routage simple.
La bonne approche est de déclarer explicitement le type de service dans un objet pool unique et de laisser la matrice de fonctionnalités se filtrer automatiquement. Plusieurs groupes de backends doivent être supportés sous le même pool, tandis que les opérateurs ne voient que les options pertinentes sans être submergés par des détails techniques inutiles.
Le modèle Trois Types de Service de TR7 réduit cette complexité : le type de service est choisi dès le départ, les fonctionnalités appropriées apparaissent automatiquement, et les groupes de backends sont gérés dans le même modèle de configuration.
TR7 fait du type de service le commutateur central de la configuration et organise toute la visibilité des fonctionnalités autour de ce choix architectural.
L'opérateur crée un pool en choisissant HTTP, TCP ou Layer4. Cette seule sélection détermine quelles actions, contrôles de santé et fonctionnalités de trafic seront disponibles par la suite.
La matrice de fonctionnalités centrale définit quelles actions sont valides pour quel type de service. L'interface graphique n'affiche que les paramètres significatifs pour le type de pool sélectionné ; les options techniquement invalides n'apparaissent jamais devant l'opérateur.
Chaque pool démarre avec un groupe de backends par défaut, et des groupes supplémentaires peuvent être ajoutés selon les besoins. Le trafic est acheminé vers le groupe pertinent via la logique ACL et les règles.
Le type de service est la décision architecturale qui affecte l'ensemble de la matrice de fonctionnalités du pool. Plutôt que de convertir un pool existant vers un type différent, le chemin recommandé est de créer un nouveau pool et d'effectuer une migration contrôlée.
Le modèle Trois Types de Service délivre les bonnes capacités au bon endroit pour le trafic HTTP, TCP et Layer4.
Le type HTTP est utilisé pour un comportement proxy Layer 7 complet. WAAP, règles content-aware, manipulation des headers et cookies, redirection, captcha, cache de réponse, compression et intégration AAM sont significatifs dans ce type. Les options ALPN h2 et http/1.1 peuvent être incluses dans le comportement du service HTTP. HTTP est le bon choix lorsque la prise de décision détaillée, la transformation et la politique de sécurité sont nécessaires sur le trafic applicatif et API.
Le type TCP est utilisé pour les services nécessitant une terminaison SSL ou un passthrough sur un flux de connexion Layer 4. Le routage basé sur SNI, l'inspection TLS hello et la gestion des connexions TCP sont proéminents ici. Les besoins de persistance spécifiques à TCP comme la persistance par cookie RDP peuvent être adressés dans ce type. Des fonctions de protocole comme MQTT et FIX peuvent également renforcer la logique de décision au niveau TCP.
Le type Layer4 est utilisé pour le modèle de distribution haute performance qui opère au niveau kernel. Les algorithmes IPVS, les modes NAT, DR et TUN peuvent être appliqués aux flux TCP, UDP ou protocol-agnostic. Aucune inspection Layer 7 n'est effectuée dans ce type ; les décisions sont basées sur l'IP, le port, le protocole et la logique de persistance. C'est la bonne architecture pour DNS, télécom ou les services purs Layer 4 où la faible latence est essentielle.
Chaque pool possède au moins un groupe de backends par défaut. Ce groupe porte l'ensemble de cibles principal du service et l'algorithme d'équilibrage de charge. Lorsqu'aucune règle de routage supplémentaire n'est écrite, le trafic est transmis à ce groupe par défaut. Le modèle garde les services simples accessibles tout en permettant l'extension pour les scénarios avancés.
Des groupes comme `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` ou `be-writes` peuvent être créés sous un seul pool. Chaque groupe peut avoir son propre ensemble de cibles, son profil de contrôle de santé et son comportement de trafic. Les conditions ACL et de règles acheminent les requêtes vers le groupe approprié. Cela rend une architecture multi-cibles gérable sous un seul point d'entrée.
Les règles peuvent être appliquées uniquement sur le groupe de backends, à la fois côté frontend et côté groupe, ou sur un groupe nommé spécifique. Ce modèle de ciblage rend la portée de chaque règle explicite. Par exemple, une transformation de header, un comportement de santé ou une condition de routage peut être défini exclusivement pour un groupe. L'opérateur sépare différentes tranches de trafic au sein du même service de manière contrôlée.
CORS, chiffrement des cookies, ajout de header, suppression de header, réécriture de chemin, normalisation URI et autorisation sont des actions exclusives à HTTP. La gestion des connexions TCP et les options de persistance spécifiques à TCP n'apparaissent que dans le type TCP. Des actions comme silent log, règle manuelle, table de quarantaine, deny et masquage IP peuvent être utilisées sur plusieurs types. Parce que l'interface graphique applique automatiquement cette séparation, les opérateurs ne se retrouvent jamais à gérer la mauvaise action sur le mauvais type de service.
Le nombre maximum de connexions et les limites de débit de connexion peuvent être définis au niveau du pool. Des limites supérieures de connexion individuelles peuvent également être appliquées par cible backend. Ce modèle aide à protéger à la fois le service global et les cibles individuelles sous un trafic intense. Les paramètres de capacité sont planifiés en fonction du type de service, du comportement de trafic et des ressources matérielles.
Le modèle Trois Types de Service est considéré avec les contraintes de changement de type, la génération de configuration, la surveillance de santé, les chemins de statistiques et le comportement d'audit.
Le type de service ne peut pas être modifié après la création comme un simple paramètre. Les types HTTP, TCP et Layer4 nécessitent chacun une matrice de fonctionnalités différente, un chemin de traitement différent et une génération de configuration différente. Lorsqu'un changement de type est nécessaire, l'approche correcte est de créer un nouveau pool et d'effectuer une migration contrôlée.
Que l'ACL dans une règle de groupe de backends soit défini côté frontend ou côté groupe dépend de la cible visée. Cette distinction clarifie à quelle étape du traitement du trafic la règle se déclenche. Elle empêche les conditions placées au mauvais endroit de perturber le comportement du service.
Chaque groupe de backends est émis comme un bloc de configuration séparé. Le groupe par défaut est défini séparément des groupes supplémentaires, et les règles sont liées à leurs cibles respectives. Cette structure bénéficie à la fois à la lisibilité de la configuration et aux scénarios de rollback.
Lorsque le paramètre approprié est activé dans le type HTTP, les options ALPN h2 et http/1.1 peuvent être utilisées sur les connexions côté serveur. Ce paramètre n'est significatif que dans un contexte de service HTTP. Un comportement HTTP Layer 7 ne doit pas être attendu des types TCP ou Layer4.
Dans le type TCP, une décision de routage peut être prise en inspectant le champ SNI dans le message TLS hello. Ceci est utilisé pour séparer les services TLS vers différentes cibles sans effectuer d'analyse HTTP complète. Les décisions basées sur SNI doivent être planifiées soigneusement selon les exigences de passthrough versus terminaison.
Dans le type Layer4, les statistiques proviennent des mécanismes de distribution au niveau kernel plutôt que du chemin proxy Layer 7. Un comportement identique aux statistiques proxy HTTP ou TCP ne doit pas être supposé. Les opérateurs surveillant les services Layer4 doivent utiliser la source de statistiques appropriée.
Les équipes SaaS peuvent gérer le trafic API sous une visibilité Layer 7 complète en utilisant le type HTTP. WAAP, validation JWT, règles content-aware et routage basé sur le chemin sont appliqués dans le même modèle de service.
Les équipes d'entreprise peuvent gérer des services orientés connexion qui nécessitent une terminaison SSL, un passthrough ou une persistance par IP source en utilisant le type TCP. Les services qui n'ont pas besoin de fonctionnalités HTTP Layer 7 sont servis avec un modèle plus simple.
Les équipes télécom et infrastructure peuvent distribuer le trafic UDP au niveau kernel en utilisant le type Layer4. Les algorithmes IPVS et les options de persistance permettent une livraison de service à faible latence et orientée protocole.
Les équipes e-commerce peuvent créer des groupes comme `be-variant-a` et `be-variant-b` sous le même service HTTP. Les conditions ACL ou basées sur le hash acheminent le trafic vers différentes expériences de manière contrôlée.
Gérez le trafic HTTP, TCP et Layer4 dans un seul modèle de configuration — construisez une architecture de cibles flexible avec les groupes de backends. Laissez-nous vous guider dans une configuration en direct dans votre propre environnement.