Auteur Sujet: Linux: Réaliser un test de débit descendant/montant avec CURL  (Lu 79711 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Réaliser un test de débit descendant ou montant avec CURL sous Linux

Également disponible : Tutoriel CURL pour Windows et Tutoriel CURL pour MacOS

Vous connaissez WGET ? ( wget -O /dev/null http://bouygues.testdebit.info/1G.iso )
CURL offre plus d'options.

Installer CURL sous Linux (Ubuntu, Debian et dérivés)

- Ouvrez un terminal (Raccourci clavier : "Ctrl" + "Alt" + "T")
- Exécutez sudo apt install curl



Test de débit descendant (download) sur une connexion TCP sous Linux :

Le débit moyen est affiché dans la colonne Average Dload. C'est un débit en Mo/s et non en Mb/s. C'est un débit utile, les encapsulations ne sont pas comptées.

IPv4 uniquement :
- http, sur une durée de 8 secondes : curl --max-time 8 -4 -o /dev/null http://bouygues.testdebit.info/10G.iso
- https, sur une durée de 8 secondes : curl --max-time 8 -4 -o /dev/null https://bouygues.testdebit.info/10G.iso
- http, taille fixe de 100Mo : curl -4 -o /dev/null http://bouygues.testdebit.info/100M.iso
- https, taille fixe de 100Mo : curl -4 -o /dev/null https://bouygues.testdebit.info/100M.iso
- http, taille fixe de 1Go : curl -4 -o /dev/null http://bouygues.testdebit.info/1G.iso
- https, taille fixe de 1Go : curl -4 -o /dev/null https://bouygues.testdebit.info/1G.iso


IPv6 uniquement :
- http, sur une durée de 8 secondes : curl --max-time 8 -6 -o /dev/null http://bouygues.testdebit.info/10G.iso
- https, sur une durée de 8 secondes : curl --max-time 8 -6 -o /dev/null https://bouygues.testdebit.info/10G.iso
- http, taille fixe de 100Mo : curl -6 -o /dev/null http://bouygues.testdebit.info/100M.iso
- https, taille fixe de 100Mo : curl -6 -o /dev/null https://bouygues.testdebit.info/100M.iso
- http, taille fixe de 1Go : curl -6 -o /dev/null http://bouygues.testdebit.info/1G.iso
- https, taille fixe de 1Go : curl -6 -o /dev/null https://bouygues.testdebit.info/1G.iso

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Linux: Réaliser un test de débit montant avec CURL
« Réponse #1 le: 28 avril 2017 à 17:24:18 »
Préparatif pour une test de débit montant (upload) : télécharger un ficher de grande taille appelé /tmp/temp.iso

- Exemple avec un fichier de 10 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10M.iso
- Exemple avec un fichier de 100 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/100M.iso
- Exemple avec un fichier de 1 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso
- Exemple avec un fichier de 10 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso



Test de débit montant (upload) sur une connexion TCP sous Linux :

Le débit moyen est affiché dans la colonne Average Upload. C'est un débit en Mo/s et non en Mb/s. C'est un débit utile, les encapsulations ne sont pas comptées.
Selon le paramétrage de HTTP/2 (comportement par défaut avec https), le débit peut être limité en fonction des paramétrages HTTP/2 du serveur.

IPv4 uniquement :
http HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/1.1, sans limite de durée : curl -4 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sans limite de durée : curl -4 --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

http HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/2, sans limite de durée : curl -4 --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sans limite de durée : curl -4 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/


IPv6 uniquement :
http HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/1.1, sans limite de durée : curl -6 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sans limite de durée : curl -6 --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

http HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/2, sans limite de durée : curl -6 --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sans limite de durée : curl -6 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

Attention : le débit est calculé coté émetteur : tout paquet émis et non acquitté est compté dans les données "size_upload"
Si une box a un petit débit et de gros buffers, il est possible d'avoir une différence très importante, les données sont émises, mais elles ne sont pas reçues, car elles sont en transit dans le buffer de la box.
Il est donc indispensable d'avoir un test de longue durée (par exemple 60 secondes) en upload. En download 8 secondes suffisent par cotre, vu que le débit est calculé coté récepteur.

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • Delta S 10G-EPON sur Les Ulis (91)
CURL Linux
« Réponse #2 le: 28 avril 2017 à 18:32:35 »
Toujours clair et pédagogique Vivien ! Par rapport à wget, l'avantage est de pouvoir tester l'upload avec curl ? Ou c'est simplement une alternative ?

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
CURL Linux
« Réponse #3 le: 28 avril 2017 à 21:22:25 »
Curl permet de tester l'upload, wget ne le permet pas.

Curl permet de faire un téléchargement sur une durée, wget ne le permet pas.

Curl permet aussi de récupérer de nombreux indicateurs, quand il est scripté.

J'ai fait rapidement ce sujet, car on me pose régulièrement la question de comment tester l'upload sous Windows.

willemijns

  • Abonné FreeMobile
  • *
  • Messages: 2 680
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #4 le: 24 août 2019 à 23:06:33 »
Hello, ftp://1.testdebit.info/ est HS ?

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #5 le: 24 août 2019 à 23:17:29 »
Cela fait des années que le protocole FTP n'est plus proposé.

C'est un protocole obsolète et non représentatif d'un débit obtenu avec les autres protocoles.

Sur le port 21, c'est le protocole https qui écoute aujourd'hui sur mes serveurs.

K-L

  • Abonné SFR THD (câble)
  • *
  • Messages: 4 651
  • HFC 100 Mbs / FTTH 1Gbs sur Oullins (69)
    • Cable Rhone
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #6 le: 25 août 2019 à 02:41:38 »
C'est un protocole obsolète et non représentatif d'un débit obtenu avec les autres protocoles.

Dans quels domaines ?

willemijns

  • Abonné FreeMobile
  • *
  • Messages: 2 680
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #7 le: 25 août 2019 à 10:06:14 »
J'avoue que toute la réponse de vivien m'a laissé coi... d'ou ma non réponse sur le champ en l'ayant lu hier soir.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #8 le: 25 août 2019 à 10:07:30 »
FTP est un protocole qui date de 1971.

Il a de gros défauts :
- L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.
- Il entraine des risques de sécurités type déni de service importants, un pirate peut demander un transfert entre deux serveurs sans faire passer le flxu par son serveur, c'est prévu par le protocole.
- Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données
- La complexité du protocole augmente le risque de failles logiciel sur le serveur, avec risque de modification des fichiers du serveur, saturation de l'espace disque ou exécution de code arbitraire
- La maintenance de plusieurs logiciels de serveurs FTP est faible et donc il y a plus de risque de sécurité, vs Apache.
- Un test de débit FTP n'est pas représentatif de ce que l'on aura avec un autre protocole, Il est donc peu pertinent.

FTP a peu d'avantages à part être supporté sur des machines bien anciennes. Si on cherche à faire des transfert de vieux système d'exploitation, cela peut être intéressant.

Bref, pour moi il faut oublier FTP et utiliser d'autre protocoles, comme par exemple SFTP (transfert sur SSH) ou HTTPS, ce dernier ayant l'avantage de la représentativité (de plus en plus tout passe sur https)

willemijns

  • Abonné FreeMobile
  • *
  • Messages: 2 680
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #9 le: 25 août 2019 à 10:46:27 »
> FTP est un protocole qui date de 1971.

et ?

> - L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.

c'est possible mais c'est pas un élèment déterminant pour notre cas soit du test UP et DL simple.

> - Il entraine des risques de sécurités type déni de service importants, un pirate peut demander un transfert entre deux serveurs sans faire passer le flux par son serveur, c'est prévu par le protocole.

exact... on peut trouver du possible bridage à faire pour limiter tout cela....

> - Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données

comme une page web en HTTP non HTTPS ^^

> - La complexité du protocole augmente le risque de failles logiciel sur le serveur, avec risque de modification des fichiers du serveur, saturation de l'espace disque ou exécution de code arbitraire

réponse valable mais on peut répondre valablement aussi avec "c'est partout pareil" ....

> - La maintenance de plusieurs logiciels de serveurs FTP est faible et donc il y a plus de risque de sécurité, vs Apache.

le HTTP ou ses comperes de streaming/netflix c'est mini 50% des trames TCP...

> - Un test de débit FTP n'est pas représentatif de ce que l'on aura avec un autre protocole, Il est donc peu pertinent.

FTP, HTTP, SFTP, iperf, rsync...  bah comme partout il y a différents moyens de...

> FTP a peu d'avantages à part être supporté sur des machines bien anciennes.

oui un PC de 1985 par exemple ^^ j'aurais préféré lire "le HTTP permet de faire la majorité des usages du FTP
et 99% du trafic qui aurait du se faire en FTP est fesable en HTTP"

FREE a abandonné ftp://test-debit.free.fr surement pour cette raison, je te l'accorde....

K-L

  • Abonné SFR THD (câble)
  • *
  • Messages: 4 651
  • HFC 100 Mbs / FTTH 1Gbs sur Oullins (69)
    • Cable Rhone
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #10 le: 25 août 2019 à 17:11:12 »
Obsolète pour le sujet qui nous intéresse ici-même, d'accord.


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Linux: Réaliser un test de débit descendant/montant avec CURL
« Réponse #11 le: 25 août 2019 à 18:14:21 »
le HTTP ou ses comperes de streaming/netflix c'est mini 50% des trames TCP...
Tu pense que FTP utilise moins d'octets que HTTP

Il me semble que non :

Debian ne va plus proposer de FTP à partir du 1er novembre 2017 : https://www.debian.org/News/2017/20170425.fr.html

Après de nombreuses années au service des besoins des utilisateurs et une utilisation encore plus décroissante en faveur de meilleures options, tous les services FTP debian.org destinés au public seront fermés le 1er novembre 2017.

Cette décision est motivée par les considérations suivantes :
- les serveurs FTP ne prennent pas en charge la mise en cache et l'accélération ;
- l'implèmentation de la plupart des logiciels a stagné et ceux-ci sont difficiles à utiliser et à configurer ;
- l'utilisation des serveurs FTP est plutôt faible puisque notre propre installateur n'offre pas depuis dix ans FTP comme moyen d'accès aux miroirs ;
- le protocole est peu efficace et demande l'ajout de bidouillages compliqués pour les pare-feu et les démons de répartition de charge.


> - L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.

c'est possible mais c'est pas un élèment déterminant pour notre cas soit du test UP et DL simple.

Il faut modifier l'IP privée en IP publique dans les paquets de commande FTP, en quoi c'est un élèment intéressant ou déterminant ?

> - Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données

comme une page web en HTTP non HTTPS ^^
Tout bascule en https, même pour configurer ta box qui est chez toi https est en train de s'imposer.

Tous les tests de débit ont soit terminés leur migration en https (SpeedTest Ookle, nPerf, test UFC Que choisir) ou sont en train de la terminer (QoSi / 5G Mark, IPv6 test)