Capacité

Limites de connexion du pool

Encodez la capacité réelle de votre backend au niveau ADC — gérez les limites de connexion, de taux, SSL et mémoire depuis un seul profil.

TR7 Pool Connection Limits définit la quantité de trafic qu'un pool de services peut transporter en toute sécurité sur 8 axes indépendants. Les connexions simultanées, le taux de nouvelles connexions, le taux de session, les connexions SSL, le taux de handshake SSL, la taille du buffer et le comportement de retry sont tous gérés au sein du même profil de limite. Cette approche ne repose pas sur un seul champ « connexions maximales » — car 20 000 connexions keep-alive inactives et 2 000 nouveaux handshakes TLS par seconde ne génèrent pas le même coût. TR7 évalue séparément la charge plain et SSL/TLS, offrant au backend une protection plus précise contre les surcharges CPU, mémoire et tempêtes de connexion. Un profil de limite est défini une fois et peut être attaché à plusieurs pools. Des profils distincts peuvent être créés pour la production, le staging, les périodes de campagne, le web public, les API internes ou les exigences par tenant. La mise à jour centrale d'un profil met à jour le comportement de capacité de chaque pool qui lui est associé. Résultat : TR7 transforme une limite de connexion d'un simple nombre en un profil de protection opérationnel qui encode explicitement la capacité backend, le coût TLS, le comportement de file d'attente et le budget mémoire au niveau ADC.

Axes de limite indépendants dans un seul profil : connexions, taux, session, SSL, buffer, retry

Connexions simultanées maximales configurables par pool (limite supérieure de maxConn)

Taux de handshake SSL par défaut par seconde (maxSslRate) — protège le CPU backend

Une valeur unique de connexions maximales ne suffit pas à protéger la capacité d'une application moderne.

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.

Notre approche

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 profil de limite à 8 dimensions encode la capacité en détail

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.

Les connexions SSL sont plafonnées séparément du trafic plain

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.

Les profils nommés sont partagés entre plusieurs pools

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.

Les paramètres de retry et de buffer définissent le comportement de back-pressure

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.

Capacités

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 plafonne le total des connexions simultanées au niveau du pool

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 contrôle les tempêtes de nouvelles connexions par seconde

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 suit l'intensité des nouvelles sessions HTTP séparément

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 plafonne les nouveaux slots de connexion à la granularité de la seconde

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 sépare les connexions TLS actives des connexions plain

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 maintient sous contrôle la charge de handshake TLS par seconde

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 limite la consommation mémoire par connexion

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 configure le comportement de retry lors d'échecs de connexion transitoires

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.

Le binding profil-pool rend la politique de capacité gérable centralement

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.

Le comportement de file d'attente produit des erreurs visibles plutôt que des abandons silencieux

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.

Profondeur opérationnelle

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.

Valeurs par défaut du profil

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.

Désactivation par zéro

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.

Limite supérieure haute densité

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.

Budget mémoire du buffer

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.

Génération de limite multi-niveaux

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.

Limites de bind SSL

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.

Quand l'utiliser

Profil de capacité temporaire lors des journées de campagne e-commerce

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.

Séparation de la capacité SSL dans le trafic API interne bancaire

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.

Protection contre les tempêtes de connexion sur les services web public

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.

Limitation de la consommation mémoire dans le trafic de clients lents

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.

Questions fréquentes

Quelle est la différence entre maxConn et maxConnRate ?

maxConn est un plafond de capacité — le nombre maximum de connexions pouvant être simultanément ouvertes sur un pool. maxConnRate est un contrôle de taux — le nombre maximum de nouvelles connexions TCP pouvant être ouvertes par seconde. Le premier protège contre la surcharge due aux connexions accumulées ; le second protège contre les tempêtes de connexion et les attaques burst.

Pourquoi les limites de connexion SSL sont-elles définies séparément des limites de connexion plain ?

Les opérations de handshake TLS sont coûteuses en CPU par rapport aux connexions plain. Les gérer sous la même limite que les connexions HTTP plain rend la charge réelle invisible. maxSslConn et maxSslRate donnent un contrôle indépendant sur le côté TLS, ce qui est particulièrement important pour le trafic web public et les API où le budget CPU est contraint.

Que se passe-t-il lorsqu'une limite de connexion est dépassée ?

Lorsqu'une limite est dépassée, les nouvelles connexions peuvent attendre dans une file jusqu'à une profondeur configurable. Si la file est pleine, le client reçoit un signal d'erreur clair plutôt qu'un abandon silencieux. Cela rend les événements de capacité visibles pour l'équipe opérationnelle via des métriques et des signaux d'erreur explicites tels que 503.

Un seul profil de limite peut-il être utilisé sur plusieurs pools ?

Oui. Un profil est défini avec un nom unique et peut être attaché à autant de pools que nécessaire. La mise à jour centrale du profil applique le changement à tous les pools qui lui sont liés. Ce modèle réduit l'effort de configuration manuelle dans les grands déploiements avec de nombreux pools de services.

Que signifie définir un champ de limite à 0 ?

Une valeur de 0 désactive le contrôle correspondant ou le fait se comporter comme illimité. C'est utile dans des scénarios spécifiques où une limite n'est intentionnellement pas appliquée. Dans les environnements de production, 0 doit être défini délibérément — sinon la protection supposée active est silencieusement supprimée.

Comment maxBufferSize doit-il être réglé pour les gros corps de requête ?

maxBufferSize contrôle la mémoire buffer par connexion et va de 16 Ko à 256 Ko, avec une valeur par défaut de 128 Ko. Les applications avec de gros corps de requête, telles que les téléchargements de fichiers ou les payloads POST volumineux, peuvent avoir besoin d'une valeur plus élevée. Les applications qui nécessitent une protection contre la pression mémoire des clients lents peuvent bénéficier d'une valeur plus faible. Le bon réglage dépend du pattern de trafic spécifique et du comportement backend.

Protégez la capacité backend avec précision — pas un simple nombre

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.