Lorsque chaque requête client ouvre une nouvelle connexion backend, les ressources vont à l'établissement de connexion — pas à servir la charge de travail.
Dans le modèle de connexion classique, un grand nombre de clients se traduit par un nombre tout aussi grand de connexions TCP ou TLS côté backend. Chaque nouvelle connexion implique un handshake TCP en trois temps, un handshake TLS, la gestion des sockets et un coût de fermeture. À mesure que le trafic augmente, les backends passent plus de temps sur la surcharge de connexion que sur la logique applicative réelle.
Les requêtes API courtes et fréquentes rendent le problème plus visible. Les applications mobiles, les appels B2B, les microservices et les flux de paiement génèrent tous de nombreuses petites requêtes. Lorsque chaque requête devient une nouvelle connexion, CPU, mémoire, sockets et ressources réseau sont consommés inutilement.
Le comportement HTTP/1.1 en frontend ajoute une autre contrainte. Une requête lente sur une connexion donnée peut bloquer celles qui suivent ; la capacité de flux parallèles est limitée. Le trafic client moderne évolue plus efficacement avec HTTP/2 et HTTP/3, et la gestion des connexions backend doit suivre.
La bonne approche n'est pas de reproduire les connexions client une à une vers les backends. C'est de mettre en pool et de réutiliser les connexions, et d'ajuster le comportement de multiplexage par type de service. Les opérations non idempotentes nécessitent des modes de réutilisation plus sûrs ; les API à fort volume bénéficient de modes plus agressifs.
TR7 Connection Multiplexing délivre ce modèle : multiplexage de flux moderne en frontend, pool keepalive en backend, et une politique de réutilisation de connexion gérable par service.
Notre approche
TR7 implémente le multiplexage de connexion via un pool keepalive backend, un mode de réutilisation par service, le support des protocoles HTTP/2 et HTTP/3, et la reprise de session TLS.
Un pool de connexions backend élimine le coût d'établissement répété
Les connexions ouvertes vers le backend ne sont pas fermées immédiatement à la fin d'une requête — elles sont retournées au pool pour réutilisation. Cela réduit la surcharge des handshakes TCP et TLS côté backend.
Le mode de réutilisation est choisi pour correspondre au comportement du service
La réutilisation des connexions peut être gérée via quatre modes : never, safe, aggressive et always. Les opérateurs sélectionnent le comportement approprié pour chaque service en équilibrant les exigences de sécurité, les contraintes d'idempotence et les objectifs de débit.
Le multiplexage de flux HTTP/2 offre du parallélisme sur une seule connexion
Avec HTTP/2 ALPN, plusieurs flux parallèles sont transportés sur une seule connexion. C'est particulièrement efficace pour un grand nombre de requêtes API courtes, améliorant l'efficacité des connexions côté client.
La reprise de session TLS réduit le coût de handshake pour les clients récurrents
La reprise de session TLS permet aux clients récurrents de sauter le handshake complet. Dans les services à fort trafic TLS, cela réduit la consommation CPU et la latence d'établissement de connexion.
Capacités
Connection Multiplexing réduit la surcharge des connexions backend via la réutilisation par service, le keepalive, HTTP/2, HTTP/3 et les profils de timeout.
Le mode http-reuse met la réutilisation des connexions sous contrôle de l'opérateur
TR7 gère la réutilisation des connexions comme une action au niveau du pool. Le mode never se comporte proche d'un modèle nouvelle connexion par requête. safe offre une réutilisation plus maîtrisée. aggressive et always ciblent des économies de connexion plus importantes pour les services à fort volume. Les opérateurs choisissent le mode qui reflète les besoins en performance et en sécurité de chaque service.
Le keepalive backend réduit la surcharge d'ouverture et de fermeture des connexions
Avec le keepalive activé côté backend, les connexions retournent dans le pool à la fin d'une requête. La requête suivante récupère une connexion prête plutôt que d'en ouvrir une nouvelle. Cela réduit significativement le coût d'établissement de connexion pour les requêtes courtes et offre aux backends un profil de connexion plus stable et prévisible.
HTTP/2 ALPN supporte les flux clients modernes en frontend
TR7 supporte HTTP/2 ALPN côté client, transportant plusieurs flux sur une seule connexion. Cela réduit le nombre de connexions que les navigateurs et les clients mobiles doivent ouvrir. La latence et la consommation de ressources deviennent plus prévisibles. Le support HTTP/2 est la couche de performance de base pour le trafic web et API moderne.
HTTP/2 backend est activé par service via un toggle
HTTP/2 côté backend est opt-in au niveau du service. Lorsqu'un backend supporte HTTP/2, ALPN négocie h2 ou http/1.1 en conséquence. Les services qui ne supportent pas HTTP/2 basculent automatiquement sur HTTP/1.1. Cela permet aux backends modernes de bénéficier de HTTP/2 sans casser les services legacy.
HTTP/3 en frontend améliore le comportement des connexions sur les réseaux peu fiables
TR7 transporte le trafic client moderne via HTTP/3/QUIC en frontend. Sur les réseaux mobiles et peu fiables, l'établissement de connexion et la continuité des flux s'améliorent. Le fallback HTTP/2 préserve la compatibilité ascendante. Le côté backend est géré indépendamment selon ses propres capacités protocolaires.
Le mode safe préserve l'intégrité des données pour les opérations non idempotentes
Le mode de réutilisation safe applique un comportement plus conservateur pour les opérations risquées ou non idempotentes. Dans les API bancaires, de paiement ou à forte écriture, l'optimisation des performances ne doit pas se faire au détriment de l'intégrité des données. Ce mode maintient la réutilisation dans des limites sûres. Les opérateurs peuvent sélectionner safe plutôt qu'aggressive pour les services à haute sensibilité.
La reprise de session TLS réduit la charge CPU pour les clients récurrents
La réutilisation de session TLS permet au même client de se reconnecter sans répéter le handshake complet. Les mécanismes de tickets de session TLS 1.2 et PSK TLS 1.3 supportent tous deux ce comportement. Sous un trafic HTTPS intense, l'utilisation CPU de l'ADC est significativement réduite. C'est particulièrement précieux dans les scénarios mobiles et API avec de nombreuses connexions de courte durée.
Les profils de timeout ajustent finement le comportement du pool
Les valeurs de timeout HTTP keepalive, client-fin, server-fin, tunnel, connect, server, client et queue façonnent tous le comportement du pool de connexions. Des timeouts trop courts drainent le pool et réduisent la réutilisation. Des timeouts trop longs augmentent le nombre de connexions inactives et la consommation mémoire. TR7 rend cet équilibre gérable par profil de service.
Les limites maxconn fixent la borne supérieure de la taille du pool
Les limites de connexion peuvent être définies au niveau du pool et du backend. Ces limites aident à protéger les services backend des bursts de connexion soudains. Elles sont particulièrement importantes pour les applications à capacité de connexion plus faible ou sous licence. Combinées au multiplexage de connexion, les limites maxconn fournissent un comportement de capacité plus prévisible.
Le rate limiting des connexions contrôle les bursts de nouvelles connexions
Le taux de nouvelles connexions par seconde peut être borné par une limite supérieure. Cela empêche les services backend d'être submergés par des vagues de bots, des tempêtes de reconnexion mobile ou des pics de trafic soudains. Le pool keepalive gère la réutilisation tandis que le taux de nouvelles connexions est géré séparément. Les équipes opérationnelles peuvent contraindre le comportement des connexions non seulement par total, mais aussi par taux.
Le TCP keepalive réduit le risque de timeout NAT et pare-feu
Les signaux TCP keepalive côté client et côté backend peuvent empêcher les dispositifs réseau intermédiaires de fermer silencieusement les connexions inactives. Les connexions de longue durée sont vulnérables aux timeouts des pare-feux et des NAT. Le keepalive aide à maintenir ces connexions. C'est surtout important pour les services avec de longues sessions ou un trafic basse fréquence.
Le soft reload applique la nouvelle configuration sans abandonner les connexions
Lors d'un changement de configuration, les connexions existantes sont drainées tandis que les nouvelles connexions sont acceptées par le nouveau worker sous la configuration mise à jour. Cela évite une perturbation abrupte des pools de connexions. Les opérateurs peuvent modifier les valeurs de timeout, les modes de réutilisation ou les paramètres ALPN tout en préservant la continuité du service. Les changements en production comportent un risque opérationnel plus faible.
Profondeur opérationnelle
Le multiplexage de connexion est exploité conjointement avec l'équilibre du timeout keepalive, le comportement de drain, le dimensionnement du cache TLS, la concurrence des flux, le bridging de protocoles et les métriques de monitoring.
Équilibre du timeout keepalive
Si le timeout keepalive est trop court, les connexions se ferment avant d'avoir pu être réutilisées et l'utilisation du pool chute. S'il est trop long, le nombre de connexions inactives augmente et la consommation mémoire s'élève. La valeur doit être ajustée pour correspondre à la densité du trafic et à la capacité backend.
Drain de connexion lors du rechargement
Lors d'un soft reload, l'ancien worker draine les connexions existantes de manière maîtrisée tandis que le nouveau worker accepte les connexions sous la nouvelle configuration. C'est critique pour les changements sans interruption dans les services qui dépendent du multiplexage de connexion. La durée du drain doit être planifiée séparément pour les connexions de longue durée.
Cache de session TLS
La taille du cache de session TLS importe pour les clients qui se reconnectent fréquemment sous un trafic HTTPS intense. Un cache trop petit réduit le taux de reprise. Un cache très large doit être pris en compte dans la planification mémoire.
Comportement TCP keepalive
Le TCP keepalive au niveau OS signale aux couches intermédiaires que la connexion est toujours active. Cela réduit le risque que les dispositifs NAT, les pare-feux ou les appliances de sécurité avec état ferment prématurément les connexions inactives. Le paramètre est le plus utile pour les connexions de longue durée.
Concurrence des flux HTTP/2
Le nombre de flux parallèles sur une seule connexion HTTP/2 peut être plafonné. Une valeur trop faible réduit le bénéfice du multiplexage ; une valeur trop élevée risque de surcharger une seule connexion. Le bon paramètre dépend du mix de trafic.
Frontend HTTP/2, backend HTTP/1.1
Lorsque le côté client utilise HTTP/2 mais que le backend fonctionne en HTTP/1.1, le comportement des flux côté backend ne reproduit pas le même parallélisme. Certaines requêtes peuvent être sérialisées selon le modèle de connexion backend. Si le backend supporte HTTP/2, l'activation du toggle pertinent doit être envisagée.
Impact CPU de la terminaison TLS
Lorsque TLS est terminé par TR7 plutôt que par le backend, la charge de handshake TLS du backend disparaît. L'ADC prend en charge le coût de traitement TLS à la place. La reprise de session TLS et le pool de connexions aident ensemble à compenser ce coût.
Métriques de monitoring
Les totaux de requêtes, la profondeur de file, le nombre de connexions, le comportement de réutilisation et les métriques d'erreur reflètent l'état du pool de connexions. Une faible réutilisation mérite une révision des paramètres de timeout ou du comportement backend. Une file croissante signale que la capacité de connexion backend ou les limites maxconn peuvent nécessiter un ajustement.
Quand l'utiliser
Économies de connexion pour passerelle API à fort QPS
Les API SaaS génèrent des volumes de requêtes courts et denses. Le multiplexage de connexion réduit le nombre de connexions backend et élimine le coût répété d'établissement TCP/TLS.
Réduction de la latence de reconnexion pour le trafic API mobile
Les clients mobiles ouvrent et ferment fréquemment des connexions. Le keepalive, HTTP/2 et la reprise TLS réduisent le coût de reconnexion côté client.
Utilisation de HTTP/2 backend dans les environnements microservices
Pour les backends qui supportent HTTP/2, le toggle ALPN peut être activé pour évaluer le multiplexage de flux. Cela produit une utilisation plus efficace des connexions sur les appels inter-services à haute fréquence.
Pool de connexions persistant pour le trafic d'origine média
Le trafic edge ou client dense peut puiser dans un pool de connexions existantes vers le backend d'origine plutôt que d'en ouvrir de nouvelles en continu. Cela réduit la pression CPU et socket de l'origine.
Mode safe pour les transactions bancaires
Pour les opérations financières non idempotentes, le mode safe est préféré à la réutilisation aggressive. Cela poursuit les gains de performance tout en préservant l'intégrité des transactions.
Réduction de la surcharge TLS pour les appels API B2B
Les services B2B transportent souvent des requêtes à haute valeur et basse fréquence qui engendrent néanmoins un coût TLS significatif. Un pool de connexions et la reprise de session réduisent la surcharge d'établissement de connexion sécurisée.
Questions fréquentes
Quelle est la différence entre les modes http-reuse ?
Comment HTTP/2 est-il activé côté backend ?
Comment fonctionne la reprise de session TLS et combien de CPU économise-t-elle ?
Le support frontend HTTP/3 est-il prêt pour la production ?
Comment la valeur de timeout keepalive doit-elle être réglée ?
Les connexions existantes sont-elles abandonnées lors d'un changement de configuration ?
Libérez vos backends de la surcharge de connexion
Pool keepalive, modes http-reuse, HTTP/2, HTTP/3 et reprise de session TLS — toute l'optimisation des connexions dans une seule politique ADC. Laissez-nous vous guider lors d'une mise en place en direct sur vos propres services.