Testez plusieurs fois la même destination dans un état normal, comparez le ping ou pathping vers la passerelle et vers une destination externe, puis conservez la sortie complète. Utilisez ensuite Clumsy uniquement pour reproduire une perte contrôlée dans une application autorisée : il ne diagnostique ni votre FAI ni une route défaillante.
01
Ce que signifie la perte de paquets avant le test
La perte de paquets signifie que des données envoyées n'atteignent pas l'étape attendue ou que la réponse ne revient pas dans le délai de mesure. Un navigateur peut afficher un délai d'attente, un appel peut se figer et un transfert peut recommencer. Ces symptômes sont des indices, pas une preuve : le DNS, la charge du serveur, les interférences Wi‑Fi, la congestion ou le délai de l'application peuvent produire le même résultat.
Un test de perte de paquets est donc une comparaison. Choisissez une destination, une période, une référence et un nombre d'échantillons suffisant. Testez la passerelle locale et une destination externe fiable. Une perte sur la passerelle oriente vers le lien local ; une perte limitée à un service distant demande une nouvelle comparaison et éventuellement des journaux côté serveur.
Séparez le diagnostic de la simulation. Le diagnostic demande si la connexion perd des paquets maintenant. Clumsy demande comment une application réelle réagit lorsque le trafic sélectionné est volontairement dégradé. Le guide du simulateur de perte de paquets Clumsy couvre les reprises, les doublons et la récupération une fois la condition de test définie.
02
Commencez par une référence propre
Une référence rend les comparaisons utiles. Notez les conditions avant d'interpréter un pourcentage.
Choisissez une destination stable que vous êtes autorisé à tester. Notez la date, le poste Windows, le Wi‑Fi ou l'Ethernet, l'interface utilisée, ainsi que tout VPN ou proxy. Si possible, mettez en pause les téléchargements, la synchronisation et les appels vidéo. Plusieurs tests simultanés ajoutent une charge qui peut fausser la mesure.
Pour un incident intermittent, comparez le routeur ou la passerelle locale, une adresse externe fiable et le service qui présente le problème. Une passerelle propre avec un seul service en échec n'a pas la même signification qu'une perte qui touche la passerelle et plusieurs applications. Répétez depuis un autre accès avant de modifier toute la configuration locale.
Répétez la mesure à une autre heure. Une réponse manquante peut être ponctuelle, tandis qu'un petit échantillon sans perte ne prouve pas qu'une connexion est parfaite. Conservez le nombre envoyé, le nombre perdu, le délai moyen, la destination et l'heure pour que le résultat soit reproductible.
- Noter la référenceEnregistrez la destination, l'interface, l'heure, le VPN et le symptôme observé.
- Tester la passerelleUtilisez le routeur local pour séparer un problème Wi‑Fi ou Ethernet d'une route distante.
- Tester une destination externeRépétez le même échantillon et conservez la sortie complète.
- Répéter plus tardVérifiez qu'un pic court ne devient pas automatiquement une conclusion permanente.
| Observation | Piste possible | Ce que cela ne prouve pas |
|---|---|---|
| Perte sur la passerelle | Lien local, routeur ou segment sans fil à examiner | Que le FAI et le service distant perdent aussi des paquets |
| Perte sur une destination externe | Route ou destination particulière affectée | Que toutes les applications ont le même taux |
| Délai d'attente de l'application | Opération lente ou échouée côté produit | Que le trafic a été perdu plutôt que retardé |
| Une seule réponse absente | Événement à reproduire | Un taux stable sur le long terme |
03
Utilisez les commandes Windows pour vérifier la perte
La première vérification utilise généralement ping avec un nombre fixe de requêtes vers la même destination. Vous obtenez les paquets envoyés, les réponses, la perte et le temps aller-retour. Certains hôtes bloquent ICMP : 100 % de perte peut donc signifier « aucune réponse au ping », et non « tout le trafic de l'application est perdu ».
pathping ajoute le chemin et des échantillons sur les sauts intermédiaires. Il peut prendre plusieurs minutes. Un routeur peut limiter ses réponses de diagnostic tout en transférant correctement le trafic. Ne désignez pas le premier saut avec un pourcentage comme responsable ; vérifiez si le motif continue vers les sauts suivants. Consultez la documentation Microsoft de pathping.
Pour une capture plus précise, vérifiez si votre version de Windows propose pktmon et suivez la documentation Microsoft de Pktmon. Gardez une hypothèse, un filtre et une courte fenêtre de mesure. Sauvegardez la sortie et ne modifiez pas le filtre entre les deux essais comparés.
- Lancer un ping fixeFixez la destination et le nombre de requêtes, puis conservez toute la sortie.
- Comparer la passerelleRépétez vers le routeur local si le problème semble lié au Wi‑Fi ou à l'Ethernet.
- Observer le cheminUtilisez pathping, mais lisez les pertes intermédiaires avec les sauts finaux.
- Capturer seulement si nécessaireUtilisez Pktmon avec une portée et une durée documentées.
04
Lire les résultats sans tirer une conclusion trop forte
Cherchez un motif stable entre les destinations et les périodes. Une passerelle propre avec un seul service en panne justifie une répétition depuis une autre route et une demande de journaux côté service. Une perte sur la passerelle au moment où plusieurs applications échouent oriente vers le signal Wi‑Fi, le câble, la charge du routeur, le pilote ou les interférences locales.
Ne transformez pas chaque ligne de pathping en diagnostic. Les routeurs traitent les réponses ICMP différemment du trafic qu'ils transmettent. Le signal le plus convaincant est une perte qui continue sur les sauts suivants et qui coïncide avec le symptôme. Un délai élevé sans perte est d'abord un problème de latence.
Gardez un tableau avec la destination, la taille de l'échantillon, les paquets perdus, le délai moyen, l'heure, l'interface et le symptôme. Notez aussi un redémarrage de routeur, un changement de câble ou un changement de réseau. La reproductibilité est plus utile qu'un chiffre spectaculaire isolé.
| Motif | Étape suivante | Éviter de conclure |
|---|---|---|
| Passerelle et externe perdent | Examiner lien local, routeur, Wi‑Fi et câblage | Que l'application soit la cause |
| Passerelle propre, un service échoue | Comparer une autre route et demander les journaux | Que toute la connexion est coupée |
| Aucune perte, délai élevé | Examiner latence, files et distance | Que des paquets sont abandonnés |
| Ping échoue, application fonctionne | Vérifier la limitation ICMP de la cible | Que le trafic applicatif a le même taux |
05
Quand un test en ligne est utile
Un test en ligne donne rapidement un signal depuis le navigateur. Il peut servir de comparaison avant/après, de seconde mesure ou de procédure simple pour un collègue. Conservez cependant le serveur, la méthode et l'heure, car ces détails changent le résultat.
Le test utilise son propre serveur, son protocole, sa route et sa taille d'échantillon. Il peut donc différer d'un jeu, d'un VPN, d'un appel vidéo ou d'une application interne. Le terme large « packet loss test » correspond souvent à un outil en ligne ; cette page vise l'intention informative « comment diagnostiquer la perte sous Windows ».
Ne saisissez pas d'adresses internes ou de données de compte dans un formulaire inconnu. Si le résultat en ligne contredit ping ou pathping, répétez les deux tests dans des conditions comparables avant de décider lequel ignorer.
Les outils en ligne mesurent le chemin vers leurs propres serveurs. Ils fournissent un indice, mais ne prouvent pas que toutes les routes et toutes les applications ont la même perte.
06
Simuler avec Clumsy après le diagnostic
Clumsy répond à une autre question : comment une application Windows réelle réagit-elle lorsque le trafic sélectionné est volontairement dégradé ? Utilisez-le pour un test QA, de fiabilité ou de récupération autorisé, après avoir établi le comportement normal. Téléchargez l'archive officielle 0.3, extrayez-la entièrement et gardez un filtre étroit. La Release officielle Clumsy 0.3 est la source du fichier lié ici.
Activez Drop seul avec une valeur modeste, exécutez une opération connue et observez le client, le serveur et l'interface. Une réponse perdue ne signifie pas forcément que le serveur a échoué : il peut avoir terminé avant la perte. Vérifiez les identifiants de requête, les clés d'idempotence et les enregistrements serveur avant de répéter une action qui crée un message ou un travail.
Sélectionnez Stop, répétez la référence et vérifiez la récupération. La procédure complète se trouve dans le guide du simulateur de perte de paquets. Si Clumsy ne démarre pas le filtrage, consultez la page de dépannage de l'erreur code 3 plutôt que d'utiliser cette erreur comme preuve réseau.
07
Liste de contrôle pour la perte de paquets
Avant de signaler une perte, vérifiez qu'une autre personne pourrait refaire le test. Indiquez la destination, le nombre d'échantillons, l'heure, l'interface, le résultat de la passerelle, le résultat externe, la sortie des commandes et le symptôme. Si un test en ligne a été utilisé, ajoutez son serveur et sa méthode. Gardez les résultats Clumsy séparés du diagnostic réel.
Choisissez l'étape suivante d'après le motif. Une perte locale appelle une vérification du Wi‑Fi, du câble, du routeur ou du pilote. Une perte propre à un service appelle une comparaison de route et des journaux côté service. Des mesures réseau propres avec une application en échec appellent une revue des délais d'attente, des reprises et de la télémétrie applicative.
Arrêtez le test lorsqu'il sort du périmètre autorisé ou risque de perturber une connexion partagée. Clumsy ne doit pas servir de lag switch, de contournement anti-triche ou de moyen de gêner d'autres utilisateurs. Un test sûr est ciblé, réversible et se termine par une preuve de récupération.
- Définir l'application, la destination et le symptôme à expliquer.
- Mesurer la référence vers la passerelle et une destination externe.
- Conserver la sortie ping, pathping ou capture avec l'heure exacte.
- Comparer plusieurs échantillons plutôt qu'une réponse isolée.
- Séparer le diagnostic réel de la simulation volontaire de Clumsy.
- Arrêter le test autorisé et confirmer le retour à la normale.
Questions fréquentes
Comment tester la perte de paquets sous Windows : FAQ
Quelle est la méthode la plus simple pour tester la perte de paquets sous Windows ?
Lancez un échantillon ping fixe vers la passerelle locale et une destination externe fiable. Conservez toute la sortie et répétez le test avant de conclure.
Une perte ping de 100 % prouve-t-elle que ma connexion est coupée ?
Non. La cible peut bloquer ou limiter ICMP. Comparez la passerelle, une autre cible et l'application qui échoue.
Faut-il utiliser un testeur de perte en ligne ?
Il peut fournir une seconde comparaison, mais il mesure le chemin vers son propre serveur. Associez-le à une mesure locale et aux journaux du service.
Clumsy peut-il diagnostiquer une perte réelle ?
Non. Clumsy dégrade volontairement le trafic sélectionné pour tester la résistance d'une application. Utilisez ping, pathping, Pktmon et les journaux pour le diagnostic.
Quelle est la différence entre perte et latence ?
La latence est le temps de trajet ; la perte signifie que le trafic ou la réponse n'arrive pas. Les reprises peuvent rendre une perte plus lente à l'écran.
Pourquoi le test réussit-il plus tard sans changement ?
La perte peut être intermittente et dépendre du Wi‑Fi, de la congestion, de la route ou de la politique de réponse de la cible. Répétez avec les mêmes conditions.