Auteur Sujet: Free FTTH : Limitation des débits en https (comparé à du trafic http) ? (Lu 10218 fois)

asu · « **Réponse #12 le:** 18 août 2020 à 12:50:00 »

Citation de: Free_me le 18 août 2020 à 12:28:39

bon effectivement avec curl ca pulse bien plus fort

En fait -O NUL sur wget a l'air d'écrire vers un fichier nommé "NUL". Possible que tu aies été limité par le débit en écriture de ton disque dur. Si tu es sur un Linux essaie -O /dev/null, je suppose que les résultats seront différents.

EDIT: ok c'est effectivement pas du tout ça, je pensais que "NUL" était une valeur spéciale de curl mais ça n'aurait pas de sens, et encore moins la diff en HTTPS... désolé du message inutile :p

kgersen · « **Réponse #13 le:** 18 août 2020 à 13:01:38 »

Citation de: asu le 18 août 2020 à 12:50:00

En fait -O NUL sur wget a l'air d'écrire vers un fichier nommé "NUL". Possible que tu aies été limité par le débit en écriture de ton disque dur. Si tu es sur un Linux essaie -O /dev/null, je suppose que les résultats seront différents.

NUL sur Windows est l'equivalent du /dev/null de Linux.

vivien · « **Réponse #14 le:** 18 août 2020 à 13:06:36 »

NULL vs /dev/null est en fonction du système d'exploitation utilisé :

Windows :
curl -4 -k -o NUL https://bouygues.testdebit.info/100M.iso

Linux et MacOS :
curl -4 -o /dev/null https://bouygues.testdebit.info/100M.iso

Steph, je pense que le problème est sur ton PC (probablement le firewall / anti-virus)

Free_me, tu as bien 1 Gb/s en https, sur le port 443 comme le port 1723. C'est intéressant de voir que la Freebox POP n'a pas de problème.

Zweit, merci pour les tests sur Freebox Mini 4k qui ouvrent plus de questions que de réponses.
Tu es en FTTH point à point (infrastructure IPv4 native, l'IPv6 est encapsulé dans de l'IPv4) ou en 10G-EPON (infrastructure IPv6 native, IPv4 encapsulé dans le l'IPv4) ?

Citation de: Zweit le 18 août 2020 à 12:34:25

Soit pour résumer :

IPv4 :

HTTP / 80 : 41.8 Mio/s
HTTP / 81 : 11.2 Mio/s
HTTPS / 82 : 11.1 Mio/s
HTTPS / 443 : 41.5 Mio/s
HTTPS / 1723 : 22.8 Mio/s
HTTPS / 8080 : 41.3 Mio/s

IPv6 :

HTTP / 80 : 42.1 Mio/s
HTTP / 81 : 42.3 Mio/s
HTTPS / 82 : 41.6 Mio/s
HTTPS / 443 : 11.2 Mio/s
HTTPS / 1723 : 41.5 Mio/s
HTTPS / 8080 : 11.2 Mio/s

Zweit · « **Réponse #15 le:** 18 août 2020 à 13:15:24 »

Mes parents sont en 10G-EPON, en zone AMII Orange à Mondeville (14).

Je ne pense pas que quoi que ce soit ait dérangé le débit chez eux pendant les tests, mais je ne peux l'affirmer à 100% (ayant pris le contrôle à distance, je ne peux pas affirmer qu'un autre périphérique ait utilisé du débit à ce moment. En tout cas pas la TV, ils préfèrent utiliser l'antenne TNT).

EDIT : je vais voir si je peux essayer avec un Windows 10 chez eux dans la journée, pour exclure le côté Win 7 / 32 bits de la curiosité de ces résultats.

Zweit · « **Réponse #16 le:** 18 août 2020 à 13:34:21 »

J'ai pu tester via un autre PC présent sur leur réseau. Il n'est pas tout jeune mais tient encore la route

i5-2500 @ 3.30 GHz, 12G RAM, Win 10 Pro 64 bits 1903

Code: [Sélectionner]

C:\Windows\System32>curl -4 http://bouygues.testdebit.info/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.8M

C:\Windows\System32>curl -4 http://bouygues.testdebit.info:81/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01  100M

C:\Windows\System32>curl -4 https://bouygues.testdebit.info:82/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01  0:00:01 --:--:-- 93.8M

C:\Windows\System32>curl -4 https://bouygues.testdebit.info/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.9M

C:\Windows\System32>curl -4 https://bouygues.testdebit.info:1723/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  31.7M      0  0:00:03  0:00:03 --:--:-- 31.7M

C:\Windows\System32>curl -4 https://bouygues.testdebit.info:8080/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.8M





C:\Windows\System32>curl -6 http://bouygues.testdebit.info/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 98.5M

C:\Windows\System32>curl -6 http://bouygues.testdebit.info:81/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 98.4M

C:\Windows\System32>curl -6 https://bouygues.testdebit.info:82/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.8M

C:\Windows\System32>curl -6 https://bouygues.testdebit.info/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.8M

C:\Windows\System32>curl -6 https://bouygues.testdebit.info:1723/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.9M

C:\Windows\System32>curl -6 https://bouygues.testdebit.info:8080/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.3M  100 95.3M    0     0  95.3M      0  0:00:01 --:--:--  0:00:01 96.9M

Soit en résumé :

IPv4 :

HTTP / 80 : 95.3 Mio/s
HTTP / 81 : 95.3 Mio/s
HTTPS / 82 : 95.3 Mio/s
HTTPS / 443 : 95.3 Mio/s
HTTPS / 1723 : 31.7 Mio/s
HTTPS / 8080 : 95.3 Mio/s

IPv6 :

HTTP / 80 : 95.3 Mio/s
HTTP / 81 : 95.3 Mio/s
HTTPS / 82 : 95.3 Mio/s
HTTPS / 443 : 95.3 Mio/s
HTTPS / 1723 : 95.3 Mio/s
HTTPS / 8080 : 95.3 Mio/s

On note deux choses :
- curl-mingw32 et / ou Win 7 32 bits n'est pas fiable vis à vis de ce test (cela dit, je n'ai pas pensé à regarder si leur antivirus, Avira, ne gênais pas)
- On observe un bridage uniquement sur le port 1723 en IPv4

vivien · « **Réponse #17 le:** 18 août 2020 à 13:38:33 »

Windows 7 n'est pas top pour les débit élevés en mono-connexion. Il y a des patch pour ces pb de performance mais ils ne sont pas proposés par Windows update donc personne ne les installent.
Je conseille fortement Windows 8.1 au minimum pour faire des tests à 1 Gb/s en mono connexion sous Windows.

J'ai mis tes résultats dans le sujet Limitation de débit de certains opérateurs sur le port TCP 1723 (PPTP) ?

et je note que le pb de débit https plus faible est fort probablement lié aux PC des testeurs (il ne reste que underground78 qu'on a pas résolut)

underground78 · « **Réponse #18 le:** 18 août 2020 à 13:51:37 »

Citation de: vivien le 18 août 2020 à 13:38:33

et je note que le pb de débit https plus faible est fort probablement lié aux PC des testeurs (il ne reste que underground78 qu'on a pas résolut)

J'y ai pensé mais il me semble bien que ça fonctionnait avant. Par ailleurs j'ai testé avec wget et curl sans voir de différence. Je vais refaire des tests ce soir.

vivien · « **Réponse #19 le:** 18 août 2020 à 13:53:34 »

Idéalement, cela serait bien d'être sous un Linux pour éviter l'effet d'un logiciel installé sous Windows.

Une clé USB de bootable est largement suffisante.

Steph · « **Réponse #20 le:** 18 août 2020 à 16:24:21 »

De K-net à K-net avec un PC en direct sur l'ONT (du boulot dont je ne maitrise pas le firewall et antivirus...)
En IPv4

Aucune différence entre les différents ports (sauf le 80 chez moi, mon PC l'aime pas)
Ça dépote à 113Mo/s

Et curl n'aime pas le port 21 ftp

Code: [Sélectionner]

curl -4 -k -o NUL http://k-net.testdebit.info/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  5  953M    5 53.6M    0     0  1409k      0  0:11:32  0:00:39  0:10:53 [color=red]1358k[/color]

curl -4 -k -o NUL http://k-net.testdebit.info:81/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   105M      0  0:00:09  0:00:09 --:--:--  101M

curl -4 -k -o NUL https://k-net.testdebit.info:82/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   119M      0  0:00:08  0:00:08 --:--:--  113M

curl -4 -k -o NUL https://k-net.testdebit.info/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   119M      0  0:00:08  0:00:08 --:--:--  113M

curl -4 -k -o NUL https://k-net.testdebit.info:1723/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   119M      0  0:00:08  0:00:08 --:--:--  113M

curl -4 -k -o NUL https://k-net.testdebit.info:8080/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   105M      0  0:00:09  0:00:09 --:--:--  113M

curl -4 -k -o NUL https://k-net.testdebit.info:21/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0  953M    0 49152    0     0  49152      0  5:39:05 --:--:--  5:39:05  440k
curl: (56) Send failure: Connection was reset

vivien · « **Réponse #21 le:** 18 août 2020 à 16:37:57 »

Steph,

Sur le port 80 tout est visible par les outils d'analyse du trafic réseau. C'est l’intérêt du https, cela limite un peu plus de ce que peut faire un opérateur, j'ai vu des truc hallucinant en http (bridage du débit en fonction de l'extension du fichier demandé ou la taille, vu dans l'en-tête de la réponse la taille est donnée, compression des fichiers, rajout d'identifiant suivre l'utilisateur, remplacement des pub à la volée, l'imagination des opérateurs est sans limite...). Mais dans ton cas K-Net ne joue pas à ce jeu là (cela se fait sur les réseaux où la bande passante coûte cher)

Tu peut t'amuser à voir si c'est l’extension qui fait changer l'analyse réalisée : j'ai mis des diazanes d'extensions sur http://k-net.testdebit.info/1G/

Le contenu du fichier est toujours le même quelque soit l'extension, c'est un fichier vidéo VP9 de l'eau sur une plage. (pour des raisons de performance, le fichier est stocké en ram et donc les différentes extensions sont juste des liens vers les différents fichiers)

Steph · « **Réponse #22 le:** 18 août 2020 à 16:57:42 »

Citation de: vivien le 18 août 2020 à 16:37:57

Sur le port 80 tout est visible par les outils d'analyse du trafic réseau. C'est l’intérêt du https, cela limite un peu plus de ce que peut faire un opérateur, j'ai vu des truc hallucinant en http (bridage du débit en fonction de l'extension du fichier demandé ou la taille, vu dans l'en-tête de la réponse la taille est donnée, compression des fichiers, rajout d'identifiant suivre l'utilisateur, remplacement des pub à la volée, l'imagination des opérateurs est sans limite...). Mais dans ton cas K-Net ne joue pas à ce jeu là (cela se fait sur les réseaux où la bande passante coûte cher)

Merci.
Ca doit être l'antivirus de mon PC qui fait du zèle sur le :80 : pas moyen de dépasser 1,5Mo/s en http:80 !
Quelle que soit l'extention.

Et pour le port 1723 comment tu t'en est rendu compte?

underground78 · « **Réponse #23 le:** 18 août 2020 à 20:21:12 »

Citation de: vivien le 18 août 2020 à 13:38:33

et je note que le pb de débit https plus faible est fort probablement lié aux PC des testeurs (il ne reste que underground78 qu'on a pas résolut)

J'ai refait mes tests ce soir après avoir téléchargé des builds récentes de wget et curl pour Windows ainsi que nspeed.

Les conclusions sont les mêmes que précédemment :
- en HTTP le débit est supérieur à 100 Mo/s indépendamment du port
- en HTTPS le débit tourne autour de 35-40 Mo/s et s'additionne si je lance plusieurs téléchargements en parallèle sauf en IPv4 sur le port 1723 où le débit reste toujours de 16-20 Mo/s indépendamment du nombre de flux.

Je n'ai pas l'impression d'avoir de cœurs qui saturent pendant les tests. Ma machine a un CPU Intel Core i7-3770 qui n'est pas récent mais qui était quand même relativement puissant à l'époque.