Quand le type de service n'est pas clairement modélisé, les mauvaises fonctionnalités apparaissent au mauvais endroit et les erreurs opérationnelles deviennent inévitables.
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 paquet, 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.
Notre approche
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.
Le type de service est sélectionné lors de la création du pool
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.
Les actions sont automatiquement filtrées par type de service
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.
Plusieurs groupes de backends peuvent être définis sous un seul service
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 ne peut pas être modifié après la création — un nouveau pool est nécessaire
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.
Capacités
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 offre une visibilité Layer 7 complète et la sécurité applicative
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 se concentre sur la gestion des connexions et les scénarios SSL
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.
Chaque service reçoit ses propres cœurs — une poussée HTTP ne peut affamer un service UDP
Les services HTTP, TCP et UDP ne se contentent pas de partager une plateforme : chaque service publié reçoit ses propres cœurs, sa propre priorité CPU et son propre plafond mémoire. Une campagne sur le service web, une politique WAF lourde sur l'API et une rafale DNS sur l'écouteur UDP restent donc chacune dans sa voie. C'est ce qui rend la consolidation dense sûre : vingt services sur un équipement se comportent comme vingt équipements, sans vingt équipements.
Le type Layer4 distribue le trafic TCP et UDP au niveau paquet
Le type Layer4 est utilisé pour le modèle de distribution haute performance qui opère au niveau paquet. 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.
Répartition de charge des pare-feu — le sandwich reste symétrique
Une paire de pare-feu entre deux couches TR7 n'est utile que si un flux et son retour empruntent le même pare-feu ; sinon celui-ci ne voit qu'une moitié de conversation et la rejette. La sélection par hachage de source sur le type de service agnostique au protocole apporte cette symétrie, les contrôles de santé sortent un pare-feu défaillant de la rotation en quelques secondes, et ajouter de la capacité revient à ajouter un membre plutôt qu'à refaire la topologie. Ce que TR7 ne fait pas : synchroniser les tables de sessions des pare-feu eux-mêmes — cela reste leur travail, et une paire à états doit toujours être clusterisée comme son constructeur le prévoit.
Le groupe de backends par défaut définit l'ensemble de cibles principal pour chaque pool
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 de backends supplémentaires créent des tranches de trafic distinctes sous le même service
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 au niveau groupe déterminent où chaque règle est appliqué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.
Les actions HTTP, TCP et partagées sont séparées par la matrice de types
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.
La capacité du pool et les limites de connexion sont gérées au niveau 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.
Profondeur opérationnelle
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.
Contrainte de changement de type
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.
Placement ACL du groupe
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.
Génération de bloc de configuration
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.
Comportement HTTP/2 ALPN
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.
Routage TCP SNI
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.
Chemin de statistiques Layer4
Dans le type Layer4, les statistiques proviennent des mécanismes de distribution au niveau paquet 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.
Quand l'utiliser
Gateway API HTTP avec protection WAAP
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.
Gateway de messagerie d'entreprise TCP
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.
Cluster de service DNS basé sur UDP
Les équipes télécom et infrastructure peuvent distribuer le trafic UDP au niveau paquet en utilisant le type Layer4. Les algorithmes IPVS et les options de persistance permettent une livraison de service à faible latence et orientée protocole.
Routage A/B avec groupes de backends HTTP
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.
Questions fréquentes
Quelle est la différence fondamentale entre les types HTTP, TCP et Layer4 ?
Le type de service peut-il être modifié après la création du pool ?
Comment plusieurs groupes de backends sont-ils définis sous le même service ?
Comment les statistiques sont-elles surveillées dans le type Layer4 ?
Comment fonctionne le routage basé sur SNI dans le type TCP ?
Quelles actions peuvent être utilisées sur plus d'un type de service ?
Découvrez le bon modèle de fonctionnalités pour votre type de service
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.