J'ai pas la bonne version ?

non tu as la 0.9. La nouvelle c'est la 0.10.

sur Mac, y'a pas grand chose encore car j'ai pas le code qu'il faut pour lire les statistiques des interfaces.

voila le code que j’utilise sur Linux:

// return rx/tx counters for interfaces - Linux version
func GetNetStats(interfaces []net.Interface, dir string) []float64 {
var values []float64
for _, itf := range interfaces {
var value int
file, err := os.Open(fmt.Sprintf("/sys/class/net/%s/statistics/%s_bytes", itf.Name, dir))
if err != nil {
value = -1
} else {
fmt.Fscanf(file, "%d", &value)
}
values = append(values, float64(value))
}
return values
}

c'est simplement une lecture des compteurs via sysfs. peut-etre pas ce qu'il y a de plus performant et ne fonctionne pas sur les Linux qui n'ont pas de sysfs actif.

sur Windows, je fais un appel systeme a GetifEntry2Ex pour chaque interface.

Je n'ai pas encore rechercher de solution pour MacOS et les autres variantes Unix et *BSD. Si quelqu'un sait ce qu'il faut faire je suis preneur (code Go ou juste les appels systèmes à faire).

os.Open(fmt.Sprintf("/sys/class/net/%s/statistics/%s_bytes

Le Code des OS pour Apple, dedans j'ai vu des trucs pour le Kernel avec les kext, je connais pas le nom de la fonction spécifique qui retourne les informations que tu nécessites "/sys/class/net/*" c'est certainement dans libsyscall

https://opensource.apple.com/releases/

Dans les exemples, "nspeed put -n 2 https://bouygues.testdebit.info/ 1g" ne fonctionne pas.
Il faut faire "nspeed put -http11 -n 2 https://bouygues.testdebit.info/ 1g", parce que malheureusement tous ces serveurs ne semblent supporter que le HTTP/1.1 en upload (alors que le HTTP/2.0 fonctionne en download).

a noter que, sous Linux, on peut ajouter "GODEBUG=http2debug=2 " devant nspeed pour voir une trace HTTP/2.

'put', en http/2, n'est pas supporter pas ce serveur.

je regarde pourquoi 'post' échoue aussi.

a noter que 'put' c'est maintenant 'post' (nspeed est maintenant en phase avec les méthodes du protocol http)

PUT et POST sont deux méthodes HTTP différentes.

Avec bouygues.testdebit.info, le test d'upload en HTTP/1.1 exploite des limitations :
 - Avec PUT, le serveur répond "100 Continue", on envoie les données, et à la fin il répond "405 Method Not Allowed".
 - Avec POST, le serveur répond "100 Continue", on envoie les données, et à la fin il répond par la page HTML.

En HTTP/2 le serveur répond en parallèle, puis termine l'échange.
Et même en essayant de tricher :
curl -vvv --http2-prior-knowledge -X POST -F "filecontent=@/dev/zero" -o /dev/null http://bouygues.testdebit.info/1G.isoCurl envoie la taille de la window HTTP/2, soit 64Ko, puis il s'arrête et il n'y a plus que le download qui continue.

Sinon, j'avais déjà relevé le comportement peu intuitif de la commande "nspeed server" sans l'option -a, ou avec une interface.
Le readme dit que par défaut ça utilise 127.0.0.1, mais ça dépend des machines :
 - sur WSL j'ai 127.0.0.1 par défaut, et "nspeed server -6" échoue (mais "nspeed server -a ::1" fonctionne)
 - sous Linux et Windows, j'ai ::1 par défaut (IPv6 seulement), et "nspeed server -4" fonctionne pour avoir l'IPv4
De même "-a lo" ou toute autre interface semble choisir IPV6.
Certes on peut :
 - utiliser -a "" ou -a :: pour écouter sur toutes les interfaces en IPv4 et IPv6.
 - donner deux commandes : "nspeed server -a enp5s0 -4 server -a enp5s0 -6" ou "nspeed server -a 127.0.0.1 server -a ::1"
De même -