Perda de pacotes causas

Como a perda de pacotes acontece

Um pacote IP e 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 saida consegue transmitir, os que não cabem na fila são descartados. Esse mecanismo e o que o RFC 793 (TCP) chama de congestion signaling: a perda e o sinal de que a rede esta saturada.

Fora do congestionamento, pacotes se perdem por corrupcao de sinal fisico. Quando o erro de transmissão excede o limite de correção do protocolo da camada de enlace, o frame e 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 e descarte por política: equipamentos de QoS (Quality of Service) descartam deliberadamente pacotes de tráfego de baixa prioridade quando o enlace esta próximo da capacidade. Isso e 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 e 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 e o mecanismo de controle de congestionamento funcionando corretamente, mas e 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 ruido de conforto em VoIP.

Níveis de perda: aceitável, ruim e crítico

O impacto da perda de pacotes varia muito dependendo do tipo de aplicação. O que e aceitável para navegação web destroi a experiência de um jogo competitivo.

Gráfico: pacotes enviados vs recebidos

O gráfico abaixo ilustra o que acontece durante um episódio de perda de pacotes em três cenários típicos: conexão saudável, perda moderada (ISP em horário de pico) e perda crítica (cabo danificado ou Wi-Fi com muito ruido).

Tabela de causas e sintomas

Tabela detalhada por sintoma

Fluxograma de diagnóstico: 9 passos

O princípio e 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 esta na rede local ou no hardware doméstico. Se for 0% de perda, o problema esta 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 e 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 fisico: 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 esta 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 ha perda para 8.8.8.8, o problema esta 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 e 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 episodica nesse horário porque o enlace satura com todos os assinantes ativos. Se o problema desaparece de madrugada, e 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, 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ê esta 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 continua: 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 continua. No Windows, WinMTR e 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 e o maior da América Latina e um dos maiores do mundo em volume de tráfego. ISPs regionais que não tem peering direto no IX.br precisam comprar trânsito de operadoras maiores, o que aumenta o custo e, em muitos casos, leva a subcontratacao 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 desnecessaria 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 pública estatísticas públicas de disponibilidade e tráfego por ASN em stats.ix.br, que podem ajudar a confirmar se um problema e generalizado no ISP antes de abrir chamado.

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.

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 e 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) as 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.

Infraestrutura de backbone e onde a perda realmente ocorre

Quando o resultado do traceroute mostra perda apenas no último hop (destino), a causa quase nunca e o enlace fisico: e roteador remoto com rate limiting no ICMP. Mas quando a perda aparece num hop intermediário e permanece em todos os hops seguintes, esse hop e o ponto de congestionamento real. Entender a topologia de backbone dos provedores brasileiros ajuda a interpretar esses resultados.

A Vivo (AS26599) opera backbone nacional de fibra óptica com nos em São Paulo, Rio de Janeiro, Belo Horizonte, Curitiba, Porto Alegre, Brasília, Salvador, Recife e Fortaleza. Perda de pacotes em horário de pico que desaparece de madrugada quase sempre indica congestionamento no enlace de distribuição regional, não no last-mile. O traceroute vai mostrar RTT subindo em hops dentro do range de ASN da própria Vivo antes de sair para o AS de destino.

A Claro (AS28573) herdou a infraestrutura da NET Virtua e do backbone da Embratel. A TIM (AS26615) e mais presente em regiões metropolitanas com fibra GPON. A Oi (AS7738) opera a maior rede de longa distância do país, com contratos de transit com AS nacionais e internacionais. A Algar Telecom (AS16735) cobre principalmente o Triangulo Mineiro e interior paulista.

O IX.br (PTT-SP, ASN 26162), operado pelo NIC.br, e o principal ponto de troca de tráfego da América Latina. Quando dois provedores fazem peering no IX.br, o tráfego entre eles não precisa passar por um terceiro AS. Quando não ha peering direto, o tráfego transita por um AS de transit e pode passar por hops nos Estados Unidos mesmo que origem e destino estejam ambos no Brasil. Esse caminho adicional pode introduzir 60-120 ms de latência extra e gargalos adicionais, especialmente com CDNs sem presença local.

A Anatel regula a qualidade de serviço dos provedores pela Resolucao 574/2011 (Regulamento de Indicadores de Qualidade dos Serviços de Telecomunicações). Para banda larga fixa, a perda de pacotes média mensal não pode ultrapassar 0,5% nos testes padronizados. A Resolucao 740/2020, que criou o Plano de Atendimento ao Cliente, obrigou os provedores a registrar e responder reclamações de qualidade com SLA definido. Se o provedor não cumprir, o usuário pode registrar reclamação formal no portal da Anatel (consumidor.gov.br).

Caminho de pacotes entre dois usuários brasileiros

Um usuário Vivo em Campinas acessando um usuário Claro no Recife pode ter o pacote passando por: CPE Vivo (AS26599) -> BRAS regional SP -> backbone Vivo -> IX.br PTT-SP -> backbone Claro (AS28573) -> nodo regional Recife -> CPE destino. Com peering no IX.br, esse caminho tem latência em torno de 30-50 ms. Sem peering, o pacote pode ir para Miami e voltar, adicionando 120-180 ms e cruzando dois enlaces submarinos, cada um com perda própria de sinal óptico.

Usuários de provedores regionais menores (ex: ISPs municipais com ASN próprio, frequentemente vistos em cidades do interior de SP, MG, RS) geralmente compram transit da GVT/Vivo, Embratel/Claro ou IPGlasnost. Quando o link de transit satura em pico, a perda aparece nesse ponto. O traceroute vai mostrar o hop dentro do AS do provedor regional antes de entrar no AS do transit provider.

Perda de pacotes em Wi-Fi: mecanismo diferente

Em conexão com fio, a perda e quase sempre de rede ou de equipamento. Em Wi-Fi, o mecanismo e diferente: o padrão 802.11 inclui retransmissao na camada de enlace, então perda visível para o TCP/IP só ocorre quando a taxa de erro de radio e alta o suficiente para esgotar as retransmissoes MAC. Isso acontece com RSSI abaixo de -75 dBm para 802.11n ou abaixo de -67 dBm para 802.11ac/Wi-Fi 5.

Interferência de canal e a segunda causa mais comum em Wi-Fi. Os canais 1, 6 e 11 na faixa de 2,4 GHz são os únicos não sobrepostos. Roteadores vizinhos no mesmo canal criam colisões de sinal que o protocolo CSMA/CA tenta evitar mas não elimina completamente. O resultado e retransmissoes excessivas e aumento de latência. A faixa de 5 GHz tem mais canais não sobrepostos (36, 40, 44, 48, 149, 153, 157, 161), menor cobertura mas menor interferência.

Para confirmar que a perda vem do Wi-Fi e não do roteador ou ISP, conecte via cabo Ethernet e repita o teste de perda de pacotes. Se a perda desaparecer no cabo, o problema e no radio. Se persistir, o problema esta do lado da WAN.

Correção sistematica e prevenção de perda de pacotes

Diagnosticar e diferente de corrigir. Muitos usuários chegam a identificar o hop com perda via traceroute mas não sabem o que fazer depois. As acoes dependem de onde esta o problema.

Problema no last-mile (cabos, conectores, ONT)

Se o primeiro hop do traceroute (gateway/roteador do ISP ou seu CPE) já mostra perda, o problema e no last-mile. As acoes em ordem de prioridade: (1) inspecionar visualmente todos os cabos Ethernet da residência, especialmente os que passam por paredes ou dobramentos agudos; (2) checar o conector RJ-45 do cabo que vai do modem/ONT ao roteador -- oxidação visível e sinal de substituição imediata; (3) se a conexão for fibra óptica GPON, verificar se a ONT mostra LED de sinal óptico estável (verde constante); (4) se for coaxial (DOCSIS), ligar o roteador diretamente na tomada coaxial para eliminar o splitter como causa.

O Marco Civil da Internet (Lei 12.965/2014), em seu artigo 7o, garante ao usuário "não suspensão da conexão salvo por débito diretamente decorrente de sua utilização". Mas mais relevante para perda de pacotes e o artigo 9o, que probe a degradação deliberada de serviço sem transparência. Se o provedor confirmar que esta aplicando traffic shaping ou QoS que cause perda em tráfego específico, o usuário tem direito a informação clara sobre isso.

Problema no backbone do ISP

Se a perda aparece em hops dentro do AS do provedor, a acao e abrir chamado técnico com evidências. O chamado precisa incluir: (1) resultado do traceroute mostrando o hop com perda, com ASN identificado via whois; (2) resultado de mtr com pelo menos 100 ciclos, mostrando porcentagem de perda por hop; (3) horário do teste e endereço completo; (4) resultado de teste de velocidade em speedtest.net (não apenas o número final, mas a URL de resultado compartilhável).

Provedores tem SLA regulatório para responder a reclamações de qualidade: 5 dias úteis para reconhecimento e 15 dias para resolucao, conforme Resolucao 740/2020. Se o prazo não for cumprido, o usuário pode registrar reclamação na Anatel. O histórico de reclamações de cada provedor e público no portal da Anatel (anatel.gov.br/consumidores).

CGNAT e perda de pacotes em jogos

O CGNAT (Carrier-Grade NAT, RFC 6598, faixa 100.64.0.0/10) e padrão em provedores móveis e em muitos provedores fixos residenciais no Brasil. Ele não causa perda de pacotes diretamente, mas afeta jogos e aplicações que dependem de NAT traversal ou UPnP. Quando o NAT centralizado do ISP não consegue mapear a porta corretamente, a conexão UDP do jogo falha e o cliente interpreta como perda.

Para confirmar se você esta atras de CGNAT, acesse a ferramenta de IP neste site e compare o IP WAN mostrado com o IP que seu roteador exibe na interface administrativa (192.168.1.1 ou 192.168.0.1 -> Status WAN). Se o IP WAN do roteador estiver no range 100.64.0.0/10, você esta atras de CGNAT. Nesse caso, a única solução para jogos que precisam de NAT aberto e solicitar IP fixo ao provedor (geralmente disponível como serviço adicional pago) ou usar VPN com endpoint fora do CGNAT.

Monitoramento continuo com ferramentas gratuitas

Para monitorar perda de pacotes ao longo do tempo sem intervenção manual, o SmokePing (open source) e a melhor opção em servidores Linux. Para Windows, o WinMTR exporta logs em CSV que podem ser analisados depois. Em macOS, o nettop e o network quality (disponível no macOS Ventura+) dao metricas de perda em tempo real. O SIMET Box do NIC.br e uma opção específica para o Brasil: e um dispositivo pequeno que se conecta a rede e envia metricas continuas para a base de dados da Anatel, servindo como evidência regulatória automatizada.

Uma prática útil e fazer um baseline antes de qualquer problema: rodar um mtr de 10 minutos para o gateway do ISP e para um servidor público (8.8.8.8 ou 1.1.1.1) em horário de baixo uso (5h-7h da manhã) e guardar o resultado. Quando o problema aparecer, repetir o mesmo teste e comparar. A diferença entre o baseline e o estado atual torna o chamado técnico muito mais objetivo e evita o clássico "não reproduzimos o problema aqui" do suporte do ISP. Resultados do SIMET são aceitos diretamente em reclamações formais na Anatel como evidência técnica padronizada.

Perguntas frequentes sobre perda de pacotes