A Internet parece estar funcionando. O Windows 11 mostra conexão normal, os sites abrem, o roteador permanece conectado e um teste com o comando ping retorna algo aparentemente perfeito:

Enviados = 100
Recebidos = 100
Perdidos = 0 (0% de perda)

Mesmo assim, alguma coisa está errada.

Um download começa rápido e, de repente, reduz drasticamente a velocidade. Uma transferência de arquivos pela rede apresenta pequenas pausas. Um sistema acessado pelo navegador demora para responder. Uma conexão remota parece travar por alguns segundos. Determinadas páginas carregam rapidamente enquanto outras parecem hesitar.

O primeiro pensamento costuma ser:

“Se o Ping não perdeu nenhum pacote, então a rede está funcionando perfeitamente.”

Essa conclusão pode estar errada.

O ping é uma excelente ferramenta de diagnóstico, mas ele observa um tipo específico de comunicação. Grande parte do tráfego utilizado diariamente por computadores não funciona exatamente da mesma maneira.

Quando utilizamos aplicações baseadas em TCP, existe um mecanismo fundamental chamado retransmissão TCP, ou TCP Retransmission.

O TCP foi projetado para perceber quando dados esperados não foram confirmados adequadamente e, quando necessário, transmiti-los novamente.

Isso é justamente o que torna o protocolo confiável.

O problema aparece quando as retransmissões deixam de ser ocasionais e passam a ocorrer continuamente.

Nesse cenário, a conexão pode continuar funcionando, mas apresentar:

• lentidão;
• pausas;
• throughput reduzido;
• downloads irregulares;
• transferências SMB instáveis;
• páginas demorando para carregar;
• sessões remotas com interrupções;
• aplicações esperando respostas;
• desempenho muito abaixo da velocidade nominal da rede.

E tudo isso pode acontecer enquanto um teste simples de Ping continua mostrando:

0% de perda

Neste guia completo da VMIA vamos entender o que são TCP Retransmissions, por que elas acontecem, como o TCP percebe que precisa retransmitir dados e como utilizar ferramentas como Wireshark, PowerShell, ping, pathping e outros recursos do Windows 11 para descobrir onde está o problema.

O objetivo não é simplesmente encontrar a mensagem:

TCP Retransmission

no Wireshark.

O objetivo é responder uma pergunta muito mais importante:

Por que o TCP precisou retransmitir aquele segmento?

---

O primeiro conceito: Ping e TCP não são a mesma coisa

Antes de analisar retransmissões, precisamos eliminar uma confusão muito comum.

O comando:

ping 8.8.8.8

não cria uma conexão TCP.

O Ping normalmente utiliza mensagens do protocolo ICMP.

De maneira simplificada:

Computador
↓
ICMP Echo Request
↓
Destino
↓
ICMP Echo Reply
↓
Computador

O Windows mede o tempo entre o envio e a resposta.

Podemos observar algo semelhante a:

Resposta de 8.8.8.8: bytes=32 tempo=11ms TTL=117

Esse teste é extremamente útil para avaliar conectividade e comportamento do caminho.

Mas uma aplicação acessando um serviço TCP trabalha de outra maneira.

---

Como uma conexão TCP funciona?

Imagine um computador acessando um servidor.

Antes da troca normal de dados, uma conexão TCP tradicional começa com o conhecido three-way handshake:

Cliente → SYN
Servidor → SYN, ACK
Cliente → ACK

Depois disso, os dados podem começar a trafegar.

De maneira simplificada:

Cliente
↓
segmentos TCP
↓
Servidor

O TCP precisa manter controle sobre aquilo que foi enviado e recebido.

É justamente essa característica que permitirá perceber quando alguma informação precisa ser transmitida novamente.

---

TCP é um protocolo confiável

Quando dizemos que TCP oferece entrega confiável, isso não significa que:

a rede nunca perde dados

Significa que o protocolo possui mecanismos para lidar com situações como:

segmento perdido
segmento atrasado
dados fora de ordem
duplicação
congestionamento

A rede abaixo dele pode apresentar problemas.

O TCP tenta reagir a esses problemas.

Essa diferença é fundamental.

---

Imagine uma transferência de arquivo

Suponha que um computador esteja enviando dados:

Segmento A
Segmento B
Segmento C
Segmento D
Segmento E

O receptor precisa informar ao remetente quais dados recebeu.

Para isso, o TCP utiliza confirmações:

ACK

ACK significa:

Acknowledgment

ou confirmação.

---

Sequence Number

O TCP trabalha com números de sequência.

Eles ajudam a identificar a posição dos dados dentro do fluxo.

Em uma representação extremamente simplificada:

Segmento 1 → dados 1–1000
Segmento 2 → dados 1001–2000
Segmento 3 → dados 2001–3000

O receptor consegue perceber se existe uma lacuna.

Imagine receber:

1–1000
1001–2000
3001–4000

Existe algo faltando.

O intervalo:

2001–3000

não chegou como esperado.

---

O ACK não significa simplesmente “recebi este pacote”

Esse detalhe ajuda muito a entender uma captura TCP.

As confirmações TCP normalmente indicam qual é o próximo número de sequência esperado.

Conceitualmente:

ACK = estou esperando o próximo byte a partir daqui

Isso permite ao remetente acompanhar o progresso do fluxo.

---

O que acontece quando um segmento não chega?

Imagine:

Segmento A → chegou
Segmento B → chegou
Segmento C → perdido
Segmento D → chegou
Segmento E → chegou

O receptor percebe que existe uma lacuna.

Dependendo da situação, o comportamento das confirmações pode indicar repetidamente que ainda está esperando os dados ausentes.

O remetente percebe o padrão e pode retransmitir.

---

O que é TCP Retransmission?

De maneira prática:

TCP Retransmission é a retransmissão de dados TCP que o remetente considera necessário enviar novamente porque não recebeu a confirmação esperada dentro das condições previstas pelo protocolo.

Podemos representar assim:

PC
↓
Segmento TCP
↓
X
↓
não houve confirmação esperada
↓
PC envia novamente

No Wireshark podemos encontrar indicações como:

[TCP Retransmission]

Mas essa mensagem precisa ser interpretada dentro do contexto.

---

Uma retransmissão significa que minha Internet está ruim?

Não necessariamente.

Redes reais não são perfeitas.

Uma retransmissão ocasional pode acontecer.

O que interessa é observar:

frequência
+
momento
+
quantidade
+
impacto
+
contexto

Um único evento em uma captura enorme não deve produzir automaticamente o diagnóstico:

“Sua Internet está perdendo pacotes.”

Precisamos analisar padrões.

---

Por que retransmissões reduzem o desempenho?

Imagine que uma aplicação precisa transferir:

100 MB

Se tudo chega corretamente, o TCP pode continuar avançando.

Agora imagine perda frequente:

enviar
↓
perder
↓
esperar
↓
detectar
↓
retransmitir
↓
confirmar
↓
continuar

Esse processo consome tempo.

Além disso, o TCP possui mecanismos de controle de congestionamento.

Quando determinadas perdas são interpretadas como sinal de congestionamento, o protocolo pode reduzir a quantidade de dados enviada antes de receber confirmações.

Resultado:

link nominal rápido
≠
transferência rápida

---

Um link de 1 Gbps pode transferir lentamente?

Sim.

Imagine:

Ethernet
Velocidade do link: 1,0 Gbps

Isso informa a velocidade negociada pela interface.

Não significa que uma transferência TCP obrigatoriamente atingirá:

1 Gbps

Podemos ter:

retransmissões
latência
armazenamento lento
CPU
SMB
antivírus
servidor lento
congestionamento

entre vários outros fatores.

Por isso precisamos separar:

Link Speed

de:

Throughput real

---

E uma conexão de Internet de 600 Mbps?

O mesmo princípio.

O plano pode fornecer:

600 Mbps

mas uma sessão TCP específica apresentar desempenho muito inferior.

Isso não prova imediatamente que a operadora esteja entregando menos velocidade.

Precisamos descobrir qual parte da comunicação está limitando a transferência.

---

Como o Ping pode mostrar 0% de perda enquanto TCP retransmite?

Existem vários motivos.

Primeiro:

ICMP
≠
TCP

Além disso, o teste de Ping pode gerar tráfego muito menor que uma transferência real.

Compare:

Ping
↓
pequenos pacotes periódicos

com:

download
↓
fluxo intenso e contínuo

Uma rede pode se comportar normalmente sob carga pequena e apresentar problemas quando submetida a tráfego intenso.

---

Exemplo: Wi-Fi aparentemente perfeito

Imagine um notebook conectado ao Wi-Fi.

Executamos:

ping 192.168.1.1 -n 50

Resultado:

0% de perda

Depois iniciamos uma transferência grande.

Agora a interface precisa sustentar muito mais tráfego.

Podem aparecer problemas relacionados a:

interferência
retransmissões no rádio
congestionamento
sinal
driver
roaming

O Ping realizado anteriormente não reproduziu essa carga.

---

Ping é uma amostra

Esse conceito é importante.

Se você envia 20 pacotes:

20 enviados
20 recebidos

você comprovou que aqueles 20 testes tiveram resposta.

Você não comprovou que:

todos os pacotes
de todos os protocolos
durante todo o dia
em qualquer nível de carga

atravessaram a rede perfeitamente.

---

O tamanho do pacote também importa

Um teste padrão de Ping utiliza um tamanho relativamente pequeno.

Uma aplicação real pode trabalhar com volumes muito maiores de dados.

Dependendo do problema, comportamento relacionado a:

MTU
fragmentação
PMTUD
VPN
encapsulamento

pode aparecer em tráfego real e não ser percebido em um Ping simples.

Esse assunto merece diagnóstico separado e será abordado mais adiante no artigo.

---

O que o Wireshark chama de TCP Retransmission?

O Wireshark analisa a sequência dos pacotes observados durante a captura.

A partir desse histórico, ele pode identificar situações que parecem representar retransmissões.

Por exemplo:

TCP Retransmission

TCP Fast Retransmission

e outros indicadores relacionados à análise TCP.

Mas existe um detalhe muito importante:

O Wireshark está interpretando aquilo que conseguiu observar no ponto onde a captura foi realizada.

Isso significa que precisamos tomar cuidado antes de concluir que cada marcação representa necessariamente perda física na rede.

---

O ponto de captura importa

Imagine:

Aplicação
↓
pilha TCP
↓
driver
↓
placa de rede
↓
rede

O Wireshark pode capturar o tráfego em determinado ponto dessa cadeia.

Recursos de offload da placa de rede podem modificar como determinados pacotes aparecem para ferramentas de captura.

Isso pode gerar interpretações confusas quando não entendemos onde a captura ocorreu.

---

Retransmissão real versus artefato de captura

Esse será um ponto importante do diagnóstico avançado.

Nem tudo que parece estranho em uma captura significa necessariamente:

pacote fisicamente transmitido daquele jeito pela rede

Recursos como:

TCP Segmentation Offload
Large Send Offload
Receive Segment Coalescing
checksum offload

podem alterar a forma como o tráfego aparece em capturas feitas no próprio host.

Por isso, em casos difíceis, comparar capturas em pontos diferentes da rede pode ser extremamente útil.

---

O que é TCP Fast Retransmission?

O TCP não precisa necessariamente esperar um longo timeout para perceber que algo provavelmente está faltando.

Determinados padrões de ACKs podem indicar rapidamente uma lacuna.

O remetente pode então retransmitir antes de esperar o temporizador normal expirar.

O Wireshark pode identificar esse comportamento como:

TCP Fast Retransmission

---

Duplicate ACK

Outro termo muito encontrado no Wireshark é:

TCP Dup ACK

ou ACK duplicado.

Imagine que o receptor continua recebendo dados posteriores, mas ainda está esperando uma parte anterior.

Ele pode continuar confirmando o mesmo ponto esperado.

Isso fornece ao remetente uma pista de que existe uma lacuna.

---

Dup ACK não deve ser analisado isoladamente

Encontrar:

TCP Dup ACK

não é suficiente para concluir:

cabo com defeito

Precisamos observar o fluxo.

Pode existir:

reordenação
perda
atraso
captura incompleta

entre outras possibilidades.

A análise precisa considerar os pacotes anteriores e posteriores.

---

Retransmission Timeout — RTO

Quando uma confirmação esperada não chega dentro do intervalo calculado pelo TCP, pode ocorrer retransmissão baseada em timeout.

O protocolo mantém estimativas relacionadas ao tempo de ida e volta da comunicação e ajusta seus temporizadores.

Isso significa que o RTO não é simplesmente um valor fixo universal para qualquer conexão.

---

RTT entra diretamente na história

RTT significa:

Round-Trip Time

É o tempo relacionado ao percurso:

origem
↓
destino
↓
origem

Quanto maior e mais variável a latência, mais complexo fica determinar quando uma resposta realmente está atrasada e quando provavelmente ocorreu perda.

---

Latência e perda não são a mesma coisa

Podemos ter:

latência alta
0% de perda

ou:

latência baixa
perda de pacotes

ou ainda:

latência variável
retransmissões TCP

Por isso, não reduza diagnóstico de rede a um único número.

---

Jitter também pode influenciar a percepção de qualidade

Jitter representa variação na latência.

Exemplo:

10 ms
11 ms
9 ms
12 ms

é diferente de:

10 ms
90 ms
15 ms
250 ms
12 ms

Mesmo sem perda total de conectividade, essa instabilidade pode afetar aplicações.

---

Congestionamento pode provocar retransmissões

Imagine um link cuja capacidade máxima foi atingida.

Filas começam a crescer.

Se buffers ficam saturados, equipamentos podem descartar pacotes.

Agora temos:

fila cheia
↓
pacote descartado
↓
TCP detecta ausência
↓
retransmissão

Nesse caso, o problema não é necessariamente:

cabo ruim

Pode ser simplesmente congestionamento.

---

Bufferbloat pode coexistir com o problema

Uma rede também pode apresentar filas excessivamente grandes.

Em vez de descartar rapidamente, equipamentos armazenam pacotes por muito tempo.

Resultado:

latência sobe drasticamente sob carga

Esse fenômeno é conhecido como bufferbloat.

Ele não é sinônimo de TCP Retransmission, mas ambos podem aparecer em diagnósticos de desempenho.

---

Wi-Fi possui retransmissões próprias

Existe outro detalhe técnico importante.

O Wi-Fi possui mecanismos de retransmissão na camada de enlace.

Portanto, um frame pode precisar ser retransmitido pelo próprio 802.11 sem que o TCP necessariamente perceba perda.

Isso significa:

retransmissão Wi-Fi
≠
TCP Retransmission

O Wi-Fi pode corrigir alguns problemas antes que eles cheguem ao TCP.

---

Quando o TCP começa a perceber?

Se a camada inferior não consegue entregar adequadamente os dados e a perda se torna visível ao fluxo TCP, então os mecanismos do TCP entram em ação.

Podemos ter:

interferência Wi-Fi
↓
retries 802.11
↓
alguns frames ainda falham
↓
perda percebida pelo TCP
↓
TCP Retransmission

---

Ethernet também pode apresentar problemas físicos

Em uma rede cabeada, investigamos:

cabo
conector
porta do switch
NIC
negociação
erros físicos

Mas um cabo com defeito não deve ser diagnosticado apenas porque o Wireshark mostrou uma retransmissão.

Precisamos de evidências adicionais.

---

O primeiro grande princípio deste diagnóstico

Quando encontrar:

TCP Retransmission

não pergunte apenas:

“Como faço para eliminar isso?”

Pergunte:

“Onde o segmento original deixou de ser entregue ou confirmado corretamente?”

Essa mudança transforma completamente o diagnóstico.

---

A retransmissão pode ser consequência, não causa

Esse conceito merece destaque.

Imagine:

Wi-Fi ruim
↓
pacote perdido
↓
TCP Retransmission

A retransmissão não é o defeito.

Ela é a reação do TCP ao defeito.

Outro exemplo:

congestionamento
↓
pacote descartado
↓
TCP Retransmission

Novamente, a retransmissão é consequência.

Portanto, simplesmente “desabilitar alguma função TCP” raramente representa um diagnóstico adequado.

---

Como começaremos a investigar no Windows 11

Na próxima etapa vamos montar um diagnóstico real.

A sequência será:

1. reproduzir o problema
↓
2. identificar a conexão TCP afetada
↓
3. capturar no Wireshark
↓
4. filtrar o fluxo
↓
5. localizar retransmissões
↓
6. analisar ACKs e sequência
↓
7. descobrir de qual lado ocorre a perda
↓
8. comparar Wi-Fi, Ethernet e Internet

Essa metodologia evita olhar para milhares de pacotes aleatoriamente.

---

Não comece capturando toda a rede sem saber o que procura

Uma captura de poucos minutos pode produzir milhares ou até milhões de pacotes.

Se simplesmente abrir o Wireshark e procurar qualquer linha vermelha ou preta, provavelmente encontrará alguma coisa.

Isso não significa que encontrou a causa do problema.

Primeiro determine:

qual aplicação?
qual servidor?
qual momento?
qual sintoma?

Depois capture.

---

Exemplo prático

Imagine:

download normal:
70 MB/s

De repente:

download:
8 MB/s

Esse é um excelente momento para capturar.

Queremos correlacionar:

queda de throughput

com:

eventos TCP

Se as retransmissões aumentarem exatamente quando o desempenho cai, temos uma evidência relevante.

---

A correlação temporal é essencial

O mesmo princípio vale para qualquer diagnóstico de desempenho.

Não basta descobrir:

houve retransmissões às 14:00

e:

usuário reclamou de lentidão às 17:00

Precisamos tentar relacionar os eventos.

Quanto mais próxima a correlação, mais forte a evidência.

---

O objetivo final

Ao terminar este diagnóstico, queremos conseguir diferenciar cenários como:

TCP retransmite porque há perda no Wi-Fi

de:

TCP retransmite por congestionamento

de:

problema aparece depois do roteador

de:

servidor remoto está retransmitindo

de:

captura local está sendo interpretada incorretamente

e até:

não existe problema relevante de retransmissão

Essa última possibilidade também é importante.

Nem toda captura precisa revelar um defeito.

Agora que entendemos o mecanismo básico das retransmissões TCP, podemos partir para a análise prática.

O objetivo não será simplesmente abrir o Wireshark e procurar linhas marcadas como:

TCP Retransmission

Precisamos responder perguntas mais importantes:

Qual conexão está retransmitindo?
Quem está retransmitindo?
Quando começou?
Acontece junto com a lentidão?
Existe Dup ACK?
Existe Fast Retransmission?
É um evento isolado ou contínuo?
O problema ocorre no Wi-Fi, na LAN ou depois do roteador?

Essa abordagem transforma o Wireshark de uma ferramenta cheia de pacotes difíceis de interpretar em um instrumento de diagnóstico.

1. Instale e abra o Wireshark

O Wireshark permite capturar e analisar o tráfego observado pelas interfaces de rede do computador.

Ao iniciar, normalmente encontramos interfaces como:

Ethernet
Wi-Fi

e eventualmente:

VPN
adaptadores virtuais
Hyper-V
VMware
VirtualBox

Escolher a interface correta é o primeiro passo.

2. Descubra qual interface realmente transporta a conexão

No PowerShell:

Get-NetAdapter

Você pode encontrar algo semelhante a:

Name       Status    LinkSpeed
----       ------    ---------
Ethernet   Up        1 Gbps
Wi-Fi      Up        866 Mbps

Ter duas interfaces em estado Up não significa necessariamente que a aplicação esteja usando aquela que você imagina.

Podemos investigar a rota utilizada pelo Windows antes da captura.

3. Descubra a rota para o servidor

Suponha que o servidor analisado possua o endereço:

203.0.113.50

No PowerShell, podemos consultar a decisão de rota com ferramentas adequadas do Windows e verificar a interface escolhida.

Também podemos observar a tabela:

route print

ou:

Get-NetRoute

O objetivo é descobrir:

aplicação
↓
destino
↓
rota
↓
interface

Isso evita capturar no Wi-Fi enquanto o tráfego real está saindo pela Ethernet.

4. Inicie a captura antes de reproduzir o problema

Uma metodologia eficiente é:

1. preparar Wireshark
2. iniciar captura
3. reproduzir lentidão
4. aguardar alguns segundos
5. parar captura

Isso produz uma janela relativamente pequena em torno do problema.

Evite capturar 40 minutos de tráfego quando o defeito pode ser reproduzido em 30 segundos.

5. Anote exatamente quando o problema ocorreu

Por exemplo:

14:32:10 — download normal
14:32:18 — velocidade caiu
14:32:27 — velocidade voltou

Agora podemos examinar especificamente esse intervalo.

A correlação temporal será extremamente importante.

6. Primeiro filtro: retransmissões TCP

No campo de filtro de exibição do Wireshark, podemos usar:

tcp.analysis.retransmission

Esse filtro mostra pacotes que a análise TCP do Wireshark classificou como retransmissões.

Se existirem eventos, começaremos a vê-los isoladamente.

Mas ainda não conclua nada.

7. Filtre Fast Retransmissions

Também podemos investigar:

tcp.analysis.fast_retransmission

Isso procura situações classificadas pelo Wireshark como Fast Retransmission.

Agora já conseguimos separar determinados mecanismos observados durante a captura.

8. Procure Duplicate ACK

Outro filtro útil:

tcp.analysis.duplicate_ack

Você poderá encontrar sequências semelhantes conceitualmente a:

TCP Dup ACK
TCP Dup ACK
TCP Dup ACK
TCP Fast Retransmission

Esse padrão pode indicar que o receptor continuou recebendo dados posteriores enquanto uma parte anterior estava ausente.

Mas precisamos abrir o fluxo para entender o contexto.

9. Não analise apenas os pacotes filtrados

Esse é um erro comum.

Se você filtrar somente:

tcp.analysis.retransmission

perde boa parte do contexto.

Imagine encontrar:

Packet 845
TCP Retransmission

Precisamos saber o que aconteceu em:

Packet 830
831
832
...
844
845
846

O contexto anterior pode explicar por que a retransmissão ocorreu.

10. Identifique a conexão TCP afetada

Um computador pode manter dezenas ou centenas de conexões simultâneas.

Podemos ter:

navegador
OneDrive
Windows Update
antivírus
Teams
WhatsApp
serviços do Windows

todos utilizando TCP.

Encontrar retransmissões em uma conexão qualquer não prova que elas tenham relação com o aplicativo lento.

11. Observe IP de origem e destino

Suponha que a conexão relevante seja:

192.168.1.50
↓
203.0.113.50

Agora podemos concentrar a análise nesses hosts.

Exemplo de filtro:

ip.addr == 192.168.1.50 && ip.addr == 203.0.113.50

Isso reduz drasticamente o ruído.

12. Portas também identificam a conversa

Uma sessão TCP não é definida apenas pelos IPs.

Ela envolve:

IP origem
porta origem
IP destino
porta destino

Exemplo:

192.168.1.50:52341
→
203.0.113.50:443

O mesmo computador pode possuir várias conexões HTTPS simultâneas para um servidor.

Por isso, precisamos chegar ao fluxo específico.

13. Follow TCP Stream

Uma das funções mais úteis do Wireshark é:

Follow
→
TCP Stream

Ao selecionar um pacote pertencente à conexão correta, podemos acompanhar aquele fluxo.

O Wireshark associa um identificador ao stream.

Podemos então trabalhar com algo semelhante a:

tcp.stream eq 17

Agora vemos somente aquela conversa TCP.

14. Combine stream e retransmissão

Depois de identificar o stream, podemos usar conceitualmente:

tcp.stream eq 17 && tcp.analysis.retransmission

Assim perguntamos:

Existem retransmissões especificamente nesta conexão?

Isso é muito mais útil do que contar todas as retransmissões existentes no computador.

15. Descubra quem retransmitiu

Observe:

Source
Destination

Se encontramos:

192.168.1.50 → servidor
[TCP Retransmission]

o computador local está retransmitindo dados que havia enviado.

Isso sugere que a confirmação esperada daquele tráfego não foi observada conforme esperado.

Agora imagine:

servidor → 192.168.1.50
[TCP Retransmission]

Nesse caso, quem retransmite é o servidor.

Essa distinção muda completamente a investigação.

16. Se o computador local retransmite, a perda aconteceu onde?

Ainda não sabemos.

O segmento original pode ter sido perdido:

PC
↓
Wi-Fi
X

ou:

PC
↓
roteador
↓
Internet
X

ou ainda a transmissão pode ter chegado ao servidor, mas a confirmação correspondente ter se perdido no caminho de volta.

Portanto:

PC retransmitiu

não significa automaticamente:

problema está no PC

17. O ACK pode ter sido perdido

Imagine:

PC → dados → servidor

O servidor recebe corretamente.

Depois:

servidor → ACK → X

O ACK se perde.

Do ponto de vista do computador:

não recebi a confirmação esperada

e ele pode retransmitir.

Nesse cenário, o dado original nem sequer foi perdido.

Foi a confirmação.

18. Por isso uma captura em apenas um ponto possui limites

Uma captura no computador local mostra:

o que o computador observou

Ela não necessariamente mostra exatamente o que ocorreu em todos os equipamentos intermediários.

Para investigações avançadas podemos comparar capturas em:

PC
roteador
servidor
switch

quando temos controle desses pontos.

19. Sequence Number na prática

Selecione um pacote TCP e expanda:

Transmission Control Protocol

Você encontrará campos relacionados a:

Sequence Number
Acknowledgment Number
Flags
Window

O Wireshark normalmente facilita a leitura usando números relativos de sequência.

Isso evita trabalhar constantemente com números enormes.

20. Exemplo simplificado

Imagine:

Seq=1 Len=1000

Depois:

Seq=1001 Len=1000

Depois:

Seq=2001 Len=1000

Se o segundo segmento desaparecer, o receptor pode continuar indicando que ainda espera os dados iniciados em determinado ponto.

Esse padrão ajuda a revelar a lacuna.

21. Duplicate ACK na prática

Imagine:

A → B
Seq 1

recebido.

Depois:

Seq 1001

é perdido.

Mas:

Seq 2001
Seq 3001
Seq 4001

chegam.

O receptor continua informando que existe uma parte anterior faltando.

Podemos então observar ACKs repetidos.

22. Fast Retransmission

Quando o remetente interpreta os ACKs duplicados como evidência suficiente de perda, pode retransmitir o segmento ausente sem aguardar um timeout completo.

Isso reduz o impacto da perda.

No Wireshark, podemos encontrar:

TCP Fast Retransmission

próximo ao padrão de ACKs duplicados.

23. RTO costuma causar uma pausa mais perceptível

Se não existe informação suficiente para uma recuperação rápida, o remetente pode depender de um temporizador.

A retransmissão baseada em timeout pode introduzir uma pausa mais evidente.

Em aplicações interativas, essa espera pode ser percebida como:

travou
↓
esperou
↓
voltou

24. Retransmissões consecutivas merecem atenção

Uma retransmissão isolada possui significado diferente de:

Retransmission
Retransmission
Retransmission
Retransmission

durante exatamente o período em que a aplicação parou de responder.

Quanto mais forte a correlação entre o sintoma e o comportamento TCP, mais relevante a descoberta.

25. Existe um percentual ideal de retransmissões?

Não devemos transformar a análise em uma regra universal como:

menos de X% = perfeito
mais de Y% = defeito

O impacto depende de:

aplicação
RTT
throughput
duração
padrão da perda
direção
congestionamento

Uma pequena quantidade de perda em determinados cenários pode ter impacto significativo.

Em outros, algumas retransmissões ocasionais passam despercebidas.

26. Analise a direção

Suponha que um download esteja lento.

Grande parte dos dados segue:

servidor
↓
computador

Se encontramos muitas retransmissões justamente nessa direção, temos uma pista.

Agora imagine um upload lento.

A direção principal muda:

computador
↓
servidor

Isso ajuda a estruturar o diagnóstico.

27. Download lento e retransmissões do servidor

Imagine:

Servidor
↓
dados
↓
PC

O servidor começa a retransmitir frequentemente.

Isso pode indicar que ele não está recebendo confirmações adequadas do cliente.

A causa pode estar em qualquer trecho do caminho.

Mas agora sabemos qual fluxo está sofrendo.

28. Compare com um Ping simultâneo

Durante a reprodução do problema, abra outro Terminal:

ping 192.168.1.1 -t

Esse teste acompanha o gateway local.

Em outro Terminal:

ping 8.8.8.8 -t

Agora temos dois pontos de referência:

PC → roteador

e:

PC → Internet

29. Cenário A: Ping do roteador também falha

Imagine durante a lentidão:

192.168.1.1
Request timed out

e simultaneamente aparecem retransmissões TCP.

Agora temos uma forte razão para investigar primeiro:

Wi-Fi
Ethernet
adaptador
cabo
roteador local

porque o problema já aparece antes de sair da LAN.

30. Cenário B: roteador perfeito, Internet falha

Imagine:

ping roteador:
1 ms
1 ms
1 ms

mas:

ping Internet:
15 ms
timeout
300 ms
timeout

Agora a LAN parece mais estável e devemos avançar para:

WAN
operadora
congestionamento
rota externa

Ainda não é prova absoluta, mas reduz o espaço de busca.

31. Cenário C: ambos os Pings parecem perfeitos

Também pode acontecer:

gateway = estável
Internet = estável
TCP = retransmissões

Esse é justamente um dos casos que justificam este artigo.

Agora investigamos:

servidor específico
caminho específico
carga
MTU
VPN
aplicação
TCP
captura

32. Ping não precisa falhar junto

Não espere que todo problema TCP apareça no ICMP.

O Ping é uma ferramenta complementar.

O objetivo é comparar evidências.

33. Teste o gateway com carga

Se o problema aparece somente durante downloads, faça o Ping enquanto a transferência está acontecendo.

Não compare:

Ping às 10:00

com:

download lento às 15:00

Faça:

download intenso
+
Ping simultâneo
+
captura Wireshark

Isso cria uma correlação muito mais útil.

34. Latência explode durante o download

Imagine:

sem download:
2 ms

Depois:

download iniciado:
80 ms
150 ms
300 ms

Esse comportamento aponta para saturação e filas.

Pode existir bufferbloat.

Se também aparecem perdas e retransmissões, investigue congestionamento e capacidade dos equipamentos.

35. pathping pode complementar o diagnóstico

O Windows possui:

pathping

Ele combina aspectos de descoberta do caminho e medições ao longo de um período.

Por exemplo:

pathping 8.8.8.8

A ferramenta pode ajudar em algumas investigações de perda ao longo do caminho.

Mas existe uma armadilha importante.

36. Um roteador intermediário não responder não prova perda de trânsito

Equipamentos podem:

limitar ICMP
priorizar pouco ICMP
não responder determinadas mensagens

enquanto continuam encaminhando tráfego normalmente.

Portanto, se um salto intermediário mostra perda, mas os saltos posteriores não apresentam a mesma perda, não conclua automaticamente que aquele roteador está descartando o tráfego real.

37. A perda precisa continuar depois do salto

Conceitualmente:

Hop 3 = 50% de perda
Hop 4 = 0%
Hop 5 = 0%
Destino = 0%

Isso sugere que o Hop 3 pode simplesmente limitar suas próprias respostas.

Agora:

Hop 3 = perda
Hop 4 = perda
Hop 5 = perda
Destino = perda

merece investigação muito maior.

38. tracert também ajuda a entender o caminho

Execute:

tracert destino

O objetivo não é encontrar “o roteador culpado” automaticamente.

É compreender quantos trechos existem entre:

PC
↓
destino

e observar mudanças relevantes no caminho.

39. Test-NetConnection

No PowerShell:

Test-NetConnection exemplo.com -Port 443

Esse teste pode verificar conectividade TCP até uma porta específica.

Isso é diferente de apenas testar ICMP.

40. Por que testar a porta real?

Imagine:

Ping funciona

mas:

TCP 443 falha

Agora sabemos que:

conectividade ICMP

não equivale à disponibilidade do serviço TCP.

Isso pode apontar para:

firewall
servidor
rota
serviço
política de rede

41. Wi-Fi versus Ethernet é um dos melhores testes

Se o notebook apresenta retransmissões no Wi-Fi, conecte-o temporariamente por Ethernet.

Repita exatamente:

mesmo servidor
mesmo download
mesmo horário aproximado
mesmo computador

e compare.

Se:

Wi-Fi
→ muitas retransmissões
→ throughput instável

e:

Ethernet
→ poucas retransmissões
→ throughput estável

temos uma evidência muito forte apontando para o caminho sem fio.

42. Não conclua imediatamente que o roteador Wi-Fi está com defeito

Ainda pode ser:

sinal
interferência
canal
driver
adaptador
distância
roaming
economia de energia

O teste Ethernet apenas delimitou o problema.

43. Compare dois computadores

Outro teste excelente:

PC A
↓
mesma rede
↓
mesmo servidor

e:

PC B
↓
mesma rede
↓
mesmo servidor

Se apenas o PC A apresenta o problema, investigue:

adaptador
driver
Windows
VPN
software de segurança
hardware

Se ambos apresentam simultaneamente, a infraestrutura compartilhada ganha relevância.

44. Compare dois destinos

Também podemos inverter o raciocínio.

No mesmo computador:

Servidor A → ruim
Servidor B → perfeito

Isso sugere que o problema não afeta necessariamente toda a Internet.

Pode existir:

rota específica
servidor específico
CDN
peering
congestionamento externo

45. VPN muda o comportamento?

Esse teste pode fornecer pistas interessantes.

Imagine:

sem VPN
→ retransmissões

e:

com VPN
→ comportamento diferente

A VPN modifica:

rota
encapsulamento
MTU
ponto de saída

Isso não prova automaticamente que a operadora seja culpada, mas demonstra que alterar o caminho modifica o problema.

46. O contrário também acontece

Podemos ter:

sem VPN
→ normal

e:

com VPN
→ retransmissões

Agora investigamos:

MTU da VPN
servidor VPN
rota
sobrecarga
driver virtual
filtro de rede

47. MTU pode produzir sintomas peculiares

MTU significa:

Maximum Transmission Unit

Em uma Ethernet tradicional, encontramos frequentemente MTU de 1500 bytes.

Mas túneis e encapsulamentos podem reduzir o espaço disponível.

Quando existe um problema relacionado a MTU ou Path MTU Discovery, determinadas conexões podem se comportar de maneira estranha.

48. Ping pequeno funcionar não elimina MTU

Um Ping padrão pode atravessar perfeitamente:

pacote pequeno
→ funciona

enquanto tráfego maior encontra dificuldades.

Isso ajuda a explicar alguns casos em que:

Ping = perfeito

mas:

aplicação TCP = problemática

49. Não altere MTU sem evidência

Um erro comum é encontrar um tutorial e executar imediatamente comandos para reduzir MTU.

Isso pode mascarar sintomas ou criar novos problemas.

Primeiro prove que o tamanho do pacote está relacionado ao defeito.

50. Retransmissões durante SMB

Imagine uma transferência:

PC A
↓
SMB
↓
PC B

pela LAN.

Se existem retransmissões, não temos:

operadora
Internet
CDN

no caminho.

Agora a investigação fica muito menor:

PC A
NIC A
cabo/Wi-Fi
switch/roteador
cabo/Wi-Fi
NIC B
PC B

Esse tipo de teste é excelente para separar LAN de Internet.

51. Faça uma transferência grande dentro da rede

Se você possui dois computadores, transfira um arquivo grande entre eles.

Compare:

LAN

com:

Internet

Se a LAN já apresenta instabilidade, não comece culpando a operadora.

52. Throughput SMB também depende do armazenamento

Lembre-se:

transferência lenta

não significa automaticamente:

rede lenta

O disco de origem ou destino pode limitar o desempenho.

Por isso, precisamos correlacionar a lentidão com retransmissões reais antes de culpar a rede.

53. CPU também pode limitar transferências

Em equipamentos mais antigos ou em cenários específicos, processamento pode se tornar gargalo.

Isso pode envolver:

criptografia
VPN
antivírus
SMB
compressão

Uma transferência lenta sem retransmissões pode apontar para outra camada.

54. Antivírus e filtros de rede

Softwares de segurança podem instalar componentes que interagem com tráfego.

VPNs também adicionam adaptadores e filtros.

Se o problema começou depois da instalação de determinado software, preserve a cronologia.

Não desinstale tudo aleatoriamente.

55. Capture antes e depois de uma alteração

Por exemplo:

driver versão A
→ captura A

Depois:

driver versão B
→ captura B

Agora podemos comparar:

retransmissões
throughput
latência

Isso é muito mais confiável que simplesmente dizer:

“Parece que melhorou.”

56. Cuidado com Checksum Offload

Durante uma captura feita no próprio computador, o Wireshark pode mostrar avisos relacionados a checksum que parecem erros.

Isso pode ocorrer porque determinados cálculos são realizados posteriormente pela placa de rede.

Portanto:

checksum incorreto na captura local

não significa automaticamente:

pacote corrompido na rede

Esse é um exemplo clássico de como recursos de offload podem confundir uma análise.

57. Large Send Offload

Com LSO, o sistema pode entregar um bloco maior de dados para a NIC, que posteriormente realiza segmentação apropriada para transmissão.

A captura feita antes dessa etapa pode parecer diferente do tráfego efetivamente colocado no cabo.

Por isso, análises avançadas precisam considerar offload.

58. Receive Segment Coalescing

No caminho de recepção, mecanismos de coalescência também podem combinar processamento de segmentos para melhorar eficiência.

Novamente:

captura no host

nem sempre equivale perfeitamente a:

captura física no fio

59. Quando suspeitar de artefato de captura?

Se o Wireshark apresenta algo aparentemente absurdo, mas:

aplicação funciona perfeitamente
throughput está normal
outro ponto de captura não confirma

considere a possibilidade de interpretação influenciada pelo ponto de captura ou offload.

60. Captura em outro computador pode ajudar

Em uma LAN controlada, uma captura feita em outro ponto pode revelar uma visão diferente.

Em redes profissionais, podemos utilizar:

port mirroring

em um switch gerenciável.

Assim observamos o tráfego mais próximo do que realmente atravessa o enlace.

61. Não desabilite todos os offloads como primeira solução

Encontrar:

LSO
RSC
Checksum Offload

em um artigo não significa que todos devem ser desativados.

Esses recursos existem para melhorar eficiência.

Desabilitá-los indiscriminadamente pode reduzir desempenho.

Use alterações como testes controlados quando houver evidências.

62. A pergunta mais importante depois da captura

Depois de identificar retransmissões reais e relevantes, pergunte:

Elas começam antes, durante ou depois do sintoma?

Se:

retransmissões aumentam
↓
throughput despenca

temos uma forte correlação.

Se:

aplicação fica lenta
↓
nenhuma retransmissão relevante

provavelmente precisamos investigar outro gargalo.

63. Matriz inicial de diagnóstico

Podemos resumir:

Gateway ruim + TCP ruim
→ investigar LAN primeiro

Gateway bom + Internet ruim + TCP ruim
→ investigar WAN/caminho externo

Gateway bom + Internet aparentemente boa + servidor específico ruim
→ investigar fluxo/rota/servidor

Wi-Fi ruim + Ethernet boa
→ investigar rede sem fio

Dois PCs ruins ao mesmo tempo
→ infraestrutura compartilhada ganha força

Somente um PC ruim
→ investigar host/adaptador/driver/software

LAN SMB ruim
→ problema pode existir antes da operadora

LAN perfeita + Internet ruim
→ ampliar diagnóstico para fora da LAN

64. Não use uma única ferramenta como veredito

O diagnóstico forte combina:

Wireshark
+
Ping
+
pathping
+
tracert
+
Test-NetConnection
+
teste LAN
+
comparação Wi-Fi/Ethernet
+
correlação temporal

Cada ferramenta responde uma pergunta diferente.

65. O objetivo desta Parte

Neste ponto já conseguimos sair de:

“Wireshark mostrou TCP Retransmission”

para uma investigação muito mais precisa:

qual stream?
↓
qual direção?
↓
qual momento?
↓
qual quantidade?
↓
qual impacto?
↓
qual segmento da rede?

Como descobrir a causa das TCP Retransmissions: Wi-Fi, cabo, roteador, operadora, MTU, VPN e drivers

Depois de identificar retransmissões relevantes no Wireshark, chega a parte mais difícil:

Descobrir por que elas estão acontecendo.

A mensagem:

TCP Retransmission

é um sintoma observado na conexão.

Ela não informa automaticamente:

“o cabo está ruim”

nem:

“a operadora está perdendo pacotes”

nem:

“o servidor remoto está com problema”

Precisamos correlacionar o comportamento TCP com a infraestrutura.

---

1. Comece pela camada mais próxima

A ordem mais eficiente costuma ser:

computador
↓
placa de rede
↓
Wi-Fi ou Ethernet
↓
roteador/switch
↓
WAN
↓
operadora
↓
Internet
↓
servidor remoto

Quanto mais cedo encontramos o problema, menor fica o espaço de investigação.

---

2. Wi-Fi é um dos primeiros suspeitos quando o problema é intermitente

Uma conexão Wi-Fi pode mostrar:

Ping aparentemente normal
↓
download inicia rápido
↓
velocidade oscila
↓
TCP retransmite

Isso pode acontecer por:

• sinal fraco;
• interferência;
• congestionamento do canal;
• distância;
• obstáculos;
• roaming;
• driver;
• economia de energia;
• saturação do rádio;
• retransmissões 802.11.

---

3. RSSI baixo pode aumentar erros e retries

Quanto pior a qualidade do sinal, maior pode ser a necessidade de retransmitir frames na camada sem fio.

O ponto importante é:

problema Wi-Fi
↓
retries de enlace
↓
algumas perdas deixam de ser recuperadas
↓
TCP percebe a falta
↓
TCP Retransmission

Por isso, a retransmissão TCP pode ser a consequência final de um problema que começou muito antes, na camada de rádio.

---

4. Compare Wi-Fi e Ethernet no mesmo computador

Esse é um dos testes mais fortes.

Faça:

Teste A
Wi-Fi

Depois:

Teste B
Ethernet

Mantendo o máximo possível de variáveis iguais:

• mesmo computador;
• mesmo servidor;
• mesmo horário aproximado;
• mesmo arquivo;
• mesma aplicação.

Se:

Wi-Fi → muitas retransmissões
Ethernet → comportamento normal

a investigação deve se concentrar no caminho sem fio.

---

5. Interferência pode existir mesmo com sinal forte

Um erro comum é pensar:

sinal forte = Wi-Fi perfeito

Não necessariamente.

Você pode estar próximo do roteador e ainda sofrer com:

• redes vizinhas;
• interferência;
• canal congestionado;
• múltiplos clientes transmitindo;
• dispositivos competindo pelo airtime.

A intensidade do sinal é apenas uma parte da qualidade da conexão.

---

6. O problema aparece somente sob carga?

Esse detalhe é extremamente importante.

Imagine:

navegação leve
→ normal

mas:

download grande
→ latência aumenta
→ retransmissões aparecem

Isso pode apontar para saturação do enlace, filas ou capacidade limitada do equipamento.

---

7. Faça um Ping simultâneo ao roteador

Durante o problema:

ping 192.168.1.1 -t

Observe:

tempo
perda
variação

Se o próprio gateway local começa a apresentar:

timeouts
latência elevada
jitter forte

ao mesmo tempo que o TCP retransmite, temos evidência de problema dentro da rede local.

---

8. Se Ethernet funciona e Wi-Fi falha

Agora vale analisar:

canal
largura de canal
banda 2,4 GHz / 5 GHz / 6 GHz
sinal
roaming
driver
posição do roteador
Mesh

Não comece culpando a operadora.

---

9. Mesh pode introduzir outro enlace sem fio

Em uma rede Mesh:

PC
↓
Wi-Fi
↓
nó Mesh
↓
backhaul
↓
nó principal
↓
Internet

podemos ter dois trechos sem fio.

Mesmo que o PC possua boa conexão com o nó próximo, o backhaul entre os nós pode estar congestionado ou com sinal ruim.

---

10. Ethernet elimina completamente problemas de rede?

Não.

A Ethernet também pode apresentar problemas.

Um cenário clássico:

Link Speed = 1 Gbps

mas a transmissão mostra:

retransmissões
instabilidade

Agora investigamos:

• cabo;
• conector;
• porta;
• NIC;
• switch;
• negociação;
• driver.

---

11. Cabo defeituoso pode causar comportamento intermitente

Um cabo não precisa simplesmente “parar de funcionar”.

Ele pode permitir link, mas apresentar erros.

Por isso, o teste mais simples é substituir temporariamente o cabo por um cabo conhecido como bom.

Se o problema desaparece:

cabo antigo

se torna um forte suspeito.

---

12. Verifique a velocidade negociada

No PowerShell:

Get-NetAdapter

Observe:

LinkSpeed

Se esperávamos:

1 Gbps

mas encontramos:

100 Mbps

já existe algo a investigar.

Possíveis causas:

cabo
conector
porta
negociação
hardware

---

13. 100 Mbps não significa necessariamente retransmissão

Esse cuidado é importante.

Um link negociado em:

100 Mbps

pode ser perfeitamente estável.

Ele apenas terá menor capacidade.

Portanto:

link a 100 Mbps

e:

TCP retransmitindo

são problemas diferentes.

Podem coexistir, mas um não prova o outro.

---

14. Troque a porta do switch

Se possível:

porta 1 → problema
porta 2 → normal

Isso pode indicar:

porta defeituosa
configuração diferente
conector ruim

Em switches gerenciáveis, também verifique contadores de erros.

---

15. Erros físicos ajudam muito no diagnóstico

Interfaces de rede podem manter contadores de:

erros
descartes
pacotes

A disponibilidade e o detalhamento desses contadores dependem do driver, dispositivo e ferramenta usada.

Se o número de erros cresce exatamente durante a transferência problemática, isso fortalece a hipótese de problema local de enlace.

---

16. O roteador pode ser o gargalo

Roteadores domésticos precisam processar:

NAT
firewall
Wi-Fi
QoS
VPN
DNS
múltiplos clientes

Em determinadas condições, o equipamento pode chegar ao limite.

O sintoma pode ser:

download intenso
↓
CPU/filas do roteador saturam
↓
latência aumenta
↓
pacotes são descartados
↓
TCP retransmite

---

17. Reiniciar o roteador “resolver” não prova a causa

Depois de reiniciar:

problema desaparece

Isso pode indicar alguma condição interna do equipamento.

Mas ainda precisamos descobrir se o problema volta com:

tempo
carga
muitos dispositivos
VPN
QoS

Reinicialização é um teste, não necessariamente uma solução definitiva.

---

18. Bufferbloat

Quando um link é saturado, equipamentos podem acumular pacotes em filas grandes.

Resultado:

download ocupa link
↓
fila cresce
↓
ping aumenta muito

Esse comportamento é chamado de bufferbloat.

Ele pode produzir uma Internet que parece rápida em teste de velocidade, mas fica lenta para uso interativo durante transferências.

---

19. Bufferbloat sempre gera retransmissões?

Não.

Ele pode gerar principalmente:

latência elevada

Mas se filas chegam ao limite e pacotes começam a ser descartados, retransmissões TCP também podem aparecer.

Por isso, os fenômenos podem coexistir.

---

20. QoS pode ajudar, mas não deve ser configurado no escuro

Quando o gargalo está na saturação de um link, políticas adequadas de QoS ou gerenciamento de filas podem melhorar a experiência.

Mas configurar QoS sem saber:

qual link satura
qual tráfego domina
qual banda real existe

pode piorar a situação.

---

21. Como saber se o problema está depois do roteador?

Faça três comparações:

PC → roteador

PC → outro equipamento da LAN

PC → Internet

Se os dois primeiros são estáveis, mas o terceiro apresenta problema, a suspeita se desloca para fora da LAN.

---

22. Teste uma transferência dentro da rede

Copie um arquivo grande entre dois PCs.

Se:

LAN = estável
Internet = instável

isso ajuda a retirar:

Wi-Fi local
cabo local
switch local

da lista de principais suspeitos, dependendo da topologia utilizada no teste.

---

23. A operadora pode perder pacotes?

Sim.

Podemos ter problemas em:

enlace de acesso
equipamento da operadora
congestionamento
rota
peering

Mas devemos evitar concluir:

“é a operadora”

apenas porque um servidor específico está lento.

---

24. Compare vários destinos

Faça testes com:

Servidor A
Servidor B
Servidor C

Se apenas um destino apresenta retransmissões, pode existir um problema:

na rota específica
no servidor
na CDN
no peering

Se múltiplos destinos apresentam o mesmo comportamento simultaneamente, uma causa mais próxima da sua conexão ganha força.

---

25. O horário importa

Imagine:

08:00 → normal
14:00 → normal
21:00 → retransmissões e lentidão

todos os dias.

Isso pode sugerir congestionamento associado ao horário de maior uso.

A repetição temporal é uma evidência importante.

---

26. Teste em horários diferentes

Registre:

data
horário
latência
perda
throughput
retransmissões

Uma única medição não representa necessariamente o comportamento da conexão ao longo do dia.

---

27. pathping pode ajudar, mas interprete corretamente

Execute:

pathping destino

Se um salto intermediário mostra perda, veja se a mesma perda continua nos saltos posteriores.

Se não continuar, aquele equipamento pode estar apenas limitando respostas ICMP destinadas a ele próprio.

---

28. Não culpe um hop somente porque ele mostra 80% de perda

Exemplo:

Hop 4 = 80%
Hop 5 = 0%
Destino = 0%

Isso não faz sentido como 80% de perda real de encaminhamento, porque os pacotes seguintes continuam chegando normalmente.

A interpretação mais provável é limitação das respostas daquele hop.

---

29. Se a perda continua até o destino

Agora:

Hop 4 = 10%
Hop 5 = 10%
Hop 6 = 10%
Destino = 10%

a hipótese de perda naquele trecho ou antes dele merece muito mais atenção.

Mesmo assim, combine com outros testes.

---

30. Servidor remoto também pode retransmitir por problema do lado dele

Imagine que vários usuários em diferentes conexões reclamam do mesmo servidor.

Nesse caso, a origem pode estar próxima do próprio servidor.

Sua captura local mostrará retransmissões vindas dele, mas isso não significa que sua rede doméstica seja culpada.

---

31. Compare outro dispositivo usando outra conexão

Um teste poderoso é acessar o mesmo serviço por:

Internet residencial

e depois:

rede móvel

Se o comportamento muda completamente, a rota ou infraestrutura pode estar influenciando.

---

32. VPN pode modificar o caminho

Quando uma VPN é ativada:

PC
↓
túnel
↓
servidor VPN
↓
destino

A rota externa muda.

Se um problema desaparece pela VPN, isso pode indicar diferença no caminho, peering ou MTU.

Mas não significa automaticamente:

operadora está errada

---

33. VPN também pode criar o problema

O túnel adiciona:

encapsulamento
criptografia
overhead
driver virtual

Isso pode reduzir MTU efetiva e aumentar uso de CPU.

Se:

sem VPN = perfeito
com VPN = ruim

a VPN entra diretamente na investigação.

---

34. MTU e PMTUD

MTU define o tamanho máximo da unidade que pode ser transportada em determinado enlace sem necessidade de fragmentação naquele contexto.

Em Ethernet encontramos frequentemente:

1500 bytes

Mas um túnel pode precisar de espaço adicional para seus próprios cabeçalhos.

Assim, o tamanho útil para o tráfego interno pode ser menor.

---

35. Path MTU Discovery

O TCP/IP tenta descobrir um tamanho adequado ao caminho.

Esse mecanismo é conhecido como:

PMTUD

ou Path MTU Discovery.

Se mensagens necessárias para esse processo forem bloqueadas em algum ponto, podem surgir problemas com pacotes maiores.

---

36. O clássico “site abre pela metade”

Problemas de MTU podem produzir sintomas estranhos:

Ping pequeno funciona
alguns sites funcionam
outros travam
VPN apresenta comportamento estranho

Não é o único motivo possível, mas entra na investigação quando existe esse padrão.

---

37. Ping com DF pode ajudar em testes IPv4 específicos

No Windows, podemos usar opções do Ping para testar tamanhos diferentes e impedir fragmentação em determinados testes IPv4.

Por exemplo:

ping destino -f -l 1472

Esse tipo de teste pode ajudar a investigar limites do caminho.

Mas o valor correto depende do encapsulamento e do cenário.

Não trate 1472 como valor universal.

---

38. Por que 1472 aparece frequentemente?

Em um cenário IPv4 tradicional, podemos pensar:

1500 MTU Ethernet
-
20 bytes IPv4
-
8 bytes ICMP
=
1472 bytes de payload

Mas isso muda com outros cabeçalhos e tecnologias.

Por isso, o cálculo precisa respeitar a topologia real.

---

39. Não reduza a MTU para 1200 “porque resolveu”

Esse tipo de alteração pode esconder a causa real.

O diagnóstico ideal determina:

qual trecho limita
por quê
qual MTU é necessária

antes de modificar permanentemente a configuração.

---

40. Driver da placa de rede

Problemas de driver podem causar:

quedas
reset da interface
latência
desempenho estranho

e eventualmente contribuir para perdas visíveis pelo TCP.

Verifique:

versão
data
fabricante
cronologia

---

41. Se o problema começou depois da atualização

Compare:

driver antigo

com:

driver novo

Se possível, faça um teste controlado.

Não instale dez versões seguidas sem registrar resultado.

---

42. Gerenciamento de energia da NIC

Algumas configurações permitem ao Windows reduzir consumo da interface.

Em certos drivers ou equipamentos, comportamentos relacionados a economia de energia podem gerar instabilidade.

Se o problema aparece após:

suspensão
retorno
longos períodos ociosos

vale considerar essa camada.

---

43. Mas não desabilite toda economia de energia preventivamente

Isso pode aumentar consumo sem necessidade.

Primeiro confirme que existe uma relação reproduzível entre a configuração e o problema.

---

44. Large Send Offload

O LSO permite que a pilha entregue blocos maiores para a NIC e deixe parte da segmentação para o hardware.

Isso reduz carga de CPU.

Em alguns diagnósticos, o recurso entra na lista de testes quando existe incompatibilidade específica entre:

driver
NIC
VPN
software de filtragem

Mas não deve ser desabilitado automaticamente.

---

45. Checksum Offload

A NIC também pode calcular checksums.

Por isso, capturas feitas no próprio host podem mostrar:

checksum incorreto

antes que o hardware tenha realizado o cálculo final.

Não confunda isso com corrupção real na rede.

---

46. RSC e coalescência

Recursos de recepção podem combinar dados para reduzir custo de processamento.

Isso melhora eficiência, mas também significa que:

visualização da captura

pode diferir do formato exato no fio.

---

47. Se desabilitar um offload resolve, investigue o motivo

Imagine:

LSO ligado → problema
LSO desligado → normal

Isso é uma pista importante.

Agora devemos investigar:

driver
firmware
VPN
filtro
compatibilidade

e não simplesmente concluir:

LSO é ruim

---

48. Software antivírus e filtros

Soluções de segurança podem inserir filtros no caminho da rede.

Elas podem analisar:

HTTPS
downloads
conexões

dependendo do produto e das configurações.

Se o problema começou imediatamente após uma instalação ou atualização desse tipo, preserve essa informação.

---

49. Desabilitar o antivírus permanentemente não é solução

O objetivo é identificar se existe relação.

Faça testes seguros e controlados conforme a documentação do produto.

Depois corrija:

configuração
versão
compatibilidade

em vez de remover proteção como solução padrão.

---

50. Firewall pode causar retransmissão?

Um firewall pode descartar tráfego.

Se determinado pacote esperado é filtrado silenciosamente, o TCP pode acabar retransmitindo.

Mas, novamente:

TCP Retransmission

sozinho não prova:

firewall

Precisamos de contexto e regras.

---

51. Teste dois protocolos ou serviços diferentes

Se:

HTTPS = ruim
SMB LAN = perfeito

temos um cenário.

Se:

HTTPS = ruim
SMB LAN = ruim
qualquer TCP = ruim

o problema parece mais geral.

---

52. Problema em somente um navegador

Se apenas um navegador apresenta lentidão, mas outros aplicativos TCP funcionam normalmente, investigue:

extensões
proxy
configuração do navegador
software de segurança

antes de concluir que existe perda de rede generalizada.

---

53. Proxy pode modificar a rota da aplicação

Uma aplicação pode enviar:

PC
↓
proxy
↓
servidor

enquanto outra acessa diretamente.

Isso explica alguns casos em que somente certos programas apresentam comportamento estranho.

---

54. Servidor sobrecarregado não precisa causar retransmissões

Um servidor pode responder lentamente simplesmente porque está:

CPU alta
armazenamento lento
aplicação sobrecarregada

Nesse caso, o TCP pode estar funcionando perfeitamente.

Por isso:

aplicação lenta

não significa automaticamente:

retransmissão

---

55. Retransmissões ajudam justamente a separar esses casos

Se o aplicativo está lento e a captura mostra:

TCP saudável
sem perda relevante

devemos olhar além da rede.

Se a lentidão coincide com:

retransmissões
timeouts
queda de janela

a rede ganha relevância.

---

56. Janela TCP

O TCP também controla a quantidade de dados que pode permanecer em trânsito.

O receptor anuncia uma janela.

Se a janela fica muito pequena, o throughput pode cair mesmo sem perda.

Isso é diferente de TCP Retransmission.

---

57. Zero Window

O Wireshark pode identificar situações como:

TCP ZeroWindow

Isso normalmente indica que o receptor informou não possuir espaço naquele momento para receber mais dados.

Agora o problema pode estar relacionado a:

aplicação
buffer
processamento
host receptor

e não à perda da rede.

---

58. Window Full também possui significado diferente

Mensagens de análise relacionadas à janela não devem ser agrupadas automaticamente com retransmissões.

Elas indicam outro tipo de comportamento do fluxo.

Por isso, analisar somente “linhas coloridas” é insuficiente.

---

59. Out-of-Order

O Wireshark pode identificar:

TCP Out-Of-Order

Quando segmentos chegam fora da ordem esperada.

Isso pode ocorrer por:

reordenação do caminho
captura
múltiplos caminhos
atrasos diferentes

e não significa automaticamente perda.

---

60. Spurious Retransmission

Em algumas situações, o Wireshark pode indicar algo como:

TCP Spurious Retransmission

A ideia é que uma retransmissão pode ter ocorrido mesmo que os dados anteriores já tivessem sido recebidos.

Isso mostra novamente como o comportamento TCP é mais complexo que:

retransmission = pacote perdido

---

61. Compare as análises do mesmo stream

Em vez de procurar somente:

tcp.analysis.retransmission

observe o conjunto:

Dup ACK
Fast Retransmission
Out-of-Order
Zero Window
Window Full

O padrão completo conta a história da conexão.

---

62. Um método prático para Wi-Fi

Se suspeitamos de Wi-Fi:

1. capturar problema
2. medir gateway
3. repetir por Ethernet
4. comparar retransmissões
5. observar sinal e canal
6. atualizar/testar driver quando justificado

Se Ethernet elimina completamente o sintoma, o diagnóstico fica muito mais focado.

---

63. Um método prático para cabo

Se suspeitamos de Ethernet:

1. trocar cabo
2. trocar porta
3. verificar LinkSpeed
4. repetir transferência LAN
5. comparar outro PC
6. observar erros da interface

Isso costuma identificar problemas físicos rapidamente.

---

64. Um método prático para o roteador

Se vários dispositivos apresentam o mesmo problema:

1. testar gateway sob carga
2. comparar cabeado e Wi-Fi
3. observar horários
4. verificar QoS
5. atualizar firmware quando apropriado
6. testar outro equipamento quando possível

---

65. Um método prático para a operadora

Se a LAN está comprovadamente estável:

1. testar múltiplos destinos
2. testar horários diferentes
3. comparar rota
4. usar pathping com interpretação correta
5. testar outro dispositivo
6. comparar com outra conexão quando possível

Isso gera evidências muito melhores para abrir um chamado técnico.

---

66. Capturas também podem ajudar ao falar com suporte

Em vez de dizer apenas:

“Minha Internet está ruim.”

podemos registrar:

horário
destino
perda
latência
captura
comparação Ethernet/Wi-Fi

Isso ajuda a demonstrar um padrão reproduzível.

---

67. Não exponha capturas completas publicamente sem revisar

Arquivos .pcap e .pcapng podem conter:

IPs
nomes
conexões
metadados

e outros dados da rede.

Antes de enviar capturas para terceiros, avalie o conteúdo e compartilhe apenas o necessário.

---

68. Diagnóstico por exclusão

O objetivo final é reduzir as possibilidades.

Exemplo:

Ethernet LAN = perfeita
Wi-Fi LAN = ruim
Internet por Ethernet = perfeita

Conclusão provável:

problema concentrado no Wi-Fi

Outro exemplo:

LAN = perfeita
todos os dispositivos = problema Internet às 21h
vários destinos = afetados

Agora:

WAN/operadora/congestionamento

ganham muito mais peso.

---

69. Nunca pule direto para “formatar o Windows”

Retransmissões TCP são um problema de comunicação.

Formatar o computador sem identificar a camada pode não mudar absolutamente nada.

Primeiro investigue:

rede
adaptador
driver
infraestrutura
caminho

---

70. Também não troque o roteador por tentativa

Trocar equipamento pode resolver se ele realmente for a causa.

Mas diagnóstico técnico deve buscar evidência.

Se:

outro roteador
→ problema desaparece de forma reproduzível

a comparação é valiosa.

Trocar sem teste apenas aumenta custo e incerteza.

---

71. O verdadeiro objetivo não é zerar retransmissões

Redes reais podem apresentar eventos ocasionais.

O objetivo é ter:

desempenho estável
latência adequada
baixa perda
aplicação funcionando corretamente

e entender quando as retransmissões passam a ser relevantes.

---

72. Matriz de causas

Podemos resumir:

Wi-Fi ruim
→ retries de rádio
→ perda residual
→ TCP retransmite

cabo/porta ruim
→ erros de enlace
→ perda
→ TCP retransmite

roteador saturado
→ filas/descartes
→ TCP retransmite

congestionamento WAN
→ descarte
→ TCP retransmite

MTU/PMTUD problemático
→ determinados pacotes não atravessam corretamente
→ conexão degrada

VPN
→ rota/MTU/overhead mudam
→ comportamento TCP muda

driver/offload
→ incompatibilidade ou artefato de captura
→ análise precisa de contexto

---

73. A Parte 3 nos leva a uma conclusão importante

TCP Retransmission não é um diagnóstico pronto.

É uma evidência.

O diagnóstico real aparece quando combinamos:

retransmissão
+
direção
+
tempo
+
topologia
+
comparação
+
sintoma

Só então conseguimos dizer com confiança onde devemos investigar.

Procedimento completo de diagnóstico, filtros do Wireshark, checklist, FAQ, conclusão e CTA VMIA

Agora vamos fechar o diagnóstico de TCP Retransmissions no Windows 11 com uma metodologia completa.

A proposta desta última parte é transformar todos os conceitos anteriores em um procedimento técnico que possa ser repetido em situações reais.

O objetivo é evitar dois extremos:

“o Ping funciona, então a rede está perfeita”

e:

“o Wireshark mostrou retransmissão, então a Internet está com defeito”

Nenhuma dessas conclusões é tecnicamente suficiente sozinha.

O diagnóstico correto precisa combinar sintomas, fluxo TCP, topologia, testes comparativos e contexto.

1. Primeiro defina exatamente qual é o sintoma

Não comece pelo Wireshark.

Comece pela pergunta:

O que exatamente está ruim?

Exemplos:

download cai de 70 MB/s para 8 MB/s

transferência SMB pausa por alguns segundos

sistema web demora para responder

RDP trava de tempos em tempos

site específico demora, mas outros funcionam

Quanto mais preciso o sintoma, melhor será a captura.

2. Descubra se o problema é reproduzível

Pergunte:

acontece sempre?
só em determinado horário?
somente em Wi-Fi?
somente durante download?
apenas em um servidor?
somente com VPN?

Um defeito reproduzível é muito mais fácil de investigar.

3. Identifique a interface utilizada

No PowerShell:

Get-NetAdapter

Observe:

Name
Status
LinkSpeed
InterfaceDescription

Isso ajuda a diferenciar:

Ethernet
Wi-Fi
VPN
adaptadores virtuais

4. Veja a configuração IP

Execute:

ipconfig /all

Confira:

IPv4
IPv6
Gateway
DNS
DHCP
adaptador

O objetivo não é procurar retransmissão nesse comando.

É compreender a topologia do host antes de capturar.

5. Teste o gateway local

Por exemplo:

ping 192.168.1.1 -t

Deixe o teste em execução enquanto reproduz o problema.

Observe:

latência
timeouts
variação

6. Teste simultaneamente um destino externo

Em outro Terminal:

ping 8.8.8.8 -t

Agora temos:

PC → LAN

e:

PC → Internet

sendo observados ao mesmo tempo.

7. Comece a captura no Wireshark

Escolha a interface que realmente transporta o tráfego.

Inicie a captura pouco antes de reproduzir o sintoma.

Depois de alguns segundos de problema, pare.

Evite capturas enormes sem necessidade.

8. Identifique o servidor afetado

No Wireshark, observe os IPs relacionados à aplicação.

Se necessário, combine informações do sistema com:

Get-NetTCPConnection

Esse comando ajuda a listar conexões TCP do Windows.

Podemos observar campos como:

LocalAddress
LocalPort
RemoteAddress
RemotePort
State
OwningProcess

9. Relacione conexão e processo

O campo:

OwningProcess

representa o PID.

Podemos consultar processos com:

Get-Process

Ou, se já conhecemos o PID:

Get-Process -Id 1234

Assim conseguimos relacionar:

processo
↓
conexão TCP
↓
IP remoto
↓
captura Wireshark

10. Use Follow TCP Stream

Dentro do Wireshark:

botão direito em um pacote
→ Follow
→ TCP Stream

Depois identifique o número do stream.

Por exemplo:

tcp.stream eq 11

Agora podemos trabalhar apenas com aquela conversa.

11. Primeiro filtro essencial

Para retransmissões:

tcp.analysis.retransmission

12. Fast Retransmission

tcp.analysis.fast_retransmission

13. Duplicate ACK

tcp.analysis.duplicate_ack

14. Out-of-Order

tcp.analysis.out_of_order

15. Zero Window

tcp.analysis.zero_window

16. Window Full

tcp.analysis.window_full

17. Lost Segment

O Wireshark também possui análises heurísticas relacionadas a perda de segmento, como:

tcp.analysis.lost_segment

Lembre-se de que essas classificações são interpretações baseadas na captura.

18. Filtre somente o stream afetado

Exemplo:

tcp.stream eq 11 && tcp.analysis.retransmission

Ou:

tcp.stream eq 11 && tcp.analysis.duplicate_ack

Isso reduz muito o ruído.

19. Veja retransmissions e fast retransmissions juntas

Podemos usar uma expressão do tipo:

tcp.analysis.retransmission || tcp.analysis.fast_retransmission

Se quiser limitar ao stream:

tcp.stream eq 11 &&
(tcp.analysis.retransmission || tcp.analysis.fast_retransmission)

20. Identifique a direção

Veja:

Source
Destination

Pergunte:

Quem está retransmitindo?

Se o computador local transmite novamente:

cliente → servidor

Se o servidor retransmite:

servidor → cliente

Isso ajuda a interpretar o fluxo.

21. Compare com o momento da lentidão

Agora volte ao horário anotado.

Por exemplo:

14:17:08 — velocidade normal
14:17:14 — queda brusca
14:17:15 — múltiplos Dup ACK
14:17:15 — Fast Retransmission
14:17:17 — throughput recupera

Essa correlação possui grande valor.

22. Observe o gráfico de throughput

O Wireshark possui ferramentas gráficas que ajudam a visualizar tráfego ao longo do tempo.

Uma queda de throughput sincronizada com retransmissões pode tornar o problema muito mais evidente.

O gráfico não substitui a análise do pacote, mas ajuda a visualizar padrões.

23. Um único pacote não define o diagnóstico

Imagine uma captura de 20 minutos com:

1 retransmissão

e nenhum sintoma percebido.

Isso é muito diferente de:

dezenas de retransmissões
em poucos segundos
durante cada travamento

Sempre considere densidade e contexto.

24. Registre os resultados

Uma planilha ou bloco de notas simples pode conter:

Data:
Horário:
Interface:
Destino:
Aplicação:
Sintoma:
Ping gateway:
Ping Internet:
Retransmissions:
Fast Retransmissions:
Dup ACK:
Wi-Fi ou Ethernet:
VPN:

Isso torna comparações futuras muito mais úteis.

25. Teste Ethernet versus Wi-Fi

Essa comparação merece aparecer novamente no procedimento final porque é extremamente valiosa.

Resultado A:

Wi-Fi:
retransmissões frequentes
throughput irregular

Resultado B:

Ethernet:
praticamente estável
throughput constante

Agora temos uma direção clara.

26. Teste outro cabo Ethernet

Se o problema ocorre cabeado:

troque o cabo

e repita exatamente o mesmo teste.

Depois:

troque a porta do roteador ou switch

Não mude as duas coisas simultaneamente se puder evitar.

Mudar uma variável de cada vez ajuda a identificar a causa.

27. Compare outro computador

Se dois PCs usam a mesma rede:

PC A → problema
PC B → normal

isso coloca mais peso em:

PC A
driver
NIC
software

Se:

PC A → problema
PC B → problema

ao mesmo tempo, a infraestrutura compartilhada merece mais atenção.

28. Compare uma transferência LAN

Faça uma transferência grande entre dois dispositivos locais.

Se houver retransmissões e lentidão dentro da LAN, você já sabe que não precisa da Internet para reproduzir o problema.

Isso reduz drasticamente a investigação.

29. Compare um destino externo diferente

Exemplo:

Servidor A → ruim
Servidor B → normal

Esse resultado aponta para um caminho específico.

Agora:

Servidor A → ruim
Servidor B → ruim
Servidor C → ruim

a possibilidade de problema mais próximo da sua conexão aumenta.

30. Compare com outra conexão de Internet

Quando possível:

mesmo notebook
mesmo servidor
Internet residencial

e:

mesmo notebook
mesmo servidor
outra conexão

Se o comportamento muda, temos mais uma evidência importante.

31. Teste com VPN apenas quando fizer sentido

A VPN altera o caminho.

Se:

sem VPN = ruim
com VPN = bom

isso pode sugerir diferença em:

rota
peering
MTU
ponto de saída

Não significa automaticamente que a operadora seja culpada.

32. Se a VPN piora

Agora investigue:

MTU
servidor VPN
driver virtual
criptografia
overhead

33. Teste de MTU com cuidado

Em IPv4, um teste possível é:

ping destino -f -l 1472

Se aparecer indicação de necessidade de fragmentação, reduza gradualmente o payload para investigação.

Mas não transforme o teste em uma receita universal.

VPNs, PPPoE e outros encapsulamentos alteram os valores úteis.

34. Nunca diagnostique MTU apenas porque um tamanho falhou

Alguns destinos podem tratar ICMP de forma diferente.

Use o teste como parte de um conjunto de evidências.

35. Test-NetConnection para uma porta

Por exemplo:

Test-NetConnection exemplo.com -Port 443

Podemos observar se o estabelecimento TCP até aquele serviço funciona.

Isso ajuda quando:

Ping funciona

mas:

serviço específico não conecta

36. Get-NetTCPConnection para conexões estabelecidas

Execute:

Get-NetTCPConnection -State Established

Isso permite verificar sessões ativas.

Também podemos filtrar:

Get-NetTCPConnection |
Where-Object State -eq "Established"

37. Descubra quais conexões pertencem a um processo

Exemplo conceitual:

Get-NetTCPConnection |
Where-Object OwningProcess -eq 1234

Isso ajuda em situações nas quais uma aplicação mantém várias conexões simultâneas.

38. netstat ainda pode ajudar

O tradicional:

netstat -ano

mostra:

protocolo
endereço local
endereço remoto
estado
PID

É simples, mas continua útil.

39. netstat -e

Podemos consultar estatísticas Ethernet básicas com:

netstat -e

Ele mostra contadores gerais de bytes e pacotes.

Não substitui estatísticas detalhadas da NIC, mas pode complementar.

40. netstat -s

Execute:

netstat -s

O Windows exibe estatísticas por protocolo.

Podemos observar informações relacionadas a:

IPv4
IPv6
TCP
UDP
ICMP

Esses contadores são acumulados e precisam ser interpretados no contexto.

41. Estatísticas TCP podem crescer naturalmente

Não veja um contador alto e conclua:

“existem milhares de erros agora”

O sistema pode estar ligado há dias.

O ideal é:

registrar valor
reproduzir problema
comparar aumento

42. Reinicializar o PC pode zerar alguns contextos, mas não é método de diagnóstico

Se você reinicia antes de cada teste, perde parte do histórico.

Use reinicialização quando fizer parte do teste, por exemplo:

problema aparece após horas de uso
↓
reinicia
↓
problema desaparece
↓
volta depois de algumas horas

Esse padrão é uma evidência.

43. Verifique eventos do Windows quando a interface cai

Abra:

Visualizador de Eventos

Procure eventos próximos ao horário da falha relacionados a:

driver de rede
interface
DHCP
TCP/IP
WLAN

Se o adaptador reinicia exatamente quando o TCP começa a retransmitir, isso muda o diagnóstico.

44. WLAN AutoConfig para problemas Wi-Fi

O Windows mantém eventos relacionados ao serviço WLAN.

Esses registros podem ajudar quando o Wi-Fi:

desconecta
roaming
reautentica
troca de ponto de acesso

durante o problema.

45. Verifique o BSSID

Em ambientes com Mesh ou vários access points, saber apenas o SSID não basta.

O computador pode estar conectado a diferentes pontos físicos.

Podemos investigar informações da conexão Wi-Fi e identificar o BSSID usado.

Isso ajuda a descobrir situações como:

problema só acontece conectado ao nó 2

46. Mudança de BSSID durante o fluxo

Em Mesh, uma mudança de ponto de acesso pode introduzir uma interrupção pequena.

Se a aplicação sofre exatamente naquele instante, vale correlacionar:

roaming
↓
interrupção
↓
TCP recovery

47. Verifique driver e versão

No Gerenciador de Dispositivos:

Adaptadores de rede
→ placa
→ Propriedades
→ Driver

Registre:

fabricante
versão
data

48. Não confie apenas na data mostrada

Datas de drivers no Windows nem sempre representam claramente quando o pacote foi realmente lançado.

Use versão e fonte do driver como referências mais úteis.

49. Atualização de driver deve ter objetivo

Exemplo:

versão atual apresenta problema reproduzível
↓
fabricante publicou correção
↓
atualizar
↓
repetir captura

Isso é muito diferente de atualizar aleatoriamente.

50. Rollback pode ser mais correto que update

Se:

problema começou depois da versão X

e:

versão anterior era estável

um rollback controlado pode ser mais informativo.

51. Verifique propriedades avançadas da NIC

Dependendo do fabricante, podem existir opções como:

Large Send Offload
Checksum Offload
Receive Side Scaling
Energy Efficient Ethernet
Interrupt Moderation

Não altere todas ao mesmo tempo.

52. O teste correto é uma alteração por vez

Por exemplo:

Estado original
↓
captura
↓
alterar LSO
↓
captura
↓
comparar

Se não mudou nada, restaure a configuração.

53. Desabilitar tudo “para otimizar a Internet” é uma má prática

Offloads existem para reduzir processamento e melhorar desempenho.

Otimizações genéricas copiadas da Internet podem:

aumentar CPU
reduzir throughput
criar novos problemas

54. Analise o throughput real

Não confunda:

LinkSpeed

com:

transferência real

Um link Ethernet de:

1 Gbps

não significa que uma cópia de arquivo necessariamente mostrará:

125 MB/s

na prática.

Existem overheads e outros gargalos.

55. Mbps versus MB/s

Essa confusão é extremamente comum.

8 bits = 1 byte

Assim:

800 Mbps

corresponde teoricamente a:

100 MB/s

antes de considerar overheads e limitações reais.

56. Uma cópia de 80 MB/s em Gigabit não significa obrigatoriamente problema

Pode existir limitação por:

armazenamento
SMB
CPU
antivírus
origem
destino

O foco deste artigo é descobrir se as retransmissões estão relacionadas à queda.

57. RDP é sensível a interrupções

Sessões remotas podem parecer travadas mesmo com pequenas interrupções.

Se o RDP apresenta problemas, correlacione:

travamento
Ping
Wireshark
eventos da NIC

Mas lembre-se de que aplicações modernas podem utilizar combinações de protocolos e mecanismos diferentes conforme versão e configuração.

58. Navegação Web também não é sempre TCP puro

Outro cuidado moderno:

HTTP/3 pode utilizar QUIC sobre UDP.

Portanto, nem todo tráfego de navegador atual necessariamente aparecerá como uma conexão TCP tradicional.

Se o objetivo é investigar uma aplicação web, identifique primeiro qual transporte está sendo utilizado.

59. Isso explica por que talvez você não veja TCP Retransmissions

Imagine:

site lento

mas o navegador está utilizando:

HTTP/3
QUIC
UDP

Nesse caso, procurar apenas:

tcp.analysis.retransmission

não cobre o fluxo principal.

Esse detalhe evita diagnósticos equivocados.

60. QUIC possui seus próprios mecanismos de recuperação

Embora também implemente confiabilidade para os fluxos de aplicação, o mecanismo não aparece como retransmissões TCP porque não estamos usando TCP naquele transporte.

Por isso, sempre identifique o protocolo real.

61. SMB normalmente é excelente para teste controlado de TCP em LAN

Uma cópia de arquivo entre dois computadores Windows pode fornecer um cenário útil para reproduzir carga dentro da rede.

Se a transmissão apresenta:

quedas
pausas
retransmissões

sem envolver a operadora, a investigação fica bem mais simples.

62. Cuidado com SMB Multichannel

Em equipamentos e configurações compatíveis, SMB pode usar múltiplas conexões.

Se estiver analisando desempenho avançado, um único TCP stream pode não representar toda a transferência.

Considere todos os fluxos relacionados.

63. Um stream limpo e outro problemático

Essa situação também pode ocorrer.

Você pode encontrar:

stream A = normal
stream B = retransmissões

na mesma aplicação.

Por isso, conhecer como a aplicação usa múltiplas conexões ajuda bastante.

64. Checklist técnico completo

Ao encontrar TCP Retransmissions relevantes, siga aproximadamente esta ordem:

1. Defina o sintoma.
2. Reproduza o problema.
3. Anote o horário.
4. Identifique a interface.
5. Verifique LinkSpeed.
6. Faça Ping contínuo no gateway.
7. Faça Ping simultâneo externo.
8. Capture com Wireshark.
9. Identifique o servidor.
10. Identifique o TCP Stream.
11. Filtre retransmissions.
12. Analise Dup ACK.
13. Analise Fast Retransmission.
14. Verifique a direção.
15. Correlacione com a lentidão.
16. Compare Wi-Fi e Ethernet.
17. Troque cabo quando aplicável.
18. Troque porta.
19. Teste outro computador.
20. Faça transferência LAN.
21. Teste outro destino externo.
22. Teste outro horário.
23. Analise pathping/tracert.
24. Verifique VPN.
25. Investigue MTU quando houver evidência.
26. Verifique driver.
27. Verifique eventos do Windows.
28. Teste offloads somente se justificado.
29. Compare capturas antes/depois.
30. Documente o resultado.

65. Cenário real 1 — Ping perfeito, download ruim

Sintoma:

Ping:
0% perda
15 ms

Download:

300 Mbps
↓
40 Mbps
↓
280 Mbps
↓
30 Mbps

Wireshark:

múltiplos Dup ACK
Fast Retransmission

Ethernet:

normal

Wi-Fi:

ruim

Direção provável:

investigar Wi-Fi

e não simplesmente:

“operadora”

66. Cenário real 2 — LAN também está ruim

Sintoma:

SMB entre dois PCs:
instável

Wireshark:

retransmissões TCP

Ping do gateway:

varia e perde

Resultado:

problema existe dentro da LAN

A operadora pode ser retirada temporariamente do foco.

67. Cenário real 3 — somente um servidor

Internet geral:

normal

Servidor A:

retransmissões e lentidão

Servidor B:

normal

Servidor C:

normal

Agora vale investigar:

rota específica
servidor A
CDN
peering

68. Cenário real 4 — problema só com VPN

Sem VPN:

normal

Com VPN:

lentidão
retransmissões

Possíveis áreas:

MTU
driver virtual
servidor VPN
rota
CPU

69. Cenário real 5 — retransmissões sem impacto

Captura:

algumas retransmissões ocasionais

Aplicação:

normal

Throughput:

estável

Ping:

normal

Nesse caso, pode não existir um problema que mereça correção.

Não tente “zerar” o TCP.

70. Erros comuns no diagnóstico

Os erros mais frequentes são:

culpar a operadora cedo demais
culpar o roteador cedo demais
trocar cabo sem testar
desativar offloads aleatoriamente
mexer em MTU sem evidência
considerar todo Dup ACK como perda
considerar toda retransmissão um defeito
ignorar a direção do fluxo
ignorar o horário
ignorar o protocolo real da aplicação

71. Pergunta essencial: retransmissão ou aplicação lenta?

Sempre faça essa distinção.

Se:

aplicação lenta
+
TCP saudável

investigue:

servidor
CPU
disco
aplicação
banco de dados

Se:

aplicação lenta
+
TCP recovery constante

a rede ganha relevância.

72. Pergunta essencial: local ou remoto?

Tente separar:

problema no PC?
problema na LAN?
problema na WAN?
problema no servidor?

Cada comparação deve reduzir uma dessas possibilidades.

73. Pergunta essencial: ocorre sob carga?

Uma rede que funciona em repouso e falha durante download intenso pode estar sofrendo com:

congestionamento
bufferbloat
Wi-Fi saturado
roteador limitado

Por isso, testes sem carga podem perder o problema.

74. Pergunta essencial: todo o tráfego é afetado?

Se somente um serviço falha, não trate o incidente como falha geral da conexão.

Se tudo falha simultaneamente, procure um ponto compartilhado.

FAQ — TCP Retransmissions no Windows 11

TCP Retransmission significa perda de pacote?

Geralmente indica que dados TCP precisaram ser enviados novamente porque o remetente não recebeu a confirmação esperada dentro das condições previstas pelo protocolo.

Mas a causa pode envolver perda dos dados, perda do ACK, atraso, reordenação ou até limitações da captura.

Ping com 0% de perda prova que a rede está boa?

Não.

O Ping normalmente usa ICMP e representa apenas as amostras enviadas durante o teste.

Uma aplicação TCP pode apresentar problemas mesmo com Ping aparentemente normal.

TCP Retransmission é normal?

Eventos ocasionais podem acontecer.

O que importa é frequência, contexto e impacto.

Quantas retransmissões são aceitáveis?

Não existe um número universal que defina automaticamente uma rede boa ou ruim.

Avalie a relação entre retransmissões, throughput, latência e sintomas.

Como filtrar retransmissões no Wireshark?

Use:

tcp.analysis.retransmission

Como encontrar Fast Retransmissions?

Use:

tcp.analysis.fast_retransmission

Como encontrar Duplicate ACK?

Use:

tcp.analysis.duplicate_ack

O que é TCP Dup ACK?

É uma confirmação duplicada observada no fluxo.

Frequentemente aparece quando o receptor continua indicando o mesmo próximo ponto esperado após receber dados posteriores.

Dup ACK significa cabo ruim?

Não.

Pode estar associado a perda, reordenação, atraso ou características da captura.

O que é Fast Retransmission?

É um mecanismo que permite ao TCP retransmitir dados considerados ausentes antes de depender apenas de um timeout mais longo.

O que é RTO?

RTO significa Retransmission Timeout.

É um temporizador utilizado no processo de retransmissão quando a confirmação esperada não chega no tempo calculado.

Um cabo ruim pode gerar TCP Retransmissions?

Sim, se problemas no enlace resultarem em perda que chegue à camada TCP.

Mas retransmissão sozinha não prova defeito no cabo.

Wi-Fi pode causar TCP Retransmissions?

Sim.

Problemas de rádio podem levar a retries na camada Wi-Fi e, se a recuperação não for suficiente, perdas podem chegar ao TCP.

Sinal Wi-Fi forte elimina essa hipótese?

Não.

Interferência e congestionamento podem existir mesmo com sinal forte.

Bufferbloat é a mesma coisa que retransmissão?

Não.

Bufferbloat é associado principalmente ao crescimento excessivo de filas e aumento de latência sob carga.

Se houver descarte, retransmissões também podem aparecer.

A operadora pode causar retransmissões?

Sim, mas retransmissões também podem ocorrer na LAN, Wi-Fi, servidor remoto ou em outros trechos.

pathping mostra exatamente onde a perda está?

Ele pode fornecer pistas, mas respostas ICMP de hops intermediários precisam ser interpretadas com cuidado.

Um hop com 80% de perda significa problema?

Não necessariamente.

Se os hops posteriores e o destino respondem sem a mesma perda, esse equipamento pode apenas limitar suas próprias respostas ICMP.

Uma VPN pode resolver retransmissões?

Pode alterar o comportamento porque muda rota, encapsulamento e ponto de saída.

Isso é uma pista, não uma prova definitiva da causa.

VPN pode causar retransmissões?

Sim, dependendo de MTU, rota, driver virtual, servidor VPN e outras condições.

MTU errada pode causar problemas que o Ping não mostra?

Sim.

Um Ping pequeno pode funcionar enquanto tráfego maior encontra problemas relacionados ao caminho e ao encapsulamento.

Devo colocar MTU menor para resolver?

Não sem diagnóstico.

Determine primeiro se MTU realmente está relacionada ao problema.

Devo desabilitar Large Send Offload?

Não como primeira ação.

LSO melhora eficiência em condições normais.

Desative apenas como teste controlado quando houver evidência.

Checksum incorreto no Wireshark significa pacote corrompido?

Não necessariamente.

Checksum Offload pode fazer uma captura local mostrar um checksum antes do cálculo final realizado pela NIC.

O Windows possui comando para ver conexões TCP?

Sim:

Get-NetTCPConnection

Também existe:

netstat -ano

Posso descobrir o processo responsável pela conexão?

Sim.

Get-NetTCPConnection fornece o PID em OwningProcess, que pode ser relacionado ao processo correspondente.

HTTP sempre usa TCP?

Não.

HTTP/3 utiliza QUIC sobre UDP.

Por isso, nem toda navegação moderna pode ser investigada apenas com filtros TCP.

TCP Retransmissions podem reduzir download?

Sim.

Perdas e mecanismos de recuperação podem reduzir throughput, especialmente quando há repetição frequente.

SSD resolve TCP Retransmissions?

Não.

Um SSD pode melhorar armazenamento e aplicações, mas não corrige perda de rede.

Formatar o Windows resolve?

Não existe motivo para formatar o computador apenas porque foram detectadas retransmissões.

Primeiro identifique a camada responsável.

Trocar o roteador resolve?

Pode resolver se ele for realmente a causa.

O ideal é provar isso por comparação.

Como saber se o problema está no Wi-Fi?

Um dos melhores testes é repetir o mesmo cenário por Ethernet.

Se o problema desaparece consistentemente, a rede sem fio se torna o principal foco.

Como saber se o problema está na operadora?

Primeiro prove que a LAN está estável, compare múltiplos destinos, horários, rotas e, se possível, outra conexão.

Zero retransmissions significa rede perfeita?

Também não.

Existem outros problemas possíveis, como latência, bufferbloat, janela TCP, gargalo de servidor, aplicação ou armazenamento.

Conclusão

TCP Retransmissions são uma das ferramentas mais úteis para entender problemas de rede que não aparecem claramente em um teste simples de Ping.

O principal erro é tratar a mensagem:

TCP Retransmission

como diagnóstico final.

Ela é apenas uma evidência.

O TCP retransmite porque percebeu que determinada parte do fluxo não avançou como esperado.

A tarefa do técnico é descobrir por quê.

A origem pode estar no:

Wi-Fi
cabo
NIC
switch
roteador
WAN
operadora
VPN
MTU
servidor remoto

ou até na forma como a captura foi realizada.

Por isso, o melhor diagnóstico combina Wireshark, testes no gateway, comparação entre Wi-Fi e Ethernet, análise de TCP Stream, Duplicate ACK, Fast Retransmission, Get-NetTCPConnection, pathping, tracert, testes de LAN e correlação temporal.

A pergunta correta não é:

“Existem retransmissões?”

A pergunta é:

“As retransmissões são relevantes, acontecem junto com o problema e qual trecho da comunicação está fazendo o TCP precisar se recuperar?”

Quando essa pergunta é respondida corretamente, deixa de existir o diagnóstico por tentativa.

Trocar roteador, reinstalar Windows, alterar MTU e desabilitar recursos da placa de rede deixam de ser palpites.

Passam a ser testes orientados por evidências.

Precisa diagnosticar perda de pacotes, Wi-Fi instável ou Internet lenta?

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores, redes domésticas, Wi-Fi, roteadores, impressoras e problemas de conectividade no Windows.

O atendimento pode investigar situações como perda de pacotes, TCP Retransmissions, Wi-Fi instável, lentidão, problemas de roteamento, configuração de roteadores e falhas que não aparecem em testes simples de velocidade.

Telefone e WhatsApp: (11) 99779-7772

Site: https://vmia.site

Blog técnico: https://vmia.com.br

WhatsApp: https://whats.vmia.com.br

Atendimento com agendamento, presencial ou por acesso remoto conforme o tipo de problema.