La Fibre
Télécom => Logiciels et systèmes d'exploitation => Iperf => Discussion démarrée par: Adefre le 02 mars 2013 à 10:57:15
-
Bonjour,
J'aurais une question par rapport à cette ligne de commande
iperf -c 3.testdebit.info -i 2 -t 60 -u -b XXm
Elle permet de tester la connexion en local ?
Car si je mets ./iperf -c 3.testdebit.info -i 2 -t 60 -u -b 1000m
J'obtiens :
[ 5] local 192.168.1.20 port 51979 connected with 89.84.127.55 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 2.0 sec 151 MBytes 632 Mbits/sec
[ 5] 2.0- 4.0 sec 150 MBytes 627 Mbits/sec
[ 5] 4.0- 6.0 sec 155 MBytes 650 Mbits/sec
[ 5] 6.0- 8.0 sec 146 MBytes 610 Mbits/sec
[ 5] 8.0-10.0 sec 152 MBytes 635 Mbits/sec
[ 5] 10.0-12.0 sec 150 MBytes 628 Mbits/sec
[ 5] 12.0-14.0 sec 151 MBytes 632 Mbits/sec
[ 5] 14.0-16.0 sec 150 MBytes 627 Mbits/sec
[ 5] 16.0-18.0 sec 148 MBytes 621 Mbits/sec
[ 5] 18.0-20.0 sec 151 MBytes 632 Mbits/sec
[ 5] 20.0-22.0 sec 147 MBytes 615 Mbits/sec
Soit 75-77 Mo/s
Je ne pense pas que j'upload tout d'un coup à 600 Mb/s avec ma Lbx Play ^^
-
En UDP pas acquittements donc il faut regarder à distance ce qui est reçu.
Donc prendre contact avec moi pour faire le test en // (là rien n'est lancé sur le serveur)
Un exemple vers un nom de domaine au hasard :
$ iperf -c orange.fr -i 2 -t 60 -u -b 1000m
------------------------------------------------------------
Client connecting to orange.fr, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.56 port 46247 connected with 193.252.148.60 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 22.9 MBytes 96.2 Mbits/sec
[ 3] 2.0- 4.0 sec 22.8 MBytes 95.8 Mbits/sec
[ 3] 4.0- 6.0 sec 22.8 MBytes 95.7 Mbits/sec
[ 3] 6.0- 8.0 sec 22.8 MBytes 95.7 Mbits/sec
Mon PC n’envoie que 95 Mb/s, car j'ai une carte réseau 100 Mb/s.
Bref ce qui est intéressant c'est de voir ce qui est reçu a l'autre bout.
-
Ton truc c'est méchant quand même.
-
Mais lol Vivien.
-
Je vais donner plus d'explications.
En TCP :
IPERF client affiche le débit utile qu'il èmet
IPERF serveur affiche le débit utile qu'il reçoit
En TCP le débit utile est le même des deux cotés (au remplissage de buffers près).
Les retransmissions des paquets perdus ne compte pas pour du débit utile.
En UDP :
IPERF client affiche le débit qu'il èmet
IPERF serveur affiche le débit qu'il reçoit
En UDP pas d’acquittement, le client peut donc èmettre beaucoup de données alors qu'elles sont toutes perdues. Sa seule limite est sa carte Ethernet et son processeur (pour ceux qui comme moi s’amusent à faire fonctionner iperf en UDP sur un Pentium 150 Mhz)
Dans le cas d'une connexion avec 50 Mb/s d'upload, si on èmet à 1 Gb/s, on aura donc 950 Mb/s de perdu sur le lan et 50 Mb/s qui vont réellement partir sur Internet.
Pour voir le vrai trafic qui est passé entre un client et un serveur, il faut donc se placer sur le serveur qui va indiquer quels paquets sont reçus.
Pour faire un test bi-directionnel, il faut utiliser deux iperf clients et deux iperf serveurs, chacun avec son propre sens et regarder le débit reçu.
-
En plus en UDP tu tentes vaguement de faire un DOS sur l'IP destination, hein.
Mais bon, qui va faire de histoires pour un malheureux DOS?
-
Il va falloir beaucoup de monde pour faire tomber testdebit.info avec de l'UDP
Par contre
Dans le cas d'une connexion avec 50 Mb/s d'upload, si on èmet à 1 Gb/s, on aura donc 950 Mb/s de perdu sur le lan et 50 Mb/s qui vont réellement partir sur Internet.
Il n'y a pas de tampon sur les carte réseaux, qui permettrait d'envoyer plus que 5% du traffic, même en partie, mais en retard?
-
Je répète : aucun IPERF UDP serveur hébergé sur testdebit.info
L'option -r (reverse) aurait permis de se servir du serveur pour lancer des attaques DOS.
Iperf n'est pas le meilleur outil pour faire tomber un site web ;D
-
Il va falloir beaucoup de monde pour faire tomber testdebit.info avec de l'UDP
Tu veux parier ?