Dans les applications modernes, les problèmes de capacité ne se mesurent pas uniquement par le nombre de requêtes. Les grands téléchargements de fichiers, le streaming vidéo, les exports API, le trafic de sauvegarde ou les extractions de données en masse pilotées par des bots peuvent consommer une bande passante élevée même à de faibles taux de requêtes. Dans ces cas, une limite de taux de requêtes seule n'est pas suffisante.
Dans les environnements multi-tenants, le problème devient plus visible. Lorsqu'un tenant effectue un transfert de données lourd, la latence pour les autres tenants peut augmenter. Sans limite de capacité entre les clients partageant le même vService, une politique d'utilisation équitable ne peut pas être techniquement appliquée.
Le traffic shaping conventionnel nécessite généralement des structures complexes de mise en file d'attente et de classes au niveau réseau. Ce modèle est puissant, mais travailler directement avec des signaux L7 tels que le chemin, le tenant, l'utilisateur, les JWT claims ou l'IP source au niveau de la couche de livraison applicative est difficile. Le débogage et la gestion des changements pour les équipes opérationnelles deviennent également plus lourds.
La bonne approche est d'appliquer un plafond de bande passante basé sur la connexion et la clé au niveau de l'ADC. Différentes limites doivent être définissables pour un vService, un utilisateur, un tenant ou un groupe de trafic risqué, et les directions upload et download doivent être gérables indépendamment.
Le Traffic Shaping et QoS par vService de TR7 contrôle la consommation de bande passante au niveau de la couche de livraison applicative avec les modes stream, per-key et shared.
TR7 applique le contrôle de bande passante comme une politique à trois modes à travers le vService, la clé de trafic et le partage en haute disponibilité.
Le trafic upload des clients vers le backend et le trafic download du backend vers les clients peuvent être limités séparément pour chaque vService. Cela place la capacité applicative sous contrôle au niveau du service.
En mode stream, chaque connexion opère sous son propre plafond de bande passante. La consommation de ressources d'une seule connexion peut être bornée dans les téléchargements, uploads ou flux de type WebSocket de longue durée.
En mode per-key, la limite est appliquée selon une clé produite par une expression FX. L'IP source, l'utilisateur, l'ID de tenant ou une valeur de JWT claim peuvent tous servir de clé de bande passante.
En mode shared, le budget de bande passante dans une configuration à deux nœuds n'est pas confiné à un seul appareil. Une limite totale pour le même tenant ou service peut être appliquée de manière plus cohérente au niveau du cluster.
Le traffic shaping transforme les limites de bande passante par connexion, par clé et partagées en une politique au niveau du vService.
Le mode stream applique un plafond séparé à chaque connexion. Le mode per-key applique une limite partagée à travers une IP, un utilisateur, un tenant ou toute autre clé FX. Le mode shared aide la même limite à être distribuée entre des nœuds dans une configuration de haute disponibilité. Une seule fonctionnalité couvre donc le simple limiteur de connexion, la gestion des quotas de tenant et le contrôle de capacité partagée à l'échelle du cluster.
Dans certains services, le trafic download est dominant ; dans d'autres, l'upload consomme une capacité critique. TR7 peut limiter la direction upload des clients vers le backend et la direction download du backend vers les clients séparément. Par exemple, l'upload peut être plus étroitement contrôlé sur un service de téléchargement de fichiers pendant que le download est plus limité sur un service vidéo. Cette séparation aligne la politique de bande passante avec le comportement réel du trafic.
En mode per-key, la clé de bande passante est construite en utilisant le moteur d'expression FX. L'IP source, les informations utilisateur JWT, l'ID de tenant, une valeur de header ou toute combinaison de ceux-ci peut servir de clé. Par exemple, tous les utilisateurs appartenant au même tenant peuvent partager un plafond de capacité commun. C'est un mécanisme puissant pour l'application d'une politique d'utilisation équitable dans les modèles SaaS multi-tenants.
En mode per-key, chaque clé est suivie comme un état d'utilisation séparé. Les clés qui sont restées silencieuses pendant une période définie sont supprimées ; les clés actives restent soumises à la politique de limite. Ce modèle fournit un contrôle de capacité centralisé pour des milliers d'utilisateurs ou de tenants. L'opérateur applique des limites contre un propriétaire de trafic logique plutôt que des connexions individuelles.
Dans les configurations actif-actif ou actif-passif, le trafic peut être distribué entre deux nœuds. Le mode shared aide le budget de bande passante à être appliqué comme un comportement de service partagé plutôt que d'être confiné à un seul nœud. Lorsqu'un tenant passe d'un nœud à l'autre, la logique de limite n'est pas perturbée. C'est particulièrement important pour les scénarios d'entreprise avec SLA et quotas.
Les règles de traffic shaping peuvent opérer conditionnellement. Un tenant premium peut être illimité, un tenant gratuit plafonné à 100 Kbps et une IP suspecte restreinte à 1 Mbps. Les conditions peuvent être construites à partir du chemin, de l'utilisateur, du header, du JWT claim, de l'IP source ou de toute expression FX. La politique de bande passante n'est plus un seul paramètre global.
Différentes tranches de trafic au sein du même vService peuvent avoir différentes règles de limite. Par exemple, le chemin `/download` peut avoir sa propre limite, `/api/export` une autre et les appels API standard encore une autre. Cela décompose le contrôle de capacité en segments alignés avec le comportement applicatif. L'opérateur applique un shaping contextuel plutôt qu'un seul plafond global.
Les connexions WebSocket, les téléchargements de grands fichiers ou les connexions de streaming de longue durée peuvent contourner les limites classiques basées sur les requêtes. Le mode stream applique un plafond de bande passante à chacun de ces flux. Une seule connexion longue est empêchée d'épuiser la capacité du service. Ce modèle est important pour les scénarios de médias, de transfert de fichiers et de streaming en temps réel.
Les limites de bande passante peuvent être mises à jour via un changement de configuration. Les nouvelles limites sont appliquées au trafic en production de manière contrôlée. Cela permet une réponse rapide lors de campagnes, d'événements DDoS suspects, de changements de quota de tenant ou de restrictions de capacité temporaires. Les équipes opérationnelles n'ont pas besoin d'attendre un changement d'appareil réseau séparé.
En mode per-key, l'état d'utilisation pour chaque utilisateur, IP ou tenant peut être observé. L'opérateur peut voir quelle clé approche de son plafond de quota. Ces informations sont précieuses pour le support client, l'analyse de sécurité et la planification de capacité. Les événements de dépassement de limite peuvent être connectés aux journaux et aux pipelines SIEM.
Chaque flux suspect ne doit pas être bloqué immédiatement. TR7 peut appliquer une faible limite de bande passante aux IP risquées, ASN, chemins ou groupes de comportement. Cela réduit l'impact d'une attaque tout en évitant une coupure complète des utilisateurs légitimes dans les situations de faux positifs. L'approche s'inscrit dans un modèle de défense graduée.
Cette fonctionnalité n'est pas un système complexe de mise en file d'attente au niveau réseau ou un mécanisme QoS matériel. TR7 applique un plafond de bande passante au niveau de la connexion et du flux. Cette limite est simple à gérer au niveau du vService, de la clé et de la condition. L'opérateur définit clairement quelle capacité chaque service ou utilisateur reçoit.
Le traffic shaping doit être planifié conjointement avec le mode de limite, la conception des clés, la direction upload et download, les flux de longue durée, le partage en cluster et la visibilité d'audit.
Le mode stream convient aux limites par connexion, le mode per-key convient aux limites par utilisateur ou par tenant, et le mode shared convient à une limite commune à travers le cluster. Choisir le mauvais mode peut rompre le comportement de capacité attendu. L'objectif de politique doit être clarifié en premier.
La clé utilisée en mode per-key détermine à qui appartient réellement la limite. L'IP source est suffisante dans certains environnements ; les informations de tenant ou d'utilisateur peuvent fournir un modèle de quota plus précis. Pour plusieurs utilisateurs derrière NAT, l'IP seule peut ne pas être équitable.
Les directions upload et download ont des impacts différents sur les ressources. Les grands uploads de fichiers consomment la capacité d'entrée du backend ; les downloads consomment la capacité de sortie. Ces deux directions doivent être limitées séparément.
Les connexions WebSocket, stream et de transfert de grands fichiers peuvent rester ouvertes pendant une période prolongée. Les limites par connexion rendent la consommation de ressources plus prévisible dans ces flux. Les paramètres de timeout et de limite de bande passante doivent être évalués ensemble.
Le mode shared peut être utilisé pour un comportement de budget commun dans les configurations à deux nœuds. L'objectif est que la politique de limite reste cohérente à mesure que la distribution du trafic évolue entre les nœuds. Ce comportement est important pour les SLA critiques des tenants.
Les clés atteignant un seuil de limite peuvent être journalisées. Des alertes côté SIEM peuvent être configurées pour les dépassements de quota par tenant, par utilisateur ou par IP. Ces informations sont utiles à la fois pour les opérations de sécurité et le support client.
Dans un environnement SaaS multi-tenant, un plafond de capacité séparé peut être défini pour chaque tenant. L'ID de tenant est utilisé comme clé, et tous les utilisateurs appartenant au même tenant partagent la limite commune.
Une limite de bande passante plus élevée peut être donnée aux clients premium et une plus basse aux utilisateurs gratuits. La différence de niveau est gérée dans la politique ADC sans intégrer la logique dans le code applicatif.
Différents niveaux de qualité dans les services vidéo ou médias nécessitent des bandes passantes différentes. TR7 peut appliquer un plafond de download basé sur le chemin ou le niveau d'abonnement de l'utilisateur.
Lors d'un événement DDoS ou bot suspect, le trafic peut être soumis à une faible limite de débit plutôt que d'être complètement coupé. Cela réduit l'impact de l'attaque tout en évitant une déconnexion complète des vrais utilisateurs dans les cas de faux positifs.
Les appels API internes peuvent être laissés illimités pendant que le trafic provenant d'internet est plafonné. La séparation est effectuée de manière centralisée en utilisant des conditions d'IP source, de chemin ou de header.
Certains endpoints peuvent recevoir des pics de trafic soudains lors de campagnes e-commerce. TR7 applique un plafond de bande passante temporaire aux API de checkout ou de campagne pour maintenir la stabilité du service.
Déplacez la gestion de la bande passante sur l'ADC. Établissez des politiques de capacité avec les modes stream, per-key et shared — aucune appliance réseau séparée ni architecture complexe de mise en file d'attente requise.