sábado, 4 de maio de 2013

Interpretação dos Resultados do Ping

Olá Pessoal.

Esse é mais um artigo que escrevo atendendo a pedido dos leitores do blog. Existem várias ferramentas de monitoramento de redes no mercado, sendo que todas elas, de alguma forma, retornam algumas métricas importantes de desempenho em redes, tais como: vazão em bps, latência (atraso), jitter (variação da latência no tempo), etc. A mais comum de todas essas ferramentas e que certamente faz parte da vida cotidiana de TODO profissional de redes é o "bom e velho" ping - presente em praticamente todas as caixas e sistemas operacionais!

Apesar de parecer simples, o ping vai MUITO além de simplesmente confirmar se há comunicação com um host remoto qualquer - ele também traz alguns valores importantes para determinar o desempenho de uma rede. Para cada linha de resposta echo-reply do ICMP (protocolo utilizado por trás do ping) ele traz o valor do atraso fim-a-fim na comunicação (latência), conforme pode ser observado no primeiro destaque em vermelho da figura abaixo.

Também ao final da sequência de respostas ele traz um resumo estatístico com os valores mais baixo, médio e alto da latência nos parâmetros rtt min/avg/max. Ele ainda mostra qual foi a porcentagem de perda de pacotes que, normalmente, não deve exceder 2%. Valores de perda de pacotes acima de 5% são indicativos de que está havendo algum problema na rede, que pode ser desde o cabeamento até a aplicação em si! É importante destacar que no Linux ele calcula o jitter (parâmetro denominado mdev no ping). Essas informações podem ser observadas no segundo destaque em vermelho da figura abaixo.


Não existe um valor único de latência que seja referência para todas as redes, por isso estarei mostrando alguns valores referenciais aceitáveis para algumas das tecnologias mais comuns que são: (1) Rede Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância Privativo.

1) Em redes locais cabeadas a comunicação deve ter excelente desempenho, haja vista a proximidade entre os dispositivos e a boa qualidade da infraestrutura de cabeamento de propriedade da empresa. É esperado que a latência em redes locais não ultrapasse 10ms (recomendado) ou é tolerável até 30ms (não recomendado). Quanto mais dispositivos intermediários existirem entre duas máquinas, naturalmente maior será essa latência porque cada dispositivo intermediário terá algum mecanismos de tratamento dos quadros;

2) Um valor ideal de latência para links de Internet via Cable Modem seria algo entre 30ms e 50ms. No entanto a arquitetura da rede é compartilhada através de barramentos nas vizinhanças e a rede tende a sofrer mais com instabilidade em momentos de muito acesso, o que pode implicar em latências maiores que 100ms; 

3) A latência ideal para a tecnologia xDSL seria algo em torno de 70ms. O que acontece é que essa tecnologia é muito popular porque aproveita a infraestrutura de cabeamento da rede telefônica, motivo pelo qual muitas operadoras acabam vendendo mais conexões do que suas centrais suportam. Essa situação pode implicar em latências de 100ms ou mais, o que é comum de acontecer no Brasil;

4) A conexão discada naturalmente é aquela que apresenta pior desempenho porque utiliza a rede pública de telefonia comutada (PSTN) através da modulação do sinal digital do computador em sinal analógico (audio), ou seja, simplificando, conversão dos dados em som. Por isso a latência dessa tecnologia pode facilmente ser bem superior a 250ms;

5) Os links de longa distância privativos mais profissionais, ou seja, aqueles normalmente utilizados pelas empresas devem apresentar excelente desempenho. Normalmente os contratos desses links têm cláusulas de SLA em que a operadora se compromete a entregar uma qualidade mínima com base em parêmetos pré-definidos. Normalmente esses links também não devem exceder 10ms (recomendado), mas pode ser tolerável latência de até 20ms ou 30ms (dependendo do contrato); 

Lembrem-se de que essas informações são referenciais, ou seja, nenhum desses valores deve ser aceito como REGRA! Há outros fatores que vão interferir diretamente na latência, principalmente quando pensamos em links de longa distância. Por exemplo, em situação ideal o sinal percorre um cabo metálico a aproximados 200.000 km/s (quase 2/3 da velocidade da luz). Isso quer dizer que você terá resultados diferentes na sua empresa se pingar um servidor localizado no Brasil e outro na China! ;-) Por isso antes de verificar o desempenho da rede é necessário estabelecer os critérios que serão utilizados para fazê-lo, criando uma metodologia homogênea que não interfira nos resultados!

Outro detalhe importante é que vejo as pessoas testando a velocidade da conexão de Internet em casa e sempre muito preocupadas com a tal largura de banda ou taxa de transmissão (em bps), no entanto tão importante quanto a largura de banda é a latência. Por exemplo, vamos pensar na seguinte situação:

Cenário 1: Ana contratou uma Internet xDSL de 25M
- Teste de Desempenho: Taxa de Transmissão de 19M; Latência de 190ms;

Cenário 2: Beto contratou Internet Cable de 10M
- Teste de Desempenho: Taxa de Transmissão de 8M; Latência de 60ms;

Na sua opinião qual dos dois cenários é melhor?
A resposta correta é: Cenário 2

Acontece que mesmo a Ana tendo mais largura de banda para acessar mais informação, o estado do link está MUITO pior do que o do Beto que possui menos da metade da largura de banda. No entanto, o retorno das requisições de Beto será muito mais rápido do que da Ana. É isso que explica porque um link de 2M na empresa em que você trabalha tende a ter desempenho muito melhor do que a Internet de 10M da sua casa!!! As latências dos links de longa distância privativos são muito menores do que as latências das conexões residencias!  

Compreenderam? Espero que sim... 

O jitter, por exemplo, é uma métrica extremamente importante para ambientes que possuem aplicações multimídia de "tempo real", como voz e vídeo. Os administradores de ambientes que possuem essas aplicações devem sempre estar atentos não somente à latência que representa o atraso na entrega dos pacotes, mas principalmente ao jitter. A latência mostra o desempenho real da rede naquele exato momento, enquanto que o jitter mostra seu comportamento ao longo do tempo, ou seja, define o grau de estabilidade da rede.

Pegando o exemplo do ping da figura acima que apresenta jitter de 15ms, esse seria um valor alto para uma rede local cabeada (ethernet), mas é um valor comum em redes sem fio pela própria natureza mutável do ambiente. Lembrem-se que as comunicações sem fio estão sujeitas a interferência de vários fatores externos, por isso o sinal tende a oscilar com maior frequência - o que as faz mais instáveis do que as redes cabeadas.

Uma evidência prática de que o jitter é ainda mais prejudicial para aplicações multimídia do que a própria latência é que normalmente o recurso comumente utilizado para minimizar o efeito do jitter consiste na utilização de buffers (pequenas memórias eletrônicas) nos dispositivos para armazenar os pacotes e, somente então, entregá-los "sem" jitter ao usuário, conforme pode ser observado na figura abaixo.


O problema é que essa "solução" implica no aumento da latência, o que mostra a preferência pelo aumento na latência se houver diminuição do jitter. Obviamente que o alinhamento dessas duas métricas (latência e jitter) acaba sendo um exercício de balança e o bom senso é fundamental para assegurar o bom desempenho das aplicações. De nada adianta eliminar totalmente o jitter se a latência ficar muito alta. O valor ideal do jitter vai variar em função da latência do link.

Por exemplo, no contexto de um link de longa distância xDSL (acesso à Internet) que tem em média de 50ms a 100ms, um jitter de até 15ms ou 30ms pode ser aceitável. Por outro lado, no contexto de uma rede local em que a latência máxima é 10ms, esses valores seriam inaceitáveis - principalmente se existirem aplicações multimídia de "tempo real".

A gente costuma utilizar como medidas de referência para latência em aplicações multimídia o limite de até 150ms para bom desempenho (recomendado) e valores entre 151ms até 400ms para desempenho tolerável (não recomendado), sendo que qualquer valor acima de 400ms é INACEITÁVEL!!!


Quem diria que uma ferramenta tão simples quanto o ping seria na realidade tão poderosa, não é mesmo? ;-) Esse é um dos motivos de eu sempre dizer aos meus alunos que na área de networking é crucial entrender os fundamentos por trás da tencologias, muito mais até do que saber operacionalizar. O ideal é "casar" as duas coisas: fundamento e prática!

Espero que esse artigo seja útil não apenas no dia-a-dia de vocês, mas principalmente no sentido de "abrir a mente" para a necessidade do profissional dessa área conhecer os fundamentos daquilo que está operacionalizando!

Abraço.

Samuel.

24 comentários:

  1. Ótimo post,

    O resultado numérico de ferramentas de monitoramento de rede são apenas números sem o devido conhecimento para interpretar os resultados. Esse post irá ajudar muitas pessoas que trabalham no dia-a-dia com monitoramente de redes.

    Parabéns,

    Filipe

    ResponderExcluir
    Respostas
    1. A proposta do artigo era exatamente essa, a de ajudar os profissionais que trabalham com redes no dia-a-dia e que precisam interpretar os resultados de um monitoramento. Fico satisfeito e realmente espero que o artigo seja útil para muitos dos leitores do blog.

      Excluir
  2. Ótima explicação.

    Excelente,

    Fabricio Cruz

    ResponderExcluir
  3. Interessante um curso de redes online com todos esses datalhes mostrados em teoria e prática? Já pensou nisso professor Samuel?

    ResponderExcluir
    Respostas
    1. Já me fizeram essa sugestão algumas vezes, no entanto a gravação das aulas consome muito tempo. Ultimamente estou com pouco tempo disponível porque estou tocando vários projetos paralelos... Abraço!

      Excluir
  4. Olá professor, qual a bibliografia usou ou que recomenda para estudar mais sobre esses assuntos desse excelente texto?

    Queria estudar mais principalmente sobre a latência que que referiu das seguintes tecnologias: "1) Rede Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância Privativo"

    Grato

    ResponderExcluir
    Respostas
    1. Eu gosto bastante dos livros da Cisco Press porque eles são bem focados e específicos na sua proposta. Por isso os livros de QoS da Cisco Press trazem uma boa abordagem desse contexto. Dois títulos que eu sugeriria são:

      > IP Quality of Service
      Autoria: Srinivas Raju Vegesna

      > End-to-End QoS Network Design: QoS in LANs, WANs, and VPNs
      Autoria: Tim Szigeti, Christina Hattingh

      Excluir
    2. Samuel, parabens pelo blog! Estou gostando muito. Inclusive adquiri seus dois livros. Quanto ao (5) links de longa Dist Privativo se inclue o ATM?
      Quanto aos dois livros, tem tradução para portugues?

      Excluir
    3. Olá Martony.

      Agradeço pelo feedback positivo. A tecnologia ATM normalmente implica em latências ainda menores porque possui backbone óptico com circuitos OC (Optical Carrier), lembrando que a latência varia em função da distância. Imagino que você esteja se referindo aos livros de QoS que mencionei em meu comentário anterior... Nesse caso, a resposta é que desconheço qualquer tradução desses livros.

      Continue acompanhando o blog!

      Abraço.

      Excluir
  5. Oi Samuel bom dia,
    Muito bom seu post, mas tenho alguma dúvida:
    Porque quando eu pingo o meu roteador com tamanho de buffer em 19232 vai ok, mas em 19233 causa "esgotado tempo limite" ?

    C:\Documents and Settings\mori>ping -t 192.168.1.1 -l 19233
    Disparando contra 192.168.1.1 com 19233 bytes de dados:
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Estat¡sticas do Ping para 192.168.1.1:
    Pacotes: Enviados = 5, Recebidos = 0, Perdidos = 5 (100% de perda),
    Control-C
    ^C
    C:\Documents and Settings\mori>ping -t 192.168.1.1 -l 19232
    Disparando contra 192.168.1.1 com 19232 bytes de dados:
    Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
    Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
    Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
    Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
    Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64

    Estat¡sticas do Ping para 192.168.1.1:
    Pacotes: Enviados = 5, Recebidos = 5, Perdidos = 0 (0% de perda),
    Aproximar um n£mero redondo de vezes em milissegundos:
    M¡nimo = 4ms, M ximo = 4ms, M‚dia = 4ms
    Control-C
    ^C
    C:\Documents and Settings\mori>

    grato e abraços,
    Morikawa

    ResponderExcluir
    Respostas
    1. Olá Morikawa,

      O tamanho máximo do pacote IPv4 é 65535 bytes e o limite permitido no parâmetro size/lenght do ping é 65500. É provável que haja alguma regra de firewall pré-configurada no seu roteador que esteja limitando esse parâmetro a 19232.

      Abraço.

      Excluir
  6. Só um detalhe sobre a medição do jitter do meu ponto de vista: Se você usar PINGs para medição de jitter então você medirá algo completamente diferente do que a maioria das pessoas querem dizer quando falam sobre "Jitter" para a Qualidade de Serviço (que é usado principalmente para medir a qualidade da linha de dados para VoIP ou Vídeo).

    Por favor, considerem os seguintes três aspectos que explicam a comparação entre a solução de medição de jitter” PING” e “PRTG Network Monitor” do sensor de QoS:

    PINGs usam pacotes ICMP e muitos roteadores / switches dão a estes uma prioridade mais baixa.
    Ao utilizar PINGs e medi-los em um ponto, o que você realmente está medindo é o tempo que o pacotes vai e volta (sensor QoS do PRTG por outro lado só envia os pacotes em uma direção e as medidas de tempo de viagem "one-way")

    VoIP e vídeo na maioria dos casos, usam pacotes UDP no qual roteadores / switches são susceptíveis a dar uma prioridade maior. Essa é a razão pela qual sensor de QoS do PRTG usa UDP para medir jitter etc .
    Ps: As palavras acima foram retiradas de um site em Ingles que nao me recordo a muito tempo e que debatiam sobre o mesmo assunto, achei interessante compartilha-las aqui! Só para incrementar o ótimo texto =D
    No caso seria melhor utilizar ferramentas que gerem pacotes UDP para calcular o jitter real.

    ResponderExcluir
    Respostas
    1. Não existem diferentes formas de jitter que, por definição, é a variação na latência da entrega de pacotes. Nesse sentido, seu comentário está incorreto ao dizer que medir o jitter pelo ping é algo completamente diferente do que a maioria das pessoas querem dizer. Se a rede não possui nenhuma priorização de tráfego configurada (QoS), então a medição pelo ping é válida porque existe somente um perfil de tŕafego para todo o ambiente. O ping é apenas mais uma ferramenta, obviamente que nem sempre a malhor...

      No entanto, sua observação está correta quando diz que medir o jitter através do ping pode ser um problema em redes que tenham QoS configurado para priorizar determinado perfil de tráfego. Isso porque é possível que o tráfego ICMP não seja priorizado e o resultado disso é uma interferência direta nos resultados na medição, uma vez que outros perfis de tráfego provavelmente tenham sido priorizados em detrimento do ICMP, o que impactaria negativamente na fidelidade da medição.

      Isso é natural, da mesma forma que a medição pelo ping sequer será possível em redes que tenham regras de firewall bloqueando o ICMP. Repare que o artigo em questão não entrou no mérito da existência dessas configurações, justamente para que o processo de medição seja válido. Em toda rede que possui VoIP e/ou outros tipos de aplicações multimídia é fortemente recomendada a configuração de QoS para definir diferentes perfis de tráfego e priorizar aqueles de tempo real (sensíveis e latência e jitter), por isso é importante fazer os testes com base no mesmo perfil de tráfego desejado para não comprometer os resultados.

      Aproveitando o gancho, o software PBX IP da Cisco (CUCM) já possui embutido nele ferramentas para medição de jitter via UDP e o administrador pode visualizar essas informações através de comandos "show" no próprio roteador. Por exemplo, o administrador pode visualizar o status das chamadas/sessões ativas entre dois telefones e checar o resultado do jitter referente àquela chamada específica, o que é muito útil.

      Certamente sua observação pode foi/será a dúvida de outros leitores, agradeço pela comentário.

      Abraço.

      Excluir
  7. Parabéns.. Otimo texto.
    Gostaria só de acrescentar uma dica que também conseguimos através do PING, que é identificar o Sistema Operacional pelo TTL ( time to live) Todo sistema operacional possui um padrão de retorno, que é em UNIX 255, Linux 64,Windows 128. Isso Ja me ajudou em alguns casos de suporte e pode ser util.

    ResponderExcluir
  8. Olá Samuel, estou como uma duvida, como eu faria para resolver esta questão?
    Qual é a formula?

    2) Qual seria a taxa real de transmissão (bps) através de uma rede que, após um teste com o comando PING no servidor, obteve-se os seguintes resultados: (Dica: 1ms = 0,001s)
    C:\PING 10.0.160.208
    Disparando contra 10.0.160.208
    Resposta de 10.0.160.208: Bytes=32 tempo = 9ms
    Resposta de 10.0.160.208: Bytes=32 tempo = 7ms
    Resposta de 10.0.160.208: Bytes=32 tempo = 6ms
    Resposta de 10.0.160.208: Bytes=32 tempo = 7ms

    Estatísticas do PING para 10.0.160.208:
    Pacotes enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda),
    Aproximar um número redondo de vezes em milissegundos:
    Mínimo = 6, Máximo = 9, Média = 7

    ResponderExcluir
    Respostas
    1. O ping isoladamente não vai te ajudar e determinar a vazão da sua rede em bps, uma vez que ele utiliza as mensagens "echo request" e "echo reply" para determinar a latência na comunicação entre dois hosts. Para ajudá-lo, recomendo a leitura de outro artigo no blog:

      http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html

      Excluir
    2. não consigo add esse servido no meu celular não pq?

      Excluir
  9. Artigo sucinto e direto.

    Parabéns!

    ResponderExcluir
  10. Este site é excelente para estudo de T.I.,pois,ajuda o estudante de T.I. a tirar suas próprias conclusões,nos dando grande campo de visão e estimulando de um modo elegante,ao estudante a ter grande interesse na matéria T.I..Parabéns!

    ResponderExcluir
  11. Muito bacana a postagem e os comentários!

    ResponderExcluir
  12. ping em todos os sites sao iguais ?? me expliquem

    ResponderExcluir
  13. "vazão em bps, latência (atraso), jitter (variação da latência no tempo)" quais ferramentas realizam essas operações?

    o cisco packet tracer tambem monitora a rede simulada e devolve essas informaçoes para o usuario?

    ResponderExcluir
  14. professor, bom dia,
    num cenário simples, qual é a ferramente utilizada mais comumente para se medir o Jitter de links de internet? ele serve também para algum tipo de medição em uma rede privada?

    ResponderExcluir