Perte de paquets : la mesurer, l’expliquer, la corriger

Ce qu’est réellement un paquet perdu

IP ne promet rien. Le protocole est dit « best effort » : chaque routeur fait de son mieux, et quand il ne peut plus, il jette. Un paquet ne s'égare donc pas dans un câble, il est supprimé à un endroit précis par une décision d'équipement, ou bien il arrive avec un FCS invalide et la carte réseau le rejette avant même que la pile IP le voie.

Deux familles de causes cohabitent. Le rejet volontaire d'abord : file d'attente saturée (tail drop), policing qui coupe au-dessus d'un débit contractuel, ACL, AQM comme fq_codel qui sacrifie un paquet pour signaler la congestion avant que la file n'explose. La corruption ensuite : interférences Wi-Fi, paire cuivre trop longue, connecteur fibre encrassé, SFP en fin de vie.

La perte est directionnelle. La métrique normalisée est unidirectionnelle, définie par la RFC 7680 (qui remplace la RFC 2680) : on compte les paquets partis d'un point A et jamais arrivés en B. Un ping, lui, mesure un aller-retour et agrège les deux sens. Si vous lisez 3 % avec ping, ce peut être 3 % à l'aller et 0 % au retour, ou l'inverse, et la correction à appliquer n'est pas la même.

Trois indicateurs sont régulièrement confondus alors qu'ils ne se soignent pas pareil :

• Perte : le paquet n'arrive pas. Mesurée en pourcentage. Elle déclenche des retransmissions TCP ou des trous audibles en VoIP.
• Latence (RTT) : le paquet arrive, mais tard. Mesurée en millisecondes. Un lien peut afficher 300 ms de latence et 0 % de perte.
• Gigue (jitter) : la latence varie d'un paquet à l'autre. Un buffer de gigue trop court transforme la gigue en perte côté récepteur, alors que le réseau, lui, n'a rien perdu.

Mesurer sans accuser le mauvais saut

Commencez par un échantillon assez grand. Le ping par défaut de Windows envoie 4 paquets : sur 4 paquets, un seul perdu affiche 25 % et ne veut rien dire. Lancez plutôt `ping -c 100 -i 0.2 1.1.1.1` sous Linux ou macOS, `ping -n 100 1.1.1.1` sous Windows. La ligne de synthèse est explicite : `100 packets transmitted, 97 received, 3% packet loss, time 20134ms`.

Pour localiser, `mtr -rwc 100 1.1.1.1` donne la perte saut par saut. C'est là que la plupart des diagnostics dérapent. Un routeur intermédiaire qui affiche 40 % de perte pendant que le saut final affiche 0 % ne perd rien du tout : il limite simplement la génération de messages ICMP Time Exceeded. Sous Linux, `net.ipv4.icmp_ratelimit` vaut 1000 ms par défaut et s'applique aux messages Time Exceeded, pas aux réponses echo. Règle pratique : seule la dernière ligne compte, et une perte réelle se propage sur tous les sauts suivants.

Sur la machine elle-même, `ip -s link show eth0` expose les compteurs `errors`, `dropped` et `overrun` de l'interface, et `ss -ti` montre le champ `retrans:` par socket TCP. Des retransmissions qui grimpent alors que l'interface est propre pointent vers le réseau, pas vers le poste. En Wi-Fi, `iw dev wlan0 station dump` donne `tx retries` et `tx failed` : quelques pourcents de retries sont normaux, 30 % signalent un canal encombré ou un signal trop faible.

Outil	Commande type	Ce qu'il donne	Limite
ping	ping -c 100 -i 0.2 1.1.1.1	Taux de perte aller-retour agrégé	Ne dit pas où ni dans quel sens
mtr	mtr -rwc 100 1.1.1.1	Perte et latence par saut	Sauts intermédiaires trompeurs (rate limit ICMP)
iperf3	iperf3 -u -b 50M -c serveur	Perte UDP réelle dans un seul sens	Exige un serveur iperf3 en face
ss	ss -ti	Retransmissions TCP par connexion	Linux uniquement
ip / ethtool	ip -s link show eth0	Erreurs et drops de l'interface locale	Ne voit que le premier lien
pathping	pathping -q 50 1.1.1.1	Équivalent mtr sous Windows	Plusieurs minutes d'exécution

Combien de perte est acceptable

TCP encaisse la perte, mais il la paye en débit. La formule de Mathis donne l'ordre de grandeur du débit maximal d'un flux TCP unique : MSS divisé par (RTT × racine carrée du taux de perte). Avec un MSS de 1460 octets et un RTT de 50 ms, 1 % de perte plafonne le flux un peu au-dessus de 2 Mbit/s. Ramenez la perte à 0,1 % et le même flux monte vers 7 Mbit/s. C'est pour cela qu'une fibre à 1 Gbit/s peut délivrer 2 Mbit/s sur un transfert longue distance : la bande passante est là, la perte l'annule.

Le mécanisme est mécanique. TCP retransmet vite quand il reçoit trois ACK dupliqués (RFC 5681) ou grâce à RACK-TLP (RFC 8985), mais si la perte touche le dernier paquet d'une rafale, il faut attendre le timer de retransmission. La RFC 6298 recommande un RTO plancher de 1 seconde ; Linux utilise 200 ms. Une seule perte mal placée coûte donc facilement 200 ms de silence sur la connexion.

En UDP, il n'y a pas de retransmission : ce qui est perdu est perdu. Un flux voix G.711 en paquets de 20 ms émet 50 paquets par seconde ; le PLC du codec masque une perte isolée, mais deux paquets consécutifs font disparaître 40 ms de parole, ce qui s'entend. Les rapports RTCP (RFC 3550) transportent d'ailleurs un champ `fraction lost` sur 8 bits, soit la fraction perdue multipliée par 256 : c'est ce que lisent les sondes de qualité VoIP.

Les seuils ci-dessous sont des repères d'exploitation courants, pas des valeurs normatives : aucune RFC ne fixe de pourcentage acceptable, la tolérance dépend du codec et du buffer applicatif.

Usage	Perte tolérable	Symptôme au-delà
Lien filaire au repos	0 %	Toute perte durable est une anomalie matérielle
Transfert de fichiers, sauvegarde	moins de 0,1 %	Débit qui plafonne loin de la capacité du lien
Voix sur IP (G.711 avec PLC)	moins de 1 %	Syllabes coupées, mots hachés
Visioconférence	moins de 1 %	Blocs d'image figés, image qui se reconstruit
Jeu en ligne temps réel	moins de 1 %	Téléportations, actions non prises en compte
Streaming vidéo à la demande	quelques % absorbés	Chute de définition puis mise en mémoire tampon

Les causes, de la plus fréquente à la plus rare

Dans la pratique, l'ordre est presque toujours le même. La congestion arrive en tête, et le plus souvent chez vous : un envoi de gros fichier sature le lien montant, la file de la box déborde, tout le reste trinque. Le Wi-Fi suit de près. Ensuite viennent les vraies pannes physiques, puis les cas tordus de MTU.

Le cas MTU mérite un test dédié parce qu'il ne ressemble pas à de la perte classique : les petits paquets passent, les gros disparaissent, le ping est parfait mais une page HTTPS se fige à mi-chargement. C'est un trou noir PMTUD (RFC 1191) : un pare-feu en route bloque les messages ICMP Fragmentation Needed, l'émetteur ne sait donc jamais qu'il doit réduire sa taille de segment. Testez avec `ping -M do -s 1472 1.1.1.1` : 1472 octets de données plus 28 d'en-têtes font exactement 1500. Si ce ping échoue alors qu'un `-s 1400` passe, vous tenez le coupable. Un accès PPPoE plafonne à 1492, un tunnel WireGuard s'installe avec une MTU de 1420 par défaut.

• Congestion du lien montant : c'est la cause n°1 chez les particuliers et les TPE, souvent invisible parce qu'on regarde le débit descendant.
• Wi-Fi : canal occupé, signal faible, borne trop chargée. La perte se voit en retries plus qu'en drops.
• Bufferbloat : la file ne perd pas encore mais la latence explose, puis le tail drop finit par frapper toutes les connexions en même temps.
• Couche physique : câble RJ45 pincé, connecteur mal serti, jarretière fibre sale, SFP qui chauffe. Symptôme typique, des erreurs FCS qui montent lentement.
• Duplex mismatch : un côté forcé en 100/full, l'autre en autonégociation. Collisions tardives et perte asymétrique, spectaculaire sur les vieux commutateurs.
• xDSL : marge de bruit trop faible, erreurs CRC en rafale, souvent corrélées à la météo ou à une paire cuivre longue.
• Trou noir PMTUD : perte sélective des gros paquets uniquement, sans aucun symptôme au ping standard.
• Équipement saturé côté CPU : un routeur qui fait du NAT et du chiffrement au-delà de sa capacité jette des paquets sans que le lien soit plein.
• Instabilité de routage (BGP), attaque volumétrique, saturation d'un peering : rare côté client, mais réel côté hébergeur.

Réduire la perte : ce qui marche vraiment

Avant toute chose, isolez le segment. Un `ping -c 100` vers la passerelle locale, puis vers le premier saut de l'opérateur, puis vers une cible publique stable. Si la perte apparaît dès la passerelle, le problème est chez vous et aucun réglage côté serveur ne le corrigera.

Contre la congestion, la réponse n'est pas d'acheter du débit mais de gérer la file. Un qdisc moderne fait la différence : fq_codel (RFC 8290) est le défaut sur la plupart des distributions Linux via `net.core.default_qdisc`, et `tc qdisc replace dev eth0 root cake bandwidth 90Mbit` sur un routeur OpenWrt règle la majorité des cas de bufferbloat en une ligne. L'idée est contre-intuitive : on jette un peu, tôt, pour éviter de jeter beaucoup, tard. ECN (RFC 3168) va plus loin en marquant les paquets au lieu de les supprimer, à condition que les deux extrémités le gèrent.

Sur la couche physique, remplacez avant de théoriser. Un câble à 3 euros écarte une hypothèse en deux minutes, et forcer les deux côtés en autonégociation résout la plupart des duplex mismatch. En Wi-Fi, changez de canal et rapprochez-vous : les retries chutent immédiatement si c'est la bonne piste.

Quand la perte est chez l'opérateur ou sur un transit, vous ne la corrigez pas, vous la contournez ou vous la documentez. Un rapport `mtr -rwc 500` pris à l'heure du problème, avec l'IP source, l'IP destination et l'horodatage, vaut infiniment mieux qu'une capture d'écran de speedtest au support. Et si la perte n'apparaît qu'aux heures de pointe sur le même saut chaque soir, c'est un lien saturé, pas une panne : le ticket doit le dire dans ces termes.

Questions fréquentes

Quel taux de perte de paquets est normal ?

Sur un lien filaire local, la réponse est 0 %. Sur un trajet Internet longue distance, une perte occasionnelle inférieure à 0,1 % passe inaperçue pour du web et du transfert de fichiers. Dès 1 % de perte soutenue, la voix se dégrade et le débit TCP s'effondre. Attention à la taille de l'échantillon : quatre pings ne permettent aucune conclusion, comptez-en au moins 100.

Pourquoi mtr affiche 40 % de perte sur un saut du milieu et 0 % à l’arrivée ?

Parce que ce routeur limite le nombre de messages ICMP Time Exceeded qu'il génère, ou dépriorise son plan de contrôle. Il transmet parfaitement le trafic, il répond juste mal aux sondes. Une perte réelle se propage : elle apparaît sur ce saut et sur tous les suivants, jusqu'à la destination. Seule la dernière ligne du rapport reflète ce que vit réellement votre trafic.

La perte vient-elle de ma box ou de mon opérateur ?

Testez par paliers. Ping vers la passerelle locale (192.168.1.1 en général) : une perte à ce niveau désigne votre câble, votre Wi-Fi ou la box. Ping vers le premier saut opérateur visible dans traceroute : une perte qui commence là désigne la boucle locale ou l'accès. Perte uniquement au-delà : c'est le réseau de l'opérateur ou un transit, et il faut un mtr complet pour l'objectiver.

Les petits paquets passent mais les gros non, est-ce de la perte de paquets ?

Techniquement oui, mais la cause est un problème de MTU, pas de congestion. Vérifiez avec `ping -M do -s 1472 ` sous Linux ou `ping -f -l 1472 ` sous Windows. Si ce test échoue alors qu'une taille de 1400 passe, un équipement bloque les messages ICMP Fragmentation Needed nécessaires à la découverte de MTU (RFC 1191). Abaisser la MTU de l'interface ou le MSS clamping sur le routeur règle le cas.

Un VPN réduit-il la perte de paquets ?

Rarement, et pas par magie. Un VPN peut emprunter un chemin différent et éviter un transit saturé, ce qui améliore réellement les choses dans certains cas de peering encombré. Mais il ajoute de l'en-tête (une MTU de 1420 par défaut avec WireGuard), du chiffrement et un saut supplémentaire. Si la perte se produit sur votre Wi-Fi ou votre lien montant, le VPN la subira exactement de la même manière.

Testez vos connaissances

À lire aussi

bande passante · box internet · commutateur reseau · adsl