Latência, jitter e perda de pacotes: o que cada medida significa

Um resultado rápido de download não garante uma chamada ou um jogo sem travamentos. O tráfego interativo também depende da latência, das variações de latência conhecidas como jitter e da perda de pacotes. Cada um descreve um aspecto diferente da conexão, então meça-os separadamente antes de trocar equipamentos ou culpar um servidor.

Três medidas, três perguntas diferentes

A latência é o tempo que os dados levam para viajar entre dois pontos. O resultado de um ping costuma informar o tempo de ida e volta (RTT): o intervalo entre o envio de uma sonda e o recebimento da resposta. O jitter descreve a variação entre atrasos sucessivos. Respostas que chegam em 20, 21, 90 e 18 milissegundos podem ter uma média aceitável e, mesmo assim, conter um pico que atrapalha. Perda de pacotes significa que uma sonda ou a resposta dela não chegou dentro do limite de tempo do teste. O congestionamento é uma causa possível; a filtragem deliberada do tráfego de diagnóstico é outra.

Essas medidas se influenciam, mas uma não substitui a outra. Um link capaz de transferir um arquivo grande rapidamente pode formar uma fila no roteador durante um upload, atrasando os pacotes curtos usados por uma chamada. Uma única resposta lenta de um roteador intermediário é uma evidência fraca de problema de ponta a ponta: os roteadores podem dar baixa prioridade às respostas ICMP enquanto encaminham o tráfego normal.

Uma sequência prática de testes

Envie uma série de sondas para o mesmo destino usando ping e traceroute. Anote o destino, o horário, o RTT mínimo e máximo e as sondas sem resposta. Repita pela Ethernet ou por outra rede. Faça o teste de velocidade separadamente; taxa de transferência e atraso respondem a perguntas diferentes. Se o Wi-Fi tiver picos que a Ethernet não tem, investigue primeiro a qualidade do sinal, as interferências e os outros dispositivos da rede local.

Mantenha as condições comparáveis: o mesmo servidor, dispositivo, método e horário aproximado. Verifique tanto a conexão ociosa quanto a conexão durante um upload grande. Um grande aumento do RTT sob carga indica formação de filas; só trocar o DNS dificilmente resolverá isso. Vários testes curtos ao longo do tempo são mais úteis do que uma única captura de tela feita durante um pico inexplicado.

Interprete os resultados na aplicação

Não existe um limite universal de jitter que torne bom qualquer jogo ou chamada. As aplicações diferem na forma como armazenam o áudio em buffer, se recuperam de perdas e escolhem os caminhos de rede. Respostas ICMP perdidas não são automaticamente pacotes de mídia perdidos. Se apenas um serviço tem problemas, examine as estatísticas e o status desse próprio serviço. Um rastreamento de rota pode ajudar a localizar um padrão, mas as sondas dele podem seguir um caminho diferente do da aplicação.

A RFC 792 descreve as mensagens ICMP Echo normalmente usadas pelo ping. Ela define o mecanismo, não uma nota de qualidade única para todas as aplicações. Compare resultados repetidos com os sintomas que os usuários realmente percebem.