Désolé, je retire ce que j'ai dis plus haut.

Mon test fonctionne avec des trames de 1514 octets dont 1460 de HTTP avec un upload de trames contenant que du TCP de contrôle de seulement 54 octets toutes les 15-30 trames de download ! (ce qui explique le petit upload que j'ai en local)

Avec Speedtest et 28 Mbps de down, j'ai 592 Kbps d'up et c'est full TCP. Donc si je fais 1000/28 = 35,7 ; 35,7*592 = 21 134 Kbps = 21 Mbps d'upload avec speedtest.net via navigateur web avec une connexion Gigabit.

Donc en fait même si l'upload a un soucis chez Antibill, les trames avec le TCP de contrôle sont perdues mais les paquets de download sont quand même reçus

Non, il n'y a plus ces problématiques de connexions fantômes.

Si ta connexion ne monte pas, c'est peut-être que les paquets ont été perdus.

Tu a un taux incroyablement haut de paquets perdus dans le sens montant.

Dans ta capture d'hier soir, le trafic descendant est pas si mauvais que ça. Les perte de paquets n'affectent pas les acquittements : Cela va juste faire un rwin plus petite mais même avec 90% des acquittements montant perdus, une connexion descendante fonctionne.

Voici le test en upload avec SpeedTest.net, serveur de SFR en mono-connexion :


On voit vers 500ms les 15 premiers paquets du test de débit montant. On voit la moitié de ces paquets sont en fait perdus et seront ré-émis par ton PC à la demande du serveur.

TCP ne peut pas fonctionner avec autant de perte de paquet et cela explique le débit catastrophique.
On voit après 4 seconde de test qu'on est presque au point mort.

Avec le commande ping (ou mieux mtr sous linux), tu vois bien des pertes de paquets partout ?

Exemple de commande vers un serveur sur Paris :
ping fr.archive.ubuntu.com
mtr fr.archive.ubuntu.com

Si oui, il faut appeler SFR en indiquant que tu perd un paquet sur deux dans le sens montant et qu'il y a donc un problème, peut-être sur la liaison optique.

Pour rétablir la connexion, éteint tout et rallume les équipements (ONT / Box) afin d'avoir d'autres tentatives.