Redes: Já “fez” um ping a uma máquina? Saiba ler o resultado
Para quem não conhece, o ping é dos comandos mais usados no mundo das redes, uma vez que permite testar a conectividade, ao nível do IP, entre equipamentos. Com esta ferramenta, que pode ser usada em todos os sistemas operativos, conseguimos saber se uma máquina está “viva” na rede.
E o resultado de um ping... sabe o que significa? Se não, nós ajudamos!
O PING (Packet InterNet Groper) é um utilitário presente em quase todos os sistemas operativos que permite saber se uma determinada máquina remota está acessível ou não (descartando as firewalls). Além disso, esta ferramenta pode dar-nos também alguma informação sobre o próprio estado da rede (ex. latência, congestionamento, etc).
O comando ping recorre ao ICMP (protocolo de mensagens de controlo de rede) enviando um pacote específico para uma determinada máquina e espera pela resposta (registando o delay). Este delay é denominado de latência. Em termo de analogia, o ping pode ser comparado ao ping-pong (se enviarmos a bola para um lado (echo request), do outro lado, se estiver lá alguém, vamos receber uma resposta (echo reply).
Como ler o resultado de um ping?
O comando ping disponibiliza ao utilizador várias informações interessantes.
Primeiro a informação se um determinado destino está alcançável. Essa informação é apresentada nas primeiras linhas, onde podemos inclusive saber qual foi o delay da resposta. Como podemos ver na imagem seguinte, no teste que realizamos para o servidor de DNS da Google, o delay foi de 34,641 ms.
O TTL (Time to Live) é o tempo de vida de um pacote e é utilizado para evitar que um pacote circule eternamente na rede. Assim quando o valor TTL de um pacote atinge um determinado valor sem encontrar o destino, esse pacote é descartado.
Por outro lado, em algumas circunstâncias (pode variar, uma vez que o valor pode ser alterado) é possível saber qual o sistema operativo que a máquina que está do outro lado está a utilizar. Para tal, basta estarmos atentos ao campo TTL (Time To Live) e verificar qual o valor. Saber mais aqui.
Na segunda parte do resultado são apresentadas algumas estatísticas. Por exemplo, ficamos a saber que foram enviados 5 pacotes e recebidos 5 pacotes, o que dá 0% de perdas. Poderíamos também concluir (apesar de prematuro) que a rede não está congestionada (é claro que apenas enviamos 5 pacotes e ainda para mais estamos efetuar um ping para uma máquina na rede local).
A segunda parte dos resultados é o RTT – Round Trip Times que nos dá informação de delay mínimo, máximo e também a média de tempos.
Este artigo tem mais de um ano
Eu fiz um pong 🙂
Pedro Pinto,usar diferentes serviços de DNS,sem ser os da operadora,influencia este tipo de testes,ou nem por isso ?? Eu uso os DNS,seja em ipv4 como em ipv6,da Cloudflare.Será que o delay será menor do que se estiver a usar os DNS da operadora ??
Certo. Mas o objetivo é mostrar como se usa o ping e como se lê os resultados.
Ok,muito obrigado. 🙂
Se queres testar Pings experimenta usar endereços de IP ao invés de HOSTNAMES. Mas julgo não haver influência.
Se fosse um Traceroute aí sim o DNS tem influência
Só influencia o tempo até haver o primeiro “ping”. Ou seja, o tempo que demora a resolver o nome (caso este não esteja em cache). Os tempos retornados pelo ping são já todos eles os corretos e não são influenciados pelo DNS. Por isso é que por vezes quando usas o ping o primeiro pacote “demora” até aparecer, porque está a resolver o nome, mas o RTT é o correto.
Outro ponto – verificar se estás a usar IPv4 ou IPv6. Podem seguir caminhos diferentes e com isso resultarem em RTT distintos (apesar de não ser normal).
Para melhores infomações usar o “mtr” em vez do ping. É uma mistura entre o traceroute e o ping.
Pedro, no texto o único exemplo que dás é o Ping para o servidor de DNS da Google (8.8.8.8) mas depois dizes (mais à frente) que apenas fizeste um teste para uma máquina local. (“é claro que apenas enviamos 5 pacotes e ainda para mais estamos efetuar um ping para uma máquina na rede local”).
Sugiro que corrijas para não “enganares” os mais desatentos.
Bom dia, julgo que posso acrescentar uma informação que é bastante útil na análise.
Em caso de sucesso, está tudo bem explicado.
em caso de insucesso existem 2 situações a considerar:
Destination Host unrechable
Request time out
Temos que considerar que existe uma rota até ao host que queremos testar, e outra desde esse host até nós.
No primeiro caso “Destination Host unrechable”, não funciona/existe rota até ao host que queremos testar.
No segundo “Request time out”, lemos que chegou ao host que queremos testar mas o echo não conseguiu regressar até nós.