La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 03 mars 2022 à 11:00:25
-
Débit faible en http/3, mais ok en http/2 sur le même serveur
(https://lafibre.info/images/logo/logo_http3.svg) (https://lafibre.info/images/logo/logo_http2.svg)
QoSi a mis en place un premier serveur http/3 basé sur un VPS OVH avec Ubuntu 20.04 LTS + Nginx avec le support de Quic & HTTP/3 afin de vérifier les performances de ce protocole.
Le serveur de test est limité (VPS OVH Essential à 10€/mois offrant 2vCore, 4Go ram, 80 Go SSD et 500 Mb/s de débit) merci de ne pas lancer de script automatique dessus.
J'ai testé le fichier https://http3.5gmark.com/dl/52428800.file avec un navigateur Web (Firefox / Chrome, la problématique est la même)
Au premier chargement le navigateur ne sait pas que le serveur est compatible http/3 et le premier transfert après son ouverture est réalisé en http/2 (trafic TCP). Lors de la réponse que va lui faire le serveur, il y a un champ « alt-svc : h3= » :443 » ; ma=259200 » qui indique au client que le serveur sait faire du http/3. Le navigateur va mémoriser cette information et les connexions suivantes seront en http/3 (trafic UDP).
Si le premier transfert http/2 se fait avec au débit maximum, le transfert suivants réalisés en http/3 sont fortement limité en débit (en fonction de la latence ?)
J'ai réalisé des tests sur les 4 opérateurs mobiles où on est limité à environ 10 Mb/s en http/s. Sur une connexion fixe, le débit est un peu plus élevé (30 Mb/s).
Avez-vous une piste pour comprendre d'où vient la limitation ? (une capture Wireshark ne permet plus de voir grand chose avec Quic)
(https://lafibre.info/images/4g/202203_transfert_http2_http3_reseau_mobile.png)
C'est bien le même serveur et le même fichier qui est demandé pour les deux transferts, seul le protocole change.
-
Voici des résultats complets de tests chez les 4 opérateurs mobiles sur plusieurs APN, configuré en IPv4 ou IPv6.
Le serveur http/3 lui n'écoute qu'en IPv4 pour le moment.
Le test http/3 est surligné en orange, les autres tests sont en http/1.1 ou http/2.
(https://lafibre.info/images/4g/202203_4g_debit_en_fonction_du_protocole_1.png)
(https://lafibre.info/images/4g/202203_4g_debit_en_fonction_du_protocole_2.png)
Le tests http/3 est dans Firefox, les autres tests utilisent Curl pour aller vite, voie la liste des commandes passées (https://lafibre.info/images/4g/202203_4g_debit_en_fonction_du_protocole.txt).
-
Autre exemple, où j'ai changé la connexion (SFR câble 100 Mb/s), le PC (Windows 11) et le navigateur (Edge 98).
Là aussi le premier transfert en http/2 a un débit sensiblement plus important que le second qui se fait en http/3.
C'est donc un pb de performance de Nginx. Si vous avez une idée, je suis preneur.
(https://lafibre.info/images/4g/202203_transfert_http2_http3_reseau_fixe.png)
-
Bonjour,
le mieux serai sans doute de poster sur la ML nginx-devel car le support http/3 n'est pas encore dans le branche mainline si mes souvenirs sont bons.
Le README contient des indications:
https://hg.nginx.org/nginx-quic/file/tip/README
-
OVH limite le trafic UDP pour limiter les attaques non ?
-
J'ai pensé à une limitation UDP d'OVH, mais le débit http/3 fluctue selon la latence.
Si c'était un limitation OVH, le débit serait le même avec toutes les connexions, non ?
A noter qu'il n'est pas facile de faire un test en ligne de commande, car curl qui a une option --http3 n'est pas compilé sur plusieurs linux avec le support d'http3
curl: option --http3: the installed libcurl version doesn't support this
-
Bah mince. Moi qui comptait sur l'UDP et son absence de contrôle de flux pour péter tout Internet plein pot ...
Blague à part doit y avoir des portions de code expérimental avec un mode debug qui doit plomber les perfs.
./auto/configure --with-debug --with-http_v3_module dans le README de nginx et visiblement des options à configurer type 0-RTT la taille max de paquets etc.
-
Bah mince. Moi qui comptait sur l'UDP et son absence de contrôle de flux pour péter tout Internet plein pot ...
C'est aussi lui qui transporte 99% des attaques DDoS donc bon... Beaucoup de réseaux limitent UDP.
-
C'est aussi lui qui transporte 99% des attaques DDoS donc bon... Beaucoup de réseaux limitent UDP.
Après si y a des lessiveuses à paquets ça va passer de QUIC à COUIC
-
y'a une limitation en réception sur certains OS : https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size
-
ton serveur HTTP/3 n'est plus en service (https://http3.5gmark.com/dl/52428800.file)?
-
Mon OS client lors de mes tests étaient Ubuntu 21.10
C'était du test. Clairement l'écosystème HTTP/3 (client de test de débit et serveur) est pas suffisamment mur pour que cela soit utilisé pour la campagne Arcep (il avait été envisage de faire 25% des tests en HTTP/3.
HTTP/3 est clairement l'avenir, mais il faut avouer que le support se limite principalement à de grands CDN (Google, Facebook,...) et aux principaux navigateurs web.
Même le curl 7.81 livré avec Ubuntu 22.04 ne supporte pas HTTP/3 :
$ curl --http3
curl: option --http3: the installed libcurl version doesn't support this
curl: try 'curl --help' or 'curl --manual' for more information
$ curl --version
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.11
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd
-
Le support HTTP3 de curl est possible a priori https://curl.se/docs/http3.html (statut expérimental dans la doc) Peut être te faire une version non packagée
-
Le support HTTP3 de curl est possible a priori https://curl.se/docs/http3.html (statut expérimental dans la doc) Peut être te faire une version non packagée
Oui le support de HTTP/3 est possible avec curl, mais effectivement expérimental et pas vraiment prêt à être utilisé pour tester des débits...
Par exemple le bug connu 18.3 HTTP/3 download is 5x times slower than HTTP/2 (https://github.com/curl/curl/issues/6494) a finalement été reclassé et n'est même plus considéré comme un bug, juste un point nécessitant amélioration.
Le problème a été complètement mis sous le tapis il y a 3 mois via le commit
KNOWN_BUGS: remove "HTTP/3 download is 5x times slower than HTTP/2" (It's not actually a bug. More like room for improvement) (https://github.com/curl/curl/commit/4c509a9b8fbe5b5ae8a29dd504daa2504eae87b7).
-
On a aussi l'impression qu'il y a autant de librairies que d'implémentations du protocole, ce serait un non-sens. Il va falloir que ça décante.
-
c'est normal et souhaitable qu'il y ai plein d'implémentations car il y a plusieurs langages , plateformes et contexte d'utilisation différents (client, serveur, etc)
La norme de QUIC est sèche depuis 1 an (https://datatracker.ietf.org/doc/html/rfc9000)/ mais il y a 2 versions en exploitation ("h3" et "h3-29",visible avec un curl -v ou dans un navigateur avec F12). A terme il n'y aura pas qu'une version car les concepteurs ne veulent pas que ca se "fige" notamment au niveau des middle box (firewall, routeur, proxy, etc) comme cela a eu lieu avec TCP. Du coup un QUIC v2 est déjà en cours https://www.ietf.org/archive/id/draft-ietf-quic-v2-03.html (c'est tout frais, le 12 mai) simplement pour forcer les tests et empêcher ce figement (en gros ils veulent pas par exemple que les vendeurs de firewall se contentent juste de tester la valeur de quelques octets d'entête pour savoir si c'est du QUIC ou pas).
Bref il faut pas répéter les erreurs du passé ou on a du conserver une version figée de TCP. L'objectif de QUIC est clairement de ne plus dépendre et être otages des intermédiaires du réseau (box, firewall, opérateurs, etc).
Pour ce qui est des implémentation, un site permet de suivre, en temps réel, les interopérabilité et les débits entre ces implémentations: https://interop.seemann.io/ (ca met du temps a charger les données).
Les mesures de débit sont limité a des transferts de 10 MB donc juste pour valider grossièrement les implémentations.
La norme HTTP/3 (HTTP au dessus de QUIC) n'est pas encore finalisée ( https://quicwg.org/base-drafts/draft-ietf-quic-http.html ). On peut utilisé QUIC pour faire autre chose que du HTTP , comme on utilise TCP pour autre chose.
La plupart des implémentations de QUIC proposent aussi une implémentation de HTTP/3 mais pas forcement. MSQuic (https://github.com/microsoft/msquic)de Microsoft par exemple ne propose pas HTTP/3. Ca n'empêche pas Microsoft de finaliser l'implémentation et de l'intégrer dans Windows (cf les perfs avec un connexion 50 Gbps: https://microsoft.github.io/msquic/ )
Curl n'est qu'un surcouche sur une de ces implémentations (voir plusieurs). De base, Curl n'implémente que HTTP/1.1 , depuis pour HTTP/2 et HTTP/3 ils utilisent des implémentations tierces (qui peut changer d'un build a un autre et d'une plateforme a une autre).
A noté aussi que QUIC nécessite une version spéciale de SSL/TLS qui n'est pas encore dispo dans les versions stables des implémentation de SSL/TLS. Ca rejoute une complexité et une dépendance.
bref c'est complexe mais HTTP/3 représente déjà un grosse partie des paquets en production sur Internet donc on n'est plus dans l'expérimental non plus.
-
Je vous parle bien de librairies, pas du nombre de clients ou services.
En quel cas la prolifération de librairies pour un même jeu de fonction se montre positive ? dans l'histoire de l'informatique ? La question se veut candide.
-
En quel cas la prolifération de librairies pour un même jeu de fonction se montre positive ? dans l'histoire de l'informatique ? La question se veut candide.
y'a plein d'avantages surtout au début d'une techno.
La concurrence entraine une émulation.
Le retex partagé profite a tout le monde (si tout le monde joue le jeu ce qui est le cas en open source) et fait avancé la mise au point de la norme.
Une société ou une équipe qui fait sa version pour son produit va a son rythme, monte ses compétences internes et donc ne dépend pas du rythme, des compétences et des progrès d'une autre société ou équipe.
Tout le monde n'a pas la même API non plus, donc ces librairies même si elles font la même chose 'en dessous' ne sont pas forcement interchangeables, sans parler des langages différents (c, rust, go, python, etc).
Regardes les implémentations de quic: https://github.com/quicwg/base-drafts/wiki/Implementations y'en a pas tant que ca non plus.
Regardes les libc par exemple, y'a pas qu'une. loin de la.
-
petit test HTTP/3 avec nspeed (version a venir bientot):
transfert 20Gb en localhost (loopback):
comparison HTTP/1.1 vs HTTP/2 vs HTTP/3:
Job 1| 13.9 Gbps| 0 bps| 8.00| 13.9 GB| 0 B|get -http11 https://localhost:7333/20g (127.0.0.1:7333 - 0.110 ms - HTTP/1.1)
Job 1| 5.3 Gbps| 0 bps| 8.00| 5.3 GB| 0 B|get https://localhost:7333/20g (127.0.0.1:7333 - 0.368 ms - HTTP/2.0)
Job 1| 1.7 Gbps| 0 bps| 8.00| 1.7 GB| 0 B|get https://localhost:7333/20g ( - 0.0 ms - HTTP/3)
A noter qu'en HTTP/3 utiliser plusieurs flux n'améliore pas plus le résultat contrairement a HTTP1 et HTTP2:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 1| 416.5 Mbps| 0 bps| 8.00| 416.6 MB| 0 B|get https://localhost:7333/20g ( - 0.0 ms - HTTP/3)
Job 2| 415.2 Mbps| 0 bps| 8.00| 415.3 MB| 0 B|get https://localhost:7333/20g ( - 0.0 ms - HTTP/3)
Job 3| 412.8 Mbps| 0 bps| 8.00| 412.9 MB| 0 B|get https://localhost:7333/20g ( - 0.0 ms - HTTP/3)
Job 4| 415.3 Mbps| 0 bps| 8.00| 415.4 MB| 0 B|get https://localhost:7333/20g ( - 0.0 ms - HTTP/3)
Total| 1.7 Gbps| 0 bps| 8.00| 1.7 GB| 0 B|
Le graphe des interfaces montre qu'on a un pic a 2,1 Gbps et une occupation cpu forte (cpu 4c/8t):
graphiques interfaces & cpu:
(https://i.imgur.com/fsM0L4w.png)
(https://i.imgur.com/K19jFNp.png)
A suivre donc.
-
Comment tu as fait pour implémenter la partie serveur HTTP/3 ?
Cela serait utilisable avec un autre outil ?
-
Comment tu as fait pour implémenter la partie serveur HTTP/3 ?
j'utilise quic-go (https://github.com/lucas-clemente/quic-go) vu que NSpeed est écrit en Go.
Cela serait utilisable avec un autre outil ?
c'est a dire ? un autre client ?
oui curl ou meme un navigateur peuvent download/upload de/vers un serveur nspeed.
-
Intéressant. Cela permettrait d’identifier de manière certaine si c'est le serveur web Nginx, l'hébergeur, le réseau ou le client qui pose problème pour ma problématique de débit.
-
Le graphe des interfaces montre qu'on a un pic a 2,1 Gbps et une occupation cpu forte (cpu 4c/8t):
Dans tous les cas cela paraît logique d'avoir une utilisation forte en CPU lors d'un test en localhost non ? (surtout en chiffré)
Tu utilises quel modèle de CPU et tu montes à combien en non chiffré HTTP/1.1 ?
-
Dans tous les cas cela paraît logique d'avoir une utilisation forte en CPU lors d'un test en localhost non ? (surtout en chiffré)
Tu utilises quel modèle de CPU et tu montes à combien en non chiffré HTTP/1.1 ?
oui le test localhost est en general toujours 'cpu bound'.
le cpu est un "Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz" (la machine est un Intel NUC 7)
en non chiffré HTTP/1.1 le meme test monte a 58 Gbps et n'utilise que 2 cores, un pour le client un pour le server dont un des 2 moins utilisé.
on voit que le chiffrement utilisé (cipher=TLS_AES_128_GCM_SHA256 crypto=TLS13) impacte fortement le max.
en non chiffré HTTP/2 (mode h2c) ca monte a moins de 9 Gbps (probleme connu de l'implémentation en Go, il y a bugfix a venir qui permet d'atteindre 30 Gbps) et tres réparti sur plusieurs cores.
test HTTP/1.1 non chiffré suivi d'un test HTTP/2 (h2c):
(https://i.imgur.com/KLcvoxp.png)
courbe cpu en meme temps:
(https://i.imgur.com/KEjJTmO.png)
on voit que l'implémentation de HTTP/2 (et de HTTP/3 sur le graphique du post précédent) utilise plus de cores ce qui les pénalisent quand y'a qu'un flux.
Apres les test en localhost n'est qu'une indication, un test avec carte réseau reste plus réaliste car le drivers et ses optimisations (offload) sont sollicités.
-
Apres les test en localhost n'est qu'une indication, un test avec carte réseau reste plus réaliste car le drivers et ses optimisations (offload) sont sollicités.
Oui c'est sûr, après ça donne une bonne idée des capacités / perfs de base de la chaine d'outils utilisée quand même :)
Merci pour ce retour détaillé !