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

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, pour Linux ou pour MacOS

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.

vivien · « **Réponse #1 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 :

Citation de: underground78 le 18 août 2020 à 00:02:10

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

Citation de: Free_me le 18 août 2020 à 10:10:26

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

kgersen · « **Réponse #2 le:** 18 août 2020 à 11:01:04 »

ca ressemble plus a un souci de saturation du cpu pour déchiffrer les flux non ?

Zweit · « **Réponse #3 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 ?)

vivien · « **Réponse #4 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.

Citation de: vivien le 25 juin 2020 à 22:45:09

Le rapport explique que le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :

Extrait de la 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, 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.

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.

Free_me · « **Réponse #5 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.

Zweit · « **Réponse #6 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 $:-\$

vivien · « **Réponse #7 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)

asu · « **Réponse #8 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?

Free_me · « **Réponse #9 le:** 18 août 2020 à 12:28:39 »

bon effectivement avec curl ca pulse bien plus fort :

Code: [Sélectionner]

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

Zweit · « **Réponse #10 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.

Code: [Sélectionner]

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

Steph · « **Réponse #11 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

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
  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