Outils populaires

Thème

Test de Perte de Paquets

Ce test de perte de paquets envoie de vrais paquets UDP, comme les jeux et les appels, et vous montre si vous les perdez à l'envoi ou à la réception. Un seul passage sert aussi de test de latence, de mesure de la gigue (jitter) et de test de bufferbloat.

Chaque paquet chronométré via le centre de données Cloudflare le plus proche · perte séparée entre envoi et réception · rien n'est conservé
Profil

3 000 paquets UDP aller-retour via le centre de données Cloudflare le plus proche · 1 min · rien n'est conservé

Chaque paquet, à son arrivéeExemple : 1 min sur une ligne fibre

  • À l'heure 2 995
  • En retard 0
  • Perdu 4
  • Dans le désordre 1
  • Doublon 0
PaquetsRafalesEnvoiEnv.RéceptionRéc.Délai msPerdus : 4aucun–
Chaque colonne correspond à une seconde : ses paquets de haut en bas. Pointez une seconde, ou sélectionnez la bande et utilisez les flèches du clavier.

Comment fonctionne ce test de perte de paquets ?

Votre navigateur envoie un flux régulier de petits paquets UDP jusqu'au centre de données Cloudflare le plus proche, qui les lui renvoie aussitôt, et compte chacun de ceux qui ne reviennent jamais.

Les paquets passent par un canal de données WebRTC configuré pour ne jamais renvoyer un message perdu : un paquet manquant reste donc manquant. C'est une vraie perte de paquets, pas un délai masqué par une retransmission. Ils sont relayés par le service TURN de Cloudflare, qui est en anycast : votre navigateur atteint le centre de données Cloudflare le plus proche, et le relais y est rattaché. Les deux extrémités du flux se trouvent dans votre navigateur, sur une même horloge : le délai de chaque paquet est donc exact au dixième de milliseconde près.

Un paquet de cette boucle traverse votre connexion deux fois, à l'aller et au retour : à lui seul, il ne permet donc pas de savoir où un paquet a été perdu. C'est pourquoi un court appel vocal tourne en parallèle : votre navigateur envoie un flux audio silencieux au serveur d'appel de Cloudflare (Realtime SFU) et le reçoit en retour. Cloudflare signale les paquets qu'il n'a jamais reçus, c'est votre perte à l'envoi ; ce qui manque ensuite, c'est votre perte à la réception.

Sous charge, la ligne est saturée de téléchargements puis d'envois depuis les serveurs de test de débit de Cloudflare pendant que les paquets continuent de circuler : vous voyez ainsi comment la perte, la gigue et la latence évoluent quand la ligne est chargée.

Votre navigateurRelais (TURN)Cloudflare, le plus procheServeur d'appel (SFU)Cloudflare, le plus procheLa boucle : les paquets à l'aller et au retourperdu à l'envoi ou à la réception ?la boucle ne peut pas le dire ; elle chronomètre chaque paquet sur une seule horlogeL'appel de test : Opus, 50 paquets par seconde↑ envoi↓ réceptionCloudflare compte ce qu'il a reçu ↑votre navigateur compte ce qui est revenu ↓
  • Boucle : le délai et le sort de chaque paquet
  • Appel : le sens dans lequel il a été perdu
  • Un paquet perdu
Les deux tournent en même temps pendant tout le test.
Résultat du test de perte de paquets : chaque paquet, rafales de pertes en téléchargement, perte par sens, gigue, bufferbloatRésultat du test de perte de paquets : chaque paquet, rafales de pertes en téléchargement, perte par sens, gigue, bufferbloatLe verdictLa perte, les rafales et la hausse du délai sous charge, jugées selon les objectifs de Microsoft Teams ou le score de jeu de Cloudflare.Chaque paquetChaque colonne correspond à une seconde et chaque marque à un paquet : à l'heure, en retard, perdu ou dans le désordre, avec les rafales encadrées.Envoi ou réceptionL'appel de test sépare la perte : ce que Cloudflare n'a jamais reçu de votre part, et ce qui s'est perdu au retour vers vous.Scores et noteLes scores de Cloudflare pour le streaming, le jeu et les appels vidéo, et la note de bufferbloat de Waveform, de A+ à F.
Un test d'une minute sur une ligne avec du bufferbloat : aucune perte au repos, de courtes rafales de pertes et un délai qui grimpe pendant le téléchargement. Sélectionnez un numéro pour voir ce que montre chaque partie.

Qu'est-ce que la perte de paquets ?

La perte de paquets est la part des paquets de données qui quittent votre appareil mais n'atteignent jamais l'autre extrémité, ou l'atteignent trop tard pour servir.

Les jeux et les appels vocaux et vidéo envoient de petits paquets en UDP plusieurs fois par seconde et n'attendent pas que les paquets perdus soient renvoyés : un paquet perdu, c'est une image figée, un mot coupé dans un appel ou un personnage qui recule d'un coup. Les téléchargements et les pages web utilisent TCP, qui renvoie ce qui a été perdu : la perte n'y apparaît que sous la forme d'une page plus lente. C'est aussi pourquoi un test de débit classique ne peut pas voir la perte de paquets.

Ce test compte quatre choses. Perdu : un paquet qui n'est pas arrivé au bout de 3 secondes, le délai d'attente que la métrique de perte de l'IETF impose de déclarer. En retard : un paquet arrivé, mais loin derrière les autres. Dans le désordre : un paquet arrivé après un paquet envoyé plus tard (RFC 4737). Doublon : un paquet arrivé deux fois, compté une fois.

16 paquets, un toutes les 20 ms1 perdu · 1 en retard · 1 dans le désordre · 1 en double
EnvoyésArrivés en retard : 100 ms derrière les autres11223344566778899101011111212131314141415151616
  • À l'heurearrivé avec les autres
  • En retardarrivé, mais loin derrière les autres : trop tard pour un appel
  • Perdunon revenu dans les 3 secondes
  • Dans le désordrearrivé après un paquet envoyé plus tard
  • Doublonarrivé deux fois, compté une fois
La bande du résultat utilise les mêmes couleurs, une case par paquet.

Quel taux de perte de paquets est acceptable ?

Pour les appels vidéo, moins de 1 % : l'objectif de Microsoft pour Teams est une perte inférieure à 1 % sur toute période de 15 secondes et à 10 % sur toute période de 200 millisecondes, et Zoom recommande 2 % ou moins.

Chaque verdict de cette page suit exactement une règle publiée. Appels vidéo : les objectifs de Microsoft Teams pour le trajet entre votre appareil et la périphérie du réseau (aller-retour sous 100 ms, perte sous 1 % sur chaque période de 15 secondes, perte en rafale sous 10 % sur chaque période de 200 ms, gigue sous 30 ms, paquets dans le désordre sous 0,05 %) et la recommandation de Zoom : 150 ms de latence, 40 ms de gigue et 2 % de perte.

Jeux et streaming : les scores de qualité réseau de Cloudflare, les mêmes points qu'utilise speed.cloudflare.com : moins de 1 % de perte rapporte tous les points, de 1 % à 5 % la moitié, de 5 % à 25 % aucun, et au-delà on perd des points. Pour les jeux, les éditeurs ne publient aucune limite de perte ; même 1 % en rafale produit une saccade visible à 64 ou 128 mises à jour par seconde.

Microsoft Teams moins de 1 % sur toute période de 15 s Zoom 2 % ou moins 0 %0,5 %1 %2 %3 %4 %5 % Cloudflare AIM +10 points +5 5 % à 25 % : 0 · moins de 50 % : −10 · puis −20
  • Moins de 1 % : tous les points, dans l'objectif de Teams
  • 1 % à 2 % : dans celui de Zoom
  • Plus de 2 % : hors des deux
La règle propre à chaque autorité, telle que l'appliquent les vérifications du résultat. Le chiffre de Teams vaut par fenêtre de 15 secondes : un court passage difficile le fait échouer même quand la moyenne est basse.

Votre perte de paquets est-elle aléatoire ou en rafales ?

Le profil compte autant que le pourcentage : 2 % de perte dispersée passent presque inaperçus dans un appel, alors que 2 % perdus en quelques rafales donnent une série de coupures.

Le test compte les épisodes de perte, des séries de paquets perdus les uns après les autres (RFC 6534), affiche le plus long et calcule le ratio de rafale de l'UIT-T G.107 : 1 quand les pertes tombent au hasard, plus de 1 quand elles se regroupent. Les rafales viennent généralement d'une file pleine dans un routeur ou un modem, qui rejette d'un coup plusieurs paquets du même flux, ou d'une coupure momentanée du Wi-Fi.

Un test court ne peut pas prouver l'absence de perte. Si aucun paquet sur 750 n'a été perdu, le taux de perte se situe quand même quelque part sous 0,4 % : la page affiche donc une plage, pas un simple 0 %. Lancez le test de 3 minutes pour détecter une perte intermittente.

La même perte de paquets de 2 %, deux fois1 min · 3 000 paquets · 60 perdus chacun

Aléatoirepertes isolées, dispersées

Épisodes de perte
60
Rafale la plus longue
1 · 20 ms
Ratio de rafale
0,98

En appel : un léger clic de temps en temps

En rafalescinq séries de 12

Épisodes de perte
5
Rafale la plus longue
12 · 240 ms
Ratio de rafale
11,76

En appel : cinq coupures de 240 ms par minute

Ratio de rafale (UIT-T G.107) : la longueur moyenne des rafales divisée par celle que donnerait une perte aléatoire au même taux. 1 = aléatoire ; plus il est haut, plus les pertes se regroupent.

Qu'est-ce que la gigue (jitter), et comment la mesurer ?

La gigue indique à quel point le délai varie d'un paquet à l'autre. Les appels et les jeux mettent les paquets en mémoire tampon pour la lisser, et ce tampon ajoute du délai.

Cette page mesure la gigue avec la formule du RFC 3550, celle qu'affichent les applications d'appel WebRTC : la variation du délai entre les paquets à leur arrivée, lissée sur les derniers paquets. D'autres outils utilisent d'autres formules : le test de débit de Cloudflare fait la moyenne de l'écart entre pings consécutifs, Waveform et Ookla mesurent l'écart à la moyenne, si bien que leurs chiffres de gigue ne sont pas directement comparables. Les scores de Cloudflare sur cette page utilisent la propre formule de Cloudflare, comme il se doit.

Gigue d'interarrivée RFC 3550J = J + (|D| − J) / 16
EnvoyéArrivéVariation DGigue J 0 ms1820 ms21+340 ms19−260 ms26+780 ms18−8100 ms30+12120 ms19−11140 ms20+1160 ms22+22,31

Temps de transit en ms. Chaque variation déplace J d'un seizième du chemin : un pic le fait monter un peu, et des paquets réguliers le font redescendre.

Le test de débit de Cloudflare fait la moyenne de l'écart entre pings consécutifs, Waveform et Ookla mesurent la dispersion autour de la moyenne : la même ligne donne trois chiffres de gigue différents.

Qu'est-ce que le bufferbloat ? Le test de latence sous charge

Le bufferbloat est le délai supplémentaire qu'ajoute votre connexion quand elle est chargée : votre routeur ou votre modem met trop de données en file d'attente, et chaque paquet fait la queue derrière un téléchargement ou un envoi.

Le test sous charge mesure la latence au repos, puis pendant le téléchargement, puis pendant l'envoi, et note la hausse sur l'échelle de Waveform : A+ sous 5 ms ajoutées, A sous 30, B sous 60, C sous 200, D sous 400, F à 400 ms ou plus, à partir de la latence moyenne et du pire des deux sens.

La solution est la gestion intelligente des files d'attente (SQM) sur votre routeur : CAKE ou FQ-CoDel, avec un débit réglé un peu en dessous de ce que fournit votre ligne, environ 90 % du débit mesuré selon le guide d'OpenWrt. Relancez ensuite le test : la note devrait remonter à A ou A+.

Le paquet d'un appel derrière un envoiune ligne d'exemple
File d'envoi du routeur votre appel attend 175 mspuis la file est pleineet rejette les suivants une sauvegarde ou l'envoi d'une vidéo, paquet après paquet
Au repos21 ms
En téléchargement63 ms
En envoi196 ms
C+175 ms sous charge : note C sur l'échelle de WaveformWaveform
  1. A+<5
  2. A<30
  3. B<60
  4. C<200
  5. D<400
  6. F400+
Le délai ajouté est la latence moyenne sous charge moins la moyenne au repos, en retenant le pire entre téléchargement et envoi, comme le note Waveform.

Quelles sont les causes de la perte de paquets, et comment la corriger ?

La plupart des pertes de paquets viennent du Wi-Fi, d'une ligne chargée (bufferbloat), d'un câble ou d'un port défectueux, ou du réseau de votre fournisseur ; le profil du test vous dit lequel.

Une perte uniquement pendant le téléchargement ou l'envoi désigne le bufferbloat : activez le SQM. Une perte aléatoire au repos en Wi-Fi désigne des interférences ou la distance : refaites le test avec un câble. Une perte également avec un câble peut venir d'un câble abîmé, d'un mauvais port ou d'un ancien firmware de routeur. Si le test d'appel place la perte du côté de la réception, avec un câble et le SQM activé, le problème se situe généralement au-delà de votre routeur : envoyez à votre fournisseur le lien de partage et le CSV du test.

Choisissez le profil que vous voyez

Perte uniquement pendant le téléchargement ou l'envoi

Cause probable

Bufferbloat : la file du routeur ou du modem déborde

Solution

Activez le SQM (CAKE ou FQ-CoDel) à environ 90 % de votre débit

Pertes isolées aléatoires, en Wi-Fi uniquement

Cause probable

Interférences, distance ou signal faible

Solution

Rapprochez-vous, passez en 5 GHz ou utilisez un câble

Perte aussi avec un câble, même au repos

Cause probable

Un câble ou un port défectueux, un ancien firmware

Solution

Changez de câble et de port, mettez à jour le routeur

Perte côté réception, avec câble et SQM activé

Cause probable

Le réseau de votre fournisseur

Solution

Envoyez le lien de partage et le CSV à votre fournisseur

Test de perte de paquets, test de ping et test de débit : quelles différences ?

Un test de débit mesure la quantité de données que transporte votre ligne, un test de ping la durée d'un aller-retour, et un test de perte de paquets la fiabilité avec laquelle de petits paquets arrivent : trois questions différentes.

Utilisez un test de ping pour voir votre latence vers des lieux du monde entier, ce test de perte de paquets quand les appels se coupent ou que les jeux saccadent, et un test de débit quand les téléchargements sont lents.

CritèreTest de perte de paquetsTest de pingTest de débit
MesurePaquets perdus, en retard et dans le désordre, gigue, latence sous chargeTemps d'aller-retour vers un serveur ou une régionDébit en téléchargement et en envoi
ProtocoleUDP (aucune retransmission)ICMP, TCP ou HTTPSTCP (les retransmissions masquent la perte)
Répond àPourquoi les appels se coupent et les jeux saccadentÀ quelle distance un serveur semble se trouverPourquoi les téléchargements sont lents

Test de perte de paquets : questions et réponses

Quel est un bon taux de perte de paquets pour jouer ?

Le plus proche possible de 0 %. Le score de jeu de Cloudflare donne tous les points sous 1 % de perte et la moitié de 1 % à 5 %. Les éditeurs de jeux ne publient aucune limite de perte, mais à 64 ou 128 mises à jour par seconde, même une courte rafale signifie un tir manqué ou un personnage qui recule d'un coup : regardez donc les rafales sur la bande autant que le pourcentage.

1 % de perte de paquets, est-ce mauvais ?

Pour un appel vidéo, c'est pile la limite de Microsoft : Teams vise moins de 1 % de perte sur toute période de 15 secondes. Zoom recommande 2 % ou moins. Dans un jeu, 1 % se remarque, d'autant plus quand la perte arrive en rafales. Pour les téléchargements et les pages web, cela compte à peine, car TCP renvoie les paquets perdus.

Pourquoi ce test affiche-t-il de la perte de paquets alors que mon test de débit est bon ?

Un test de débit passe par TCP, qui renvoie chaque paquet perdu : la perte ne fait que ralentir un peu le téléchargement. Ce test envoie des paquets qui ne sont jamais renvoyés, comme un jeu ou un appel : chaque paquet perdu est donc compté. Une ligne peut atteindre son plein débit et perdre quand même des paquets en rafales, surtout quand elle est chargée.

Pourquoi est-ce que je perds des paquets seulement pendant les téléchargements ?

C'est le signe classique du bufferbloat : votre routeur ou votre modem garde trop de données dans sa file d'attente, et quand la file déborde, il rejette des paquets en rafales. Le test sous charge le montre sous la forme d'une perte et d'une hausse du délai pendant la partie téléchargement ou envoi. La gestion intelligente des files d'attente (CAKE ou FQ-CoDel) sur le routeur corrige généralement les deux.

La perte de paquets vient-elle de chez moi ou de mon fournisseur ?

Séparez la question en trois étapes. Le test d'appel indique si les paquets sont perdus à l'envoi ou à la réception. Un test avec un câble plutôt qu'en Wi-Fi vous dit si le Wi-Fi est en cause. Un test avec et sans charge vous dit s'il s'agit de bufferbloat. Une perte qui reste du côté de la réception, avec un câble et au repos, vient généralement de votre fournisseur.

Comment un test dans le navigateur peut-il distinguer la perte à l'envoi de la perte à la réception ?

Des paquets qui montent puis redescendent ne peuvent pas dire où ils ont été perdus : le test passe donc aussi un court appel vocal silencieux vers le serveur d'appel de Cloudflare. Cloudflare indique à votre navigateur combien de vos paquets il a reçus, c'est votre perte à l'envoi ; ce qui manque au retour, c'est votre perte à la réception.

Combien de temps doit durer un test de perte de paquets ?

Lancez le test de 15 secondes pour une vérification rapide, et celui de 3 minutes quand le problème va et vient. Zéro perte sur un test court ne prouve pas qu'il n'y en a aucune : avec 750 paquets et aucun perdu, la perte se situe quand même quelque part sous 0,4 %, et la page affiche cette plage au lieu de 0 %.

Un VPN fausse-t-il le test de perte de paquets ?

Oui. Avec un VPN activé, les paquets passent d'abord par le serveur du VPN : le résultat montre donc le trajet à travers le VPN, pas votre ligne seule. Désactivez le VPN pour tester votre connexion, puis réactivez-le pour voir ce qu'il ajoute.

Combien de données le test consomme-t-il ?

Le flux de paquets lui-même est léger : un test d'une minute transfère quelques mégaoctets tout au plus, même à 128 paquets par seconde. Les parties sous charge téléchargent et envoient aussi vite que votre ligne le permet, chacune pendant au plus un tiers du test, avec un plafond de 250 Mo en réception et 100 Mo en envoi : sur une connexion limitée ou mobile, laissez donc l'option sous charge désactivée.

Est-ce que quelque chose est conservé ?

Non. Le test s'exécute entre votre navigateur et le centre de données Cloudflare le plus proche, qui relaie les paquets chiffrés sans les lire. Les tests précédents restent uniquement dans ce navigateur. Un lien de partage contient le résultat, jamais votre adresse IP, et il est signé : un lien modifié après sa création apparaît comme modifié.

Outils associés