Comment calculer la bande passante d’un réseau avec iperf ?
Sommaire
I. Présentation
Très souvent, lors de mes différentes missions, j’ai été confronté à la fameuse question : "quelle est la bande passante du réseau sous-jacent ?". La plupart du temps, les entreprises où je travaillais possédaient leur(s) propre(s) outil(s) de mesure. Toutefois, dans certains cas, on peut manquer de moyen ou ne pas avoir sous la main un tel outil. Pour pallier à ce manque, on peut alors faire appel à iperf, véritable couteau suisse de la mesure réseau.
II. L'outil iperf
Ce petit outil permet de mesurer la bande passante d’un réseau, mais également la qualité du lien sous-jacent. La prise de mesure s’effectue généralement entre deux machines, sur lesquelles iperf est installé. Trois caractéristiques fondamentales déterminent la qualité d’un lien :
- la latence (aussi appelé temps de réponse et abrégé en RTT) se mesurant la plupart du temps via une commande ping.
- La gigue (aussi appelée jitter ou variation de la latence).
- La perte de paquets.
Les deux derniers éléments peuvent se mesurer, nous le verrons un peu plus loin via une simple commande iperf, en filtrant les paquets de type UDP.
RAPPEL : TCP (Transmission Control Protocol) utilise des processus pour vérifier que les paquets sont correctement transmis au(x) destinataire(s) alors qu’UDP (User Datagram Protocol) envoie ses paquets sans aucun contrôle de transmission. Ce que l’on perd en qualité de service, on le gagne en vitesse de transmission.
En fait, l’outil iperf utilise l’ensemble des propriétés des protocoles TCP et UDP pour collecter et fournir des statistiques précises sur les liens réseau. On peut l’installer très facilement sur n’importe quel plateforme Unix/Linux ou Microsoft Windows. Dans son principe de base, iperf fonctionne en mode Client/Serveur : on doit donc déclencher le serveur sur la machine où l’on souhaite collecter les informations réseau, et déclencher le client sur l’autre extrémité :
Prenons l’exemple d’un serveur 'Srv', sur lequel on va installer la version iperf 2.0.10. Dès lors que l’outil est installé peut exécuter le service :
# iperf -s
REMARQUE : pour connaître la version de l’outil, il suffit d’exécuter l’instruction suivante :
$ iperf –v
Côté client, il ne reste plus qu’à lancer la collecte de statistiques via la commande ci-dessous (où 'Srv' est le nom court du serveur dont on souhaite mesurer la qualité du réseau):
$ iperf –c Srv
ATTENTION : il faut que les versions du client et du serveur soient compatibles et restent tous deux dans des versions proches. Sinon, on risque de ne pas pouvoir faire communiquer iperf client avec son serveur.
Lorsque l’on ne précise aucune durée, par défaut, l’utilitaire effectue ses mesures sur une période de soixante secondes. Le résultat se présente alors sous la forme suivante :
Ensuite, on peut s’intéresser au calcul de la bande passante bidirectionnelle en utilisant, côté client, l’option –r. Cela permet alors de faire afficher le calcul de la bande passante du client vers le serveur et réciproquement :
Côté Serveur, on devrait avoir sensiblement les mêmes valeurs que celles affichées côté client :
------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local Srv port 5001 connected with X.X.X.X port 8093 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 416 MBytes 348 Mbits/sec ------------------------------------------------------------ Client connecting to X.X.X.X, TCP port 5001 TCP window size: 119 KByte (default) ------------------------------------------------------------ [ 4] local Srvport 42058 connected with X.X.X.X port 5001 [ 4] 0.0-10.0 sec 496 MBytes 416 Mbits/sec
REMARQUE : si l’on souhaite mesurer la bande passante bidirectionnelle simultanée, plutôt que séquentiellement (avec l’option –r ci-dessus), on doit alors utiliser l’option –d.
L’outil permet également de fixer une taille de fenêtre TCP correspondant aux paquets qui peuvent être transmis dans des tampons (appelés buffers), durant une connexion, sans la validation du destinataire. Pour se faire, on utilise l’argument –w. La valeur passée en paramètre, doit être alors comprise entre 2 et 65535 et est exprimée en bytes.
$ iperf –c Srv –w 2000
Le résultat obtenu est de la forme ci-dessous :
WARNING: TCP window size set to 2000 bytes. A small window size will give poor performance. See the Iperf documentation. ------------------------------------------------------------ Client connecting to srsu337, TCP port 5001 TCP window size: 1.95 KByte ------------------------------------------------------------ [ 3] local 10.64.6.1 port 8335 connected with 10.87.2.137 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 70.9 MBytes 59.4 Mbits/sec
On distingue clairement le calcul de la fenêtre TCP (ici à la valeur 1.95 KByte) et iperf permet alors d’en déduire un taux de transfert à 70.9 MBytes et une bande passante de 59.5 Mbits/s. Au niveau du serveur, les valeurs affichées, comme pour le calcul de la bande passante doivent afficher des valeurs très proches de celles décrites ci-dessus.
ATTENTION : sur des systèmes GNU/Linux, lorsque l’on fixe une taille de fenêtre TCP via l’option –w, le noyau linux alloue alors le double de la valeur indiquée.
Dans le prolongement de ce type de mesure, on peut également souhaiter changer de port de communication (pour contourner un pare-feu, ou pour effectuer des tests sur un port autre que celui par défaut), en utilisant l’option –p.
ATTENTION : pour changer de port de communication, il faut le faire à la fois sur le serveur et sur le client :
- Côté Serveur:
# iperf –s –p 24000
- Côté Client:
$ iperf –c Src –p 24000
Par ailleurs, si l’on souhaite prolonger la durée de la mesure, qui par défaut est de dix secondes, on peut le faire en utilisant l’option –t. A l’instar de la commande ping, on peut également introduire un délai entre les prises de mesures successives en utilisant l’option –i :
$ iperf –c Srv –t 30 –i 3
Au final, on obtient alors les statistiques successives décrites ci-dessous effectuées durant une période de trente secondes avec des intervalles de trois secondes entre chacune:
------------------------------------------------------------ Client connecting to Srv, TCP port 5001 TCP window size: 63.0 KByte (default) ------------------------------------------------------------ [ 3] local X.X.X.X port 8440 connected with Srv port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 3.0 sec 122 MBytes 341 Mbits/sec [ 3] 3.0- 6.0 sec 123 MBytes 343 Mbits/sec [ 3] 6.0- 9.0 sec 124 MBytes 345 Mbits/sec [ 3] 9.0-12.0 sec 124 MBytes 347 Mbits/sec [ 3] 12.0-15.0 sec 123 MBytes 345 Mbits/sec [ 3] 15.0-18.0 sec 123 MBytes 345 Mbits/sec [ 3] 18.0-21.0 sec 124 MBytes 348 Mbits/sec [ 3] 21.0-24.0 sec 124 MBytes 345 Mbits/sec [ 3] 0.0-25.0 sec 1.00 GBytes 345 Mbits/sec
REMARQUE : l’unité de la bande passante peut être exprimée en différents formats, selon les valeurs et les lettres utilisées lors de la commande :
- En bits/s: on utilise l’option –b suivie de la valeur avec l’une des unités standards : b(its/s), k(ilobits/s), m(égabits/s), g(igabits/s).
- En octets/s: on utilise alors toujours la même option, mais avec les lettres d’unité en majuscule : B(octets/s), K(ilooctets/s), M(égaoctets/s), G(igaoctets/s).
Exemple : pour exprimer une bande passante en kilooctets/s :
$ iperf –c Srv –u –b 3K
III. Mesures et fonctionnalités complémentaires
Comme nous l’avons mentionné en préambule, le calcul de la gigue ou des pertes de paquets peut être quantifié via la commande iperf. Par défaut, si l’on ne précise pas l’option –u, l’outil effectue ses calculs statistiques en utilisant le protocole TCP. Mais, avec cette nouvelle option, iperf va alors réaliser ses mesures via le protocole UDP.
Afin de disposer d’un réseau avec une bonne qualité de lien, la perte de paquet ne doit pas dépasser 1%. Un très grand taux de perte de paquets implique alors un grand nombre de retransmissions de segments TCP, et affecte alors la bande passante.
De même, la gigue (aussi appelée jitter) représente la variation de la latence induite sans dépendance. Cela signifie que l’on peut parfaitement avoir des temps de réponse importants mais une gigue plus faible. La valeur de ce paramètre est particulièrement importante, surtout pour des liens réseau devant supporter de la voix sur IP (abrégée en VoIP). En effet, une gigue trop importante peut amener l’interruption du service et couper l’appel téléphonique. Pour régler ce niveau, on utilise alors l’option –b permettant de fixer le niveau de bande passante souhaitée.
Ainsi, côté Serveur, on va alors redémarrer une nouvelle session de prise de mesures en exécutant la commande suivante :
# iperf –s –u –i 1
Quant au client, on doit aussi lui préciser que les mesures se font sur le protocole UDP en précisant aussi la bande passante souhaitée (ici de 10Mbits/s) :
$ iperf –c Srv –u –b 10m
On recevra alors le calcul du taux de transfert et des datagrammes transmis que l’outil déduit, pour une bande passante souhaitée de 10MBits/s:
------------------------------------------------------------ Client connecting to Srv, UDP port 5001 Sending 1470 byte datagrams, IPG target: 1176.00 us (kalman adjust) UDP buffer size: 63.0 KByte (default) ------------------------------------------------------------ [ 3] local X.X.X.X port 50939 connected with Srv port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 11.9 MBytes 9.99 Mbits/sec [ 3] Sent 8507 datagrams
Ce qui est intéressant, c’est ce qu’affiche alors le serveur durant la période de mesures :
En effet, on voit alors clairement que pour une bande passante quasi constante de 10Mbits/s on affiche alors une gigue moyenne de 0.115ms. Bien évidemment ces valeurs représentent les performances d’un réseau normal (c’est-à-dire sans engorgement, sans problème de transmission ou de latence). Dans le cas où l’on aurait des valeurs moindres, il faudrait alors chercher la cause du ralentissement de trafic.
L’outil iperf permet aussi d’afficher la taille du segment maximum (ce que l’on nomme en langue anglaise Maximum Segment Size ou MSS). Il s’agit du plus grand nombre de données (exprimé en octets ou bytes), qu’une machine peut supporter un et un seul segment TCP non fragmenté. Cette valeur peut être calculée grâce à la formule suivante :
MSS = MTU – (Taille entêtes TCP et IP)
RAPPEL : la taille des entêtes TCP et IP occupent généralement 40 octets et le MTU (Maximum Transmission Unit aussi appelé unité de transmission maximale) représente la plus grande quantité d’information pouvant être transférée au sein d’une trame. Ce dernier critère diffère selon les topologies réseau mises en œuvre :
- Pour Ethernet (réseaux locaux) le MTU est de 1500 octets
- Pour PPPoE (ADSL) le MTU est de 1492 octets
- Pour Token Ring (16Mbits/s) le MTU est de 17914 octets
- Pour une connexion téléphonique le MTU est de 576 octets
Du coup, en exécutant la commande iperf cliente suivante, on devrait visualiser la taille MSS et celle du MTU :
$ iperf –c Srv –m
Au final, on devrait alors voir apparaître les lignes suivantes :
Client connecting to Srv, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local X.X.X.X port 41532 connected with Srv port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.27 MBytes 1.04 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
D’ailleurs, en utilisant l’option –M on peut alors fixer la taille de segment maximum souhaité (le fameux MSS précédent). L’option –P, quant à elle permet d’effectuer des prises de mesure en parallèle (au lieu d’une collecte unique et/ou séquentielle). Cela peut s’avérer pratique pour simuler plusieurs utilisateurs simultanés :
$ iperf –c Srv –P 2
IV. Mode daemon et supervision
Par ailleurs, iperf dispose d'une option qui peut s'avérer très pratique: -D. Ce mode déclenche l'utilisation d'iperf en mode daemon permettant d'historiser et de transférer les statistiques récoltées au sein d'un fichier passé en paramètre.
REMARQUE : sur un serveur Windows, cela transforme ainsi iperf en service s'exécutant automatiquement, à condition que services soit accessible.
Ainsi, en exécutant l'instruction suivante:
$ iperf -s -D -o <File.out>
On peut stocker l'intégralité des données en sorties d'iperf dans le fichier <File.out> passé en paramètre. Ce mode s'avère très pratique, car couplé à un outil de supervision (Nagios, Shinken, Cacti ou autre), cela permet de lister les journaux de traces comme étant des logs statiques et peut venir compléter les données graphiques des outils de supervision en question. Ainsi, iperf se transforme en agent de surveillance.
V. Conclusion
Voilà un outil bien pratique pour mesurer, décortiquer et quantifier votre réseau favori. Cela devrait vous permettre de détecter facilement les goulots d’étranglement et/ou de rechercher la cause de certaines latences à moindre coût. N’oublions jamais que les collectes de statistiques au niveau du réseau permettent d’observer l’amélioration (ou la dégradation) des performances. Il est même conseillé d’effectuer ce genre d’opérations, le plus régulièrement possible, particulièrement :
- après l’installation de nouveaux équipements
- après la configuration de nouvelles applications ou protocoles
- de façon ponctuelle, pour évaluer l’évolution du réseau
Cet outil m’a permis de nombreuses fois de mettre en évidence un problème de latence sur une ligne ou lien réseau entre deux sites distants. Dans d’autres cas, j’ai pu déterminer le point de rupture d’une application en simulant les multiples connexions simultanées via iperf afin de connaître le nombre maximum d’utilisateurs qu’une application peut véritablement supporter. En somme, un utilitaire très intuitif et surtout très efficace pour nos précieux réseaux et leurs performances.
Son frère JPERF existe avec interface graphique et qui donne la ligne de commande qu’il va exécuter.
Bonjour,
merci pour cette précision. C’est toujours bon d’avoir plusieurs cordes à son arc et plusieurs outils pour résoudre les problèmes.
Merci encore.
Bonjour
Deux petits ajouts sur cet excellent article :
> iperf3 est la « dernière » version d’iperf (enfin, il faut le dire vite puisque la dernière version iPerf 3.1.3 est sortie en juin 2016 !). C’est un recodage complet de l’appli qui a permis de corriger certaines limitations (ex: 64bits) d’iperf2 qui reste toujours d’actualité,.
> Il aurait été sympa de parler du mode daemon d’iperf, ce qui permet d’en faire un agent de surveillance
Merci
Bonjour, C’est vrai qu’iperf3 n’est pas du plus récent. Mais, c’est un outil efficace. J’ai eu l’occasion à plusieurs reprise de me servir de son prédécesseur iperf2, puis plus récemment d’iperf3. Effectivement, dès que je trouverai un peu de temps je compléterai l’article pour parler du daemon iperf ou mieux encore je ferai un nouveau tutoriel. Merci pour ces excellentes remarques.
Bonjour. Après analyse, je n’ai pas assez de matière pour créer un nouveau tutoriel. J’ai donc ajouté un paragraphe concernant iperf et le mode Daemon. Il est vrai qu’avec un outil de supervision disposer de l’intégralité des statistiques réseau peut compléter (au format logs statiques) des informations de supervision réseau.
Bonjour Mr Philippe Pierre .Document bien libellé.J’ai une préoccupation qui est la suivante:D’apres vous comment va se partager la bande passante entre les serveur iperf et le serveur http Dash?Justifiez. Merci!