Comment calculer la bande passante d’un réseau avec iperf ?

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. 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.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

    philippe-pierre has 29 posts and counting.See all posts by philippe-pierre

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

     

    Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.