par René Pfeiffer(Copyright © 2010) lynx@luchs.at
traduction par BENMEKKI MALIK (tous droits réservés) malik@benmekki.com
relecture MARTIN Antoine martinantoine59000@gmail.com
À partir du printemps 2009, des problèmes de réseaux sont apparu sur les sites de certains clients : transmissions de données se bloquaient puis expiraient ; les connexions via VPN fonctionnaient dans un premier temps mais expiraient dès que de nouvelles données étaient transmises ; les connexions VPN utilisant le mode UDP n'étaient pas du tout fonctionnelles (mais l'étaient curieusement le port de l'OpenVPN était modifié à 80/TCP). Tous ces symptômes sont généralement liés au format du trafic, les problèmes liés à la MTU (unité de transfert maximale) ou à d'autres problèmes souvent constatés entre les extrémités de la transmission . Mais comment pourriez-vous tester et enregistrer la performance de "votre" internet ?
Tout d'abord, vous pouvez utiliser des outil réseaux pour inspecter le trajet entre deux hôtes de communication.
La plupart des outils affichent les messages d'erreurs, temps de réponse d'un aller-retour ( RTT ) et autres informations utiles. Bien que beaucoup de monde fait confiance aux résultats de ces outils, il faut toujours garder en tête que l'envoi des paquets de test n'est pas la même chose que d'envoyer des données réelles via différents protocoles. Il y a des routeurs et autres équipements réseaux qui ne traitent pas chaque paquet de manière égale.
Un site rapportait de très étranges effets. Immédiatement après avoir utilisé un client Bittorrent ou un protocole via un "mauvais port", la bande passante du trafic réseaux "régulier" a décliné de façon notable. Après une demi-heure ou plus, la performance revenait à la normale. Ce comportement pourrait indiquer une violation de la neutralité du réseau , la présence de filtres ou autres défaillances. Le principal problème est d'en trouver la cause, car cela pourrait être lié au trajet du réseau, aux matériels défectueux, à l’interruption d'un programme, aux priorités du trafic réseaux, au renforcement de la politique ou d'autres raisons encore. Si des équipements réseaux intermédiaires manipulent le flux des paquets, il y aura alors de fortes chances que vous ne puissiez jamais identifier ou "voir" ces appareils avec les outils disponibles.
Utiliser des données "réelles" et des protocoles "réels" est la meilleur façon de tester, mais comment faites-vous ça ? Cliquer sur des liens de téléchargement dans votre explorateur internet et utiliser un chronomètre n'est pas bien adapté pour retrouver les informations. Qu'en est-il de l'autre direction ? Si vous avez une connexion internet asymétrique, le téléchargement est effectivement géré différemment du téléversement Vous devez tester les transferts dans les deux directions et utiliser des protocoles et des ports différents. Pourquoi ne pas laisser un script faire tout cela et récupérer un résumer ?
Tout d'abord, on a pensé à utiliser un script shell contenant quelques outils et envoyer des données tout au tour, le problème est que vous voudriez probablement en faire quelques statistiques. Cela pourrait paraître un peu difficile de filtrer la sortie et de calculer le taux de transmission. C'est donc pourquoi le script Perl a été créer. Il utilise les protocoles HTTP, HTTPS, SCP, FTP, SMTP et IMAP. tous les protocoles exceptés SMTP sont utilisés automatiquement de façon bidirectionnelle. Le script utilise le fichier de configuration où le login, le mot de passe, le chemin, et autres paramètres peuvent être configurés. Si vous voulez, vous pouvez utiliser des serveurs différents pour chaque protocole. Les données destinées à être transférées peuvent être explicitement données par le fichier. S'il n'y a pas de fichier présenté alors le script va créer le montant de données aléatoires en utilisant le générateur de code pseudo-aléatoire d'OpenSSL. Le fichier de configuration totale avec toutes les entrées ressemble à ça :
# Size of data - you can either provide a file or a number of bytes. # If the file is set to "none", the number of random bytes is used. data_bytes=65536 data_chunk=8192 data_file="none" logfile="result.log" tests=3 # Send report by email email="recipient@example.net" cc="none" smtp_relay="localhost" # HTTP URLs http_download="http://www.example.net/tmp/crypto_schrift.png" http_upload="http://www.example.net/internettester.php" # HTTPS URLs https_download="https://www.example.net/tmp/crypto_schrift.png" https_upload="https://www.example.net/internettester.php" # FTP ftp_server="ftp.example.net" ftp_username="ftpuser" ftp_password="password" ftp_path="none" # IMAP connection (we use the INBOX) imap_server="mail.example.net" imap_port="143" imap_messages=5 imap_username="mailuser" imap_password="password" imap_ssl="no" # SCP connection scp_server="www.example.net" scp_port=22 scp_path="/tmp" scp_username="user" # SMTP smtp_server="mail.example.net" smtp_port=25 smtp_subject="This is a automatically generated email from internettester.pl (%u)" smtp_from="tester@example.net" smtp_to="devnull@example.net" # SSL parameters ssl_ca="" ssl_cert="" ssl_key="" # Temporary directory tmpdir="/tmp"
C'est important que les protocoles HTTP et HTTPS envoient les requêtes POST des URLs. Une manière de faire cela est de placer le script PHP internettester.php dans le serveur web. Le script reçoit des requêtes POST ensuite verifie les paramètres, et rejette les données chargées. Si vous avez besoin d'utiliser les certificats SSL, dans ce cas-là vous ajoutez le chemin du certificat, de la clé, et du certificat d'authorité à la configuration. ( voir "SSL parameters".)
Les résultats sont imprimés sur la sortie standard. Si vous souhaitez recevoir les résultats par e-mail, vous pouvez donc paramètrer email, cc, et smtp_relay. Le résultat est alors mis dans le message de l'e-mail et sera envoyé via le protocole SMTP.
Afin de faire des mesures réelles, vous aurez besoin d'au moins un terminal avec une connexion internet configurée avec les paramètres connus. vous pouvez exploiter la place sur un serveur localisé. Mais gardez à l'esprit que la connectivité sera probablement partagée. Une valeur supérieure à 100 Mbits/s semble beaucoup - si vous avez des voisins qui se comportent correctement. La bande passante devrait être au moins plus élevée que celle du terminal que vous voulez tester.
Le script en lui-même a besoin de seulement de Perl et de quelques modules pour tous les protocoles utilisés. Vous pouvez vérifier si vous avez tous les modules en utlisant perl -cw internettester.pl sur la ligne de commande. Sur les systèmes d'exploitation Debian ou Ubuntu, les paquets des modules Perl commencent par lib et finissent par -perl. Donc le le module Crypt::OpenSSL::Random se traduit par le paquet libcrypt-openssl-random-perl.
Le lancement du script est assez simple. Il prend seulement deux paramètres optionels . En utilisant --config, vous pouvez rediriger la configuration de celui-ci vers un fichier de configuration. Par défaut, il utilise internettester.cfg. Le second paramètre active le mode débogage. Il permet de voir ce que le script est en train de faire.
lynx@nightfall:~$ ./internettester.pl --config lg.cfg +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Test run - using configuration file lg.cfg - + Sun Dec 13 03:35:01 CET 2009 + + Test file has a size of 3284992 bytes. + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --- HTTP download --------------------------------------------------------- Number of tests : 5 Mean : 227.16 KiB/s Minimum : 221.96 KiB/s Maximum : 231.75 KiB/s Standard deviation : 4.66 KiB/s --- HTTP upload ----------------------------------------------------------- Number of tests : 5 Mean : 1195.61 KiB/s Minimum : 1171.40 KiB/s Maximum : 1208.61 KiB/s Standard deviation : 14.47 KiB/s --- HTTPS download -------------------------------------------------------- Number of tests : 5 Mean : 227.64 KiB/s Minimum : 222.47 KiB/s Maximum : 233.43 KiB/s Standard deviation : 4.13 KiB/s --- HTTPS upload ---------------------------------------------------------- Number of tests : 5 Mean : 1054.77 KiB/s Minimum : 978.15 KiB/s Maximum : 1138.29 KiB/s Standard deviation : 64.00 KiB/s [...] lynx@nightfall:~$
J'ai stoppé la sortie des résultats après les deux premiers protocoles. Le script mesure seulement la bande bassante. Les paquets perdus et les RTT ne sont pas enregistrés. Vous pouvez voir la moyenne, le maximum, le minimum des taux mesurés. Ils sont calculés avec l'aide du module Statistics: :Descriptive. La quatrième valeur est l’écart-type. Il indique à quelle distance les mesures sont éloignées de la moyenne. Les valeurs inférieures à l’écart-type indiquent les faibles variations du taux de transfert individuelles. Assurez-vous que le nombre de tests n'est pas très faibles pour l'analyse des statistiques.
Avertissement : les tests vont probablement saturer votre site internet, tous les tests utilisent le mode TCP, qui a tendance à prendre toute votre bande passante ( sur le lien "Standard"). Durant les horaires de travail les mesures devront être coordonnées.
Le script n'est pas une baguette magique, il ne va pas détecter tous vos problèmes de réseaux mais il peut effectuer un test automatique et enregistre la bande passante utilisée. Se sentir libre d'adapter le code à vos besoins.
René Pfeiffer
Adaptation française de la Gazette Linux
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux
Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site http://www.traduc.org/Gazette_Linux
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.