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

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

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.

Comment tu as fait pour implémenter la partie serveur HTTP/3 ?

Cela serait utilisable avec un autre outil ?

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.

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

courbe cpu en meme temps:



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.