Débit réseau et retransmissions sous Linux : ss -ti, nstat et iperf3

Objectif

Déterminer si un chemin réseau lent perd réellement des paquets et les retransmet, ou s'il transporte simplement moins de trafic que prévu, en s'appuyant sur les compteurs déjà disponibles sur l'hôte avant de recourir à une capture de paquets.

Prérequis

iproute2 pour ss et nstat (généralement préinstallé) ; iperf3 sur deux hôtes pour un test de débit actif ; garder à l'esprit qu'un test actif consomme de la bande passante réelle sur un lien réel.

Étapes

1. Examiner la vue d'une connexion donnée : ss -ti dst <ip> (affiner si besoin avec sport/dport). Le manuel de ss indique que -i/--info affiche les informations TCP internes ; la sortie comprend le temps aller-retour lissé (rtt:), la fenêtre de congestion (cwnd:) et, dès qu'il y en a eu, retrans:<in flight>/<total> pour ce socket précis.
2. Examiner les compteurs à l'échelle de l'hôte : nstat. Son manuel décrit nstat comme un outil de surveillance des compteurs SNMP du noyau et des statistiques des interfaces réseau ; par défaut, il affiche les incréments depuis son exécution précédente (-a affiche les valeurs absolues depuis le démarrage, -z inclut les compteurs à zéro). Repérer les compteurs liés aux retransmissions qui augmentent entre deux exécutions.
3. Comprendre la signification de ces compteurs avant d'agir : la documentation réseau du noyau définit, parmi les compteurs exposés de cette manière, des statistiques TCP étendues comme TcpExtTCPRetransFail (une tentative de retransmission qui a échoué dans une couche inférieure), à côté du compteur plus élémentaire des segments retransmis défini par SNMP, TcpRetransSegs.
4. Établir une référence avant de reproduire un transfert lent : nstat -n met à jour l'historique enregistré sans rien afficher, de sorte que le nstat suivant ne rapporte que les variations survenues depuis.
5. Si les retransmissions sont faibles mais que le débit reste décevant, mesurer directement le débit atteignable : iperf3 -s -1 sur un hôte (-1 sert un seul test puis quitte ; le port TCP 5201 doit être joignable), iperf3 -c <server> -t 10 sur l'autre, en ajoutant -R pour tester le sens inverse. La documentation d'iperf3 le présente comme un outil de mesure active de la bande passante maximale atteignable sur les réseaux IP. Limiter la durée (-t) et, sur un lien de production, effectuer le test pendant une fenêtre de maintenance : dans son mode TCP par défaut, il consomme autant de bande passante que possible pendant cette durée.
6. Si le serveur a été lancé sans -1, l'arrêter une fois le test terminé ; sinon, il reste à l'écoute.

Résultat attendu

Soit un nombre de retransmissions, pour une connexion précise ou pour l'ensemble de l'hôte, qui augmente pendant la période de lenteur, ce qui indique des pertes sur le chemin ; soit un test de débit propre conforme aux attentes, ce qui oriente plutôt vers l'application ou une limitation de débit.

Limites et base de vérification

ss -ti n'affiche que les sockets actuellement ouverts ; une connexion fermée disparaît de sa sortie, même si les compteurs cumulés de nstat en gardent la trace. iperf3 mesure le chemin entre les deux hôtes de test, qui peut différer de celui d'un client réel. Aucun de ces outils n'attribue les retransmissions à une cause (congestion, lien instable, équipement intermédiaire) ; pour cela, une capture de paquets reste nécessaire.