Pour un test de limitation de bande passante, mesurez le même transfert sans Clumsy, choisissez une cible autorisée, utilisez le filtre le plus précis possible, activez seulement Throttle, notez le débit observé puis arrêtez Clumsy avant de refaire la mesure de base. Le résultat est une condition locale, pas un diagnostic exact du fournisseur.
01
Ce que mesure un test de limitation de bande passante
La formule recouvre souvent deux questions différentes.
La limitation de bande passante réduit volontairement la vitesse de transfert des données dans le temps. Dans un test Clumsy autorisé, le module Throttle applique une condition de livraison contrainte aux paquets correspondant au filtre. L’application continue d’utiliser sa vraie pile réseau Windows : vous pouvez donc observer progression, file d’envoi, mise en mémoire tampon, planification des requêtes et délais d’attente. Un test de limitation de bande passante doit enregistrer la condition appliquée et le résultat dans l’application, car le débit dépend du filtre, du protocole, de la taille des paquets et de la destination.
Cela ne correspond pas au diagnostic d’un bridage par le fournisseur d’accès. Un FAI peut limiter un forfait, un service ou une période ; Clumsy ne dit pas pourquoi une connexion domestique est lente et ne la répare pas. Le terme internet throttling sert ici à poser la limite du sujet, pas à remplacer une démarche de diagnostic FAI.
Clumsy n’est pas non plus un débitmètre de laboratoire. Le résultat dépend du filtre, du sens, de la taille des paquets, du protocole, du RTT, du serveur et de la charge locale. Utilisez Throttle pour créer une condition comparable, puis mesurez le transfert réel à chaque exécution. Consultez la documentation officielle de Clumsy pour le contexte du projet.
| Condition | Ce qui change | Question produit utile |
|---|---|---|
| Limitation de bande passante | La livraison soutenue est réduite | La progression reste-t-elle visible et annulable ? |
| Latence | Les paquets attendent avant livraison | L’interface explique-t-elle l’attente ? |
| Perte de paquets | Certains paquets sont supprimés | Les reprises évitent-elles les doublons ? |
| Bridage FAI | Le fournisseur ou le forfait limite | La contrainte existe-t-elle hors de l’application ? |
| Bridage navigateur | Une session applique un réglage | Cette page se comporte-t-elle sous ce réglage ? |
02
Préparer la référence et le filtre
Écrivez une hypothèse avant d’ouvrir Clumsy. Exemple : lorsque le flux de téléchargement API est contraint, le client doit afficher la progression, conserver l’action d’annulation, éviter les requêtes parallèles illimitées et terminer avec une réponse intègre. Cette formulation produit des preuves concrètes plutôt qu’une impression de lenteur.
Lancez le même transfert sans altération. Notez la taille, les heures de début et de fin, le débit approximatif, les états visibles, le nombre de requêtes et les identifiants côté serveur. Une petite requête peut finir avant que Throttle soit perceptible ; un transfert stable de plusieurs mégaoctets laisse le temps d’observer la condition.
Définissez le filtre le plus étroit couvrant la cible autorisée. Un hôte, un protocole, un port ou un sens précis est plus explicable qu’une règle qui touche tous les paquets de l’ordinateur. Fermez les téléchargements et sessions distantes non concernés, gardez Stop accessible et préparez une restauration immédiate.
- Une application, un endpoint ou un transfert par essai.
- Un filtre et un sens documentés.
- Throttle seul au départ ; laissez Lag, Drop, Duplicate, Out of order et Tamper désactivés.
- Une mesure de référence et un critère de réussite.
- Une action Stop et une mesure de récupération.
03
Configurer Throttle sans masquer la cause
Ouvrez la page de release officielle Clumsy 0.3 et choisissez-y l’archive Win64 ou Win32. Les métadonnées de la release indiquent 536 789 octets pour Win64 A et 581 772 pour Win32 A ; cette page ne prétend pas avoir téléchargé les ZIP ni confirmé ici les réponses HTTP des fichiers directs. Téléchargez depuis GitHub, puis comparez nom, taille en octets et SHA-256 avant l’extraction.
Saisissez le filtre étroit, confirmez le sens et activez seulement Throttle. La valeur doit venir du cas de test, pas d’une recette agressive trouvée sur un forum inconnu. Commencez avec une contrainte modérée qui laisse le transfert observable. S’il n’y a aucune différence, vérifiez d’abord le filtre et la durée du transfert.
Ne présentez pas le réglage comme une limite exacte de 1, 5 ou 10 Mbps sans mesure propre à l’endpoint. Clumsy modifie la livraison des paquets ; le débit effectif est un résultat à mesurer. Gardez filtre, données, endpoint, sens et durée constants pour comparer.
04
Exécuter et mesurer un test de limitation
Un résultat utile compare le même transfert dans deux conditions documentées.
Lancez d’abord le transfert normalement et enregistrez la référence. Sélectionnez ensuite Start dans Clumsy et répétez exactement l’opération. Observez l’application, les compteurs Clumsy, les journaux client et les temps serveur. Si le produit utilise plusieurs connexions, notez-le : un flux unique et un groupe de flux ne réagissent pas nécessairement pareil.
Mesurez plus que la durée finale : octets, secondes, débit moyen, délai du premier progrès, pauses, reprises, annulation et intégrité de la réponse. Une page peut finir tout en échouant si elle reste muette plusieurs minutes ou ouvre des requêtes en double.
Gardez chaque scénario séparé. Pour une contrainte plus forte ou plus faible, arrêtez l’essai, sauvegardez le résultat et créez-en un autre en ne changeant qu’une variable. Modifier filtre et valeur pendant le transfert rend le résultat difficile à interpréter.
- RéférenceExécutez le transfert fixe sans Clumsy et notez octets, temps, débit et états visibles.
- PérimètreAppliquez le filtre autorisé et vérifiez que le trafic extérieur reste intact.
- ThrottleActivez uniquement Throttle avec la valeur documentée.
- ObserverRépétez le transfert et collectez preuves UI, client, serveur et intégrité.
- ComparerComparez débit et comportement avec la référence avant de conclure.
- RécupérerSélectionnez Stop, rejouez la référence et confirmez le retour au niveau normal.
| Mesure | Pourquoi | Preuve |
|---|---|---|
| Débit observé | Montre l’effet réel pour l’endpoint | Octets divisés par secondes |
| Premier progrès | Révèle une interface apparemment figée | Horodatage du premier changement |
| Intégrité | Sépare lenteur et corruption | Checksum, longueur ou validation applicative |
| Reprises et concurrence | Révèle le travail caché | ID, reprises et connexions ouvertes |
| Récupération | Confirme la fin de la condition | Même transfert dans la plage de référence |
05
Choisir des scénarios qui exposent un vrai risque
Un gros téléchargement est un bon premier scénario : il laisse le temps d’observer progression, annulation et intégrité. Un envoi peut révéler si l’interface conserve le fichier, signale l’attente et évite une seconde soumission. Un flux média peut montrer tampon et reconnexion, mais il dépend aussi de l’adaptation serveur et demande des métriques adaptées.
Les requêtes API courtes demandent de la prudence. Elles peuvent finir avant que la file Throttle soit visible, ou le filtre peut ne pas correspondre. Utilisez une réponse stable plus grande ou un lot contrôlé de lectures. Ne commencez pas par une mutation irréversible : une réponse lente peut masquer une réussite côté serveur.
Cette distinction aide à choisir un autre outil. Clumsy convient à l’émulation de conditions de paquets sélectionnés. Un gestionnaire de bande passante par application convient mieux à une règle du type ‘ce processus ne dépasse pas X Mbps’. Un simulateur convient à une topologie qui n’existe pas encore. Consultez le manuel de l’émulateur réseau et la comparaison Clumsy/NetLimiter.
| Scénario | À observer | Piège courant |
|---|---|---|
| Transfert important | Progression, annulation, fin et checksum | Le déclarer réussi parce qu’il finit |
| Envoi de fichier | Fichier, reprise, doublon et trace serveur | Tester une mutation sans réconciliation |
| Flux API en lecture | Premier octet, tampon, file et timeout | Réponse trop petite |
| Média ou mises à jour | Tampon, reconnexion et continuité | Attribuer l’adaptation serveur à Clumsy seul |
| Règle par application | Plafond du processus et comptage | Supposer que Clumsy est un gestionnaire précis |
06
Arrêter Clumsy et prouver la récupération
Sélectionnez Stop avant de modifier le filtre ou de démarrer un autre essai. Rejouez le transfert de référence avec Clumsy inactif et comparez débit, latence, requêtes, état applicatif et traces serveur. Si le résultat reste anormal, conservez les journaux, fermez l’outil et vérifiez les autres pilotes de paquets ou gestionnaires de trafic.
La récupération est une partie du résultat. Elle montre que le ralentissement venait d’une condition contrôlée et protège les autres applications du poste. Si Clumsy ne démarre pas le filtrage, consultez la page consacrée à l’erreur de code 3 plutôt que d’élargir le filtre ou de désactiver la sécurité.
Conservez une fiche courte : version, archive, architecture Windows, filtre, sens, valeur Throttle, données, référence, résultat contraint, journaux, heures de début et d’arrêt et résultat de récupération. Une plainte vague de bandwidth throttling devient alors un cas QA reproductible.
- Ne limitez pas tout le trafic si un filtre autorisé plus étroit suffit.
- Ne combinez pas Lag, Drop et Throttle avant d’avoir compris une condition seule.
- Ne présentez pas un essai Clumsy comme un diagnostic FAI.
- Ne testez pas une opération irréversible sans réconciliation serveur.
- Arrêtez toujours la condition et rejouez une référence connue.
Utilisez Clumsy uniquement sur des systèmes et trafics que vous possédez ou êtes autorisé à tester. Cette page ne couvre ni triche de jeu, ni contournement anti-triche, ni lag switch dissimulé, ni perturbation de services tiers.
Questions fréquentes
Questions fréquentes : limiter la bande passante avec Clumsy
Clumsy limite-t-il exactement un nombre de Mbps ?
Ne le supposez pas. Throttle crée une condition de livraison limitée, mais le débit dépend du filtre, du protocole, des tailles, de l’endpoint et du système. Mesurez chaque scénario.
Que tester d’abord avec Throttle ?
Commencez par un transfert important et répétable en lecture seule, un filtre étroit autorisé et une condition documentée. Notez débit, progression, annulation, intégrité et récupération.
Pourquoi une petite requête ne montre-t-elle rien ?
Elle peut finir avant que la condition soit visible ou le filtre peut ne pas correspondre. Confirmez la règle et utilisez une réponse plus grande ou un transfert plus long.
Cette page diagnostique-t-elle le bridage FAI ?
Non. Le bridage FAI concerne le fournisseur ou le forfait. Clumsy crée une condition locale contrôlée pour tester une application autorisée.
Comment savoir que le test est terminé ?
Sélectionnez Stop, fermez ou désactivez Clumsy, rejouez la référence et comparez. Si le comportement ne revient pas, conservez les preuves et examinez l’environnement local.
Que signifie la limitation réseau dans un test Clumsy ?
C’est une réduction volontaire de la condition de livraison pour le trafic sélectionné. Avec Clumsy, mesurez le transfert réel plutôt que de supposer une limite fixe en Mbps et n’utilisez pas ce test local pour prouver que le FAI ou le routeur limite la connexion.