Perda de pacotes causas

Como a perda de pacotes acontece

Um pacote IP é descartado quando a fila de envio de um roteador intermediário transborda. Cada roteador tem um buffer finito. Quando mais pacotes chegam do que o enlace de saída consegue transmitir, os que não cabem na fila são descartados. Esse mecanismo é o que o RFC 793 (TCP) chama de congestion signaling: a perda é o sinal de que a rede está saturada.

Fora do congestionamento, pacotes se perdem por corrupção de sinal físico. Quando o erro de transmissão excede o limite de correção do protocolo da camada de enlace, o frame é descartado. Isso acontece em cabos danificados, conectores oxidados, fibra com curvatura excessiva ou Wi-Fi com sinal abaixo do necessário para a taxa de transmissão configurada.

Um terceiro mecanismo é descarte por política: equipamentos de QoS (Quality of Service) descartam deliberadamente pacotes de tráfego de baixa prioridade quando o enlace está próximo da capacidade. Isso é especialmente comum em roteadores de provedores que limitam tráfego de determinados protocolos (P2P, por exemplo) em horário de pico.

Impacto diferente em TCP e UDP

TCP detecta perda automaticamente e retransmite. Quando o emissor não recebe ACK dentro do timeout, ou quando recebe três ACKs duplicados (sinal de que um pacote chegou fora de ordem e outros foram recebidos depois), ele reenvia o segmento e reduz a janela de congestionamento pela metade. O resultado é throughput menor, não falha de conexão.

Para transferência de arquivo via TCP com 5% de perda de pacotes, a velocidade efetiva pode cair para menos de 10% do máximo teórico porque o TCP interpreta a perda como congestionamento e recua agressivamente. Essa redução é o mecanismo de controle de congestionamento funcionando corretamente, mas é invisível para quem só olha a velocidade.

UDP não retransmite. Em jogos online, 2% de perda causa rubber banding e dessincronização visível. Em VoIP, causa chiados e interrupções de áudio. A aplicação lida com a perda no nível da lógica do programa: interpolação de posição em jogos, preenchimento de lacuna com ruído de conforto em VoIP.

Tabela de causas e sintomas

Fluxograma de diagnóstico: 9 passos

O princípio é eliminar causas do mais próximo para o mais distante. Cada passo confirma ou descarta uma hipótese antes de avançar.

1. Passo 1 - Medir perda no gateway: abra o Prompt de Comando no Windows (Win + R, cmd) e rode ping -n 100 192.168.0.1 (substitua pelo IP do seu gateway, que aparece em ipconfig como "Gateway padrão"). Se houver perda para o gateway, o problema está na rede local ou no hardware doméstico. Se for 0% de perda, o problema está fora da sua rede.
2. Passo 2 - Testar cabo vs Wi-Fi: conecte o computador ao roteador por cabo Ethernet Cat5e ou Cat6 e repita o ping do Passo 1. Se a perda desaparece conectado por cabo mas estava presente no Wi-Fi, o problema é interferência ou configuração de Wi-Fi. Troque o canal do roteador para 1, 6 ou 11 em 2,4 GHz. Use 5 GHz se o dispositivo suportar e estiver próximo ao roteador.
3. Passo 3 - Inspecionar o cabo físico: examine o conector RJ-45 por pins dobrados ou amarelados pela oxidação. Teste um cabo diferente, conhecido como funcionando. Se disponível, troque também a porta do switch ou roteador onde o cabo está conectado. Portas individuais podem falhar mantendo as outras funcionando.
4. Passo 4 - Testar endereço externo: rode ping -n 100 8.8.8.8. Se o gateway estava em 0% e agora há perda para 8.8.8.8, o problema está no enlace do provedor ou na infraestrutura entre seu roteador e a internet. Anote a porcentagem de perda e os valores de RTT.
5. Passo 5 - Traceroute para localizar o hop com perda: rode tracert google.com no Windows ou use a ferramenta Traceroute deste site. Observe em qual salto a perda aparece pela primeira vez. Perda apenas no Hop 1 (seu gateway) geralmente é rate limiting de ICMP, normal. Perda a partir do Hop 2 ou 3 (equipamento do provedor) indica problema de infraestrutura do ISP.
6. Passo 6 - Verificar padrão de horário: anote se a perda ocorre somente entre 18h e 23h. ISPs regionais brasileiros com peering insuficiente para o IX.br apresentam perda episódica nesse horário porque o enlace satura com todos os assinantes ativos. Se o problema desaparece de madrugada, é congestionamento de ISP. Documente com prints do traceroute em diferentes horários.
7. Passo 7 - Verificar driver e firmware: driver desatualizado de placa de rede (especialmente chipsets Realtek em notebooks e desktops de entrada) pode causar perda em rajadas. Baixe o driver mais recente diretamente do site do fabricante da placa, não pelo Windows Update. Atualize também o firmware do roteador, que normalmente está disponível no site do fabricante.
8. Passo 8 - Verificar CGNAT: acesse Meu IP e compare o endereço público com o endereço WAN exibido no painel do roteador. Se o endereço WAN do roteador começa com 100.64 a 100.127, você está em CGNAT. Saturação de sessões no servidor NAT do provedor pode causar perda em novas conexões. Solicite ao provedor a desativação do CGNAT (geralmente pago em residencial BR).
9. Passo 9 - MTR para análise contínua: para diagnóstico mais completo, use o MTR (My Traceroute). No Linux/macOS, mtr google.com combina ping e traceroute em tempo real, mostrando perda e RTT por hop em atualização contínua. No Windows, WinMTR é a versão gráfica equivalente. Monitore por pelo menos 5 minutos para capturar perda intermitente.

Perda de pacotes no Brasil: ISPs regionais e IX.br

O Brasil tem mais de 15.000 provedores de internet registrados na Anatel, mas a infraestrutura de tráfego passa por pontos de concentração críticos. O IX.br (Ponto de Troca de Tráfego Internet, operado pelo NIC.br) em São Paulo é o maior da América Latina e um dos maiores do mundo em volume de tráfego. ISPs regionais que não têm peering direto no IX.br precisam comprar trânsito de operadoras maiores, o que aumenta o custo e, em muitos casos, leva a subcontratação de capacidade menor que o pico de uso.

O resultado prático: em uma cidade do interior de Goiás, o tráfego de um assinante de ISP regional pode ir de São Paulo para Brasília e de Brasília para o IX.br-SP antes de chegar a um servidor hospedado em São Paulo, adicionando 20 a 40ms de latência desnecessária e passando por um enlace com capacidade mais limitada.

Grandes operadoras como Vivo (AS26599) e Claro (AS28573) também apresentam perda em regiões específicas durante obras de fibra ou degradação de equipamento. O NIC.br publica estatísticas públicas de disponibilidade e tráfego por ASN em stats.ix.br, que podem ajudar a confirmar se um problema é generalizado no ISP antes de abrir chamado.

CGNAT adiciona uma variável específica ao contexto brasileiro. Quando vários assinantes compartilham um servidor NAT do provedor, picos de uso simultâneo podem saturar a tabela de sessões NAT. O efeito é descarte de novas conexões enquanto conexões existentes continuam funcionando. Aparece como perda intermitente que afeta principalmente abertura de novas conexões, não transferências em andamento.

Ferramentas para medir e monitorar perda de pacotes

Para diagnóstico de redes Wi-Fi especificamente, o NetSpot (Windows e macOS) faz heatmap de sinal e identifica canais congestionados. No Android, o aplicativo WiFi Analyzer mostra canais em uso por redes vizinhas, o que ajuda a escolher o canal menos congestionado no 2,4 GHz.

Como abrir chamado técnico com evidências

Um chamado sem evidências geralmente termina em "monitorando o caso". O provedor precisa de dados específicos para agir.

O que incluir no chamado: screenshot ou log do traceroute mostrando o hop específico onde a perda começa, horário exato dos testes (com fuso horário), porcentagem de perda medida com ping -n 100, e se a perda é consistente ou só em horário de pico. Se tiver histórico de mais de um dia, inclua comparação entre diferentes horários mostrando que o problema piora entre 18h e 23h.

Com traceroute mostrando perda no Hop 3 (dentro da rede do provedor) às 20h de uma sexta-feira, o chamado sai da categoria "problema do cliente" e entra na categoria "problema de infraestrutura". Isso muda a prioridade do atendimento.

Perguntas frequentes sobre perda de pacotes