O que é ping
O que e ping: ICMP Echo, latencia, RTT, criado por Mike Muuss em 1983, como usar para diagnostico de rede e valores normais de ping no Brasil.
Ping e uma ferramenta de diagnostico de rede que mede o tempo de ida e volta (RTT, Round-Trip Time) entre dois dispositivos, usando pacotes ICMP Echo Request e Echo Reply definidos pelo RFC 792 de 1981. Mike Muuss escreveu o código original em uma única noite de dezembro de 1983 no U.S. Army Ballistic Research Laboratory, inspirado no sonar submarino que emite um sinal e aguarda o eco. Quarenta e dois anos depois, o ping continua sendo o primeiro comando que qualquer engenheiro de rede executa ao investigar um problema de conectividade. O que os valores significam, como interpretar RTT, jitter e perda de pacotes, e os valores de referência para conexões no Brasil em 2025 e o que este artigo explica com detalhe.
Neste artigo
- O que e ping: ICMP, RTT e o protocolo por tras
- Historia: Mike Muuss e a noite de 1983
- Como o ping funciona na prática
- Como interpretar os resultados do ping
- Valores de referência de latência no Brasil
- Ping bloqueado: ICMP filtrado e alternativas
- Sequencia de diagnostico com ping
- Ping no Brasil: topologia, IX.br e provedores
- Ferramentas além do ping: traceroute e MTR
- Perguntas frequentes
O que e ping: ICMP, RTT e o protocolo por tras
Ping utiliza o ICMP (Internet Control Message Protocol), protocolo de camada de rede definido pelo RFC 792 (setembro 1981, IETF). O ICMP transporta mensagens de controle e erro para o protocolo IP: destino inalcancavel, tempo excedido (TTL esgotado), redirecionamentos de rota e, no caso especifico do ping, mensagens Echo Request e Echo Reply.
Um pacote ICMP Echo Request (tipo 8, código 0) contem: o tipo (8), o código (0), um checksum de 16 bits para verificação de integridade, um identificador de 16 bits (para associar respostas ao processo correto quando multiplos pings rodam simultaneamente), um número de sequência (para detectar pacotes perdidos e fora de ordem) e um campo de dados opcional (preenchido com bytes de teste). O host destino deve responder com um Echo Reply (tipo 0, código 0), copiando o identificador, o número de sequência e os dados. O cliente calcula o RTT subtraindo o timestamp de envio do timestamp de recepcao.
ICMPv6 para redes IPv6
Para redes IPv6, o ICMPv6 (definido pelo RFC 4443, IETF) define Echo Request como tipo 128 e Echo Reply como tipo 129. O comando ping6 (ou ping -6 em sistemas modernos) usa ICMPv6. O ICMPv6 e obrigatório no IPv6, diferente do ICMP no IPv4 que e tecnicamente opcional mas crítico. O ICMPv6 também e responsável pelo NDP (Neighbor Discovery Protocol, RFC 4861), que substitui o ARP do IPv4 e e essencial para o funcionamento de redes IPv6.
Fundamentos acadêmicos do ping
O ICMP, protocolo sobre o qual o ping opera, e documentado em detalhe nos textos classicos de redes. Tanenbaum explica o mecanismo de TTL que o ping usa indiretamente via traceroute:
"A mensagem TIME EXCEEDED e enviada quando um pacote e descartado porque seu contador chegou a zero. Esse evento e um sintoma de que os pacotes estão entrando em loop, de que ha um enorme congestionamento ou de que estão sendo definidos valores muito baixos para o timer."
Andrew S. Tanenbaum - Redes de Computadores, 4a edição, p. 346 (Campus, 2004)
Peterson & Davie descrevem como o TTL foi reinterpretado como contador de hops, o que e a base do funcionamento do ping e do traceroute:
"como era raro que um pacote ficasse por 1 segundo em um roteador, e nem todos os roteadores tinham acesso a um relogio em comum, a maioria dos roteadores simplesmente decrementava o TTL em 1 quando encaminhava o pacote. Assim, ele tornou-se mais um contador de hops do que um temporizador."
Larry L. Peterson, Bruce S. Davie - Redes de Computadores: Uma Abordagem de Sistemas, 5a edição, p. 128 (Elsevier, 2013)
O campo TTL que o ping monitora e especificado na estrutura do cabeçalho IPv4, conforme descrito por Fernandez:
"Esse campo serve para evitar que um datagrama transmitido na Internet com endereço errado fique circulando eternamente."
Marcial Porto Fernandez - Rede de Computadores. UAB/UECE, 2019, p. 125
Historia: Mike Muuss e a noite de 1983
Mike Muuss criou o ping em dezembro de 1983 enquanto trabalhava no U.S. Army Ballistic Research Laboratory (BRL) em Aberdeen, Maryland. Ele investigava problemas de performance numa rede local e precisava de um modo rápido de verificar se outros hosts respondiam e qual era o tempo de resposta.
Em 2000, Muuss escreveu sobre a criação: "O nome PING veio do sonar: quando um submarino emite um pulso sonoro e aguarda o eco retornar, sabe que ha algo la. Era exatamente o que eu precisava para confirmar que um host estava vivo na rede. Mas PING também pode ser lido como acronimo recursivo: Packet InterNet Groper." O código original tinha menos de 150 linhas de C e foi escrito em uma única noite.
Berkeley Software Distribution incluiu o ping no BSD 4.3 em 1986. Microsoft incorporou o ping.exe no Windows NT 3.1 em 1993. Muuss faleceu em novembro de 2000 em um acidente de carro na US Route 40 em Maryland. Sua contribuicao persiste em cada terminal aberto ao investigar conectividade.
| Ano | Evento | Impacto |
|---|---|---|
| 1981 | RFC 792: ICMP especificado por Jon Postel | Protocolo de controle do IPv4 padronizado |
| 1983 | Mike Muuss escreve o ping no BRL | Ferramenta de diagnostico nasce em uma noite |
| 1986 | BSD 4.3 inclui ping como ferramenta padrão | Ping se torna ubiquo em sistemas UNIX |
| 1993 | Windows NT 3.1 inclui ping.exe nativamente | Ping alcanca usuários de desktop corporativo |
| 2006 | RFC 4443: ICMPv6 especificado | Ping para redes IPv6 (tipos 128/129) |
| 2025 | Ping presente em todo SO moderno | 42 anos depois, ainda o primeiro diagnostico de rede |
Como o ping funciona na prática
Ao executar ping 8.8.8.8 em um terminal Linux, o sistema envia por padrão pacotes ICMP de 64 bytes (8 bytes de cabeçalho ICMP + 56 bytes de dados de preenchimento) em intervalos de 1 segundo. A saida tipica exibe: tamanho do pacote recebido, IP de origem da resposta, número de sequência, TTL do pacote de retorno e RTT em milissegundos.
O TTL na resposta do ping
O TTL (Time to Live) na resposta indica o valor remanescente após percorrer os saltos de volta. O TTL inicial varia por sistema operacional do destino: 64 e o padrão em Linux e Android; 128 e o padrão do Windows; 255 e o padrão de equipamentos Cisco e Juniper. Subtraindo o TTL recebido do TTL inicial estimado, obtem-se o número aproximado de saltos no caminho de retorno.
Pacotes de tamanho variavel e MTU
O ping com pacotes grandes (ping -s 1400 8.8.8.8) testa a MTU (Maximum Transmission Unit) do caminho. O MTU padrão da Ethernet e 1500 bytes. Se algum trecho da rota tem MTU menor (comum em conexões VPN, CGNAT ou links WAN com configurações especificas), pacotes maiores são fragmentados ou descartados com uma mensagem ICMP "Fragmentation Needed" (tipo 3, código 4).
O problema de PMTU Blackhole ocorre quando roteadores descartam pacotes grandes sem enviar o ICMP de volta, quebrando silenciosamente conexões TCP que tentam usar payloads acima do MTU real do caminho. O diagnostico usa ping -M do -s 1400 host (Linux, flag "Don't Fragment") para identificar o MTU máximo que passa sem fragmentação.
| Parametro | Linux/macOS | Windows | Funcao |
|---|---|---|---|
| Numero de pacotes | -c N | -n N | Envia N pacotes e para (padrão: infinito Linux, 4 Windows) |
| Tamanho do payload | -s N | -l N | Define tamanho dos dados em bytes (padrão: 56/32 bytes) |
| Intervalo entre pacotes | -i N | (não suportado) | Segundos entre pacotes (padrão: 1s) |
| Forcar IPv6 | -6 | -6 | Usa ICMPv6 mesmo que IPv4 esteja disponível |
| No-fragment | -M do | -f | Proibe fragmentação (para teste de MTU) |
| TTL dos pacotes enviados | -t N | -i N | Define TTL; útil para traceroute manual |
| Flood ping (root) | -f | (não disponível) | Maxima taxa de envio, sem delay entre pacotes |
Como interpretar os resultados do ping
Um ping retorna três métricas essenciais: RTT (latência), perda de pacotes e jitter (variacao do RTT). Cada uma aponta para problemas diferentes.
RTT: latência de ida e volta
O RTT (Round-Trip Time) e medido em milissegundos. Na linha de estatísticas ao final do ping no Linux, os campos min/avg/max/mdev mostram o mínimo, média, máximo e desvio padrão das medicoes. Um RTT alto indica grande distância física, muitos saltos, congestionamento de rede ou processamento lento no destino. Para aplicações em tempo real (chamadas de voz, jogos competitivos), o min e o mdev são mais relevantes do que a média.
| Faixa (ms) | Qualidade | Cenario tipico |
|---|---|---|
| < 30 | Excelente | Fibra capital BR para CDN em SP/RJ |
| 30-60 | Bom | Fibra interior para CDN em SP |
| 60-100 | OK | Norte/Nordeste para servidor SA, intercontinental para Miami |
| > 100 | Ruim/Critico | Wi-Fi degradado, peering ruim, transcontinental EU/Ásia |
Perda de pacotes
Perda de pacotes (packet loss) e a porcentagem de Echo Requests que não receberam Echo Reply dentro do timeout. Zero perda e o resultado esperado para conexões saudaveis. Perda de 1-3% e detectavel em chamadas de video e jogos que usam UDP. Perda acima de 5% causa degradacao perceptível em quase qualquer aplicação. Perda de 100% pode significar host fora do ar, ICMP bloqueado por firewall ou rota não existente.
Jitter: variacao do RTT
Jitter e a variacao do RTT entre medicoes consecutivas. RTTs de 10ms, 11ms, 10ms, 12ms tem jitter baixo (sinal de rede estavelmente congestionada ou com latência consistente). RTTs de 10ms, 45ms, 12ms, 80ms tem jitter alto (ruim para chamadas de voz e video em tempo real). Aplicacoes de audio/video usam buffers de jitter para compensar variacao, mas buffers maiores adicionam latência percebida. Para jogos competitivos, jitter alto e mais prejudicial do que latência consistentemente alta: um jitter de 80ms em média de 50ms de RTT e pior para shooter do que RTT constante de 100ms.
| Metrica | Excelente | Aceitavel | Degradado | Critico |
|---|---|---|---|---|
| RTT (ping nacional BR) | < 10ms | 10-50ms | 50-150ms | > 150ms |
| Perda de pacotes | 0% | 0,1-1% | 1-5% | > 5% |
| Jitter (mdev) | < 3ms | 3-15ms | 15-50ms | > 50ms |
| Impacto em chamada VoIP | Perfeito | OK | Eco/cortes | Inutilizavel |
| Impacto em jogos online | Perfeito | OK | Lag perceptível | Injogavel |
Valores de referência de latência no Brasil
A topologia geográfica do Brasil, com distâncias continentais entre o Norte e o Sul, cria situacoes de latência não intuitivas. São Paulo e o hub de conectividade: a maioria dos IXPs relevantes (IX.br SP com pico de 30 Tbps em 2025 conforme NIC.br), data centers de provedores de conteudo (Google, Cloudflare, AWS) e cabos submarinos internacionais tem pontos de presença em SP.
Estimativa para conexões a servidores hospedados no Brasil, 2025
| Origem-Destino | RTT esperado (fibra) | RTT esperado (4G) | RTT Starlink |
|---|---|---|---|
| SP - SP (mesmo data center) | < 2ms | 30-60ms | N/A |
| SP - RJ | 5-12ms | 40-80ms | N/A |
| SP - BH | 8-18ms | 45-90ms | N/A |
| SP - Fortaleza | 35-60ms | 70-130ms | N/A |
| SP - Belém / Manaus | 60-100ms | 100-180ms | 30-60ms |
| Brasil - EUA (Miami/NY) | 90-140ms | 130-200ms | 30-60ms |
| Brasil - Europa (Amsterdam) | 180-240ms | 220-300ms | 30-60ms |
| Brasil - Ásia (Tóquio) | 270-350ms | 320-420ms | 30-60ms |
Ping bloqueado: ICMP filtrado e alternativas
E muito comum que o ping retorne 100% de perda de pacotes para um destino que esta perfeitamente funcional. A causa mais frequente e o bloqueio de ICMP por firewall ou configuração de rede.
Por que administradores bloqueiam ICMP
Dois motivos principais levam ao bloqueio de ICMP. Primeiro, mapeamento de rede: um atacante pode usar pings em massa para descobrir quais IPs estão ativos numa sub-rede (ICMP sweep ou ping sweep). Segundo, histórico de ataques DDoS de amplificação via broadcast ICMP (ataques Smurf, agora mitigados). Muitos firewalls corporativos e CDNs bloqueiam ICMP de entrada por padrão conservador.
| Ferramenta | Comando | O que mede | Quando usar |
|---|---|---|---|
| hping3 (TCP ping) | hping3 -S -p 80 -c 3 host | RTT via TCP SYN para porta 80 | Host aceita TCP mas bloqueia ICMP |
| curl com tempo | curl -o /dev/null -s -w "%{time_connect}ms\n" https://host | Tempo de conexão TCP+TLS | Benchmarking de servidor web |
| nmap (host discovery) | nmap -sn host | Combinacao ARP, TCP, UDP para detectar se host esta vivo | Scan de rede local |
| traceroute | traceroute host (Linux) | Latencia por cada salto da rota | Diagnosticar onde latência aumenta |
| MTR | mtr --report-cycles 60 host | Latencia + perda por salto em tempo real | Diagnostico completo de rota |
Sequencia de diagnostico com ping
O ping e o primeiro comando numa cadeia de diagnostico. Cada resultado tem uma interpretação e uma próxima acao. A sequência correta isola o problema rapidamente.
-
ping 127.0.0.1 (loopback): Testa se a pilha TCP/IP do dispositivo local funciona. Se falhar aqui, o problema e no próprio sistema operacional, no driver de rede ou na configuração da pilha IP. Requer reinstalacao ou reset da pilha TCP/IP (
netsh int ip resetno Windows,systemctl restart NetworkManagerno Linux). -
ping [gateway padrão]: Testa conectividade com o roteador local. O gateway padrão esta visível via
ip route show(Linux) ouipconfig(Windows). Falha indica problema na rede local: cabo desconectado, autenticação Wi-Fi, IP mal configurado ou roteador com problema. - ping 8.8.8.8: Testa conectividade internet sem depender de DNS. Se o gateway funciona mas 8.8.8.8 falha, o problema esta no link do provedor (CGNAT, PPPoE, link físico) ou no roteamento do provedor. Ligue para o suporte do ISP com esse diagnostico.
-
ping google.com: Testa DNS mais conectividade. Se 8.8.8.8 funciona mas google.com falha, a resolução DNS tem problema. Verifique o servidor DNS configurado (
cat /etc/resolv.conf) e tente trocar para 8.8.8.8 ou 1.1.1.1 manualmente. -
ping [servidor especifico]: Testa o caminho até um destino especifico. Alta latência ou perda aqui, com ping ok para 8.8.8.8, indica congestionamento ou problema especifico na rota para aquele servidor. Use MTR (
mtr --report-cycles 60 [host]) para identificar o salto problemático.
Ping no Brasil: topologia, IX.br e provedores
O IX.br (Internet Exchange Brazil), operado pelo NIC.br, e o maior fator que afeta latência para conteudo popular no Brasil. O IX.br SP atingiu pico de 30 Tbps em 2025 e o conjunto de 38 nos ativos supera 40 Tbps agregados segundo dados do NIC.br de início de 2025. Provedores que fazem peering no IX.br SP trocam tráfego diretamente com Google, Cloudflare, Akamai, AWS e centenas de outros, sem passar por links internacionais. O resultado prático: latências de 2-8ms para acessar serviços hospedados ou com PoPs no IX.br SP, contra 80-120ms se o tráfego precisasse sair para os EUA.
Para diagnosticar latência alta para um servidor especifico, o MTR e mais útil do que o ping simples. Execute mtr 8.8.8.8 --report-cycles 60 e observe qual salto na rota tem latência alta ou perda de pacotes. Um salto com latência 50ms acima do anterior e o gargalo. Em conexões com CGNAT, o primeiro salto externo pode adicionar 5-15ms de latência adicional comparado a conexões sem NAT.
A Anatel pública semestralmente o Mapa de Qualidade de Banda Larga (Ato 14.612/2022), que inclui métricas de latência por provedor e região. Em 2024, provedores de fibra simetrica nas capitais do Sudeste apresentaram latências médias abaixo de 15ms para servidores nacionais. Provedores via satélite GEO (ex: Hughes, Viasat) mantiveram latências acima de 600ms por natureza da tecnologia, enquanto Starlink LEO ficou na faixa de 30-60ms.
Ferramentas além do ping: traceroute e MTR
O ping mede conectividade ponto-a-ponto e RTT total. Quando o problema e no meio da rota, ferramentas que mostram cada salto são necessarias.
Traceroute: mapeando a rota
O traceroute (Linux/macOS: traceroute, Windows: tracert) envia pacotes com TTL crescente (1, 2, 3...) e coleta os ICMP Time Exceeded de cada roteador que descarta o pacote por TTL expirado. O resultado e uma lista de todos os saltos da rota até o destino, com a latência de cada um. Asteriscos na saida indicam saltos que não respondem ICMP (normal, não necessariamente problema).
MTR: diagnostico continuo combinado
MTR (My Traceroute, disponível em Linux como mtr e no Windows como WinMTR) combina ping e traceroute em tempo real. Mostra latência e perda de pacotes por salto de forma continua, o que permite identificar congestionamento intermitente. Para compartilhar com suporte técnico, mtr --report-cycles 60 8.8.8.8 > mtr-report.txt gera um relatório de 60 ciclos de medicao.
Perguntas frequentes sobre o que e ping
O que e ping e como funciona?
Ping e uma ferramenta de diagnostico de rede que mede o RTT (Round-Trip Time) entre dois dispositivos usando pacotes ICMP Echo Request (tipo 8) e Echo Reply (tipo 0), definidos pelo RFC 792. Ao executar "ping 8.8.8.8", o sistema envia pacotes para o IP de destino e mede o tempo até receber a resposta, em milissegundos. O nome vem do sonar submarino e foi criado por Mike Muuss em 1983 no U.S. Army Ballistic Research Laboratory.
O que e RTT e latência?
RTT (Round-Trip Time) e o tempo total para um pacote ir do remetente ao destino e voltar, medido em milissegundos. Latencia one-way e o tempo de apenas uma direcao, tipicamente aproximadamente metade do RTT em redes simetricas. Em jogos online, latência geralmente se refere ao RTT do próprio protocolo do jogo para o servidor. Ping abaixo de 50ms e excelente para jogos; acima de 150ms, lag torna-se perceptível em jogos de acao rápida.
Por que o ping pode estar bloqueado para um site?
Muitos servidores e firewalls bloqueiam pacotes ICMP por padrão, seja para evitar mapeamento de rede por ferramentas de scan (ICMP sweep) ou como política de seguranca conservadora. Google.com e Cloudflare bloqueiam ping ICMP mas funcionam normalmente via HTTPS. Um ping sem resposta (100% de perda) não significa necessariamente que o host esta fora do ar. Alternativas: usar curl para medir tempo de conexão TCP, ou hping3 para "TCP ping" via porta 80 (hping3 -S -p 80 -c 3 host).
Qual ping e normal no Brasil?
Para servidores dentro de São Paulo em fibra, ping abaixo de 5ms e normal. Para servidores em outras cidades brasileiras: RJ 5-12ms, BH 8-18ms, Fortaleza 35-60ms, Belém 60-100ms. Para servidores nos EUA (Miami), 90-130ms e tipico. Para Europa (Amsterdam), 180-240ms. Para Ásia (Tóquio), 270-350ms. Valores muito acima podem indicar roteamento subotimal, CGNAT adicionando latência ou problema especifico no link do provedor.
Ping mede a velocidade da internet?
Não. Ping mede latência (tempo de resposta), que e independente do throughput (velocidade de transferência de dados). Uma conexão pode ter ping excelente de 5ms mas baixa largura de banda (transferência lenta), ou alta velocidade de download com ping ruim de 200ms. Para medir velocidade, use testes de throughput como fast.com ou speedtest.net. Ping e traceroute diagnosticam latência e roteamento; são ferramentas complementares, não substitutos de testes de velocidade.
O que e jitter e como afeta a conexão?
Jitter e a variacao do RTT entre medicoes consecutivas do ping. RTTs de 10ms, 11ms, 10ms, 12ms tem jitter baixo (bom). RTTs de 10ms, 80ms, 15ms, 90ms tem jitter alto (ruim para chamadas de voz, video em tempo real e jogos online). Conexoes Wi-Fi e 4G tem jitter naturalmente maior do que fibra. O campo "mdev" na estatística do ping Linux mostra o desvio médio, que e um bom indicador de jitter.
O que e MTR e como usar para diagnosticar problemas de rede?
MTR (My Traceroute) combina ping e traceroute em tempo real, mostrando latência e perda de pacotes em cada salto da rota até o destino. E muito mais informativo do que o ping simples para diagnosticar onde na rota um problema ocorre. Instalar no Linux: "apt install mtr" ou "yum install mtr". Usar: "mtr --report-cycles 60 8.8.8.8". Um salto com latência subitamente maior ou perda de pacotes e o ponto de congestionamento ou problema na rota.
Como usar o ping para testar MTU da conexão?
O MTU (Maximum Transmission Unit) padrão do Ethernet e 1500 bytes. Para testar se sua conexão suporta pacotes de tamanho máximo sem fragmentação, use "ping -M do -s 1472 [gateway]" no Linux. O "-M do" proibe fragmentação; "-s 1472" envia payload de 1472 bytes (1472 + 28 bytes de cabeçalho IP+ICMP = 1500 bytes total). Se o ping falhar, o MTU do caminho e menor. Reduza o tamanho até encontrar o maior valor que passa. Isso e útil para diagnosticar problemas de PMTU com VPNs e CGNAT.
Qual a diferença entre ping e traceroute?
Ping mede RTT para um destino especifico sem mostrar o caminho. Traceroute (tracert no Windows) mostra cada salto (roteador) da rota até o destino, com a latência de cada um. Ping e usado para verificar se um host esta acessivel e medir latência ponta-a-ponta. Traceroute e usado para identificar onde na rota a latência aumenta ou onde os pacotes são descartados. Para diagnostico completo, use MTR, que combina os dois em tempo real.
O ping funciona em IPv6?
Sim. Para redes IPv6, o ICMPv6 (RFC 4443) define Echo Request (tipo 128) e Echo Reply (tipo 129). Em sistemas modernos, "ping -6 ipv6.google.com" ou "ping6 ipv6.google.com" testa conectividade IPv6. O Windows também suporta "ping -6" na versão nativa. Com o Brasil atingindo 50% de adocao de IPv6 em 2025, diagnosticar conectividade IPv6 com ping torna-se cada vez mais relevante. Se um host funciona via IPv4 mas falha em IPv6, pode haver problema na configuração de SLAAC, DHCPv6 ou no prefixo /64 delegado pelo provedor.
Como o CGNAT afeta os resultados do ping?
Em conexões com CGNAT, o ping para destinos externos passa por um NAT adicional no provedor, que pode adicionar 5-15ms de latência em relacao a uma conexão sem CGNAT. Mais relevante: o ping de dentro de casa para o gateway CGNAT (primeiro IP público) pode ser de 2-10ms, enquanto o IP mostrado na internet e diferente do seu gateway local. Para identificar se você esta em CGNAT, use "ping [seu IP público]": se não houver resposta ou o TTL for muito alto, pode indicar que o IP público esta em um roteador do provedor, não no seu equipamento.
Por que o ping para meu gateway e alto em Wi-Fi?
Wi-Fi adiciona latência variavel que pode ir de 1ms a 30ms dependendo da distância do roteador, interferencia de outros dispositivos, número de clientes conectados e padrão Wi-Fi (Wi-Fi 6 / 802.11ax tem latência menor em redes congestionadas vs Wi-Fi 5). Ping alto para o próprio gateway (acima de 20ms) indica problema na camada sem fio, não no link do provedor. Solucoes: aproximar-se do roteador, mudar para banda 5 GHz, reduzir interferencias ou usar cabo Ethernet para diagnosticar se o problema e no Wi-Fi ou no link externo.
Compreender o que e ping e como interpretar seus resultados permite diagnosticar se um problema de conectividade e local (rede doméstica), no provedor ou no destino, distinguir latência de perda de pacotes, e identificar gargalos em rotas especificas. Use a ferramenta Ping online desta pagina para testar latência a qualquer IP ou domínio a partir dos servidores do SaberMeuIP, sem instalar nada localmente.
Para diagnosticos mais avancados, o traceroute e o MTR complementam o ping mostrando cada salto da rota. Para entender os protocolos por baixo, os artigos sobre o que e IP e o que e IPv6 cobrem o protocolo IP sobre o qual o ICMP opera. Para contexto de rede brasileira, o artigo o que e CGNAT explica como o NAT do provedor pode afetar latência e diagnosticos. A especificacao completa do ICMP esta no RFC 792 (setembro 1981, rfc-editor.org).
Referencias bibliograficas
- Tanenbaum, A. S. Redes de Computadores. 4a edição. Campus, 2004. (Secao 5.6.4 - ICMP, p. 345-346)
- Peterson, L. L.; Davie, B. S. Redes de Computadores: Uma Abordagem de Sistemas. 5a edição. Elsevier, 2013. (Secao 3.2 - TTL e ICMP)
- Fernandez, M. P. Rede de Computadores. UAB/UECE, 2019. (Secao 1.3 - ICMP, p. 125)
- Postel, J. RFC 792 - Internet Control Message Protocol (ICMP). IETF, setembro 1981.
- Muuss, M. - Artigo original sobre a criação do ping (U.S. Army Ballistic Research Laboratory, dezembro 1983). Disponivel em https://ftp.arl.army.mil/~mike/ping.html
Teste de Ping
Leituras Relacionadas
- Ping alto causas — Ping alto causas no Brasil: distância, peering de ISP, CGNAT, Wi-Fi, hardware. Fluxograma de diagnostico com exemplos de latencia tipica para jogadores BR.
- Perda de pacotes causas — Perda de pacotes causas: congestionamento, hardware defeituoso, interferencia Wi-Fi, ISPs regionais BR. Fluxograma de diagnostico passo a passo com ping e traceroute.
- Jitter explicado — Jitter explicado de forma clara: o que e variacao de latencia, como afeta VoIP e jogos online, valor ideal abaixo de 30 ms e como medir na sua conexão.