Dans la plupart des conceptions d'équilibrage de charge, la limite de connexion est traitée comme un seul champ : combien de connexions peuvent être ouvertes simultanément ? Ce modèle est incomplet. Dix mille connexions keep-alive en attente peuvent être peu coûteuses, tandis que 1 000 nouveaux handshakes SSL simultanés peuvent rapidement épuiser le CPU backend. Le même nombre génère un coût totalement différent selon le type de trafic.
Le nombre de connexions et le taux de connexion ne sont pas non plus la même chose. « Jusqu'à 20 000 connexions peuvent être ouvertes simultanément » est un plafond de capacité ; « jusqu'à 10 000 nouvelles connexions peuvent être ouvertes par seconde » est un contrôle des bursts et des tempêtes de connexion. Les systèmes qui ne séparent pas ces deux valeurs contraignent inutilement le trafic légitime ou échouent à protéger le backend contre une vague d'attaque soudaine.
Le trafic TLS doit être considéré séparément. Les opérations de handshake SSL/TLS sont coûteuses en CPU, et lorsqu'elles sont gérées sous la même limite que les connexions HTTP plain, la charge réelle devient invisible. Surtout lors du trafic web public, de passerelle API et de périodes de campagne, limiter indépendamment le taux de handshake maintient la consommation CPU backend sous contrôle.
Le comportement de file d'attente est également souvent opaque. Lorsqu'une limite est dépassée, la connexion est-elle silencieusement abandonnée, expire-t-elle, attend-elle dans une file, ou le client reçoit-il un 503 clair ? Sans visibilité sur ce comportement, la cause racine n'est pas claire au moment de l'incident — les utilisateurs voient un timeout, et l'équipe opérationnelle identifie la vraie raison trop tard.
TR7 Pool Connection Limits protège les services backend grâce à une gestion prévisible de la capacité plutôt qu'à une surcharge silencieuse, en contrôlant indépendamment le total des connexions, le taux de connexion, le taux de session, la charge SSL, le budget buffer et le comportement de retry.
TR7 gère la capacité du pool non pas avec un seul champ, mais avec une structure de profil construite sur des axes de connexion, taux, SSL, retry et buffer.
Un seul profil définit maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate et maxBufferSize. Cela permet de régler indépendamment les limites de connexion, de taux, TLS et mémoire du backend.
Parce que les handshakes TLS sont coûteux en CPU, TR7 gère maxSslConn et maxSslRate comme des valeurs distinctes. Cette séparation aide à empêcher une tempête de handshake d'épuiser le backend même lorsque le nombre total de connexions semble faible.
Un profil de limite est défini avec un nom unique et peut être attaché à différents pools de services. Les politiques de capacité de production, staging, canary ou par tenant peuvent toutes être gérées avec un seul modèle de profil.
maxRetries définit combien de fois une connexion au backend est retentée en cas d'échec transitoire. maxBufferSize contrôle la consommation mémoire par connexion dans les scénarios de client lent ou de backend lent.
TR7 Pool Connection Limits contraint les services backend de manière maîtrisée contre les tempêtes de connexion, la charge TLS, les bursts de session et la pression mémoire.
maxConn fixe le plafond des connexions ouvertes simultanément par pool, avec une valeur par défaut de 20 000 et une limite supérieure de 1 000 000. Cette valeur encode au niveau ADC exactement le nombre de connexions que le backend peut transporter simultanément. Lorsque la limite est atteinte, les nouvelles connexions sont soumises au comportement de file d'attente ou à un flux de rejet.
maxConnRate limite le nombre de nouvelles connexions TCP pouvant être ouvertes par seconde, avec une valeur par défaut de 10 000. Contrairement au total des connexions, ce champ régit le taux d'ouverture des connexions. Il aide à empêcher le backend d'être submergé en un seul burst lors de tempêtes de connexion, de scans agressifs ou de tests de charge mal configurés. C'est un contrôle de protection burst critique pour les services exposés au public.
maxSessRate applique un plafond par seconde aux nouvelles sessions, avec une valeur par défaut de 10 000. La réutilisation des connexions keep-alive et l'ouverture répétée de nouvelles sessions ont des coûts différents. Cette distinction est utile notamment contre les tempêtes d'ouverture de session basées sur des cookies ou le comportement de bots qui épuise les sessions applicatives. Le trafic est contraint non seulement par le nombre de connexions, mais aussi par le taux de production de sessions.
rateLimitSessions fournit un contrôle par seconde séparé pour l'allocation de nouveaux slots de connexion, avec une valeur par défaut de 5 000. Il est utilisé pour gérer le comportement d'acceptation de nouvelles connexions avec une granularité plus fine. Il aide le pool à avancer à une capacité maîtrisée lors de bursts de connexion soudains. La relation entre la capacité backend et le taux d'acceptation ADC est ajustée plus précisément.
maxSslConn définit une limite de connexions simultanées séparée pour les connexions SSL/TLS actives, avec une valeur par défaut de 5 000. Les connexions TLS doivent être traitées différemment des connexions plain en raison des coûts CPU, mémoire et de traitement cryptographique. Cette limite reflète plus précisément la capacité réelle du backend côté TLS. Elle simplifie la planification de capacité SSL, notamment pour le trafic web public et les API.
maxSslRate plafonne le nombre de handshakes SSL/TLS pouvant être initiés par seconde, avec une valeur par défaut de 2 000. Les opérations de handshake peuvent engendrer un coût élevé selon l'utilisation RSA ou ECDSA, la taille de la clé et la capacité CPU. Ce champ aide à empêcher les tempêtes de handshake TLS d'épuiser le CPU backend. Il fournit une protection plus significative qu'une limite de connexion plain lors de trafic DDoS ou de bots agressifs.
maxBufferSize fixe la taille du buffer disponible par connexion en Ko, avec une valeur par défaut de 128 Ko et une plage de 16 à 256 Ko. La consommation mémoire est contrôlée par cette valeur pour les clients lents, les lecteurs lents ou les requêtes transportant de gros corps. Ce champ fournit une protection opérationnelle contre les comportements de type Slowloris et la pression mémoire.
maxRetries définit combien de fois la connexion backend est retentée en cas d'échec, avec une valeur par défaut de 3 et une limite supérieure de 1 000. Une valeur faible permet un retour d'erreur rapide ; une valeur plus élevée peut améliorer la résilience lors de perturbations réseau transitoires. Cependant, des retries excessifs peuvent ajouter de la charge à un backend déjà en difficulté et doivent être choisis avec soin.
Un profil de limite est défini avec un nom unique et peut être assigné à plusieurs pools. La modification d'un seul profil change le comportement de connexion de tous les pools qui lui sont liés. Ce modèle réduit la nécessité de configurer chaque pool de services individuellement. Les profils de production, test, campagne ou par tenant peuvent chacun être gérés indépendamment.
Lorsqu'une limite est dépassée, les connexions peuvent attendre dans une file jusqu'à une profondeur définie. Lorsque la file est pleine, le client reçoit une erreur claire plutôt qu'un timeout silencieux. Les équipes opérationnelles peuvent identifier plus rapidement l'atteinte d'un plafond de capacité grâce à des signaux d'erreur explicites tels que 503. Le problème devient un événement de capacité mesurable plutôt qu'une attente ambiguë côté utilisateur.
Les limites de connexion du pool doivent être planifiées conjointement avec les valeurs par défaut, le comportement de désactivation par zéro, la génération global/frontend/pool et le budget mémoire.
Le modèle par défaut utilise maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K et maxBufferSize 128 Ko. Ce sont des points de départ. Le vrai réglage doit être effectué selon la capacité backend, le coût TLS et le pattern de trafic.
Tous les champs de limite acceptent 0 comme valeur minimale. Cela peut être utilisé pour les scénarios où un contrôle donné doit être désactivé ou se comporter comme illimité. En production, cependant, une valeur de 0 doit être définie délibérément — sinon la protection attendue est supprimée.
maxConn peut être réglé jusqu'à 1 000 000. Cela offre de la flexibilité pour les scénarios keep-alive très haute densité ou de pool de connexions. Même ainsi, la capacité réelle n'est pas déterminée par ce seul nombre — les descripteurs de fichiers, la mémoire, le CPU, le coût TLS et les limites backend doivent tous être pris en compte ensemble.
maxBufferSize affecte directement la consommation mémoire par connexion. Une valeur plus faible augmente la protection mémoire, mais peut introduire des problèmes de compatibilité pour les applications avec de gros corps ou des flux lents. La plage de 16 à 256 Ko permet un compromis maîtrisé entre sécurité et besoins applicatifs.
Les valeurs du profil se reflètent sur les comportements de connexion au niveau global, frontend et pool. Cette séparation permet de gérer indépendamment la capacité globale du dispositif et la capacité d'un pool spécifique. Dans les grands déploiements, la capacité totale de l'ADC et la capacité d'un seul pool ne doivent pas être confondues.
Les limites de connexion SSL sont liées au comportement de bind TLS. Des valeurs telles que maxSslConn permettent de gérer les connexions TLS séparément des connexions plain. C'est important pour protéger le budget CPU dans les services exposés au public où le trafic TLS est intense.
Une plateforme e-commerce fonctionnant avec un profil de 20 000 connexions les jours normaux peut passer à un profil à connexions plus élevées pendant une période de campagne. Le même pool est conservé ; seul le profil de limite est modifié pour se préparer au trafic de campagne.
Une banque peut autoriser un nombre total de connexions élevé sur son pool d'API interne tout en maintenant un taux de connexion et de handshake SSL plus étroit. Cette structure contrôle le coût TLS et protège le CPU backend des pics de handshake soudains.
Sur une application web exposée à Internet, le scan par bots ou les clients mal configurés peuvent ouvrir un grand nombre de connexions en peu de temps. TR7 limite le taux de nouvelles connexions via maxConnRate et rateLimitSessions, protégeant le backend d'une tempête de connexion.
Les clients à lecture lente peuvent augmenter l'utilisation du buffer par connexion. TR7 contraint la consommation mémoire de ce trafic avec un profil maxBufferSize plus faible, permettant aux autres utilisateurs de continuer à recevoir le service.
Profils de limite de connexion à 8 axes pour les tempêtes de connexion, la charge TLS et la pression mémoire des clients lents. Laissez-nous vous guider lors d'une mise en place en direct sur vos propres services.