Comece com uma linha de base, escolha uma única degradação, use o filtro mais estreito que responda à pergunta, execute uma ação repetível, registre evidências do cliente e do servidor, selecione Stop e repita a linha de base. Quando o cenário estiver claro, abra o guia específico de latência, perda de pacotes, largura de banda ou ordem dos pacotes.
01
O que este guia de testes de rede do Clumsy cobre
A melhor primeira decisão é a pergunta do teste, não uma porcentagem dramática.
O Clumsy altera o tráfego selecionado do Windows por meio do WinDivert. Os módulos atrasam, descartam, duplicam, reordenam, modificam ou limitam pacotes correspondentes para observar aplicativos reais em condições repetíveis. Ele não cria um roteador virtual nem diagnostica um provedor.
O centro complementa o tutorial de configuração em seis etapas: ajuda a escolher o cenário, decidir o que registrar e abrir a receita mais estreita. Diagnostique a falha real antes de simular uma condição conhecida.
Use o Clumsy somente em dispositivo, aplicativo e caminho que sejam seus ou estejam autorizados. Um filtro amplo pode afetar acesso remoto, atualizações, chamadas e abas não relacionadas. O teste deve ser reversível, observável e repetível.
- Um fluxo de trabalho de aplicativo próprio ou autorizado.
- Uma condição e um valor documentado por execução.
- Uma linha de base medida antes e depois da degradação.
- Evidências do cliente, servidor e usuário quando a solicitação pode ter efeitos colaterais.
02
Escolha o cenário certo de teste de rede no Windows
Relacione a condição ao comportamento que precisa observar. Este guia de testes de rede do Clumsy deixa a escolha clara. Não combine Lag, Drop e Throttle no início: se falhar, você não saberá a causa. Comece pelo perfil mínimo e faça um teste de limite apenas quando necessário.
O guia de emuladores de rede explica emulação e simulação. Use o throttling do navegador para uma aba ou um proxy para regras HTTP; use o Clumsy quando um aplicativo do Windows precisar de condições reais de pacotes sem alteração de código.
| Pergunta | Comece com | Evidência a coletar |
|---|---|---|
| A interface explica uma resposta lenta? | Lag de 200-300 ms em um destino | Confirmação imediata, estado de carregamento, timeout e cancelamento |
| As tentativas se recuperam de tráfego ausente? | Drop com baixa probabilidade | IDs de solicitação, número de tentativas, reconexão e efeitos duplicados |
| Uma transferência grande continua utilizável? | Throttle ou Bandwidth em uma transferência | Progresso, fila, cancelamento e contagem final de bytes |
| O cliente lida com entregas repetidas? | Duplicate em um registro de teste seguro | Resultado de idempotência e quantidade de registros no servidor |
| Um fluxo preserva a sequência? | Out of order em um fluxo descartável | Números de sequência, buffer, remontagem e logs de recuperação |
03
Prepare uma linha de base antes de alterar pacotes
Um teste controlado com Clumsy começa com um comportamento normal que pode ser comparado depois.
Escreva uma pergunta observável. Por exemplo: “Com 300 ms adicionados à API de staging, a página deve confirmar o clique, manter os filtros e mostrar um resultado sem solicitação duplicada.” Anote build, host ou porta, estado esperado e ação de recuperação. “Deixar a rede ruim” é vago demais.
Execute a ação sem Clumsy e registre tempo de resposta, carregamento, código de status, ID da solicitação, log do servidor ou tamanho da transferência. Pause downloads não relacionados e use dados de staging para escrever.
Verifique o arquivo antes de solucionar problemas. O release oficial jagt/clumsy 0.3 é um ZIP portátil Win64/Win32 com assinaturas A/B/C. O manual oficial cobre filtros e direção; não use um build modificado desconhecido.
- DefinaEscreva uma pergunta do produto, alvo, condição e critério de aprovação.
- Linha de baseExecute a ação exata normalmente e salve a evidência para comparar.
- VerifiqueMantenha o arquivo oficial, a arquitetura e o checksum no registro do teste.
- ProtejaUse dados de staging ou uma conta descartável em operações com efeitos colaterais.
04
Defina o escopo do filtro e da direção
O filtro é o limite do experimento. Uma regra para todos os pacotes pode fazer autenticação, monitoramento, suporte remoto e outros aplicativos parecerem quebrados. Comece com destino, protocolo ou porta conhecidos. Uma expressão de porta pode incluir vários aplicativos; explique o escopo no registro.
A direção muda a observação: o atraso de saída testa a solicitação e o de entrada testa carregamento e timeout. Comece com uma direção e faça outro teste se ambos os caminhos importarem.
Se não consegue explicar a correspondência, não copie o filtro de fórum ou vídeo. Selecione Stop, simplifique a expressão e salve filtro, direção e hora com o resultado.
| Escolha de escopo | Útil quando | Erro comum |
|---|---|---|
| Host ou serviço conhecido | Um endpoint de staging é o alvo | Supor que o host cubra todas as dependências |
| Protocolo e porta | O fluxo tem uma fronteira de transporte clara | Prejudicar outros aplicativos que compartilham a porta |
| Somente entrada | A pergunta é tempo de resposta ou renderização | Esquecer que o caminho da solicitação continua normal |
| Somente saída | A pergunta é atraso de solicitação ou comportamento de envio | Tratar o atraso adicionado como latência total de ida e volta |
| Todo o tráfego | Teste descartável e aprovado para todo o sistema | Executar em máquina de trabalho ou conexão compartilhada |
05
Execute uma condição e reúna evidências
Um bom teste produz uma comparação, não apenas uma tela lenta.
Ative um módulo e informe um valor documentado. Lag é um bom primeiro teste porque atrasa os pacotes sem descartá-los. 200-300 ms é um início prático; aumente apenas para um limite. Selecione Start e repita a ação da linha de base sem mudar o valor.
Observe a primeira confirmação e a resposta final. Verifique progresso, cancelamento, estado do formulário e o primeiro temporizador. Adicione IDs, horários, códigos de status e logs quando a operação puder ser repetida. Uma resposta ausente não prova que o servidor não concluiu a solicitação.
Mantenha cada execução curta e identificada. Salve versões do app, Windows e Clumsy, origem, filtro, direção, valores, linha de base, resultado e recuperação para não confundir degradação temporária com falha permanente.
- ConfirmeRevise filtro, direção e lista de módulos imediatamente antes de Start.
- ExecuteFaça uma ação conhecida com uma condição e um valor registrado.
- ObserveCapture retorno do usuário, tempo do cliente e evidências do servidor.
- PareSelecione Stop antes de mudar um valor ou passar a outro cenário.
- CompareRepita a ação da linha de base e registre se o comportamento normal voltou.
06
Do centro para uma receita específica do Clumsy
Quando a pergunta estiver clara, use o guia menor. O guia de latência cobre atraso e timeouts; o de perda de pacotes cobre Drop e tentativas. Os guias de largura de banda e pacotes fora de ordem cobrem transferência e sequência.
Uma receita deve indicar o que muda, o que não prova e como recuperar. Para uma conexão real, use o diagnóstico de perda no Windows antes de simular; para um driver, consulte Error Code 3.
| Necessidade | Próxima página | Mantenha separado |
|---|---|---|
| Entender a primeira execução | Como usar o Clumsy | Não amplie o filtro apenas para obter um efeito maior |
| Testar atraso fixo | Simulador de latência | Não chame atraso de limite de largura de banda |
| Testar pacotes ausentes | Simulador de perda de pacotes | Não deduza falha do servidor por causa de uma resposta perdida |
| Testar uma transferência lenta | Limitação de largura de banda | Não combine várias taxas em uma execução |
| Testar ordenação | Pacotes fora de ordem | Não misture Drop antes de confirmar o comportamento de sequência |
07
Recupere, documente limites e escolha outra ferramenta
A recuperação faz parte do teste. Este guia de testes de rede do Clumsy a considera obrigatória. Selecione Stop ao terminar, feche o Clumsy se necessário e repita a linha de base. Confirme o alvo e uma ação comum. Se continuar instável, verifique Clumsy, outras ferramentas ou VPN e o alcance do filtro. Pare se a linha de base for desconhecida.
O Clumsy não é um laboratório completo. Use um simulador para roteadores virtuais, um proxy para HTTP, o navegador para uma aba ou um controlador programável para perfis multiplataforma.
Não use este guia para trapacear, contornar anti-cheat, ocultar lag switch ou interromper serviços de terceiros. Uma afirmação segura é concreta: atrasar um endpoint de staging em 250 ms, observar o estado de carregamento, verificar a política de tentativas e provar a recuperação após Stop.
Uma sessão do Clumsy só termina quando a degradação é interrompida, a ação da linha de base é repetida e a evidência de recuperação é salva com o filtro e os valores do módulo.
Perguntas frequentes
FAQ do guia de testes de rede do Clumsy
Qual é o melhor primeiro teste com o Clumsy?
Use um aplicativo não crítico, um filtro estreito e um valor Lag moderado, como 200-300 ms. Registre primeiro o comportamento normal, observe uma ação conhecida e prove a recuperação após Stop.
Devo diagnosticar perda de pacotes antes de simulá-la?
Sim. Compare primeiro uma amostra fixa com o gateway local e um destino externo. Depois use o Clumsy para reproduzir uma perda controlada em um teste de aplicativo autorizado.
Por que o filtro do Clumsy deve ser estreito?
Um filtro estreito limita o alcance do impacto e facilita explicar e recuperar o resultado. Uma regra ampla pode afetar acesso remoto, atualizações, chamadas e aplicativos não relacionados.
Qual é a versão oficial atual do Clumsy?
O release oficial jagt/clumsy verificado para este guia é o 0.3, publicado em 21 de outubro de 2023. Use o histórico oficial e a página existente do 0.3 para verificar arquivos, em vez de confiar em um número maior de um mirror.