Métrologie et mesure de performances

1. Définition de la métrologie

La métrologie fait partie intégrante de la supervision. Elle désigne globalement la science de la mesure qui s’applique dans de nombreux domaines et notamment dans les réseaux informatiques. Au-delà de la simple mesure, la métrologie s’applique à garantir la mesure et à l’interpréter.

Les utilisateurs se plaignent d’un réseau lent, d’un mauvais débit lors du téléchargement de fichiers sur le cloud, d’une application qui met trop de temps à répondre : Comment solutionner ces problématiques sans éléments quantifiables et comparables ? Comment mesurer le temps de réponse d’un applicatif ? Comment mesurer un débit ? Avec quelle(s) unité(s) ? Comment s’assurer qu’un prestataire assure un service selon les SLA contractuelles ?

Si on ne met pas en place des moyens pour mesurer les performances d’un réseau ou d’une application, il sera alors difficile d’en évaluer la qualité. Ainsi, la réflexion sur l’amélioration des performances actuelles ou futures est impossible sans les évaluer concrètement selon des métriques bien déterminées. On admet aisément que la perception de vitesse de l’accès à une application par un utilisateur est une donnée à prendre en compte, mais qui n’est pas mathématiquement comparable et reste assez subjective.

Il faut qualifier ce ressenti de lenteur par une mesure précise, qui pourrait être celle du temps d’affichage de la page d’accueil d’un site Intranet à la suite de l’identification d’un utilisateur par exemple, donc évaluable en secondes. Cette valeur pourrait être quantifiée à plusieurs moments de la journée afin d’évaluer le temps de réponse moyen en période de forte ou faible utilisation. Ce relevé de moyennes permettrait également d’évaluer les conséquences induites par la modification du code de l’application par l’équipe de développement, par une modification du système d’exploitation...

1. Débit brut et débit applicatif

Les opérateurs ont l’habitude d’exprimer les débits d’une connexion de type xDSL en débit ATM. Ainsi, une connexion ADSL2 annoncée à 28 Mbits/s en téléchargement ne représente pas vraiment le débit réel mesuré, même en faisant abstraction d’une inévitable atténuation du signal qui est fonction de la distance de l’abonné. D’ailleurs, un test de débit nous fournira un résultat autour des 22 Mbits/s, c’est ce que les opérateurs appellent le débit IP, c’est-à-dire le débit disponible en omettant le débit supplémentaire utilisé par un ou plusieurs protocoles de niveau inférieur au protocole IP, comme justement ATM (cf. chapitre Évolution des métiers autour des réseaux - section L’évolution vers les réseaux ATM). En fait, il ne faut pas oublier que pour la transmission de données, ces dernières sont encapsulées dans différents protocoles qui utilisent des en-têtes de différentes tailles, potentiellement variables. Ces en-têtes utilisent donc du débit supplémentaire (puisque le nombre de bits à transmettre est augmenté).

Lorsque l’on parle de débit, il est nécessaire de préciser à quel niveau de la couche OSI on se place, par défaut on a pris l’habitude de faire référence au débit IP. Mais si l’application en question utilise TCP au lieu d’UDP, ainsi qu’IPv6 au lieu d’IPv4, la transmission d’un fichier sera plus longue, car les en-têtes TCP et IPv6 pour notre exemple ont une taille plus importante. Sachant qu’en plus il existe une taille maximum pour un paquet donné appelée MTU (Maximum Transfer Unit), nécessitant qu’au-delà de cette valeur, les données soient fragmentées et utilisent donc davantage de bits pour les en-têtes, puisqu’on utilise plus de paquets.

Le piège serait donc d’effectuer le calcul suivant : une application transfère un fichier de 25 Mo, disposant d’un lien à 100 Mbits...

1. Mesure de la latence et de la gigue

a. Ping

Le protocole ICMP, par la génération de messages Echo Request et des réponses correspondantes Echo Reply, permet de vérifier, d’une part, la connectivité réseau entre deux machines sur un réseau WAN ou LAN (par la commande ping), et d’autre part, indirectement, de remonter des valeurs de latence sur l’ensemble du ou des réseaux traversés. La latence correspond à l’un des métriques réseau défini dans ce chapitre à la section Les métriques réseau.

Le résultat d’une commande ping vers un destinataire joignable s’accompagne ainsi du temps écoulé entre l’envoi de la requête ICMP et la réponse correspondante, c’est-à-dire le temps de l’aller-retour sur le réseau ou RTT. On obtient la latence en divisant cette valeur par 2, en général elle reste symétrique bien que le trajet aller emprunté par un paquet IP peut différer du trajet retour.

La latence est fonction du support utilisé ainsi que de sa longueur. Les latences les plus faibles sont atteintes sur des supports fibrés, les latences les plus élevées se retrouvent souvent sur des connexions sans-fils type satellite ou 4G.

Voici un tableau représentant les valeurs de RTT « habituelles » sur une connexion WAN lors d’un test de ping entre deux machines en France, selon le type de connexion utilisé :

SUPPORT PHYSIQUE	RTT moyen attendu
ADSL/VDSL (cuivre)	Entre 30 ms et 80 ms
Fibre optique	Entre 2 ms et 25 ms
Connexion câblée (coaxial)	Entre 15 ms et 40 ms
4G	Entre 40 ms et 60 ms
3G	Entre 90 ms et 130 ms
Wimax	Entre 65 ms et 85 ms
Satellite	Entre 500 ms et 900 ms

Obtention du RTT via le résultat de la commande ping. La latence étant donc de 7 ms sur cette capture pour un RTT de 14 ms

La latence peut être également évaluée par rapport à l’utilisation de protocoles de plus haut niveau qu’ICMP, concrètement au niveau transport via TCP ou UDP. Pour cela, on peut utiliser l’utilitaire echoping évoqué à la section Méthodologie...

1. Stocker les mesures