Quand l'équilibrage de charge casse les sessions
Le round-robin envoie chaque requête vers un backend différent — par conception. Pour les services sans état, c'est parfait. Mais dès qu'un utilisateur se connecte, remplit un panier, ou démarre un bureau à distance, l'application commence à conserver un état sur un backend spécifique. Si la requête suivante atterrit sur un autre, l'utilisateur voit un panier vide, un écran déconnecté ou une session RDP figée.
La persistance de session (ou « affinité ») résout ce problème en épinglant un utilisateur à un backend choisi pour la durée de la session. Le problème : il n'existe pas une seule bonne façon de faire l'épinglage. La source-IP fonctionne pour les utilisateurs avec des IP uniques, mais échoue derrière un NAT d'entreprise. Les cookies fonctionnent dans les navigateurs mais pas pour les TCP bruts. Le hash sur paramètre URL fonctionne pour les URL sans état mais pas pour les flux par utilisateur. Chaque méthode est juste dans un contexte.
La réponse est d'embarquer toutes les méthodes et de choisir par vService.
Choisissez la méthode de persistance, par vService
Chaque vService choisit sa méthode de persistance dans un menu déroulant — aux côtés de son algorithme d'équilibrage de charge. Les deux couches sont indépendantes : choisissez Fastest+ pour la sélection backend et un cookie TR7 pour l'affinité, ou round-robin avec source-IP, ou toute combinaison adaptée à la charge de travail. Le choix de méthode est hot-swap, sans redémarrage.
9 méthodes embarquées
Cinq algorithmes d'équilibrage de charge auto-persistants (source, URI, URL-param, header, RDP-cookie) plus quatre méthodes de persistance explicites (cookie TR7, cookie backend, dynamique, SAM). Couvrent tous les cas courants.
SAM — contrôle total du cookie
Session Affinity Manager vous permet de définir la source du cookie (généré par TR7 ou par le backend), le format de session (UUID, IP-timestamp-aléatoire, IP-aléatoire, personnalisé) et les flags de sécurité (HttpOnly, Secure, SameSite=Strict/Lax) — sans toucher au code backend.
Composable avec tout algorithme ADC
La persistance fonctionne au-dessus de l'algorithme d'équilibrage de charge : l'algorithme choisit le backend pour la première requête, la persistance épingle le reste. Fastest+ pour le démarrage à froid, cookie sticky pour la session — fonctionne ensemble.
Hot-swap (sans redémarrage)
Changez la méthode de persistance sur un vService en production et les nouvelles sessions adoptent immédiatement la nouvelle méthode. Les sessions épinglées existantes continuent sans perturbation jusqu'à leur expiration.
9 méthodes de persistance de session embarquées
Choisissez la méthode adaptée au protocole, à la population de clients et au modèle de session de l'application. Les 9 disponibles par vService — sans code, sans plugin. Neuf est le nombre de méthodes nommées : la méthode de hachage dynamique construit sa clé à partir du langage d'expression, donc les clés sur lesquelles vous pouvez fixer une session ne se limitent pas à neuf.
Source-IP
La même IP client atterrit toujours sur le même backend. Simple, sans code, fonctionne pour tout protocole. Idéal quand les IP clients sont diversifiées — s'effondre derrière un NAT partagé ou un proxy d'entreprise.
Hash sur la longueur d'URI
Le hash sur la longueur d'URL distribue la charge par complexité d'URL tout en épinglant les URL identiques vers le même backend. Utile pour les scénarios d'affinité de cache.
Hash sur paramètre URL
Hash sur un paramètre de requête spécifique (ex. : ?user_id, ?session_token). Route la même requête par utilisateur vers le même backend sans nécessiter de cookies.
Hash sur header
Hash sur un header HTTP personnalisé. Utile quand l'appelant en amont injecte des ID de tenant ou de corrélation, ou pour le routage A/B basé sur les headers.
Cookie RDP
Lit le cookie de session RDP intégré dans la négociation de protocole. Requis pour les passerelles RDP et les fermes de bureau à distance — maintient les utilisateurs sur le même hôte RDP après reconnexion.
Cookie TR7
TR7 ADC génère et gère lui-même le cookie d'affinité — aucun code backend requis. L'opérateur définit le nom du cookie et un timeout d'inactivité maximal ; l'ADC le lit à chaque requête, le backend l'ignore. La persistance la plus facile à ajouter à une application legacy.
Cookie backend
Utilisez le cookie de session propre à l'application pour l'affinité — l'opérateur nomme le cookie (PHPSESSID, JSESSIONID, app-id, ou tout autre personnalisé) et TR7 ADC lit la valeur existante. Aucun nouveau cookie ajouté. Idéal quand l'application suit déjà les sessions et que vous ne voulez pas ajouter un deuxième cookie.
Persistance dynamique
Table de persistance par clé de hash maintenue en mémoire. Chaque entrée associe une clé — toute combinaison de headers de requête, cookies, IP source, ou paramètres URL — à un backend. L'opérateur définit la taille de la table (10K à 100M entrées, défaut 3M) et le temps d'expiration des entrées. À utiliser quand les règles de persistance doivent être plus flexibles qu'un seul cookie ou header fixe.
SAM — Session Affinity Manager
Le moteur de persistance avancé basé sur les cookies. Choisissez qui génère le cookie, le format de l'identifiant de session et les flags de sécurité — tout depuis l'UI, sans modification backend. Voir les détails ci-dessous.
SAM — Session Affinity Manager
SAM est la méthode de persistance la plus flexible de TR7. Là où un simple cookie épingle une session, SAM vous permet de contrôler chaque propriété de ce cookie depuis un menu déroulant — sans modification backend, sans écriture de code de règle.
Deux sources de cookie
Choisissez qui génère le cookie d'affinité : généré par TR7 (par défaut — sans implication backend) ou généré par le backend (utilise le cookie de session existant de l'application). Basculez entre les deux sans casser les sessions actives.
Quatre formats d'identifiant de session — dont un mode Custom entièrement ouvert
Options de format d'identifiant de session : UUID (128 bits aléatoires), IP-timestamp-aléatoire (traçable, ordonné dans le temps), IP-aléatoire (anonyme au sein d'un tenant), ou Custom. Le mode Custom ouvre la surface complète des variables de trafic — combinez tout header de requête, cookie, composant URL, info de session TLS, IP source (brute ou masquée), claims JWT, paramètres de requête, et même des champs du corps de requête avec des fonctions de transformation définies par l'opérateur (masquage, hachage, extraction de sous-chaîne, normalisation de casse, concaténation). Le même moteur de variables et de transformations pilote les clés de hash de la persistance dynamique. Consultez le focus ci-dessous pour des combinaisons réelles.
Quatre combinaisons de flags de sécurité
Flags de sécurité du cookie : HttpOnly (pas d'accès JavaScript — protection XSS), Secure (HTTPS uniquement), SameSite=Strict (pas d'envoi cross-site — protection CSRF), SameSite=Lax (variante orientée compatibilité). Combinez selon vos besoins.
Configurable par l'opérateur, sans code
Tout ce qui précède est un menu déroulant par vService dans le panneau SAM. Aucun code de règle personnalisé, aucune intégration backend, aucune règle WAAP séparée pour la gestion des cookies. SAM est une configuration, pas un script.
Au-delà des cookies et des IP — combinez toute variable de trafic
Le format Custom de SAM et les clés de hash de persistance dynamique acceptent toute variable de trafic vue par TR7 ADC — combinez-les, transformez-les, construisez la règle de persistance exacte dont votre application a besoin
Format Custom SAM — combinaisons réelles
Persistance dynamique — clés de hash multi-variables
Fonctions de transformation sur toute variable
Quand la persistance est la plus importante
Paniers e-commerce et paiement
Les utilisateurs ajoutent des articles sur plusieurs chargements de page. Le cookie backend ou le cookie TR7 maintient l'état du panier sur un seul backend — le paiement ne voit jamais un panier vide.
Tableaux de bord authentifiés
Sessions connectées où le cache de permissions de l'utilisateur réside sur un seul backend. SAM avec cookie généré par TR7 + HttpOnly + Secure fonctionne sans modification du code backend.
Passerelles RDP et fermes de bureau à distance
Les sessions RDP doivent se reconnecter au même hôte. La persistance par cookie RDP lit l'identifiant de session natif au protocole — aucune configuration supplémentaire, aucune injection de cookie.
Applications legacy sans gestion de session
Les applications qui ne suivent pas elles-mêmes les sessions. La persistance source-IP ou par paramètre URL épingle les utilisateurs sans nécessiter de modification du code de l'application legacy.
Questions courantes
Dois-je choisir entre algorithme d'équilibrage de charge et persistance ?
Quelle est la différence entre le cookie TR7 et SAM ?
Que se passe-t-il lorsque le backend épinglé tombe en panne ?
Puis-je utiliser la persistance source-IP derrière un NAT d'entreprise ?
La persistance de session affecte-t-elle les connexions WebSocket et HTTP/2 ?
Adaptez la méthode de persistance à votre charge de travail
Découvrez comment 9 méthodes de persistance couvrent tous les cas courants — des passerelles RDP aux applications legacy en passant par les cookies gérés par SAM.