Tutoriel iperf3 : Mesurer les performances réseau sous Linux et Windows

iperf3 est un outil en ligne de commande permettant de mesurer la bande passante, la gigue et la perte de paquets entre deux machines. Il utilise un modèle client-serveur : une machine écoute, l'autre envoie du trafic, et vous obtenez des chiffres précis sur le débit. Ce guide couvre l'installation, les tests de base et avancés, ainsi que la manière d'optimiser votre système pour obtenir des résultats précis sur des liaisons haut débit.

Installation d'iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Vérifiez l'installation avec iperf3 --version. Installez-le à la fois sur le serveur et sur les machines clientes.

Fedora / CentOS / Rocky / Alma

Sur Fedora 22+ ou CentOS 8+, Rocky ou AlmaLinux :

sudo dnf install iperf3

Sur CentOS 7, utilisez yum à la place. Si le paquet est introuvable, activez d'abord le dépôt EPEL :

sudo yum install epel-release
sudo yum install iperf3

Si votre pare-feu est actif, ouvrez le port 5201 :

sudo firewall-cmd --add-port=5201/tcp --permanent
sudo firewall-cmd --reload

Windows

Téléchargez l'exécutable autonome depuis iperf.fr ou le dépôt GitHub ar51an/iperf3-win-builds. Extrayez-le dans un dossier tel que C:\iperf3, puis vérifiez :

cd C:\iperf3
iperf3.exe -v

Pour exécuter iperf3 depuis n'importe quel répertoire, ajoutez le dossier à votre PATH système via Propriétés système > Avancé > Variables d'environnement. Vous devrez également créer une règle de pare-feu entrante autorisant le protocole TCP sur le port 5201 dans le pare-feu Windows Defender.

Configuration du serveur

Démarrez le serveur avec :

iperf3 -s

Par défaut, cela écoute sur le port TCP 5201. Pour l'exécuter en arrière-plan avec journalisation :

iperf3 -s -D --logfile /var/log/iperf3.log

Vérifiez qu'il fonctionne avec ss -tulpn | grep 5201.

Si le port 5201 est bloqué sur votre réseau, utilisez -p pour choisir un autre port. Pour le lier à une interface spécifique, utilisez -B:

iperf3 -s -B 192.168.1.10

Pour des tests ponctuels, iperf3 -s -1 gère une seule connexion client puis se ferme. Sur les liaisons à haut débit (40 Gbps+), exécutez plusieurs instances de serveur sur des ports différents pour contourner les limites du processeur à un seul thread.

Assurez-vous que votre pare-feu autorise le trafic sur le port choisi. Sous Ubuntu/Debian avec UFW :

sudo ufw allow 5201/tcp
sudo ufw allow 5201/udp   # if testing UDP

Exécution des tests client

Test TCP de base

iperf3 -c 192.168.1.10

Ce test mesure la bande passante en upload via TCP pendant 10 secondes. Prolongez la durée avec -t:

iperf3 -c 192.168.1.10 -t 30

Sur des liaisons de 10 Gbps ou 25 Gbps, un flux TCP unique atteint souvent un pic de 3 à 5 Gbps en raison des limites des processeurs monocœur. Utilisez des flux parallèles pour saturer la liaison :

iperf3 -c 192.168.1.10 -P 8

Interprétation des résultats

Chaque ligne d'intervalle indique le transfert (données envoyées) et le débit binaire (débit). Pour TCP, surveillez également :

• Retr (retransmissions). Des chiffres élevés indiquent une perte de paquets ou une congestion.
• Cwnd (fenêtre de congestion). Si elle est faible ou bloquée, les limites de taille de la mémoire tampon ou de la fenêtre plafonnent le débit.

Sur une liaison 1 Gbps propre, attendez-vous à environ 940 Mbps après la surcharge du protocole. Le test se termine par des lignes récapitulatives pour l'émetteur et le récepteur. Sur un réseau stable, celles-ci devraient correspondre étroitement.

Pour les tests UDP (-u flag), la sortie ajoute la gigue (variation d'arrivée des paquets) et le nombre de datagrammes perdus/totaux. Une gigue inférieure à 1 ms et une perte de 0 % sont idéales pour le trafic en temps réel comme la VoIP.

Indicateurs utiles

Tests avancés

Tests bidirectionnels

L' --bidir indicateur (iperf3 3.7+) teste simultanément le téléchargement et l'envoi :

iperf3 -c 192.168.1.10 --bidir

Les deux connexions proviennent du client, ce qui permet de passer par le NAT sans ouvrir de ports supplémentaires. Si les résultats bidirectionnels sont nettement inférieurs à ceux des tests unidirectionnels, votre routeur ou votre modem câble peut avoir des difficultés à gérer le trafic en duplex intégral.

Mode inversé

L' -R indicateur inverse le flux de données : le serveur envoie et le client reçoit. Cela permet de mesurer la vitesse de téléchargement sans inverser les rôles :

iperf3 -c 192.168.1.10 -t 30 -i 5 -R

Des différences importantes entre les résultats en mode direct et en mode inverse indiquent des chemins asymétriques, une congestion ou des erreurs de configuration de la mémoire tampon.

Tests UDP

Les tests UDP révèlent la gigue et la perte de paquets, que le protocole TCP masque derrière des retransmissions. Définissez toujours une bande passante cible avec -b, car iperf3 utilise par défaut 1 Mbps pour UDP :

iperf3 -c 192.168.1.10 -u -b 1G

Pour simuler le trafic VoIP (100 appels, paquets de 200 octets) :

iperf3 -c 192.168.1.10 -u -b 8M -l 200

Références de qualité : une gigue inférieure à 5 ms est acceptable pour la VoIP, tandis qu'une gigue supérieure à 30 ms entraîne des problèmes audibles. Une perte de paquets supérieure à 0,1 % dégrade sensiblement les médias en temps réel.

Réglage et dépannage

Problèmes courants

Vous n'obtenez que 100 Mbps sur une liaison Gigabit ? Vérifiez la vitesse de votre interface physique avec ethtool eth0. L'auto-négociation échoue parfois et réduit la vitesse de la connexion.

Le MSS affiche 536 octets sur Ethernet ? La découverte du MTU de chemin (Path MTU Discovery) est probablement désactivée. Le MSS par défaut pour un MTU de 1 500 octets est de 1 460 octets. Utilisez -m pendant les tests pour vérifier. Un MSS de 536 octets gaspille de la bande passante et ajoute une surcharge.

Le CPU est saturé sur les liaisons rapides ? Utilisez -Z (zerocopy) pour réduire la charge du processeur. Pour des débits supérieurs à 40 Gbps, exécutez plusieurs instances de serveur sur des ports différents et répartissez-les sur les cœurs du processeur.

Des résultats incohérents ? Utilisez -O 3 pour omettre les premières secondes pendant que la fenêtre de congestion TCP monte en puissance. Laissez 30 secondes entre chaque test pour vider les tampons réseau.

Un flux unique est-il beaucoup plus lent que les flux parallèles combinés ? Si un flux atteint 200 Mbps mais que huit flux combinés atteignent 1,6 Gbps, la fenêtre TCP ou les tampons du système d'exploitation limitent le flux unique. Réglez les tampons ci-dessous.

Réglage des tampons TCP

Commencez par calculer le produit bande passante-délai (BDP) : bande passante x RTT. Une liaison de 10 Gbps avec un RTT de 50 ms donne un BDP de 62,5 Mo. Réglez votre tampon maximal à au moins 2 fois le BDP.

Ajoutez ces valeurs /etc/sysctl.d/99-tcp-tuning.conf et appliquez avec sudo sysctl -p:

Réglez net.ipv4.tcp_moderate_rcvbuf réglé sur 1 pour que le noyau effectue un réglage automatique dans ces plages. Activez net.ipv4.tcp_window_scaling (régler sur 1) pour les fenêtres TCP supérieures à 64 Ko.

Vous pouvez également passer de l'algorithme de congestion CUBIC par défaut au BBR de Google. Sur les liaisons à forte latence présentant une certaine perte de paquets, le BBR offre systématiquement un débit plus élevé que le CUBIC.

Utilisez l' -w indicateur dans iperf3 pour tester des tailles de tampon spécifiques, mais notez que celles-ci ne peuvent pas dépasser la valeur définie par le noyau rmem_max ou wmem_max. Commencez par 8 Mo pour les liaisons Gigabit, 512 Ko pour les liaisons 100 Mbps.

Si vous provisionnez des serveurs dédiés et souhaitez valider les performances réseau, exécutez des tests de référence iperf3 immédiatement après la configuration et après toute modification du réseau afin de détecter rapidement les régressions.

Recommandation vidéo