Ce guide concerne BIG-IP sur TMOS. Les noms et options doivent être confrontés à la documentation de votre version.
Deux côtés peuvent avoir des besoins différents
Un VS Standard TCP agit comme un proxy avec un côté client et un côté serveur. Un client distant et un serveur local ne subissent pas nécessairement la même latence ni les mêmes pertes. BIG-IP permet de choisir des profils adaptés à ces côtés.
Les profils LAN/WAN proposés par F5 sont des points de départ. Leur nom ne remplace pas des mesures. Documentez le débit, la latence, les pertes et la taille des échanges avant de modifier les propriétés héritées.
Sources : F5, Protocol Profiles.
Idle timeout et keepalive
Idle timeout traite une période sans trafic ; il ne représente pas la durée totale autorisée d’une session. Une application qui reste silencieuse plusieurs minutes peut dépasser ce délai même si ses utilisateurs se considèrent encore connectés.
Les sondes TCP keepalive sont un autre mécanisme. Elles ne remplacent pas un heartbeat applicatif et ne réparent pas un serveur qui ne traite plus les requêtes. Comparez les délais du client, de BIG-IP et du serveur afin d’éviter des fermetures surprenantes.
Sources : F5, ltm profile tcp.
Nagle et buffers : comprendre le compromis
Nagle peut regrouper de petits envois. C’est un paramètre à examiner pour une application interactive, mais une latence élevée ne suffit pas à prouver qu’il est responsable. Corrélez les envois, accusés de réception et délais sur une capture.
Augmenter les buffers peut aider un flux confronté à un grand produit bande passante × délai, mais consomme de la mémoire par connexion. Dans un exemple purement arithmétique, 100 Mbit/s et 50 ms donnent 5 Mbits, soit environ 625 kB de données en vol. Ce calcul donne un ordre de grandeur, pas une valeur de buffer à imposer.
Sources : F5, ltm profile tcp ; F5, Protocol Profiles.
UDP conserve aussi un contexte sur BIG-IP
UDP n’établit pas une connexion TCP, mais BIG-IP peut garder un contexte pour les datagrammes d’un flux jusqu’à expiration. Datagram Load Balancing peut provoquer une sélection par datagramme au lieu de conserver la même destination pour ce contexte.
Ce choix convient seulement si le protocole et l’application peuvent recevoir ce traitement. Un échange qui attend plusieurs messages sur le même serveur peut échouer si l’on répartit chaque datagramme indépendamment. Le mode UDP ne rend pas tous les services stateless.
Sources : F5, ltm profile udp.
Lire avant de changer
Identifiez d’abord les profils associés et leurs parents. Comparez idle timeout, keepalive, Nagle, buffers et réglages UDP réellement hérités. Un profil partagé modifié peut affecter plusieurs applications.
tmsh list ltm virtual /Common/vs_application all-properties
tmsh list ltm profile tcp /Common/tcp_application all-properties
tmsh list ltm profile udp /Common/udp_application all-properties Sources : F5, ltm profile tcp ; F5, ltm profile udp ; F5, ltm virtual.
Mesurer un changement isolé
En laboratoire, reproduisez un échange court, une connexion longue et une période de silence. Changez une propriété à la fois. Comparez latence, retransmissions, mémoire et fermetures de connexion. Des valeurs copiées d’une application de streaming ne sont pas un réglage universel pour SSH ou une API.
Sources : F5, Protocol Profiles.
Sources et portée
Références consultées le . 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 — Protocol Profiles · BIG-IP 21.0.0 · consulté le 2 octobre 2026.
- F5 — ltm profile tcp · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — ltm profile udp · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — ltm virtual · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
Retrouver le parcours de lecture F5 LTM