Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.
Scénario HTTP/1.x avec profils HTTP et OneConnect, Keep-Alive serveur et trafic compatible. Après une transaction, une connexion serveur peut devenir idle et être détachée du côté client. Une nouvelle requête fait l’objet d’une sélection tenant compte de la persistance ; la réutilisation suppose un flux idle éligible vers le membre retenu. Source mask et limites du profil interviennent. Aucun flux admissible : nouvelle connexion TCP. Une connexion serveur partagée ne représente pas forcément une seule identité applicative.
Télécharger le schéma en SVG · version claireUne connexion client peut transporter plusieurs requêtes
Sans OneConnect, le comportement HTTP documenté par F5 associe normalement le choix de membre à la connexion TCP. Plusieurs requêtes du même keepalive peuvent donc rester sur la destination initiale même si leurs cookies diffèrent.
OneConnect peut détacher le côté serveur après une réponse et permettre une nouvelle décision pour la requête suivante. Il conserve aussi des connexions serveur disponibles pour réutilisation. Cela change les relations entre connexions client et connexions backend.
Sources : F5, Session Persistence Profiles.
Pourquoi un cookie ne suffit pas toujours
Considérons une connexion client qui transporte une première requête avec une affinité vers A, puis une deuxième avec une affinité vers B. Si le choix reste attaché à la connexion, regarder le second cookie ne suffit pas à expliquer une nouvelle destination. Le traitement HTTP avec OneConnect rend possible la décision par requête dans les configurations appropriées.
OneConnect ne supprime pas la persistance : il permet au système de la réexaminer au bon niveau. Il ne promet pas non plus une répartition égale de tous les objets d’une page.
Sources : F5, Session Persistence Profiles ; F5, ltm persistence cookie.
Source mask définit l’éligibilité à la réutilisation
Le source mask s’applique à l’adresse source pour déterminer quelles connexions peuvent partager une connexion réutilisable. La référence v17.0.0 décrit un masque nul permettant un partage entre clients et un masque d’hôte limitant le partage à la même adresse source.
Avec SNAT, vérifiez quelle source intervient dans votre configuration. Un masque qui paraît restrictif n’assure pas une séparation par utilisateur si plusieurs utilisateurs partagent une même adresse traduite. Ne confondez pas ce masque avec le masque source du VS.
Sources : F5, ltm profile one-connect.
La réutilisation a une durée et une capacité
Les paramètres max-age, max-reuse et max-size bornent l’âge, le nombre de réutilisations et la taille du pool de connexions. Ces paramètres ne définissent pas le nombre de membres du pool applicatif.
Les limites de connexion ont également une interaction particulière avec les requêtes en cours et les connexions idle. Une connexion conservée peut consommer des ressources alors qu’aucune nouvelle requête ne la traverse. Analysez le comportement avant de durcir les limites.
tmsh list ltm profile one-connect /Common/oc_application all-properties
tmsh list ltm virtual /Common/vs_application all-properties
tmsh show ltm profile one-connect /Common/oc_applicationSources : F5, ltm profile one-connect.
Vérifier le protocole et l’authentification
Pour HTTP, le profil HTTP permet d’identifier les frontières entre requêtes et réponses. Une authentification liée à une connexion, telle que NTLM dans certaines architectures, demande une prise en charge appropriée. Ne partagez pas aveuglément une connexion porteuse d’un état d’authentification.
Pour une application non HTTP, il faut comprendre les conditions de détachement et les messages du protocole. Ajouter OneConnect à toute application TCP sans cette analyse n’est pas une optimisation démontrée.
Sources : F5, Other Profiles.
Interpréter les traces autrement
Une capture peut montrer une connexion client et une connexion serveur qui n’ont pas été ouvertes au même instant. Une réponse ne correspond pas forcément à une nouvelle ouverture backend. Corrélez les requêtes, les réponses, le SNAT et les informations TMM plutôt que les seuls SYN.
En laboratoire, comparez deux cookies différents sur une même connexion keepalive. Vérifiez le membre choisi pour chaque requête, puis la réutilisation des connexions backend.
Sources : F5, Packet tracing with tcpdump ; F5, Capturing internal TMM information with tcpdump.
Sources et portée
Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.
- F5 — Session Persistence Profiles · BIG-IP 21.0.0 · consulté le 2 octobre 2026.
- F5 — ltm persistence cookie · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — ltm profile one-connect · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — Other Profiles · BIG-IP 21.0.0 · consulté le 2 octobre 2026.
- F5 — Packet tracing with tcpdump · Article MyF5 ; vérifier les versions applicables · consulté le 2 octobre 2026.
- F5 — Capturing internal TMM information with tcpdump · Article MyF5 ; vérifier les versions applicables · consulté le 2 octobre 2026.
Retrouver le parcours de lecture F5 LTM