Mesurer le débit réseau d’un serveur Linux avec iperf3

Un test de débit ne doit pas se limiter à un téléchargement depuis Internet. Pour isoler un problème réseau sur un VPS ou un serveur dédié, mesurez d'abord le débit entre deux machines que vous contrôlez. iperf3 crée un flux de test entre un serveur et un client, puis affiche les résultats par intervalle et au total.

Avant le test : définir ce que vous mesurez

Un débit mesuré avec iperf3 décrit le chemin entre les deux points de test et les conditions de la session. Il ne prouve pas, à lui seul, qu'une application utilisera exactement la même capacité. Notez les deux adresses IP, le protocole testé, la durée, le nombre de flux et l'heure. Évitez de conclure à partir d'une seule exécution.

Pour une comparaison utile, utilisez une machine cliente et une machine serveur distinctes, idéalement dans les mêmes conditions lors de chaque mesure. Vérifiez aussi que le test est autorisé par votre politique réseau et que le port temporairement utilisé sera fermé après le diagnostic. Un accès SSH permet généralement de lancer les commandes sur le VPS, mais ne confondez pas le débit SSH avec le débit mesuré par iperf3.

Installer iperf3 sur les deux machines

Sur une distribution Debian ou Ubuntu, le paquet s'installe avec le gestionnaire de paquets du système :

sudo apt update
sudo apt install iperf3

Sur une autre distribution Unix, utilisez le paquet iperf3 fourni par ses dépôts officiels. Contrôlez ensuite que la commande répond :

iperf3 --version

Ne téléchargez pas un binaire inconnu pour contourner le gestionnaire de paquets. La version, le noyau, la virtualisation et la charge de chaque machine peuvent influencer le résultat.

Vérifier interface, route et DNS

Avant de lancer une mesure, relevez l'interface Ethernet ou virtuelle, la route par défaut et la configuration DNS. Ces commandes en ligne de commande aident à repérer une adresse IP inattendue, un DHCP absent ou un routeur par défaut incorrect :

ip addr
ip route
resolvectl status

La commande ip addr liste les adresses des interfaces, tandis que ip route affiche la table de routage. resolvectl status aide à distinguer une panne de résolution de nom de domaine d'une panne de transport. Un nom de domaine qui ne répond pas ne signifie pas forcément que le débit IP est insuffisant.

Examinez aussi le fichier de configuration réseau si votre distribution en utilise un, le masque de sous-réseau, la passerelle, les serveurs DNS et le statut IPv6. Une adresse statique mal configurée, une carte réseau virtuelle déconnectée ou un modem et un routeur saturés peuvent modifier le résultat. Dans un réseau local, comparez si possible une mesure avec et sans VPN, sans exposer un serveur à Internet pour le test.

Lancer le serveur et le client

Sur la première machine, démarrez iperf3 en mode serveur. L'option -s attend une connexion de test :

iperf3 -s

Depuis la seconde machine, remplacez l'adresse par l'IP privée ou publique de la première :

iperf3 -c 203.0.113.10

Le client affiche des intervalles, puis un récapitulatif. Relevez notamment le débit affiché et les éventuels messages d'erreur. Une adresse d'exemple comme 203.0.113.10 n'est pas une cible réelle : utilisez l'adresse de votre propre machine.

Rendre la mesure comparable

Répétez le test avec une durée explicite et plusieurs flux parallèles, sans multiplier les paramètres au hasard :

iperf3 -c 203.0.113.10 -t 30 -P 4

-t fixe la durée du test et -P demande plusieurs flux parallèles. Comparez plusieurs exécutions identiques, puis notez la médiane ou la plage observée. Un résultat plus élevé avec plusieurs flux ne signifie pas nécessairement qu'une seule connexion applicative atteindra ce niveau.

Pour tester le sens inverse, lancez le client avec l'option documentée par votre version d'iperf3 et vérifiez le résultat côté réception. Ne mélangez pas dans votre tableau des tests réalisés dans des sens différents.

Tester UDP avec prudence

TCP et UDP ne répondent pas aux mêmes mécanismes. Un test UDP demande une bande passante cible et doit être interprété avec le débit réellement obtenu, la gigue et les pertes signalées. Commencez avec une valeur modérée et augmentez-la progressivement :

iperf3 -c 203.0.113.10 -u -b 10M -t 20

Un résultat UDP n'est pas une autorisation d'envoyer du trafic sans limite. Arrêtez le test si vous constatez une saturation, des pertes importantes ou un impact sur un service. N'utilisez que des machines et des réseaux pour lesquels vous avez une autorisation.

Croiser le débit avec le reste du diagnostic

Avant d'accuser le réseau, vérifiez l'adresse IP utilisée, l'interface réseau, la route par défaut et les règles du firewall. Un port fermé, une mauvaise résolution DNS, un proxy ou un service web qui écoute seulement sur 127.0.0.1 peuvent donner l'impression d'un problème de débit alors qu'il s'agit d'un problème de configuration. Le nombre de connexions, la mémoire RAM et la charge CPU comptent aussi lorsque le serveur traite des requêtes.

Un test vers une IP privée et un test vers une IP publique ne répondent pas à la même question. Documentez le chemin, le réseau local ou distant, la configuration du serveur et le protocole avant de comparer les valeurs. Pour une application HTTP ou un serveur de jeu, complétez iperf3 par une mesure de latence et par les journaux du service. Ne remplacez pas une sauvegarde ou un contrôle de sécurité par un simple test réseau.

Lire les résultats sans surinterpréter

Un débit inférieur à votre attente peut venir du chemin réseau, de la capacité de la machine, d'une limitation de la plateforme, d'une règle de sécurité, d'une congestion temporaire ou des paramètres du test. Comparez d'abord les tests dans le même sens et avec les mêmes options. Vérifiez ensuite la charge CPU, les erreurs d'interface, la MTU et les journaux système.

Si iperf3 est bon mais que votre application reste lente, le goulot peut être ailleurs : traitement CPU, accès disque, base de données, configuration du service ou latence. Utilisez le test comme un élément de diagnostic, pas comme une preuve isolée.

Fermer le service de test

Une fois la mesure terminée, arrêtez le processus serveur iperf3 et retirez la règle de pare-feu temporaire si vous en avez créé une. Ne laissez pas un port de diagnostic exposé inutilement. Documentez la commande, la date, les deux extrémités et les résultats avant de modifier la configuration réseau.

Pour poursuivre le diagnostic, consultez aussi notre guide sur les ports et UFW, la méthode de diagnostic du routage d'un VPS, et le guide pour réagir à un VPS inaccessible. Si le service est destiné à un serveur de jeu, comparez également les conseils de diagnostic CPU et de diagnostic des I/O disque.

Un test iperf3 fiable est donc répétable, documenté et limité à des machines autorisées. Il aide à séparer un problème de capacité réseau d'un problème applicatif, à condition de conserver les mêmes paramètres et de vérifier les autres ressources du serveur.