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
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)
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
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
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
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.
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
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
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.
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
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.
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.
> .\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
> .\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
Et pour le port 1723 comment tu t'en est rendu compte?
L'usage CPU monte plus haut en HTTP !
$ 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
$ 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
normal vu que ca va plus vite... ;DYup, 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).
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 !
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
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)
$ 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
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.
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.
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.
$ 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
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).
Le flag aes a été rajouté sur la machine virtuelle par @elkaimelie :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...Code: [Sélectionner]$ 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 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).
Avec AES, on triple les débits httpsDu coup j'ai bien le même débit en HTTP et HTTPS comme sur le serveur ByTel de Lille aussi en BBR :
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 normalIl y a les flags attendus pour un processeur ARMv8 avec extensions crypto. Il ne faut pas comparer avec un PC en x86.
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 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 ?C'est dans la ligne de commande de qemu.
IPv4 | IPv6 | |
http://ping.online.net | 677.8 Mbps | 884.4 Mbps |
http://scaleway.testdebit.info | 881.1 Mbps | 894.0 Mbps |
https://scaleway.testdebit.info | 882.0 Mbps | 885.0 Mbps |
http://bouygues.testdebit.info | 860.3 Mbps | 592.6 Mbps |
https://bouygues.testdebit.info | 867.7 Mbps | 480.0 Mbps |
http://lille.testdebit.info | 878.9 Mbps | 886.4 Mbps |
https://lille.testdebit.info | 875.0 Mbps | 888.5 Mbps |
IPv4 | IPv6 | |
http://bouygues.testdebit.info | 280.1 Mbps | 159.1 Mbps |
http://lille.testdebit.info | 859.8 Mbps | 886.5 Mbps |