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