Mesurez d'abord le flux normal, choisissez une cible autorisée, activez uniquement Out of order, notez le filtre et les valeurs, puis observez les trous de séquence, le tampon, les tentatives et l'état final. Arrêtez Clumsy et répétez l'action avant de conclure.
01
Ce que signifie une livraison dans le désordre
Le test porte sur l'ordre d'arrivée, pas simplement sur une connexion plus lente.
L'émetteur peut envoyer les paquets dans l'ordre alors que le destinataire voit d'abord un paquet plus récent. L'application, le transport ou la bibliothèque de protocole peut alors conserver les données dans un tampon, demander une retransmission, supprimer un fragment ancien ou produire un résultat partiel. La bonne question est de savoir si le logiciel conserve son état et reconstitue le message lorsque l'ordre change.
Le désordre n'est pas une perte de paquets. Lors d'une perte, un paquet n'arrive jamais ; lors d'une réorganisation, il peut arriver plus tard. Ce n'est pas non plus la latence : un délai uniforme décale la livraison sans forcément changer l'ordre. Clumsy 0.3 propose Out of order avec Lag, Drop, Throttle, Duplicate et Tamper. Le filtre, la direction, le protocole et l'application doivent donc être consignés.
| Condition | Ce qui change | À observer |
|---|---|---|
| Out of order | Des paquets ultérieurs peuvent arriver avant | Trous, tampon, réassemblage et état final |
| Perte | Des paquets correspondants sont supprimés | Tentatives, délais d'attente et reconnexion |
| Latence | Les paquets attendent avant livraison | Chargement, minuteurs et annulation |
| Duplicate | Un paquet peut être livré plusieurs fois | Idempotence, événements et écritures répétées |
02
Préparer un test de réordonnancement sûr
Choisissez un workflow reproductible : réponse en flux, API paginée, consommateur de messages ou transfert de fichier sans données critiques. Définissez le résultat attendu avant d'ouvrir Clumsy. Un client devrait tamponner une réponse réordonnée, conserver l'identifiant de requête et afficher un seul résultat complet.
Mesurez ensuite le même workflow sans perturbation. Notez le temps, les états visibles, les journaux client et serveur ainsi que les identifiants de séquence ou de requête. Utilisez le filtre le plus étroit qui couvre la cible autorisée et laissez Lag, Drop, Throttle, Duplicate et Tamper désactivés lors du premier passage.
- Un workflow répétable et une cible autorisée.
- Une référence avec preuves client et serveur.
- Un filtre dont la portée est compréhensible.
- Une seule condition Out of order par exécution.
- Un contrôle de récupération défini avant Start.
03
Exécuter le test Clumsy de paquets dans le désordre
Utilisez la page Release officielle Clumsy 0.3 comme source. Les métadonnées vérifiées le 22 août 2026 indiquent toujours 0.3, publiée le 21 octobre 2023. Téléchargez le ZIP adapté, extrayez toute l'archive et conservez le nom du fichier avec la source dans le compte rendu. Cette page ne distribue pas d'exécutable repackagé.
Ouvrez Clumsy avec les droits approuvés pour le poste de test, saisissez le filtre documenté et activez uniquement Out of order. N'utilisez pas une règle large copiée d'un forum si sa portée est inconnue. Notez direction, protocole, hôte ou port et toutes les valeurs visibles avant Start.
Rejouez l'action de référence. Cherchez un trou de séquence, un tampon temporaire, une fin tardive, une retransmission ou un état qui ne se termine jamais. Si le résultat est ambigu, arrêtez, réduisez la portée et recommencez dans une nouvelle exécution.
- RéférenceExécuter le workflow normalement et conserver résultat et durée.
- PortéeDéfinir le filtre le plus étroit et noter protocole, direction et cible.
- IsolerActiver Out of order seul et laisser les autres modules désactivés.
- ObserverComparer état client, séquence, tampon, tentatives et journaux serveur.
- RécupérerChoisir Stop, répéter le workflow et confirmer le retour à la référence.
04
Observer les preuves côté client et serveur
Un test utile produit des preuves des deux côtés. Côté client, vérifiez le tampon lié à la séquence, un état de progression qui ne reste pas bloqué, un résultat unique, l'état de navigation conservé et une erreur explicite si la récupération échoue. Côté serveur, comparez identifiants, ordre des réponses, confirmations, répétitions et écriture finale.
Dans un flux, les fragments ultérieurs doivent attendre le fragment précédent. Pour la messagerie, vérifiez qu'un événement dépendant n'est pas appliqué trop tôt et que le consommateur ne répète pas une commande. Pour un fichier ou une API, un hash final ou un objet analysé vaut mieux qu'une capture d'écran. TCP peut masquer l'ordre des paquets ; un protocole UDP peut le gérer lui-même.
Le résultat n'est pas complet parce que l'application finit par répondre. Arrêtez Clumsy, répétez la référence et consignez la récupération dans le même cas.
05
Séparer réordonnancement, perte, latence et débit
Si le produit échoue lors d'une réorganisation, gardez le constat sur cette page. Le guide de latence traite les réponses tardives, le guide de perte les tentatives et reconnexions, et le guide de débit le transfert, la progression et l'annulation.
Construisez une petite matrice seulement après le cas isolé. Conservez dans chaque ligne la version Windows, la version Clumsy, la source, le filtre, la direction, le module, les valeurs, la référence et la récupération. Une combinaison de conditions doit devenir un nouveau cas nommé.
La question de la reconstruction de paquets UDP dans le désordre concerne l'implémentation du protocole. Elle peut rester une courte explication de FAQ, sans transformer cette page en cours général de réseaux.
| Question | Commencer par... | Résultat principal |
|---|---|---|
| La séquence résiste-t-elle au désordre ? | Out of order seul | Tampon, ordre et état final |
| Les données manquantes sont-elles récupérées ? | Drop seul | Tentatives et reconnexion |
| L'interface explique-t-elle une réponse lente ? | Lag seul | Chargement, annulation et timeout |
| Le transfert reste-t-il utilisable ? | Throttle seul | Progression, file et intégrité |
06
Récupération, erreurs et usage responsable
Choisissez Stop dès que l'observation attendue est terminée. Si l'application conserve un ancien état, fermez-la, répétez la référence et contrôlez VPN, proxy, pare-feu ou messages de service. Si le comportement normal ne revient pas, n'ajoutez pas de conditions ; restaurez d'abord l'environnement.
Les erreurs courantes sont le filtre sur tout le trafic, plusieurs modules simultanés, les changements de valeur pendant l'exécution, les données de production, une capture utilisée comme preuve d'intégrité et un outil laissé actif. Un filtre étroit, des données de test et une seconde référence donnent un compte rendu plus fiable.
Utilisez Clumsy sur vos systèmes ou avec une autorisation explicite. Ce guide ne fournit ni contournement anti-triche, ni réglage de lag switch caché, ni manipulation du ping, ni instruction de perturbation.
- Arrêter la condition avant de quitter le poste.
- Confirmer la connectivité et l'état normal après Stop.
- Sauvegarder la configuration exacte avec le résultat.
- Ne pas considérer un binaire tiers à numéro supérieur comme une mise à jour officielle sans preuve.
Questions fréquentes
FAQ sur les paquets dans le désordre
Clumsy crée-t-il de vrais paquets dans le désordre ?
Clumsy peut créer une condition contrôlée de réorganisation pour le trafic correspondant. Le résultat dépend toutefois du protocole, de la direction, du filtre, du système et de l'application. Conservez la configuration et les journaux.
Est-ce la même chose que la perte de paquets ?
Non. En cas de perte, le paquet manque ; en cas de réorganisation, il peut arriver plus tard. Testez Drop et Out of order séparément au début.
TCP et UDP donnent-ils le même résultat ?
Pas nécessairement. Le transport peut cacher l'ordre à l'application, tandis qu'un protocole UDP peut gérer sa propre séquence et son réassemblage.
Pourquoi l'application semble-t-elle figée ?
Elle peut attendre un segment précédent, un délai ou une limite de tampon. Comparez les preuves client et serveur, arrêtez Clumsy et répétez la référence.
Puis-je l'utiliser comme lag switch ou ping hack ?
Non. Cette page est limitée aux tests de développement, QA et fiabilité autorisés. Elle ne contient pas de procédure de contournement ou de perturbation.