Il y a beaucoup de pertes de paquets, a un tel point que TCP/IP semble ne plus arriver à faire face.

Si vous réalisez un ping 1.testdebit.info vous avez quoi ?

Un exemple quand tout se passe bien :
$ ping 1.testdebit.info
PING 1.testdebit.info (194.158.102.114) 56(84) bytes of data.
64 bytes from 194.158.102.114: icmp_seq=1 ttl=60 time=6.80 ms
64 bytes from 194.158.102.114: icmp_seq=2 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=3 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=4 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=5 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=6 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=7 ttl=60 time=6.68 ms
64 bytes from 194.158.102.114: icmp_seq=8 ttl=60 time=6.81 ms
64 bytes from 194.158.102.114: icmp_seq=9 ttl=60 time=6.81 ms
64 bytes from 194.158.102.114: icmp_seq=10 ttl=60 time=6.80 ms
64 bytes from 194.158.102.114: icmp_seq=11 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=12 ttl=60 time=6.72 ms
64 bytes from 194.158.102.114: icmp_seq=13 ttl=60 time=6.71 ms
64 bytes from 194.158.102.114: icmp_seq=14 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=15 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=16 ttl=60 time=6.83 ms
64 bytes from 194.158.102.114: icmp_seq=17 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=18 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=19 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=20 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=21 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=22 ttl=60 time=6.72 ms
^C
--- 1.testdebit.info ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21038ms
rtt min/avg/max/mdev = 6.683/6.762/6.832/0.083 ms
J'imagine que dans votre cas il va y avoir des "icmp_seq" sans réponse.

Pouvez-vous nous faire un mtr pour voir si ces pertes démarrent dés le début ?

La commande : mtr -rwc100 1.testdebit.info
Cela va mettre un peu de temps (il n'affiche le traceroute qu'a la fin)

Ils n'en sont pas, ce sont juste des routeurs qui n'ont pas envie de répondre à l'ICMP.

Certains routeurs ne répondent qu'a une partie des ping reçu (rate-limited)

Si il n'y a pas de perte sur la destination finale, il n'y a pas de perte avant (les paquets sont bien routés)

Si il y a des pertes, cela nécessite un peu d'habitude pour tenter de discerner les non réponses au ping de vraies pertes.

nasdak, une des hypothèse à ce point de l’enquête, est que les gros paquets de 1500 octets posent problèmes. Je voudrais vérifier ce point.

Serait-il possible de refaire une capture en configurant une MTU à 1240 ?

Voici une configuration de /etc/network/interfaces qui force une mtu à 1240 (le point important, c'est la ligne mtu 1240) :
auto eth0
iface eth0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.254
    dns-nameservers 194.158.122.10 194.158.122.15
    mtu 1240
Pour la capture, il faudrait la lancer, avant de télécharger le fichier suivant :
wget -O /dev/null http://2.testdebit.info/fichiers/20Mo.dat

Si au bout de 2 minutes, il n'a pas terminé, vous pouvez arrêter l'expérience.

Encore une fausse piste.

Cela serait possible de refaire une capture qui montre chaque paquets ? (là il y a des paquets agrégés en un seul par la carte réseau, d'où des tailles de plusieurs milliers d’octets pour certains paquets. Le but est diminuer la charge CPU cf TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU)

Sous linux, il faut installer le paquet "ethtool" (sudo apt install ethtool)

Et taper en ligne de commande :
sudo ethtool -K eth0 tso off gso off

C'est actif uniquement jusqu'au prochain reboot du PC.

Ensuite, refaire une capture avec wget -O /dev/null http://2.testdebit.info/fichiers/20Mo.dat

Merci.