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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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 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 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 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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.