Mesurer le vrai débit réseau entre deux hôtes avec iperf3

Ce guide vous montre comment utiliser iperf3, un outil gratuit en ligne de commande, pour mesurer la quantité de données qu’un serveur peut réellement envoyer à un autre sur le réseau. Il s’adresse à toute personne qui gère des hôtes Linux et veut un vrai chiffre plutôt qu’une estimation.

Vous démarrez iperf3 -s (mode serveur) sur un hôte et iperf3 -c (mode client) sur l’autre. Le client affiche ensuite un tableau avec les données transférées, le débit, Retr et Cwnd. Retr compte les retransmissions, c’est-à-dire les données qu’il a fallu renvoyer. Cwnd est la fenêtre de congestion TCP, soit la quantité de données permise en transit avant que l’autre côté en confirme la réception.

Une surprise fréquente : un résultat bien sous la vitesse du lien sur un trajet longue distance, alors que rien n’est brisé. Une seule connexion TCP (Transmission Control Protocol, le protocole de transport d’Internet) est plafonnée par la taille de sa fenêtre divisée par le temps aller-retour. Vous verrez quelles colonnes indiquent si vous avez atteint ce plafond ou une vraie panne réseau, comment le confirmer avec des flux parallèles, et quand choisir un autre outil.

Ce que vous allez accomplir

• Faire un test de débit propre dans les deux sens entre deux hôtes et lire chaque colonne du tableau de sortie.
• Distinguer un chemin qui perd des paquets d’un chemin sain dont la fenêtre TCP est trop petite.
• Utiliser les flux parallèles -P et l’option -w pour prouver lequel des deux cas vous avez devant vous.
• Mesurer la perte de paquets et la gigue en mode UDP, et comprendre pourquoi le débit -b par défaut rend les résultats UDP trompeurs.
• Sortir les résultats en JSON pour qu’une exécution planifiée puisse être graphée ou comparée dans le temps.

Prérequis

• iperf3 3.x installé sur les deux hôtes. apt install iperf3 sur Debian et Ubuntu, dnf install iperf3 sur la famille RHEL. iperf3 ne partage aucun protocole avec iperf2 : un client iperf3 ne peut pas tester contre un serveur iperf (2.x), et des versions 3.x trop éloignées se disputent parfois sur les options récentes.
• Le port TCP 5201 joignable du client vers le serveur, plus l’UDP 5201 si vous comptez faire des tests UDP. Choisissez un autre port avec -p si 5201 est déjà pris. Si l’hôte a un pare-feu, ouvrez le port avec ufw pour l’adresse du client seulement, pas pour l’internet au complet.
• Aucun droit root nécessaire sur le port par défaut. Root ne sert que si vous liez un port sous 1024.
• Une mise en garde honnête : iperf3 -s sans option écoute sur toutes les interfaces et saturera volontiers votre lien montant pour quiconque s’y connecte. Lancez-le sur des réseaux de confiance, liez-le à une seule adresse avec -B, et arrêtez-le une fois le test terminé. C’est un outil de mesure, pas un service.
• Les deux hôtes raisonnablement au repos. Un CPU occupé ou un voisin bruyant change la réponse plus que la plupart des pannes réseau.

Comment ça fonctionne

iperf3 fonctionne en paire client/serveur. Le serveur écoute sur le 5201, le client ouvre une connexion de contrôle, négocie les paramètres du test, puis ouvre un ou plusieurs flux de données et pousse des octets générés aussi vite que la socket les accepte. Rien n’est lu sur disque et rien n’est conservé : le chiffre obtenu est le plafond du transport, pas celui d’une application.

Par défaut, le client émet et le serveur reçoit. Ça compte plus qu’on ne le croit : bien des chemins sont asymétriques, soit par politique (un fournisseur qui bride le téléversement), soit par panne (un module optique défectueux dans un seul sens). L’option -R inverse les rôles dans la même session, donc le serveur émet et le client reçoit, et vous devriez toujours faire les deux.

La notion la plus utile ici est le produit bande passante-délai. Un émetteur TCP ne peut avoir qu’une fenêtre de congestion de données non acquittées en vol, donc son débit maximal vaut à peu près cwnd / RTT. Sur un chemin à 1 Gbit/s avec 42 ms d’aller-retour, remplir le tuyau demande environ 5,25 Mo en vol. Linux ajuste automatiquement le tampon d’envoi jusqu’à net.ipv4.tcp_wmem, souvent 4 Mio par défaut, et la fenêtre utilisable finit plus petite que ça une fois l’entête déduit. Un seul flux sur ce chemin plafonne donc autour de 700 Mbit/s, peu importe la santé du lien. Deux conclusions en découlent : un chiffre bas à un seul flux sur un long chemin est normal, et le correctif tient dans plus de fenêtres (-P) ou une fenêtre plus grande (-w), pas dans un billet ouvert chez le transporteur.

La colonne Retr est le diagnostic le plus rapide de l’outil. Des retransmissions veulent dire que des segments ont été perdus, ce qui sur un réseau local filaire signale une vraie panne : duplex mal négocié, port qui lâche, lien montant surchargé, ou régulateur de trafic qui jette au lieu de mettre en file. Un Retr quasi nul accompagné d’un débit bas dit que le chemin est propre et que l’émetteur n’a tout simplement jamais eu assez de données en vol.

Étape par étape

1. Confirmer que les deux côtés ont des versions compatibles. Faites-le en premier; ça explique la plupart des échecs déroutants :

iperf3 --version

iperf 3.16 (cJSON 1.7.15)
Linux node-a 6.8.0-45-generic #45-Ubuntu SMP x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment

Comparez la première ligne sur les deux hôtes. Les numéros n’ont pas à être identiques, mais la version majeure, oui.

2. Démarrer le serveur, lié et au premier plan. Le lier avec -B le tient à l’écart des autres interfaces :

iperf3 -s -B 10.0.20.5

-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

Laissez-le tourner dans ce terminal pour voir arriver les connexions et l’arrêter avec Ctrl+C. L’option -D le passe en démon et -1 le fait sortir après un seul test, ce qui est le motif le plus prudent pour une machine laissée sans surveillance.

3. Faire un test de référence. Dix secondes, un flux, des intervalles d’une seconde :

iperf3 -c 10.0.20.5 -t 10 -i 1

Connecting to host 10.0.20.5, port 5201
[  5] local 10.0.10.4 port 51234 connected to 10.0.20.5 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  38.2 MBytes   320 Mbits/sec    0    1.31 MBytes
[  5]   1.00-2.00   sec  76.2 MBytes   639 Mbits/sec    0    2.62 MBytes
[  5]   2.00-3.00   sec  81.2 MBytes   681 Mbits/sec    0    3.05 MBytes
[  5]   3.00-4.00   sec  82.5 MBytes   692 Mbits/sec    0    3.05 MBytes
[  5]   4.00-5.00   sec  82.5 MBytes   692 Mbits/sec    0    3.05 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   735 MBytes   617 Mbits/sec    0             sender
[  5]   0.00-10.04  sec   733 MBytes   612 Mbits/sec                  receiver

iperf Done.

4. Lire le tableau correctement. Transfer donne les octets déplacés pendant l’intervalle, Bitrate le même chiffre en débit, Retr les segments retransmis pendant l’intervalle, et Cwnd la fenêtre de congestion à la fin de celui-ci. Deux lignes de synthèse ferment la marche : sender est ce que le côté émetteur croit avoir poussé, receiver est ce qui est réellement arrivé. Un petit écart est normal, l’intervalle du récepteur étant un peu plus long. Un gros écart veut dire que des données se sont perdues en route. Dans l’exemple ci-dessus, Cwnd monte à 3,05 Mo puis s’arrête, Retr reste à zéro, et 3,05 Mo sur 42 ms donnent presque exactement les 617 Mbit/s rapportés. C’est un plafond de fenêtre de manuel, pas une panne réseau.

5. Écarter la montée en régime. Ces deux premiers intervalles ont tiré la moyenne vers le bas pendant que TCP ouvrait encore sa fenêtre. L’option -O retire les N premières secondes de la synthèse :

iperf3 -c 10.0.20.5 -t 30 -O 5 -i 5

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  2.42 GBytes   693 Mbits/sec    0             sender
[  5]   0.00-30.04  sec  2.41 GBytes   690 Mbits/sec                  receiver

Trente secondes dont cinq écartées est un défaut sensé pour tout ce qui traverse un réseau étendu. Sur un long chemin, un test de dix secondes mesure surtout le démarrage lent.

6. Tester l’autre sens. L’option -R inverse qui émet, sur la même connexion de contrôle et le même serveur :

iperf3 -c 10.0.20.5 -t 30 -O 5 -R

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.04  sec  1.02 GBytes   291 Mbits/sec  1842             sender
[  5]   0.00-30.00  sec  1.01 GBytes   290 Mbits/sec                   receiver

La moitié du débit aller et 1842 retransmissions : ce sens-là perd vraiment des paquets. L’option --bidir fait les deux sens en même temps, ce qui est un test différent et plus dur — servez-vous-en pour voir si les deux sens se nuisent, pas comme substitut à deux passes propres dans un seul sens.

7. Se servir des flux parallèles pour séparer la fenêtre du lien. Chaque flux a sa propre fenêtre de congestion, donc -P multiplie les données que vous pouvez garder en vol sans toucher à un seul réglage noyau :

iperf3 -c 10.0.20.5 -t 30 -O 5 -P 4

[ ID] Interval           Transfer     Bitrate         Retr
[SUM]   0.00-30.00  sec  3.28 GBytes   940 Mbits/sec  0             sender
[SUM]   0.00-30.04  sec  3.27 GBytes   936 Mbits/sec                receiver

Lisez la ligne [SUM], pas les lignes par flux. Un flux donnait 693 Mbit/s et quatre en donnent 940 sur un lien gigabit : le chemin allait bien depuis le début et le flux unique était borné par la fenêtre. Si quatre flux totalisent la même chose qu’un seul, vous avez trouvé un vrai goulot.

8. Ou monter la fenêtre directement. L’option -w fixe le tampon de socket, et le noyau double la valeur demandée tout en désactivant l’ajustement automatique pour cette socket :

iperf3 -c 10.0.20.5 -t 30 -O 5 -w 8M

[  5] local 10.0.10.4 port 51248 connected to 10.0.20.5 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-30.00  sec  3.26 GBytes   933 Mbits/sec    0    8.12 MBytes

C’est un diagnostic, pas un correctif. Si -w 8M règle le problème, le vrai changement consiste à monter net.ipv4.tcp_rmem et net.ipv4.tcp_wmem sur les hôtes qui portent la charge réelle.

9. Mesurer la perte et la gigue avec UDP. Le mode UDP ne recule devant rien, donc il rapporte ce que le chemin jette. Le détail critique : -u tout seul n’émet qu’à 1 Mbit/s dans iperf3, il faut donc régler -b au débit que vous voulez offrir :

iperf3 -c 10.0.20.5 -u -b 900M -t 20 -O 2

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-20.00  sec  2.09 GBytes   900 Mbits/sec  0.000 ms  0/1589424 (0%)  sender
[  5]   0.00-20.04  sec  2.06 GBytes   885 Mbits/sec  0.084 ms  25937/1589424 (1.6%)  receiver

Seule la ligne receiver porte des chiffres de perte et de gigue exploitables; la ligne sender rapporte ce qu’elle a remis à la socket. Réservez -b 0 (sans limite) aux moments où vous cherchez la falaise, et attendez-vous à perdre beaucoup de paquets et à nuire à tout ce qui partage le chemin.

10. Sortir du JSON pour les exécutions scriptées. L’option --json remplace tout le tableau par un seul document lisible par une machine :

iperf3 -c 10.0.20.5 -t 30 -O 5 --json | jq '.end.sum_sent.bits_per_second, .end.sum_sent.retransmits'

693114882.1
0

Ajoutez --logfile pour l’écrire quelque part depuis une tâche cron, et --get-server-output pour replier la vue du serveur dans le même document.

Valider le fonctionnement

Vérifier que le serveur a bien vu le test. Le terminal du serveur affiche chaque connexion, et les identifiants doivent correspondre à ceux du client :

Accepted connection from 10.0.10.4, port 51232
[  5] local 10.0.20.5 port 5201 connected to 10.0.10.4 port 51234
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-30.04  sec  2.41 GBytes   690 Mbits/sec

Confronter le résultat à la vitesse négociée du lien. Un test qui affiche 94 Mbit/s sur du matériel que vous croyez gigabit trahit d’habitude un problème de duplex ou d’autonégociation, pas de réglage :

ethtool eno1 | grep -E 'Speed|Duplex'

	Speed: 1000Mb/s
	Duplex: Full

Vérifier que la mesure est reproductible. Trois passes consécutives de 30 secondes devraient tomber à quelques pour cent l’une de l’autre. Une forte dispersion veut dire que quelque chose d’autre utilise le chemin, et chacun de vos chiffres devient suspect.

Dépannage

• iperf3: error - unable to connect to server: Connection refused. Rien n’écoute sur cette adresse et ce port. Confirmez que le processus serveur tourne, que vous ne l’avez pas lié avec -B à une adresse que le client ne peut pas joindre, et que le port concorde des deux côtés. Un Connection timed out plutôt qu’un refused pointe vers un pare-feu qui jette en silence, pas vers un service absent.
• iperf3: error - the server is busy running a test. try again later. iperf3 ne sert qu’un test à la fois, par conception. Soit quelqu’un d’autre teste, soit un client précédent est mort et le serveur n’a pas encore expiré. Attendez, ou lancez un deuxième serveur sur un autre port avec -p 5202.
• Le client fige, puis échoue sur une erreur de message de contrôle. Incompatibilité de version classique. Un client iperf3 pointé vers un serveur iperf 2.x ne termine jamais la poignée de main : ils partagent un numéro de port et rien d’autre. Lancez iperf3 --version sur les deux hôtes et vérifiez le nom du binaire — iperf et iperf3 sont deux paquets distincts qui peuvent cohabiter.
• Les résultats UDP semblent absurdement bas et sans perte. Vous avez oublié -b. Sans lui, iperf3 n’offre que 1 Mbit/s, alors forcément rien ne tombe. Réglez -b près de la capacité attendue, et rappelez-vous que la ligne receiver est celle qui compte.
• Le débit cale sur un chiffre rond bien en dessous du lien et Retr reste à zéro. Regardez le CPU avant le réseau. iperf3 traite chaque flux dans un seul fil, donc un flux seul ne peut pas dépasser ce qu’un cœur sait faire — souvent un mur quelque part entre 10 et 40 Gbit/s selon le processeur, le MTU et l’état des déchargements. Surveillez top pendant la passe; un fil collé à 100 % est votre réponse. Répartissez avec -P et épinglez avec -A au besoin. Sur des liens de 25 Gbit/s et plus, traitez iperf3 comme un test de fumée, pas comme une mesure du matériel.
• Les chiffres ne concordent pas avec ce que voit l’application. iperf3 mesure un flux en vrac, sans temps de réflexion, sans TLS et sans allers-retours requête/réponse. Si votre application est bavarde, c’est la latence qui domine et un test de débit ne la reflétera pas. Capturez plutôt le vrai trafic — utilisez tcpdump avec des filtres de capture pour voir ce que l’application fait vraiment sur le fil.

Quand ce n’est pas la bonne approche

• Diagnostiquer la latence ou la gigue d’un trafic interactif. Un test de débit remplit délibérément les files d’attente, ce qui gonfle la latence même que vous cherchez à mesurer. Utilisez ping, mtr ou irtt pour ça, et faites-les tourner quand iperf3 ne tourne pas.
• Tester au-delà d’environ 25 Gbit/s. L’outil devient le goulot. Vous mesurerez votre processeur, votre MTU et les déchargements de votre pilote. Ce terrain appartient aux bancs d’essai spécialisés ou aux générateurs de trafic matériels.
• Tester sur l’internet public comme mesure de capacité. Vous mesurez le pire saut entre vous et un serveur que vous ne contrôlez pas, plus le bridage qui traîne au milieu, plus la charge de ce serveur. C’est une bonne vérification de joignabilité et un mauvais chiffre de capacité.
• Prouver qu’un lien va bien alors que la plainte porte sur une application. Le plein débit entre deux hôtes ne dit rien d’une requête lente, d’un bassin de connexions saturé ou d’une résolution DNS qui prend deux secondes. Confirmez où passe le temps avant de sortir un test de bande passante.
• Sur un réseau qui ne vous appartient pas ou qu’on ne vous a pas demandé de tester. Saturer volontairement un lien dérange et ressemble à s’y méprendre à une attaque dans la supervision de quelqu’un d’autre. Obtenez l’accord d’abord, et planifiez la fenêtre.

La référence faisant autorité est la documentation iperf3 d’ESnet, qui couvre chaque option et le schéma de sortie JSON.

Si c’est le genre de travail que vous préféreriez ne plus jamais porter, c’est le quotidien d’Opérations Cloud — réservez une revue d’infrastructure.