Commencez par une référence normale, choisissez une seule dégradation, utilisez le filtre le plus étroit qui réponde à la question, exécutez une action reproductible, consignez les preuves client et serveur, sélectionnez Stop puis répétez la référence. Quand le scénario est clair, ouvrez le guide ciblé de latence, de perte de paquets, de bande passante ou d'ordre des paquets.
01
Ce que couvre ce guide de test réseau Clumsy
La première décision est la question du test, pas un pourcentage spectaculaire.
Clumsy modifie le trafic Windows sélectionné grâce à WinDivert. Ses modules retardent, suppriment, dupliquent, réordonnent, modifient ou limitent les paquets correspondants afin d'observer de vraies applications dans des conditions reproductibles. Il ne crée pas de routeur virtuel et ne diagnostique pas un fournisseur d'accès.
Ce centre complète le tutoriel de configuration en six étapes : il aide à choisir un scénario, décider quoi enregistrer et ouvrir la recette la plus étroite. Diagnostiquez d'abord la panne réelle, puis simulez une condition connue.
Utilisez Clumsy sur un appareil, une application et un chemin réseau qui vous appartiennent ou sont autorisés. Un filtre large peut toucher l'accès distant, les mises à jour, les appels et les onglets sans rapport. Le test doit rester réversible, observable et répétable.
- Un flux de travail d'application possédée ou autorisée.
- Une condition et une valeur documentée par exécution.
- Une référence mesurée avant et après la dégradation.
- Des preuves côté client, serveur et utilisateur lorsqu'une requête peut avoir des effets de bord.
02
Choisir le bon scénario de test réseau Windows
Associez la condition au comportement à observer. Ce guide de test réseau Clumsy rend le choix explicite. Ne combinez pas Lag, Drop et Throttle au premier essai : vous ne connaîtrez pas la cause d'un échec. Commencez par le profil minimal et faites un essai de limite seulement si nécessaire.
Le guide des émulateurs réseau explique émulation et simulation. Utilisez la limitation du navigateur pour un onglet ou un proxy pour les règles HTTP ; utilisez Clumsy lorsqu'une application Windows a besoin de conditions de paquets réelles sans modification du code.
| Question | Commencer par | Preuves à recueillir |
|---|---|---|
| L'interface explique-t-elle une réponse lente ? | Lag de 200-300 ms sur une cible | Accusé immédiat, état de chargement, délai d'expiration et annulation |
| Les tentatives récupèrent-elles des paquets manquants ? | Drop avec une faible probabilité | ID de requête, nombre de tentatives, reconnexion et effets en double |
| Un transfert important reste-t-il utilisable ? | Throttle ou Bandwidth sur un transfert | Progression, file d'attente, annulation et nombre final d'octets |
| Le client supporte-t-il des livraisons répétées ? | Duplicate sur un enregistrement de test sûr | Résultat d'idempotence et nombre d'enregistrements serveur |
| Un flux conserve-t-il sa séquence ? | Out of order sur un flux jetable | Numéros de séquence, mise en tampon, réassemblage et journaux de récupération |
03
Préparer une référence avant de modifier les paquets
Un test Clumsy contrôlé commence par un comportement normal qui pourra être comparé ensuite.
Formulez une question observable. Par exemple : « Avec 300 ms ajoutées à l'API de staging, la page doit confirmer le clic, garder les filtres et afficher un résultat sans requête en double. » Notez la version, l'hôte ou le port, l'état attendu et l'action de récupération. « Rendre le réseau mauvais » est trop vague.
Exécutez l'action sans Clumsy et notez temps de réponse, chargement, code d'état, ID de requête, journal serveur ou taille du transfert. Mettez en pause les téléchargements sans rapport et utilisez des données de staging pour écrire.
Vérifiez l'archive avant le dépannage. La release officielle jagt/clumsy 0.3 est un ZIP portable Win64/Win32 avec signatures A/B/C. Le manuel officiel couvre filtres et direction ; n'utilisez pas une compilation modifiée inconnue.
- DéfinirÉcrivez une question produit, une cible, une condition et un critère de réussite.
- RéférenceExécutez exactement l'action en temps normal et gardez les preuves à comparer.
- VérifierConservez l'archive officielle, l'architecture et le checksum dans le relevé.
- ProtégerUtilisez des données de staging ou un compte jetable pour les opérations à effets de bord.
04
Délimiter le filtre et la direction
Le filtre est la frontière de l'expérience. Une règle pour chaque paquet peut faire paraître cassés l'authentification, la supervision, le support distant et d'autres applications. Commencez avec une destination, un protocole ou un port connu. Une expression de port peut inclure plusieurs applications : expliquez son périmètre dans le relevé.
La direction change l'observation : le délai sortant teste la requête, l'entrant le chargement et l'expiration. Commencez avec une direction et ajoutez un essai si les deux chemins comptent.
Si vous ne pouvez pas expliquer ce qu'un filtre sélectionne, ne le copiez pas d'un forum ou d'une vidéo. Sélectionnez Stop, simplifiez l'expression et sauvegardez filtre, direction et heure avec le résultat.
| Choix de périmètre | Utile lorsque | Erreur courante |
|---|---|---|
| Hôte ou service connu | Un endpoint de staging est la cible | Supposer que l'hôte couvre toutes les dépendances |
| Protocole et port | Le flux possède une frontière de transport claire | Dégrader d'autres applications partageant le port |
| Entrant uniquement | La question concerne le temps de réponse ou le rendu | Oublier que le chemin de requête reste normal |
| Sortant uniquement | La question concerne le délai de requête ou l'envoi | Prendre le délai ajouté pour la latence aller-retour totale |
| Tout le trafic | Test système jetable et explicitement approuvé | L'exécuter sur un poste de travail ou une connexion partagée |
05
Exécuter une condition et recueillir les preuves
Un bon test produit une comparaison, pas seulement un écran ralenti.
Activez un module et saisissez une valeur documentée. Lag est souvent le premier choix car il retarde les paquets sans les supprimer. 200-300 ms est un départ pratique ; augmentez seulement pour une limite. Sélectionnez Start et répétez l'action de référence sans changer la valeur.
Observez le premier accusé et la réponse finale. Vérifiez progression, annulation, état du formulaire et premier minuteur. Ajoutez ID de requête, heure, codes d'état et journaux serveur si l'opération peut être répétée. Une réponse absente ne prouve pas que le serveur n'a pas terminé.
Gardez chaque essai court et nommé. Enregistrez versions de l'application, Windows et Clumsy, origine, filtre, direction, valeurs, référence, résultat et récupération pour ne pas confondre une dégradation temporaire avec une panne permanente.
- ConfirmerRelisez le filtre, la direction et la liste des modules juste avant Start.
- ExécuterRéalisez une action connue avec une condition et une valeur enregistrée.
- ObserverCapturez le retour utilisateur, le timing client et les preuves serveur.
- ArrêterSélectionnez Stop avant de modifier une valeur ou de changer de scénario.
- ComparerRépétez l'action de référence et notez si le comportement normal revient.
06
Passer du centre à une recette Clumsy ciblée
Une fois la question claire, utilisez le guide ciblé le plus petit. Le guide de latence couvre délai et expiration ; celui de perte de paquets couvre Drop et tentatives. Les guides de bande passante et de paquets désordonnés couvrent transfert et séquence.
Une recette doit préciser ce qu'elle change, ce qu'elle ne prouve pas et comment récupérer. Pour une connexion réelle, consultez le diagnostic de perte Windows avant de simuler ; pour un pilote, le dépannage Error Code 3.
| Besoin | Page suivante | À garder séparé |
|---|---|---|
| Comprendre le premier essai | Comment utiliser Clumsy | N'élargissez pas le filtre pour obtenir un effet plus fort |
| Tester un délai fixe | Simulateur de latence | N'appelez pas un délai une limite de bande passante |
| Tester des paquets manquants | Simulateur de perte de paquets | Ne concluez pas à une panne serveur à partir d'une réponse perdue |
| Tester un transfert lent | Limitation de bande passante | Ne combinez pas plusieurs débits dans un essai |
| Tester l'ordre | Paquets hors séquence | Ne mélangez pas Drop avant de confirmer le comportement de séquence |
07
Récupérer, documenter les limites et choisir un autre outil
La récupération fait partie du test. Ce guide de test réseau Clumsy la considère obligatoire. Sélectionnez Stop à la fin, fermez Clumsy si nécessaire et répétez la référence. Vérifiez la cible et une action ordinaire. Si le réseau reste instable, contrôlez Clumsy, les autres outils ou VPN et la largeur du filtre. Arrêtez si la référence est inconnue.
Clumsy n'est pas un laboratoire complet. Utilisez un simulateur pour les routeurs virtuels, un proxy pour HTTP, le navigateur pour un onglet ou un contrôleur programmable pour des profils multiplateformes.
N'utilisez pas ce guide pour tricher, contourner un anti-triche, dissimuler un lag switch ou perturber des services tiers. Une formulation sûre est concrète : ajouter 250 ms à un endpoint de staging, observer le chargement, vérifier la politique de tentative et prouver la récupération après Stop.
Une session Clumsy est terminée uniquement lorsque la dégradation est arrêtée, que l'action de référence est répétée et que la preuve de récupération est conservée avec le filtre et les réglages du module.
Questions fréquentes
FAQ du guide de test réseau Clumsy
Quel est le meilleur premier test avec Clumsy ?
Utilisez une application non critique, un filtre étroit et une valeur Lag modérée, par exemple 200-300 ms. Notez d'abord le comportement normal, observez une action connue et prouvez la récupération après Stop.
Faut-il diagnostiquer la perte de paquets avant de la simuler ?
Oui. Comparez d'abord un échantillon fixe avec la passerelle locale et une cible externe. Utilisez ensuite Clumsy pour reproduire une perte contrôlée dans un test d'application autorisé.
Pourquoi le filtre Clumsy doit-il être étroit ?
Un filtre étroit limite la portée de l'impact et rend le résultat plus facile à expliquer et à récupérer. Une règle large peut toucher l'accès distant, les mises à jour, les appels et des applications sans rapport.
Quelle est la version officielle actuelle de Clumsy ?
La release officielle jagt/clumsy vérifiée pour ce guide est la 0.3, publiée le 21 octobre 2023. Utilisez l'historique officiel et la page 0.3 existante pour vérifier les fichiers plutôt que de faire confiance à un numéro supérieur sur un miroir.