La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => Free Débits fibre Free => Discussion démarrée par: vivien le 18 août 2020 à 10:37:46

Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 10:37:46
Free FTTH : Limitation des débits en https (comparé à du trafic http) ?

Pour approfondir le problème, serait-il possible de faire les tests suivants ?

Le but est de voir si ce sont les ports ou le protocole utilisé qui bride le débit.

- Port 80 en http (port standard pour http) : http://bouygues.testdebit.info/1G.iso (serveur Bouygues 10Gb/s) ou http://scaleway.testdebit.info/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 81 en http : http://bouygues.testdebit.info:81/1G.iso (serveur Bouygues 10Gb/s) ou http://scaleway.testdebit.info:81/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 82 en https : https://bouygues.testdebit.info:82/1G.iso (serveur Bouygues 10Gb/s) ou https://scaleway.testdebit.info:82/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 443 (port standard pour https) en https : https://bouygues.testdebit.info/1G.iso (serveur Bouygues 10Gb/s) ou https://scaleway.testdebit.info/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 1723 (VPN PPTP) en https : https://bouygues.testdebit.info:1723/1G.iso (serveur Bouygues 10Gb/s) ou https://scaleway.testdebit.info:1723/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 8080 (SpeedTest) en https : https://bouygues.testdebit.info:8080/1G.iso (serveur Bouygues 10Gb/s) ou https://scaleway.testdebit.info:8080/1G.iso (Serveur Scaleway 10 Gb/s)
- Port 21 (FTP) en https : https://bouygues.testdebit.info:21/1G.iso (serveur Bouygues 10Gb/s) ou https://scaleway.testdebit.info:21/1G.iso (Serveur Scaleway 10 Gb/s)

=> Tutoriel pour Windows (https://lafibre.info/tester-son-debit/curl-upload/), pour Linux (https://lafibre.info/tester-son-debit/curl-linux/) ou pour MacOS (https://lafibre.info/tester-son-debit/curl-mac/)

Le comportement pouvant être différent entre IPv4 et IPv6, il est intéressant de faire les tests :
- En forçant le protocole IPv4, avec l'option -4
- En forçant le protocole IPv6, avec l'option -6

Merci de préciser le CPU pour vérifier que ce n'est pas lui qui limite.
Le trafic https demande un peu plus de CPU.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 10:38:03
Ce sont deux tests réalisés par underground78 et Free_me qui jette une suspicion de différentiation de traitement :

Il semble que la différence de débit soit reproductible sur un FTTH Free en IPv4 uniquement.

J'ai des comportements assez bizarres cela dit, peut-être lié à une saturation sur le réseau interne de Free donc c'est compliqué d'être complètement sûr de ce qui se passe...

Le premier chiffre est en IPv4, le deuxième en IPv6.

http://scaleway.testdebit.info/1G.iso => 105 Mo/s | 106 Mo/s
https://scaleway.testdebit.info/1G.iso => 35,7 Mo/s | 38,6 Mo/s
https://scaleway.testdebit.info:1722/1G.iso => 34,4 Mo/s | 34,8 Mo/s
https://scaleway.testdebit.info:1723/1G.iso => 16,3 Mo/s | 37,0 Mo/s

http://bouygues.testdebit.info/1G.iso => 49,6 Mo/s | 58,9 Mo/s
https://bouygues.testdebit.info/1G.iso => 39,0 Mo/s | 38,6 Mo/s
https://bouygues.testdebit.info:1722/1G.iso => 38,6 Mo/s | 36,8 Mo/s
https://bouygues.testdebit.info:1723/1G.iso => 16,6 Mo/s | 32,5 Mo/s

de mon coté a marseille, pas de difference entre 1723 ou pas, mais grosse difference entre http/https :

wget -4 -O NUL https://bouygues.testdebit.info:1723/1G.iso
NUL                           100%[=================================================>] 953,67M  39,6MB/s    in 24s

wget -4 -O NUL https://bouygues.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M  24,5MB/s    in 39s

wget -4 -O NUL http://bouygues.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M   111MB/s    in 8,7s

wget -6 -O NUL https://bouygues.testdebit.info:1723/1G.iso
NUL                           100%[=================================================>] 953,67M  40,4MB/s    in 24s

wget -6 -O NUL https://bouygues.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M  40,0MB/s    in 24s

wget -6 -O NUL http://bouygues.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M   109MB/s    in 8,9s


wget -6 -O NUL https://scaleway.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M  36,3MB/s    in 26s

wget -6 -O NUL https://scaleway.testdebit.info:1723/1G.iso
NUL                           100%[=================================================>] 953,67M  36,3MB/s    in 26s

wget -6 -O NUL http://scaleway.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M   105MB/s    in 9,1s

wget -4 -O NUL https://scaleway.testdebit.info:1723/1G.iso
NUL                           100%[=================================================>] 953,67M  38,5MB/s    in 25s

wget -4 -O NUL https://scaleway.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M  33,3MB/s    in 26s

wget -4 -O NUL http://scaleway.testdebit.info/1G.iso
NUL                           100%[=================================================>] 953,67M   111MB/s    in 8,7s

Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: kgersen le 18 août 2020 à 11:01:04
ca ressemble plus a un souci de saturation du cpu pour déchiffrer les flux non ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Zweit le 18 août 2020 à 11:04:37
Salut,

Cela pourrait-il être du DPI ? (au niveau de la box, ce qui saturerai le CPU ?)
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 11:14:14
Non, je pense qu'il y a peu de chance que ce soit du DPI, le DPI c'est pour brider en fonction du contenu des paquets, c'est quand même coûteux sur un réseau fixe et surtout complètement interdit en Europe. Le DPI est nécessaire pour bloquer ou brider des sites précis. Le blocage se caractérise coté client par une fermeture de la connexion TCP par le serveur après l'envoit par le navigateur du SNI (le nom de domaine).

Pas besoin de DPI pour brider selon un port précis, c'est dans les en-têtes IP.
Le rapport explique que le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :

Extrait de la page 66 (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=66) : Le règlement Internet ouvert permet aux FAI d’accéder qu’aux informations contenues dans l’en-tête du parquet IP et dans l’en-tête du protocole de la couche transport (par exemple l’en-tête TCP ou l’en-tête UDP) dont les noms de domaine et URL sont exclus. Par ailleurs, dans une lettre rendue publique (https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_letter_out2019-0055_berecnetneutrality2.pdf), le Comité européen de la protection des données (EDPB) qui a été saisi pour avis, précise que le nom de domaine et l’URL peuvent être qualifiés de données à caractères personnels et à ce titre sont protégées par les dispositions de la directive vie privée et communications électroniques et du règlement général sur la protection des données. Ainsi, les FAI qui utiliseraient le nom de domaine ou les URL à des fins de catégorisation de trafic ou de facturation s’exposeraient non seulement à une violation potentielle du règlement internet ouvert, mais aussi à une possible violation de la protection des données à caractère personnel de leurs clients.

(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_4_neutralite_2.png)

Il faut plus de test pour savoir quel est le problème.

Si cela se trouve c'est une simple limitation CPU.

Le CPU de Free_me est un Core i5-2405S (4 cœurs à 2,5 GHz, turbo à 3,3 Ghz) avec les instructions AES pour aider à déchiffrer matériellement le https.

Pour moi il doit pouvoir gérer 1 Gb/s mais a voir.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Free_me le 18 août 2020 à 11:36:56
je vais remettre ce que j'ai mis sur l'autre post
la difference https/http, constatée chez moi me semble etre une limitation de mon cpu et/ou de la version wget entre windows et linux

dans le graphe suivant, les 4 premiers pic sont 4 tests 1G.iso sur bouygues en v4 ou v6 en 1723 ou 443 avec wget sur windows 10 et les 4 suivants sont les meme tests wget dans une vm debian. les 8 tests sont eh https. En http je n'ai pas pris de graphe mais je suis au max de la ligne dans tous les cas.

sous windows j'ai 40Mo/sec et dans la vm autour de 80Mo/sec. Sans difference entre 443 ou 1723.

Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Zweit le 18 août 2020 à 11:49:01
Merci Vivien pour ces précisions  :)

Pour ce que ça vaut, j'ai fait le test sur le vieux PC Windows 7 de mes parents (n'ayant pas encore la fibre chez moi) avec curl 7.71.1-mingw 32 bits. FTTH Free sur mini 4k.

i5-4590 @ 3.30 GHz, 4Go de RAM

On voit une différence HTTP/HTTPS mais je n'ai pas l'impression que le CPU souffre pour autant  :-\
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 12:00:53
Merci Zweit. Ton CPU sait gérer 10 Gb/s en https en ligne de commande (enfin pas sous Windows 7).

Je résume tes 4 tests :
- IPv4 http port 80 : débit de 42,2 Mo/s
- IPv4 https port 443 : débit de 10,8 Mo/s
- IPv6 http port 80 : débit de 42,4 Mo/s
- IPv6 https port 443 : débit de 10,8 Mo/s

Cela serait possible de faire le test sur les différents ports suggérés dans mon premier message ?
Pour gagner du temps, tu peut mettre un fichier de 100 Mo ( http://bouygues.testdebit.info/100M.iso) à la place du fichier 1G.
Pas besoin de faire des copie d'écran, indique juste le résultat, c'est le chiffre dans la colonne "Average Dload" qui est intéressant, il est exprimé en Mo/s (Mio/s pour être précis, ce sont des multiple de 1024)
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: asu le 18 août 2020 à 12:25:04
Question probablement bête: possible que ce soit de la compression quelque part derrière la box? J'imagine que ça n'expliquerait certainement pas une différence de 4x mais sait-on jamais.
Vu ma connexion je ne vais pas vérifier moi-même, mais pour le fichier 500ko qui était un JPEG sur un de ces serveurs en gzip j'avais un ratio de compression de 2x. Le fichier 5mo est une vidéo et est incompressible en gzip, mais je ne sais pas ce qu'il en est des fichiers 1Go et plus.
Peut-être que ça peut valoir la peine de regarder si le fichier 10Go donne un débit différent?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Free_me le 18 août 2020 à 12:28:39
bon effectivement avec curl ca pulse bien plus fort :

curl -4  https://bouygues.testdebit.info/1G.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   110M      0  0:00:08  0:00:08 --:--:--  112M

curl -6  https://bouygues.testdebit.info/1G.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   107M      0  0:00:08  0:00:08 --:--:--  109M

curl -6  https://bouygues.testdebit.info:1723/1G.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   107M      0  0:00:08  0:00:08 --:--:--  109M

curl -4  https://bouygues.testdebit.info:1723/1G.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  953M  100  953M    0     0   108M      0  0:00:08  0:00:08 --:--:--  110M

Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Zweit le 18 août 2020 à 12:34:25
Voila les tests avec le serveur bouygues. Résultats assez curieux. Ma version de curl n'a par contre pas l'air d'apprécier le HTTPS sur le port 21.

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  41.8M      0  0:00:02  0:00:02 --:--:-- 41.8M

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  11.2M      0  0:00:08  0:00:08 --:--:-- 11.3M

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  11.1M      0  0:00:08  0:00:08 --:--:-- 11.1M

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  41.5M      0  0:00:02  0:00:02 --:--:-- 41.5M

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  22.8M      0  0:00:04  0:00:04 --:--:-- 22.8M

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  41.3M      0  0:00:02  0:00:02 --:--:-- 41.3M

curl -4 https://bouygues.testdebit.info:21/100M.iso --output NUL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 95.3M    0 32768    0     0   603k      0  0:02:41 --:--:--  0:02:41  615k
curl: (56) OpenSSL SSL_read: Connection was reset, errno 10054





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  42.1M      0  0:00:02  0:00:02 --:--:-- 42.1M

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  42.3M      0  0:00:02  0:00:02 --:--:-- 42.3M

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  41.6M      0  0:00:02  0:00:02 --:--:-- 41.6M

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  11.2M      0  0:00:08  0:00:08 --:--:-- 11.2M

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  41.5M      0  0:00:02  0:00:02 --:--:-- 41.5M

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  11.2M      0  0:00:08  0:00:08 --:--:-- 11.3M

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
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Steph le 18 août 2020 à 12:38:18
De K-net à K-net via k-box Icotera V2b i4850_1.16.3 avec un PC du boulot dont je ne maitrise pas le firewall et antivirus...

Le record de lenteur est pour le http:80 ?!

1/3 moins bon pour 1723

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
  1  953M    1 10.7M    0     0   502k      0  0:32:25  0:00:22  0:32:03  [color=red]485k[/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  36.6M      0  0:00:26  0:00:26 --:--:-- 75.8M

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  43.3M      0  0:00:22  0:00:22 --:--:-- 62.2M

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  25.7M      0  0:00:37  0:00:37 --:--:-- 69.9M

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  19.8M      0  0:00:48  0:00:48 --:--:-- 23.4M

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  45.4M      0  0:00:21  0:00:21 --:--:-- 66.7M

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 98304
curl: (56) Send failure: Connection was reset
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: asu le 18 août 2020 à 12:50:00
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
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: kgersen le 18 août 2020 à 13:01:38
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.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien 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) ?
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
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Zweit 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.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Zweit 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

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
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien 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) ? (https://lafibre.info/vpn/limitation-debit-port-1723/)

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)
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 18 août 2020 à 13:51:37
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.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien 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.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Steph 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

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
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien 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)
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: Steph le 18 août 2020 à 16:57:42
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?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 18 août 2020 à 20:21:12
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 (https://ark.intel.com/content/www/fr/fr/ark/products/65719/intel-core-i7-3770-processor-8m-cache-up-to-3-90-ghz.html) qui n'est pas récent mais qui était quand même relativement puissant à l'époque.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: kgersen le 18 août 2020 à 20:22:01
nspeed affiche l'occupation des coeurs du cpu. ca indique quoi ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 18 août 2020 à 20:23:30
> .\nspeed.exe https://scaleway.testdebit.info/1G.iso
max cores =  8
spawning workload  0 https://scaleway.testdebit.info/1G.iso false
LookupIp for scaleway.testdebit.info
  2001:bc8:3::7
  62.210.156.7
1 size 1000000000 procotol HTTP/1.1 local IP:port [2a01:e0a:xxxx:xxxx:54dd:xxxx:xxxx:b7a2]:54704 remote IP:port [2001:bc8:3::7]:443
40 00 14 02 19 02 06 03 tick  0 5
1 ; 0.9570595 ; 24.5 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
36 02 06 00 16 05 05 02 tick  0 5
1 ; 1.9565462 ; 58.5 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
33 02 15 00 09 03 05 02 tick  0 5
1 ; 2.9570068000000003 ; 95.8 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
46 00 25 00 08 03 08 02 tick  0 5
1 ; 3.9563587 ; 131.1 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
39 00 14 02 12 03 09 02 tick  0 5
1 ; 4.9568738 ; 167.3 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
33 00 25 00 17 03 02 05 tick  0 5
1 ; 5.9566386 ; 203.5 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
49 00 14 00 03 03 08 00 tick  0 5
1 ; 6.9571974 ; 240.7 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
29 02 27 03 08 05 11 06 tick  0 5
1 ; 7.9567744000000005 ; 277.8 MB ; 953.7 MB ; 8192 ; https://scaleway.testdebit.info/1G.iso
master timeout reached
main loop ended rc = 0
1 speed = 292.9 Mbps time = 7.9577736s size = 291323904 291.3 MB url  https://scaleway.testdebit.info/1G.iso
summary: speed = 292.9 Mbps time = 7.9587723s size = 291356672 291.4 MB

L'usage CPU monte plus haut en HTTP !
> .\nspeed.exe http://scaleway.testdebit.info/1G.iso
max cores =  8
spawning workload  0 http://scaleway.testdebit.info/1G.iso false
LookupIp for scaleway.testdebit.info
  2001:bc8:3::7
  62.210.156.7
1 size 1000000000 procotol HTTP/1.1 local IP:port [2a01:e0a:xxxx:xxxx:54dd:xxxx:xxxx:b7a2]:54713 remote IP:port [2001:bc8:3::7]:80
67 00 81 00 03 00 00 00 tick  0 5
1 ; 0.9847964 ; 103.5 MB ; 953.7 MB ; 448 ; http://scaleway.testdebit.info/1G.iso
54 00 92 00 08 02 03 20 tick  0 5
1 ; 1.9834429 ; 209.4 MB ; 953.7 MB ; 1440 ; http://scaleway.testdebit.info/1G.iso
54 00 86 00 02 00 05 29 tick  0 5
1 ; 2.9839618999999997 ; 315.2 MB ; 953.7 MB ; 7200 ; http://scaleway.testdebit.info/1G.iso
60 00 85 00 12 03 11 00 tick  0 5
1 ; 3.9765205 ; 421.4 MB ; 953.7 MB ; 1440 ; http://scaleway.testdebit.info/1G.iso
77 00 87 00 05 02 00 02 tick  0 5
1 ; 4.9835761 ; 528.5 MB ; 953.7 MB ; 3328 ; http://scaleway.testdebit.info/1G.iso
56 00 86 00 02 02 00 17 tick  0 5
1 ; 5.9836825000000005 ; 635.3 MB ; 953.7 MB ; 1440 ; http://scaleway.testdebit.info/1G.iso
62 00 92 00 05 00 00 25 tick  0 5
1 ; 6.9837007 ; 741.5 MB ; 953.7 MB ; 448 ; http://scaleway.testdebit.info/1G.iso
73 03 85 03 02 02 11 28 tick  0 5
1 ; 7.9841415 ; 846.0 MB ; 953.7 MB ; 448 ; http://scaleway.testdebit.info/1G.iso
master timeout reached
main loop ended rc = 0
1 speed = 888.8 Mbps time = 7.9861389s size = 887251437 887.3 MB url  http://scaleway.testdebit.info/1G.iso
summary: speed = 888.8 Mbps time = 7.9871384s size = 887340717 887.3 MB
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 20:32:41
Un Intel Core i7-3770 reste encore aujourd'hui rapide et dépasse de très nombreux PC portables de 2020 (je vois bien ce que cela représente en puissance, j'ai un Core i3-4150 CPU @ 3.50GHz qui devrait deux fois moins performant en multi-thread).

Le Core i7-3770 intègre les instructions AES pour aider pour le https.

Sous Linux tu devrait dépasser 2 Gb/s pour un test de débit dans un navigateur web.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 20:46:26
Et pour le port 1723 comment tu t'en est rendu compte?

Je m'intéresse à tous les ports !

Sur le port 1723, j'ai bien compris que ce que font les opérateurs est normal.

Sur d'autres ports, comme le 5060 / 5061, cela semple plus discutable : https://lafibre.info/vpn/limitation-debit-port-1723/msg784888/#msg784888
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: kgersen le 18 août 2020 à 20:47:30
L'usage CPU monte plus haut en HTTP !

normal vu que ca va plus vite...  ;D

chez moi aussi (bbox6) scaleway.testdebit.info a du mal en https...mais pas bouygues.testdebit.info

scaleway.testdebit.info:
250 Mbps en HTTPS
939 Mbps en HTTP

bouygues.testdebit.info:
940 Mbps en HTTPS
939 Mbps en HTTP

et avec 4 sessions en meme temps ca rempli bien les 1Gbps meme avec scaleway https.

probleme  de serveur ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 21:04:46
Le logiciel est presque identique, scaleway est en bbr et bouygues en cubic, mais si vous souhaitez tester lille.testdebit.info est en bbr pour un test en ce moment.

Les serveurs Bouygues sont des Dell R330, sans virtualisation : Un Xeon E3-1240 v5 @3.5GHz et 32 Go DDR4.
(https://lafibre.info/images/materiel/201703_Dell_PowerEdge_R330_Intel_X710-DA2_0.jpg)
$ lscpu
Architecture :                          x86_64
Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit
Boutisme :                              Little Endian
Processeur(s) :                         8
Liste de processeur(s) en ligne :       0-7
Thread(s) par cœur :                    2
Cœur(s) par socket :                    4
Socket(s) :                             1
Nœud(s) NUMA :                          1
Identifiant constructeur :              GenuineIntel
Famille de processeur :                 6
Modèle :                                94
Nom de modèle :                         Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz
Révision :                              3
Vitesse du processeur en MHz :          3880.389
Vitesse maximale du processeur en MHz : 3900,0000
Vitesse minimale du processeur en MHz : 800,0000
BogoMIPS :                              6999.82
Virtualisation :                        VT-x
Cache L1d :                             32K
Cache L1i :                             32K
Cache L2 :                              256K
Cache L3 :                              8192K
Nœud NUMA 0 de processeur(s) :          0-7
Drapaux :                               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Scaleway est virtualisé, mais je suis presque seul sur la machine. J'ai 12 VCPU et 16 Go de ram.
$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              12
On-line CPU(s) list: 0-11
Thread(s) per core:  1
Core(s) per socket:  6
Socket(s):           2
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          15
Model:               6
Model name:          Common KVM processor
Stepping:            1
CPU MHz:             2400.084
BogoMIPS:            4800.16
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0-11
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti

Si vous avez des questions sur le serveur hote et la virtualisation réalisée, il faut demander à @elkaimelie (https://x.com/elkaimelie), celui qui administre l’hôte (de mon coté j'administre la VM, mais il n'y a pas de différence avec lille.testdebit.info)
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 18 août 2020 à 21:09:30
normal vu que ca va plus vite...  ;D
Yup, c'est bien comme ça que je vois la chose.

probleme  de serveur ?
J'avais un comportement similaire sur ByTel (mais mon accès sature le soir, ce qui complique les tests).
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 18 août 2020 à 21:16:19
Le logiciel est presque identique, scaleway est en bbr et bouygues en cubic, mais si vous souhaitez tester lille.testdebit.info est en bbr pour un test en ce moment.
Intéressant, ça sature très fort vers ByTel en cubic, pas en BBR et je n'ai pas de différences entre HTTP et HTTPS dans ce cas !

1 speed = 890.0 Mbps time = 7.9826318s size = 888029037 888.0 MB url  http://scaleway.testdebit.info/1G.iso
1 speed = 300.7 Mbps time = 7.959022s   size = 299122688 299.1 MB url  https://scaleway.testdebit.info/1G.iso

1 speed = 366.7 Mbps time = 7.9758691s size = 365637357 365.6 MB url  http://bouygues.testdebit.info/1G.iso
1 speed = 219.6 Mbps time = 7.9612455s size = 218562560 218.6 MB url  https://bouygues.testdebit.info/1G.iso

1 speed = 885.8 Mbps time = 7.9779101s size = 883400429 883.4 MB url  http://lille.testdebit.info/1G.iso
1 speed = 882.1 Mbps time = 7.9345349s size = 874921984 874.9 MB url  https://lille.testdebit.info/1G.iso

Tout ça est assez obscure...
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 21:22:40
Impressionnant le BBR.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: kgersen le 18 août 2020 à 21:47:06
je ne pense pas que bbr/cubic explique la différence entre http et https depuis le meme serveur...

y'a pas le flag "aes" dans le serveur virtualisé (scaleway):

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti
sslscan pour scaleway:
Version: 2.0.0 Windows 64-bit (Mingw)
OpenSSL 1.1.1e-dev  xx XXX xxxx

Connected to 62.210.156.7

Testing SSL server scaleway.testdebit.info on port 443 using SNI name scaleway.testdebit.info

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Accepted  TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve 25519 DHE 253

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)

donc TLS_AES_256_GCM_SHA384  préféré.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 18 août 2020 à 22:10:42
Je viens de tester depuis un serveur 10 Gb/s :
- IPv4 http : 5,39 Gb/s (14 secondes pour télécharger le fichier de 10 Go)
- IPv6 http : 5,35 Gb/s (14 secondes pour télécharger le fichier de 10 Go)
- IPv4 https : 318 Mb/s (4 minutes 11 secondes pour télécharger le fichier de 10 Go)
- IPv6 https : 317 Mb/s (4 minutes 12 secondes pour télécharger le fichier de 10 Go)

J'ai regardé les CPU, j'ai un cœur (sur les 12) qui est bloqué à 100% pendant tout le téléchargement.

Il y a donc un vrai problème de performance en https.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: alain_p le 18 août 2020 à 22:37:01
Et bien personnellement, j'ai de grosses différences sur le serveur scaleway entre https et http, je passe de ~30 Mo/s à ~150 Mo/s, mais pas sur le serveur bouygues.
Je fais les tests sur une VM Ubuntu sur le serveur Delta, avec un CPU ARM, donc pas très puissant :

$ wget -4 -O /dev/null https://bouygues.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  30,1MB/s    in 33s

$ wget -4 -O /dev/null http://bouygues.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  36,0MB/s    in 31s

$ wget -6 -O /dev/null https://bouygues.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  25,9MB/s    in 35s

$ wget -6 -O /dev/null http://bouygues.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  26,1MB/s    in 35s

$ wget -4 -O /dev/null https://scaleway.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  33,4MB/s    in 26s

$ wget -4 -O /dev/null http://scaleway.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M   150MB/s    in 6,5s

$ wget -6 -O /dev/null https://scaleway.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M  38,9MB/s    in 25s

$ wget -6 -O /dev/null http://scaleway.testdebit.info/1G.iso
/dev/null                       100%[=======================================================>] 953,67M   161MB/s    in 5,9s
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 19 août 2020 à 00:55:46
J'ai l'impression que KVM n'est pas bien configuré :
The following CPUs models are compatible with most AMD and Intel x86 hosts, but their
usage is discouraged, as they expose a very limited featureset, which prevents guests
having optimal performance.

"kvm32"
"kvm64"
           Common KVM processor (32 & 64 bit variants)

           Legacy models just for historical compatibility with ancient QEMU versions.

Le CPU émulé par défaut est "QEMU Virtual CPU", mais il n'a probablement pas AES-NI non plus (sans même parler d'IBRS et autres pour les failles de sécurité).
Le mieux serait d'utiliser "-cpu host", à moins de vouloir cacher le CPU réellement utilisé, ou de supporter la migration vers des machines plus anciennes (dans ce cas on peut choisir dans les modèles prédéfinis).
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: alain_p le 19 août 2020 à 08:46:58
Tu parles de la configuration de KVM sur la Delta ? Tu y a accès (en tant que client Orange) ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 19 août 2020 à 08:48:26
Tu parles de la configuration de KVM sur la Delta ? Tu y a accès (en tant que client Orange) ?
Non, il parle de la configuration du serveur Scaleway.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 19 août 2020 à 09:39:12
Tu parles de la configuration de KVM sur la Delta ? Tu y a accès (en tant que client Orange) ?
Tes tests sur la Delta semblent limités soit par une saturation avec Bouygues, soit par le problème du serveur Scaleway.
Le CPU de la Delta devrait avoir les extensions crypto ARMv8, donc si les VM sont bien configurées (il faudrait regarder /proc/cpuinfo), le HTTPS devrait être aussi rapide que le HTTP (sauf problème serveur au réseau bien sûr).
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 19 août 2020 à 13:04:23
Le flag aes a été rajouté sur la machine virtuelle par @elkaimelie :

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              12
On-line CPU(s) list: 0-11
Thread(s) per core:  1
Core(s) per socket:  6
Socket(s):           2
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          15
Model:               6
Model name:          Common KVM processor
Stepping:            1
CPU MHz:             2400.084
BogoMIPS:            4800.16
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0-11
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic aes hypervisor lahf_lm cpuid_fault pti
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 19 août 2020 à 13:11:32
Je viens de tester depuis un serveur 10 Gb/s :
- IPv4 http : 5,39 Gb/s (14 secondes pour télécharger le fichier de 10 Go)
- IPv6 http : 5,35 Gb/s (14 secondes pour télécharger le fichier de 10 Go)
- IPv4 https : 318 Mb/s (4 minutes 11 secondes pour télécharger le fichier de 10 Go)
- IPv6 https : 317 Mb/s (4 minutes 12 secondes pour télécharger le fichier de 10 Go)

J'ai regardé les CPU, j'ai un cœur (sur les 12) qui est bloqué à 100% pendant tout le téléchargement.

Il y a donc un vrai problème de performance en https (le coeur est à 100% pendant un transfert à 1 Gb/s).

Avec AES, on triple les débits https :
- IPv4 https : 1015 Mb/s (1 minutes 18 secondes pour télécharger le fichier de 10 Go)
- IPv6 https : 1006 Mb/s (1 minutes 18 secondes pour télécharger le fichier de 10 Go)

Donc le serveur sait gérer 1 Gb/s en https, mais pas plus.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 19 août 2020 à 16:44:02
Le flag aes a été rajouté sur la machine virtuelle par @elkaimelie :

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              12
On-line CPU(s) list: 0-11
Thread(s) per core:  1
Core(s) per socket:  6
Socket(s):           2
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          15
Model:               6
Model name:          Common KVM processor
Stepping:            1
CPU MHz:             2400.084
BogoMIPS:            4800.16
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0-11
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic aes hypervisor lahf_lm cpuid_fault pti
Il manque AVX et/ou PCLMULQDQ pour ghash (AES-GCM), et peut-être SSSE3 et AVX2 (pour SHA et ChaCha20/Poly1305, même si on ne les utilise probablement pas par défaut ici), voire d'autres...
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 19 août 2020 à 17:16:19
Il n'y aurait pas moyen d'exposer l'ensemble des capacités du processeur hôte ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 19 août 2020 à 18:40:20
Il n'y aurait pas moyen d'exposer l'ensemble des capacités du processeur hôte ?
Oui, "-cpu host" serait l'idéal, pas besoin de supporter la migration (pour un changement de serveur, on peut redémarrer).
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 19 août 2020 à 19:54:10
Avec AES, on triple les débits https
Du coup j'ai bien le même débit en HTTP et HTTPS comme sur le serveur ByTel de Lille aussi en BBR :

1 speed = 893.1 Mbps time = 7.9889936s size = 891847917 891.8 MB url  http://scaleway.testdebit.info/1G.iso
1 speed = 893.2 Mbps time = 7.9570714s size = 888438784 888.4 MB url  https://scaleway.testdebit.info/1G.iso

1 speed = 885.1 Mbps time = 7.9663679s size = 881364717 881.4 MB url  http://lille.testdebit.info/1G.iso
1 speed = 884.7 Mbps time = 7.9471446s size = 878854144 878.9 MB url  https://lille.testdebit.info/1G.iso

Par contre sur le serveur ByTel en cubic, j'ai toujours une différence relativement notable entre HTTP et HTTPS, comme si HTTPS était plus sensible à la saturation :

1 speed = 745.7 Mbps time = 7.9808569s size = 743918157 743.9 MB url  http://bouygues.testdebit.info/1G.iso
1 speed = 567.7 Mbps time = 7.9636011s size = 565084160 565.1 MB url  https://bouygues.testdebit.info/1G.iso

Quelle est la configuration du serveur chez K-Net ? J'ai bien le même débit en HTTP et HTTPS :

1 speed = 885.0 Mbps time = 7.967134s size = 881324397 881.3 MB url  http://k-net.testdebit.info/1G.iso
1 speed = 884.8 Mbps time = 7.8770982s size = 871186432 871.2 MB url  https://k-net.testdebit.info/1G.iso

Sur celui de PlanetHoster, j'ai un débit moins bon à la base et aussi une différence entre HTTP et HTTPS :

1 speed = 526.3 Mbps time = 7.9665232s size = 524135354 524.1 MB url  http://paris.planethoster.testdebit.info/1G.iso
1 speed = 390.7 Mbps time = 7.9284485s size = 387186688 387.2 MB url  https://paris.planethoster.testdebit.info/1G.iso

Sinon le serveur chez Ikoula renvoie vers scaleway.testdebit.info avec une redirection 301, c'est un peu bizarre.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: alain_p le 19 août 2020 à 21:20:51
Tes tests sur la Delta semblent limités soit par une saturation avec Bouygues, soit par le problème du serveur Scaleway.
Le CPU de la Delta devrait avoir les extensions crypto ARMv8, donc si les VM sont bien configurées (il faudrait regarder /proc/cpuinfo), le HTTPS devrait être aussi rapide que le HTTP (sauf problème serveur au réseau bien sûr).

Le processeur de la VM sous Delta montrent beaucoup moins de flags qu'un processeur normal, mais il y a quand même aes :

$ cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 50.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 1

Et malheureusement sur la Delta, il n'y a pas beaucoup d'options pour configurer tout cela.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 19 août 2020 à 22:21:13
Le processeur de la VM sous Delta montrent beaucoup moins de flags qu'un processeur normal
Il y a les flags attendus pour un processeur ARMv8 avec extensions crypto. Il ne faut pas comparer avec un PC en x86.
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 20 août 2020 à 08:00:51
Par contre sur le serveur ByTel en cubic, j'ai toujours une différence relativement notable entre HTTP et HTTPS, comme si HTTPS était plus sensible à la saturation :
(...)
Sur celui de PlanetHoster, j'ai un débit moins bon à la base et aussi une différence entre HTTP et HTTPS :

Le matin RAS comme on pouvait s'y attendre :

1 speed = 893.0 Mbps time = 7.8966269s size = 881441037 881.4 MB url  http://bouygues.testdebit.info/1G.iso
1 speed = 891.1 Mbps time = 7.9591112s size = 886571008 886.6 MB url  https://bouygues.testdebit.info/1G.iso

1 speed = 878.4 Mbps time = 7.5905001s size = 833402774 833.4 MB url  http://paris.planethoster.testdebit.info/1G.iso
1 speed = 880.8 Mbps time = 7.3603495s size = 810369024 810.4 MB url  https://paris.planethoster.testdebit.info/1G.iso
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: vivien le 20 août 2020 à 08:17:55
Le CPU émulé par défaut est "QEMU Virtual CPU", mais il n'a probablement pas AES-NI non plus (sans même parler d'IBRS et autres pour les failles de sécurité).
Le mieux serait d'utiliser "-cpu host", à moins de vouloir cacher le CPU réellement utilisé, ou de supporter la migration vers des machines plus anciennes (dans ce cas on peut choisir dans les modèles prédéfinis).

Ce n'est pas moi qui gère le KVM, mais @elkaimelie, l'admin voudrait savoir comment faire : on colle où le -cpu host ?
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: hwti le 20 août 2020 à 10:04:41
Ce n'est pas moi qui gère le KVM, mais @elkaimelie, l'admin voudrait savoir comment faire : on colle où le -cpu host ?
C'est dans la ligne de commande de qemu.
Il y a peut-être une solution de gestion par dessus, auquel cas il faudrait regarder la documentation associée. Il y a toujours un moyen de passer le CPU hôte (que qemu ne filtre quasiment pas le CPUID, à part ce qui est incompatible avec la virtualisation bien sûr).
Titre: Free FTTH : Limitation des débits en https (comparé à du trafic http) ?
Posté par: underground78 le 30 août 2020 à 10:33:30
J'ai toujours des trucs bizarres :
IPv4IPv6
http://ping.online.net677.8 Mbps884.4 Mbps
http://scaleway.testdebit.info881.1 Mbps894.0 Mbps
https://scaleway.testdebit.info882.0 Mbps885.0 Mbps
http://bouygues.testdebit.info860.3 Mbps592.6 Mbps
https://bouygues.testdebit.info867.7 Mbps480.0 Mbps
http://lille.testdebit.info878.9 Mbps886.4 Mbps
https://lille.testdebit.info875.0 Mbps888.5 Mbps

Le comportement est inversé entre Scaleway et Bouygues en IPv4/IPv6 sur des serveurs en Cubic. Les serveurs en BBR ont toujours le débit maximal.

Edit : Ce soir ça sature juste un max, sauf sur les serveurs en BBR :

IPv4IPv6
http://bouygues.testdebit.info280.1 Mbps159.1 Mbps
http://lille.testdebit.info859.8 Mbps886.5 Mbps