Ping: o que é, como funciona, como ler a saída e usar no monitoramento de redes
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREO ping é o comando que mede se um destino responde e em quanto tempo. Ele envia pacotes ICMP Echo Request a um endereço IP e cronometra o retorno, o ICMP Echo Reply. Em quatro linhas de saída ele entrega disponibilidade, latência, perda de pacotes e uma pista sobre quantos roteadores separam você do destino.
Três dessas leituras costumam sair erradas. Os números deste artigo vieram de um teste rodado em 2 de setembro de 2026, num host Windows 11 e num contêiner Alpine com iputils. A subtração do TTL ficou abaixo da contagem real do tracert nos três destinos. Ademais, a amplitude entre mínimo e máximo não mede jitter.
Para equipes de NOC e administradores de redes, o ping é o ponto de partida do diagnóstico. Assim, este artigo cobre o que cada campo significa, onde a leitura intuitiva falha e quais são os limites do ping no monitoramento corporativo contínuo.
Como o ping funciona tecnicamente
O ping opera sobre o protocolo ICMP (Internet Control Message Protocol), definido na RFC 792. Ele envia pacotes Echo Request com identificador e número de sequência. Em seguida, o destino responde com um Echo Reply que carrega os mesmos dados. O tempo decorrido entre os dois é o RTT.
Por padrão, o comando no Windows envia 4 pacotes de 32 bytes e para. No Linux e no macOS, ele continua até receber Ctrl+C. Para teste contínuo no Windows existe o -t. Por outro lado, um número fixo de pacotes vem do -n. Ou seja, é o -n que interessa quando o objetivo é medir perda, pelo motivo que a seção sobre perda demonstra.
Na camada de rede (Layer 3 do modelo OSI), o ICMP fica abaixo do TCP e do UDP. Logo, o ping testa a conectividade na camada IP e nada além dela. Inclusive, ele não valida se uma aplicação está funcional, nem se uma porta TCP específica aceita conexão.
Lendo a saída do ping: o que cada campo significa
Abaixo está o que a ferramenta realmente imprime, capturado do Prompt de Comando do Windows 11, build 26200, em 2 de setembro de 2026. Foram oito pacotes para o resolvedor público 8.8.8.8.
Cada linha de resposta traz três campos e o resumo final traz outros três. Nesse sentido, a tabela abaixo diz onde ler cada um, qual valor esperar e o que fazer quando o número sai da faixa.
| Campo | Onde aparece e como ler | Limiar e o que fazer |
|---|---|---|
| RTT | Campo tempo= de cada resposta. Soma a ida e a volta, não só a ida. |
Compare com a linha de base do próprio destino. Os mesmos 26 ms são bons para um salto intercontinental e ruins para o roteador da ponta. |
| TTL | Campo TTL= de cada resposta. É o que sobrou do contador, não o que saiu do destino. |
Queda do valor no mesmo destino entre dois dias indica mudança de rota. Não sustenta contagem exata de saltos. |
| Perda de pacotes | Linha Perdidos do resumo, em número absoluto e em percentual. |
Acima de 1% em enlace corporativo é defeito a investigar. Meça com 400 pacotes: 4 não distinguem 0% de 5%. |
| Mínimo e Máximo | Última linha do resumo. A diferença entre os dois é a amplitude. Amplitude não é jitter. | Amplitude alta com média estável denuncia um pacote fora da curva, não degradação contínua do enlace. |
| mdev | Só existe no iputils do Linux, no fim da linha rtt min/avg/max/mdev. É a dispersão das amostras. |
No teste de 2 de setembro deu 0,813 ms num enlace saudável e 9,133 ms com degradação injetada de propósito. |
| bytes | Tamanho do payload: 32 bytes no Windows e 56 no Linux, por padrão diferente em cada um. | Para investigar MTU e fragmentação, aumente o payload com -l no Windows ou -s no Linux. |
RTT (tempo de resposta em ms)
O RTT é a métrica central do comando. Ele diz quantos milissegundos o pacote levou para ir ao destino e voltar. O valor esperado depende da distância física e da infraestrutura. Por exemplo, o gateway local costuma responder em 1 ms ou menos, enquanto um servidor em outro continente varia entre 100 ms e 300 ms.
Para latência em ambiente corporativo, valores acima de 100 ms já degradam VoIP e videoconferência de forma perceptível. O resumo, por fim, fecha com mínimo, médio e máximo. É nessa última linha que mora o erro de leitura mais comum.
Amplitude não é jitter. A diferença entre mínimo e máximo mede a amplitude, refém de um único pacote fora da curva. O jitter, por outro lado, é a dispersão das amostras. O comando do Linux publica essa dispersão no campo mdev, que a versão do Windows não calcula.
Essa diferença de conceito vira diferença de número assim que o enlace piora. O teste abaixo rodou num contêiner Alpine com iputils 20240117, medindo o mesmo destino duas vezes com segundos de intervalo. Entre uma medição e outra, o tc netem injetou 8% de perda e 20 ms de atraso com 8 ms de variação.
Repare no contraste. A média subiu 2,1 vezes, de 19,495 ms para 41,495 ms. O mdev subiu 11,2 vezes, de 0,813 ms para 9,133 ms. Dessa forma, a dispersão acusa a degradação muito antes da média. É ela que merece o limiar de alerta no monitoramento contínuo.
TTL (Time to Live)
O TTL é o campo mais subestimado da saída. Ele conta quantos saltos ainda restam ao pacote antes do descarte. Cada roteador atravessado decrementa o valor em 1. Assim, ao chegar a zero, o roteador descarta o pacote e devolve um ICMP Time Exceeded ao remetente.
Vale fixar uma distinção: o TTL que aparece na resposta é o valor restante, nunca o inicial. Sistemas operacionais partem de bases distintas: Linux e derivados usam 64, Windows usa 128 e equipamentos Cisco usam 255. Portanto, a base da conta não é o sistema que você imagina no destino: é o primeiro valor padrão acima do TTL recebido.
Esse arredondamento é o que salva a estimativa. Um TTL de 60 vem da base 64 e indica 4 saltos, enquanto um TTL de 119 vem da base 128 e indica 9. Ou seja, aplicar 128 aos dois casos devolveria 68 saltos no primeiro, um número sem sentido físico.
Resta saber se a estimativa bate com a realidade. Para isso, o teste abaixo comparou o TTL recebido com a contagem de roteadores do tracert, nos mesmos três destinos e no mesmo momento.
| Destino | TTL recebido | Saltos pela conta | Roteadores no tracert |
|---|---|---|---|
| 8.8.8.8 | 119 (base 128) | 9 | 11 |
| 1.1.1.1 | 60 (base 64) | 4 | 9 |
| www.opservices.com.br | 56 (base 64) | 8 | 11 |
Em todos os três destinos a conta ficou abaixo da contagem real, com diferença de 2 a 5 roteadores. Duas causas explicam o desvio. O TTL decrementa no caminho de volta, que nem sempre coincide com o de ida. Além disso, túnel MPLS com ttl-propagate desligado atravessa o núcleo sem decrementar nada.
Na prática, a estimativa serve para comparar dois momentos do mesmo destino. Se o TTL cai de 119 para 115 de um dia para o outro, a rota mudou e vale investigar. Todavia, apresentar o número como topologia exata é o que não se sustenta.
Perda de pacotes
Perda de pacotes aparece no resumo final, em número absoluto e em percentual. Em enlace corporativo estável, ela fica em zero. Acima de 1%, contudo, aparecem as suspeitas de sempre: congestionamento, hardware degradado, enlace saturado ou interferência em rede sem fio. Em VoIP, por exemplo, perda acima de 5% torna a conversa inaceitável.
Só que o padrão do Windows não enxerga 1%. Com 4 pacotes, o resultado só pode ser 0%, 25%, 50%, 75% ou 100%, porque a resolução da medida é 25%. Portanto, um enlace que perde 1 pacote em cada 100 devolve 0% quase sempre nessa amostra.
Nada disso é teoria. O teste abaixo mostra o efeito num enlace com 5% de perda real, imposta pelo tc netem. Foram 12 rodadas de 4 pacotes e depois uma rodada de 400 no mesmo enlace, sem mexer em mais nada.
Dez das doze rodadas de 4 pacotes reportaram 0% de perda. Em contrapartida, a rodada de 400 pacotes no mesmo enlace mediu 4,25%, perto do valor imposto. Em resumo, o padrão do Windows disse que estava tudo bem em 83% das tentativas, num enlace que derrubava 1 pacote a cada 20.
Daí a regra operacional: para qualificar um enlace, use ping -n 400 no Windows ou ping -c 400 no Linux. Quatro pacotes respondem se o host está vivo. No entanto, eles não respondem se o enlace está bom.
Quando o ping falha mas o host está online
Ler Request timed out como prova de host inacessível é o erro de diagnóstico mais frequente. Acontece que administradores de segurança bloqueiam respostas ICMP em firewalls e sistemas operacionais para dificultar a enumeração de hosts. Nesse caso, portanto, o host está funcional e apenas ignora o ICMP.
Para validar um host que não responde ao ICMP, teste uma camada acima. No PowerShell, Test-NetConnection -Port 443 -ComputerName endereço verifica uma porta TCP específica. Do mesmo modo, no Linux, nc -zv endereço 443 verifica a porta, independentemente da política de ICMP do destino.
Isso tem efeito direto no monitoramento de servidores: alerta baseado só em ping gera falso positivo em servidor com ICMP bloqueado. Por isso, plataformas maduras combinam o teste ICMP com verificação de porta TCP e checagem de serviço antes de abrir o incidente.
Ping no monitoramento contínuo de infraestrutura
Executado à mão, o ping resolve o diagnóstico pontual. Em operação de TI, o que muda o resultado é o monitoramento contínuo automatizado. Ele mede disponibilidade e latência de cada dispositivo em intervalo fixo, então alerta quando o limiar estoura.
Plataformas como o OpMon (da OpServices) executam essa verificação por ativo e guardam o histórico de RTT e de perda. Em seguida, disparam alerta quando a latência passa do limite e montam o gráfico de tendência que revela degradação gradual antes do incidente.
Coleta contínua responde perguntas que o teste manual não alcança. A latência para o gateway está subindo ao longo do dia? O enlace WAN principal perde pacote fora do horário comercial? Como resultado, essas respostas alimentam o diagnóstico de causa raiz de incidentes intermitentes, que ninguém consegue reproduzir sob demanda.
Vale notar que os testes deste artigo mostram por que o intervalo importa. Uma coleta de 4 pacotes a cada 5 minutos herda a mesma cegueira de 25% demonstrada acima. Em síntese, amostra grande em intervalo curto é o que transforma o ping em sensor confiável de qualidade.
Identificamos gargalos de rede antes que virem incidentes críticos.
Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.
Conclusão
O ping continua sendo o primeiro comando do diagnóstico de rede. Quatro campos da saída carregam a informação que importa: RTT, TTL, perda de pacotes e dispersão. Em suma, ler os quatro corretamente separa o diagnóstico da adivinhação.
Três correções práticas saíram do teste de 2 de setembro de 2026. A subtração do TTL é um piso, não a contagem de saltos. Amplitude entre mínimo e máximo não é jitter: quem mede dispersão é o mdev. Por fim, 4 pacotes não medem perda de um dígito, então use 400.
Entender os limites vale tanto quanto ler os campos. ICMP bloqueado não significa host inacessível. Tampouco o teste manual substitui coleta contínua. Combinado com verificação de porta TCP e monitoramento de aplicação, o ping vira o sensor base da camada de monitoramento em tempo real da infraestrutura.
A OpServices implementa monitoramento contínuo com verificação de disponibilidade, latência, perda de pacotes e alerta proativo em infraestrutura corporativa. Para estruturar o monitoramento da sua rede, fale com nossos especialistas.
Perguntas Frequentes
O que é ping em redes de computadores?
Echo Request a um endereço IP e medir o tempo de resposta (Echo Reply). O RTT (Round Trip Time) resultante indica a latência entre dois pontos da rede. Além da latência, o ping fornece informações sobre TTL, perda de pacotes e dispersão.
O que significa o TTL na saída do ping?
Para que serve o ping -t?
-t mantém o ping enviando pacotes até você interromper com Ctrl+C, em vez dos 4 pacotes do padrão. Serve para acompanhar um enlace instável em tempo real durante o diagnóstico. Para medir perda com número fechado de pacotes, prefira -n 400 no Windows ou -c 400 no Linux: com 4 pacotes a resolução da medida é 25%. Uma perda real de 5% aparece como 0% na maioria das rodadas.
Qual a diferença entre ping e latência?
Por que o ping falha mas o host está online?
Test-NetConnection -Port 443 -ComputerName endereço; no Linux, nc -zv endereço 443.
Como usar o ping para monitorar a infraestrutura de TI?
