Vu que tu es sous Ubuntu, idéalement, cela serait intéressant de faire une courbe BBR et une courbe Cubic, afin de comparer les deux sur les mêmes tranche horaires.

Vu qu'il y a pas mal de courbes, peut-être arrêter de faire des tests en IPv4 et en IPv6, on a vu que cela change peu les résultats. Je serais d'avis de ne garder que les tests IPv6. Tant qu'à changer le protocole, je partirais sur le serveur de Lille, moins chargé que celui de Paris.

Pour iPerf3, cela serait bien de passer sur le version 3.7 => https://lafibre.info/iperf/installation-iperf3-7/

pour les optimisation TCP, je n'ai pas encore tout vérifié (il y a peut-être des bonnes idées que je devrait reprendre), mais je suis étonné par "net.ipv4.tcp_rmem = 4096 87380 134217728" la valeur par défaut, 87380 est inférieur à celle mise sur des OS récent.

Voici les valeurs que j'utilise coté serveur, avec la version par défaut indiquée :

# Reduce the swap
cat /proc/sys/vm/swappiness
1 (défaut : 60)

# Désactiver la mémorisation des tests précédents sur le serveur afin d’assurer une décorrélation des tests successifs et éviter que le serveur bride les tests suite à une performances limitée
cat /proc/sys/net/ipv4/tcp_no_metrics_save
1 (défaut :  0)

# Increase TCP buffers
cat /proc/sys/net/ipv4/tcp_rmem
4096 131072 16777216 (défaut : 4096   131072   6291456)

cat /proc/sys/net/ipv4/tcp_wmem
4096 87380 16777216 (défaut : 4096   16384   4194304)

cat /proc/sys/net/core/rmem_max
16777216 (défaut : 212992)

cat /proc/sys/net/core/wmem_max
16777216 (défaut : 212992)

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
cat /proc/sys/net/core/netdev_max_backlog
4000 (défault : 1000)

# Reduce the threshold where a DDOS impacts the server
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
4096 (défaut : 1024)

# Increase number of incoming connections
cat /proc/sys/net/core/somaxconn
512 (défaut : 128)

En complément, le trafic par serveur : (ce sont tous des serveurs 10 Gb/s)

https://paris.testdebit.info/


https://lille.testdebit.info/


https://lyon.testdebit.info/


https://aix-marseille.testdebit.info/


https://bordeaux.testdebit.info/

En complément, le trafic par serveur : (ce sont tous des serveurs 10 Gb/s)

https://paris.testdebit.info/

C'est "amusant" le gros pic du serveur Paris, juste avant le moment où j'ai eu impossibilité de faire des tests en IPv6...
Coïncidence ? 
Nan, ça n'existe pas...

Là c'est mystérieux, mais la solutions permettra peut-être de comprendre les problèmes que tu as eu.

Cela serait possible d'avoir le retour complet donné par iPerf3 ?

Cela pourrait être une option du script d'archiver les retours (fichier en local portant la date et l'heure précise du test), de façon à pourvoir analyser un problème.

Au passage, je pense que cela serait intéressant de partager le script que tu as crée, pour que d'autres puissent l'utiliser.

Coté serveur de Paris, le graphique du débit utilisé est stable, autour de 1 Gb/s la nuit dernière.
Je note toutefois nombreuses requêtes entre 21h00 et 23h00 sur Apache (requête de petite taille).
Il y a également eu une sorte de slow DDOS entre 12h00 et 19h30 avec des connexions TCP ouvertes jusqu'au timeout sur Apache.

Donc le process iPerf semble bien fonctionner.

Cela serait bien de faire une capture wireshark pour comprendre ce qu'il se passe.

J'étais en train de faire plusieurs fois des tests à la main.

- Sur Lille, IPv6 ne fonctionnait pas du tout, alors qu'IPv4 est OK.

- Sur Paris, j'ai reproduit le comportement évoqué jusqu'à présent, puis au bout de plusieurs tentatives, j'ai réussi un multithread, mais il était lent à réagir, très lent. Toujours aucun problème en IPv4.

Je penche pour un souci (côté Free ?) sur l'IPv6. A confirmer dans les heures à venir.

EDIT : à l'instant : je ping paris.xxx en IPv6, mais pas lille.xxx ; en IPv4, tous les pings sont OK