Lorsque la bande passante est illimitée, un seul tenant ou un seul flux lourd peut affecter l'ensemble du service.
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.
Notre approche
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é.
Les plafonds upload et download sont appliqués par vService
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.
Le mode stream donne à chaque connexion sa propre limite
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.
Le mode per-key applique des quotas par utilisateur, IP ou tenant
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.
Le mode shared fournit un budget de capacité commun à travers le cluster
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.
Capacités
Le traffic shaping transforme les limites de bande passante par connexion, par clé et partagées en une politique au niveau du vService.
Trois modes de limite couvrent différents scénarios de contrôle de capacité
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.
Cœurs CPU et mémoire alloués par service, pas par locataire
Chaque service publié reçoit ses propres cœurs, sa propre priorité CPU et son propre plafond mémoire. Un pic de trafic sur une application, ou une politique WAF lourde sur une autre, reste à l'intérieur de cette application et ne peut pas affamer les autres. L'isolation des ressources au niveau du service est ce qui rend la consolidation dense sûre : vingt applications sur un équipement se comportent comme vingt équipements, sans vingt équipements.
Les limites upload et download sont définies indépendamment
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.
Le constructeur de clé FX produit des limites par tenant et par utilisateur
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.
La table per-key peut suivre un grand nombre d'utilisateurs ou de 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.
Le mode shared préserve la limite totale à travers une paire de haute disponibilité
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.
L'application conditionnelle sépare le trafic premium et standard
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.
Plusieurs règles de limite peuvent être définies au sein d'un vService et d'un pool
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.
Un plafond au niveau de la connexion est appliqué aux flux de longue durée
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 changements de limite peuvent être appliqués sans interruption du service
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é.
La surveillance montre quelle clé consomme sa limite
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.
Un plafond de débit peut être appliqué au trafic suspect dans la mitigation DDoS
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.
Fonctionne comme un contrôle de flux au niveau de la connexion transparent et prévisible
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.
Profondeur opérationnelle
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.
Sélection du mode de limite
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.
Conception des clés
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.
Séparation upload et download
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.
Connexions de longue durée
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.
Partage en cluster
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.
Audit et alertes
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.
Quand l'utiliser
Application des quotas de bande passante pour les tenants SaaS
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.
Délivrance de vitesses différentes entre les niveaux premium et gratuit
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.
Application de limites de débit par niveau de qualité dans le streaming médias
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.
Ralentissement du trafic suspect au lieu de le bloquer
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.
Politiques de capacité séparées pour le trafic interne et externe
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.
Limitation de débit d'endpoints spécifiques lors de campagnes promotionnelles
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.
Questions fréquentes
Comment choisir entre les modes stream, per-key et shared ?
Les limites upload et download peuvent-elles être définies séparément ?
Comment une clé est-elle construite en mode per-key, et combien de clés peuvent être suivies ?
Comment fonctionne le mode shared dans une configuration de haute disponibilité ?
Cette fonctionnalité est-elle la même que Linux tc ou les systèmes QoS matériels ?
Que se passe-t-il lorsqu'une limite est dépassée, et ces événements peuvent-ils être surveillés ?
Contrôlez la capacité de trafic au niveau du vService et du tenant
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.