Sur la capture IPv4 Cubic, on voit bien le fait que les buffers sont trop petits.
Cela ne se voit pas sur la capture IPv6 Cubic, mais c'est peut-être que tu avait fait un test avant : TCP est mesure de garder souvenir des destinations où les précédents connexions on posées problème et où il faut donc envoyer les paquets à un faible débit.
Pour éviter ce phénomène de mémoire, il faudrait employer net.ipv4.tcp_no_metrics_save=1 comme je l'ai mis dans mon fichier d'optimisation, présent sur les serveurs de test de débit que j'administre :
nano /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 512
Par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, de sorte que les connexions établies dans un proche avenir peuvent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dépendance du test N au test N-1.
Dans le cadre des tests réalisés ici, nous souhaitons voir les problèmes et éviter qu'il réduise préventivement son débit.
Afin d’assurer une décorrélation des tests successifs, il semble opportun de désactiver la mémorisation des tests précédents sur le serveur pour les tests download (déjà fait) et sur le client pour les tests upload, via l'emploi de « tcp_no_save_metrics=1 » afin d’éviter que serveur bride tous les tests suite à une performance limitée.
Les optimisations des buffers sont aussi bienvenue pour ne pas avoir de limitation de ce coté là (mais à priori ce n'est pas la cause de la limitation de débit enregistré et si cela briderait le débit, cela le ferait de manière équivalente en Cubic et en BBR)
Maintenant l'autre problème qui est présents dans les différentes captures (et que je n'avais pas vu lors de la première analyse de Breizh29), c'est le fait que les paquets arrivent régulièrement dans le désordre.
Je pense que ce désordre est probablement la cause des coupures vu avec un transfert avec le protocole de congestion BBR.
Il y a donc deux gros problèmes rencontrés dans ces captures.
Le buffer on sait que c'est sous la responsabilité de Free.
Les paquets qui arrivent dans le désordre, on n'a rien qui prouve que c'est sous la responsabilité de Free.
Il faudrait faire un capture en Cubic (BBR c'est compliqué à analyser vu les pertes dans tous les sens) avec un serveur qui n'est pas hébergé chez Bouygues Telecom pour voir si les paquets dans le désordre sont toujours présents.
Je suis donc intéressé par un upload Cubic, plutôt en IPv6, vers un autre serveur iPerf3.