tutoriel iperf3 : Mesurer les performances d'un réseau sous Linux et Windows

iperf3 est un outil en ligne de commande qui permet 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, et la manière de régler votre système pour obtenir des résultats précis sur des liaisons à haut débit.

Installer iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Confirmez l'installation avec iperf3 --version. Installez-le sur le serveur et les machines clientes.

Fedora / CentOS / Rocky / Alma

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

sudo dnf install iperf3

Sur CentOS 7, utilisez plutôt yum. Si le paquet n'est pas trouvé, 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 repo GitHub ar51an/iperf3-win-builds. Extrayez-le dans un dossier comme C:\iperf3, puis vérifiez :

cd C:\iperf3
iperf3.exe -v

Pour lancer 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 entrant autorisant TCP sur le port 5201 dans Windows Defender Firewall.

Configuration du serveur

Démarrez le serveur avec :

iperf3 -s

Il écoute sur le port TCP 5201 par défaut. Pour le faire fonctionner 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 se lier à une interface spécifique, utilisez -B:

iperf3 -s -B 192.168.1.10

Pour les tests ponctuels, iperf3 -s -1 gère une seule connexion client et quitte ensuite. Sur les liaisons à large bande passante (40 Gbps+), exécutez plusieurs instances de serveur sur des ports différents afin de contourner les limites imposées par le processeur à un seul thread.

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

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

Exécution des tests clients

Test TCP de base

iperf3 -c 192.168.1.10

Ce test mesure la bande passante de téléchargement sur 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 seul flux TCP plafonne souvent à 3-5 Gbps en raison des limites du processeur à cœur unique. Utilisez des flux parallèles pour saturer la liaison :

iperf3 -c 192.168.1.10 -P 8

Lecture des résultats

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

• Retr (retransmissions). Un nombre élevé signifie une perte de paquets ou un encombrement.
• Cwnd (fenêtre de congestion). S'il est bas ou bloqué, les limites de la taille de la mémoire tampon ou de la fenêtre limitent le débit.

Sur une liaison propre de 1 Gbps, il faut s'attendre à un débit d'environ 940 Mbps après les frais généraux du protocole. Le test se termine par les lignes de résumé de l'expéditeur et du destinataire. Sur un réseau stable, ces lignes devraient correspondre étroitement.

Pour les tests UDP( drapeau-u ), la sortie ajoute la gigue (variance d'arrivée des paquets) et les datagrammes perdus/total. 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'option --bidir (iperf3 3.7+) permet de tester simultanément le chargement et le téléchargement :

iperf3 -c 192.168.1.10 --bidir

Les deux connexions proviennent du client, ce qui permet de traverser le NAT sans ouvrir de ports supplémentaires. Si les résultats des tests bidirectionnels sont beaucoup plus faibles que ceux des tests unidirectionnels, il se peut que votre routeur ou votre modem câble ait du mal à gérer le trafic full-duplex.

Mode inversé

L'option -R inverse le flux de données de sorte que 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

De grandes différences entre les résultats en mode avant et en mode arrière indiquent des chemins asymétriques, un encombrement ou une mauvaise 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 dissimule derrière des retransmissions. Définissez toujours une bande passante cible avec -b, car iperf3 propose 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

Repères de qualité : une gigue inférieure à 5 ms est bonne pour la VoIP, une gigue supérieure à 30 ms provoque des problèmes audibles. La 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 fait passer la liaison à une vitesse inférieure.

MSS affiche 536 octets sur Ethernet ? La fonction 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 la bande passante et ajoute de la surcharge.

L'unité centrale est au maximum de ses capacités sur les liaisons rapides ? Utilisez -Z (zerocopy) pour réduire la charge du processeur. Pour les liaisons à plus de 40 Gbps, exécutez plusieurs instances de serveur sur différents ports et répartissez-les sur les cœurs de l'unité centrale.

Résultats incohérents ? Utilisez -O 3 pour ne pas tenir compte des premières secondes pendant lesquelles la fenêtre d'encombrement TCP augmente. Laissez 30 secondes entre les tests pour vider les tampons du réseau.

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

Réglage des tampons TCP

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

Ajoutez ces paramètres au fichier /etc/sysctl.d/99-tcp-tuning.conf et appliquez-les avec sudo sysctl -p :

Gardez net.ipv4.tcp_moderate_rcvbuf à 1 pour que le noyau s'adapte automatiquement à ces plages. Activez net.ipv4.tcp_window_scaling (réglé sur 1) pour les fenêtres TCP de plus de 64 Ko.

Vous pouvez également passer de l'algorithme de congestion CUBIC par défaut à l'algorithme BBR de Google. Sur les liens à forte latence avec quelques pertes de paquets, BBR fournit systématiquement un débit plus élevé que CUBIC.

Utilisez l'option -w dans iperf3 pour tester des tailles de tampon spécifiques, mais notez qu'elles ne peuvent pas dépasser les valeurs rmem_max ou wmem_max du noyau. Commencez par 8 Mo pour les liaisons gigabit, 512 Ko pour 100 Mbps.

Si vous provisionnez des serveurs dédiés et souhaitez valider les performances du réseau, exécutez les tests de base iperf3 juste après l'installation et après toute modification du réseau afin de détecter rapidement les régressions.

Recommandation vidéo