Je vais aussi développer un outil pour remplacer IPerf3 si vous avez des idées & demandes c'est le moment.

Je me demande si il est pertinent de se lancer sur un nouvel outil coté serveur.

Je verrais plus un outil de test de débit en ligne de commande qui utilise un serveur web classique (Apache2 / Nginx) pour tester les débits.

Un serveur web classique à de nombreux avantages sur un outil dédié :
- Robustesse (vs plantage régulier quand l'usage est un peu exotique avec iPerf3)
- Nombreux flux et clients en parallèle (vs 1 client max par port avec iPerf3)
- Chiffrent représentatif (vs pas de chiffrement avec iPerf3)
- Prise en charge de http/2 et les nouvelles technologies...

Le test de débit se fait en téléchargeant de gros fichiers comme le propose https://bouygues.testdebit.info/ et en upload en recevant le flux envoyé par le client (comme cela fonctionne bien avec curl)

Le gros manque pour exploiter pleinement un serveur web pour faire des tests de débit, c'est le coté client.

Il y a bien curl qui permet de faire un test sur une durée fixe (Réaliser un test de débit descendant ou montant avec CURL sous Linux) mais les débits sont affichés en Mio/s, pas de possibilité d’exclure le slow start, pas de possibilité de multithread et le test upload est peu performant et nécessite d'avoir un gros fichier sur le client. Il serait bien aussi de pouvoir changer de port TCP pour faire des tests de neutralité.

Bref, je pense qu'il serait plus intéressant de faire un client efficace que de faire un nouvel outil coté serveur.

Remonter la charge réseau est intéressante. La charge CPU ou Ram est peu intéressante dans mon cas car l'utilisation est faible, même dans le cas de trafic https en 10 Gb/s, que ce soit sur une ou plusieurs connexion TCP. Pour un test monothread en https, il faut qu'un seul cœur soit capable de traiter le trafic, mais c'était déjà le cas sur la génération précédente de serveur que j'avais.

Peut-être créer un sujet dédié... le jour où on souhaite retrouver l'info au milieu de ce sujet, ce sera pas simple (je peut aussi séparer les messages pour en faire un nouveau sujet)

kgersen tu comptes faire ce projet en opensource ?
Je cherchais justement une idée de projet concret pour mettre en pratique du rust (ça fait quelques mois que j'avance progressivement sur la doc), du-coup je souhaiterai contribuer au projet.
Pour le code client je suppose qu'il faudra développer un programme multiplateforme ? On peut aussi envisager tenter quelque chose en webassembly, il y a surement moyen de faire des tests de débit moins gourmand dans le navigateur avec cette techno.

oui surement open-source , c'est trop tot pour le langage toutefois et j’avoue que ma préférence va a Go plutôt qu'a Rust (je ne suis pas convaincu par Rust en l'état, y'a trop  'd'effet de mode' autour et un manque de recul. Les packages tiers manquent de maturité et de mise a l'épreuve).
J'ai fais des benchmarks et je continue a en faire avant de décider du langage.
L'important c'est surtout de trouver une bonne lib client http car le but n'est pas d'aller se taper l'écriture d'un client http (surtout avec http/2 et quic...). Go a une bon client HTTP de base (net/http) et une variante rapide (valyala/fasthttp), et Go a servit pour développer HTTP/2. Rust a reqwest et Hyper.rs et au pire y'a libcurl pour quasi tout les langages...c'est peut-être le mieux mais la portabilité est plus compliqué.

Webassembly n'apportera pas grand chose en terme de performance , js ou wasm c'est pareil pour ce cas d'usage. Le bottleneck c'est les limites du sandbox des navigateurs et comment ils implémentent les websockets (ou l'api fetch) car wasm n'a pas d'accès plus bas niveau que js. Franchement et ca fait un moment que je suis sur ce sujet je ne pense pas qu'on puisse fait mieux que ce que font les 'speedtest' web actuels donc ca ne sert pas a grand chose de vouloir utiliser un navigateur.

Du moins pour le code du test lui meme (aka le client http), par contre j'ai bien l'intention de faire une interface 'web' pour l'utilisateur non expert (c'est le défaut #1 des tests avec IPerf et curl). L'idée est de faire comme avec 'Electron' mais sans la lourdeur Electron: le programme n'a pas d'interface native mais expose une interface web accessible sur localhost (ou meme en réseau). Je n'ai toutefois pas encore décider quel framework web utilisé (d'autant que je déteste JS donc ca doit être du TS ou peut-être gopherjs). L'idéal sera un seul langage pour toute la stack...a ce niveau wasm peut peut-être jouer un role...

Je vais procéder par étape:

1. Client sans interface web, ligne de commande, multiplate-forme. L'équivalent de "curl" mais vers /dev/null par défaut (et optimiser pour ca) avec parallélisme et génération d'une résultat exportable (image ou graphe). Le client pourra mesurer le crosstalk, savoir quel type d'interface et type/debit (filiaire,wifi, 4g,) est utilisée , la charge cpu, etc bien plus qu'un navigateur donc. On peut meme embarquer libupnp pour connaitre le crosstalk a la box du FAI...(vu que l'API des box c'est un sujet mort ou pas utilisable).

2. Interface web sur ce client pour les utilisateurs moins avertis. Ils téléchargent un 'exe' et le lance et ca ouvre leur navigateur sur 'localhost:1234' par exemple et une interface facon speedtest va controler le .exe pour faire des tests. L'interface doit permettre de proposer une liste de tests: download d'un fichier depuis testdebit.info par exemple, de plusieurs fichiers fichiers meme temps, etc. on peut meme envisager de concevoir des "groupes d'url" a proposer.

3. Le serveur dédié qui apportera des fonctionnalités supplémentaires (j'ai pas mal d'idées a ce sujet) notamment ce qu'on fait coté client (interface, crosstalk, cpu,etc). on peut envisager de mettre le client et le serveur dans le meme .exe par la suite pour faire des tests lan ou P2P entre 2 abonnés (moyennant l'ouverture des ports/IP qui va bien).

C'est vraiment un projet intéressant, surtout avec l'arrivée des connexion à 10 Gb/s, débit qui nécessite de très grosses ressources CPU pour être testé dans un navigateur web (quel que soit la navigateur et quel que soit l'outil de test).

Je pense intéressant d'en faire une version clé USB Bootable, afin de pouvoir aider une personne à vérifier un logiciel ou driver de Windows 10 bride le débit.

Effectivement il y a beaucoup de hype autour du Rust, à voir si c'est juste passager où si cela restera. Après effectivement il faut bencher un maximum comme on cherche le plus de perf. À voir en fonction du niveau d'optimisation des libs existantes et du possible impact du garbage collector de Go (mais j'ai entendu dire qu'il a été beaucoup optimisé dans les dernières versions, son impact est vraiment minime depuis).
Ok donc effectivement si c'est la sandbox / l'implémentation websocket il y a effectivement rien à explorer dans les autres langages.
Alors pour un electron en plus léger, il y a webview : https://github.com/zserge/webview (avec des binding pour Go inclus et pour Rust sur ce projet : https://github.com/Boscop/web-view ) Je l'ai déjà utilisé pour quelques tests et pour un petit programme de remonté de log via une ligne série au boulot, ça permet d'avoir un exécutable beaucoup plus léger comme il passe par le navigateur du système au lieu d'embarquer un chromium. Et pour la partie backend tu codes en natif au lieu du JS.
Pour le front, tu peux mettre ce que tu veux, mais vaut mieux quelque chose qui gère du polyfill ou à minima qui compile vers du JS ancien, car sous Windows ça tourne par dessous IE11 (il est aussi possible de targer edge). J'approuve Typescript, j'en fais depuis bientôt 2 an maintenant, le retour au JS est compliqué une fois habitué.

Si on fait bien la 'boucle' en Go ou autre langage avec GC, y'a pas d'allocation mémoire donc pas de GC nécessaire. J'ai tester goben ou un go-httpbin modifié par mes soins sur 10Gbits ca passe sans souci , la mémoire et le cpu s'ennuient.

Du coup niveau perf je ne pense pas que le langage fera la différence. La maillon lent est dans la stack IP de l'OS. C'est vraiment la "lib client http" qui va importer (notamment sa gestion de la boucle d'envoi/reception et ce qu'on peut modifier ou pas dedans). Et si elle est au point, si elle permet HTTP/2 et QUIC (ideal pour tester UDP).

J'avais croisé webview mais mais ce n'est pas vraiment ce que je cherche. Tout les PC desktop ont un navigateur autant en profiter plutôt que d'embarquer nous meme du 'code de rendu html' (en plus EdgeHTML est abandonné non?).

De toute facon l'interface web est a l'étape 2, ca laisse du temps pour réfléchir et faire du design.

J'avais plus dans l'idée de développer un testeur de débit en peer-to-peer pour ne plus être dépendant d'un seul serveur par test.