forked from quentin/quentin.dufour.io
84 lines
3.1 KiB
Markdown
84 lines
3.1 KiB
Markdown
---
|
|
layout: post
|
|
slug: iperf
|
|
status: draft
|
|
sitemap: false
|
|
title: iperf
|
|
disqus: true
|
|
description: iperf
|
|
categories:
|
|
- monitoring
|
|
tags:
|
|
---
|
|
|
|
|
|
# Monitorer votre connexion internet (1/?)
|
|
|
|
## Connexion internet grand public : que mesurer ?
|
|
|
|
Nous dirons qu'il y a trois points intéressants à mesurer quand il s'agit d'une connexion internet :
|
|
* La disponibilité (est-ce qu'internet marche)
|
|
* La bande passante (est-ce que je peux transférer beaucoup de données en un temps donné)
|
|
* La latence (est-ce que je peux transférer des données rapidement)
|
|
|
|
Evidemment, il y a d'autres points plus ou moins liés qui sont aussi de bons indicateurs mais que je considère plus secondaire comme le drop de paquets, la marge aux bruits, etc.
|
|
|
|
## La bande passante
|
|
|
|
Dans cet article, on va s'intéresser uniquement à mesurer la bande passante disponible.
|
|
J'aborderai peut-être les autres points dans un article à part.
|
|
|
|
La bande passante est toujours le premier élément que l'on mesure sur une connexion internet.
|
|
J'imagine que vous avez déjà du utiliser [speedtest](https://speedtest.net) ou le dernier né, l'outil de [netflix](https://fast.com).
|
|
Bien que ces outils donnent une bonne idée de la vitesse de la connexion, il est possible d'aller plus loin.
|
|
|
|
Le principal problème est qu'on effectue une mesure à un instant donné sur un serveur donné.
|
|
Un des reproche souvent fait aussi et que les opérateurs pourraient prioritiser le traffic allant vers ces outils de mesure pour tromper les chiffres.
|
|
On est aussi tributaire du protocole HTTP qui peut-être prioritisé ou non selon les règles de ce dernier opérateur.
|
|
|
|
De plus, le fournisseur d'accès passe des accords de peering. Ainsi, si certains accords sont insuffisants, certains sites peuvent être pénalisés.
|
|
On a donc tout intérêt de faire des tests sur plusieurs serveurs.
|
|
|
|
Ensuite l'utilisation du réseau varie en fonction de l'heure de la journée, du jour de la semaine et même de la période de l'année. Faites un test à 5 heure de matin ou à 20h le soir, je parie que vous verrez la différence. Il faudrait donc faire des tests réfulièrements.
|
|
|
|
On ajoutera aussi que le problème peut venir du réseau local. Un réseau wifi saturé, un routeur de mauvaise qualité, un CPL cassé ou je ne sais quel autre problème.
|
|
|
|
Enfin les autres utilisateurs peuvent perturber le test en utilisant le réseau en même temps.
|
|
|
|
En conclusion, nous allons étudier des solutions pour augmenter au maximum la qualité de nos tests à partir des contraintes :
|
|
|
|
* Faire des mesures à travers le temps
|
|
* Faire des mesures sur plusieurs serveurs
|
|
* Avoir un témoin sur le réseau local
|
|
* Limiter ou annuler l'impact des autres utilisateurs
|
|
|
|
## Un script + un cron
|
|
|
|
Pour commencer, on peut juste utiliser curl pour télécharger des ISO sur des miroirs un peu partout et logger ça dans un fichier.
|
|
Voici un exemple avec l'ISO de free :
|
|
|
|
```
|
|
curl free dl iso
|
|
```
|
|
|
|
ping.online.net
|
|
|
|
## iperf
|
|
|
|
## script python rrdtool
|
|
|
|
## munin
|
|
|
|
* plugin existant
|
|
* modification
|
|
* tests
|
|
|
|
## limites
|
|
|
|
* dégrade la qualité de la connexion
|
|
* peut etre basse a cause d'autres utilisateurs
|
|
* peut etre du au réseau interne
|
|
|
|
## solutions
|
|
|
|
* QoS
|