> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/pt-br/concepts/latency-jitter-packet-loss.md).

# Latência, jitter e perda de pacotes

Os três números que descrevem a qualidade da conexão muito melhor do que a velocidade bruta, o que conta como bom e qual deles estraga qual atividade.

Seu teste de velocidade diz 500 Mbps. Sua chamada de vídeo ainda apresenta falhas. Como as duas coisas podem ser verdade?

Porque velocidade é apenas uma dimensão de uma conexão, e muitas vezes não é a que importa. Outros três números costumam explicar a diferença.

## As três métricas em palavras simples

Imagine enviar uma carta e esperar uma resposta.

**Latência** é o tempo que a ida e volta leva. Você envia, eles respondem, a resposta chega. Medido em milissegundos (ms). Isso é o que um teste de ping informa. Latência baixa significa que a conexão parece responsiva.

**Jitter** é o quanto esse tempo de ida e volta varia. Se as respostas chegam em 20 ms, depois 22 ms, depois 21 ms, a entrega é confiável. Se elas chegam em 20 ms, depois 90 ms, depois 15 ms, há algo inconsistente — mesmo que a média pareça boa. Jitter é o tamanho dessa variação, também em milissegundos.

**Perda de pacotes** é quando cartas simplesmente nunca chegam. Os dados trafegam em pequenos pedaços chamados pacotes, e uma parte deles pode ser perdida no caminho. Medido como porcentagem. Os pedaços perdidos normalmente são reenviados, o que leva tempo; para áudio e vídeo ao vivo não há tempo para reenviar, então a lacuna simplesmente fica audível.

E **largura de banda**, o número que um teste de velocidade destaca, é quanto pode ser transportado de uma vez — quão larga é a estrada, não quão rápido um carro a atravessa.

| Métrica          | Pergunta que responde                     | Unidade | Experiência arruinada                      |
| ---------------- | ----------------------------------------- | ------- | ------------------------------------------ |
| Latência         | Quanto tempo até eu receber uma resposta? | ms      | Tudo parece lento; jogos injogáveis        |
| Jitter           | Quão consistente é o atraso?              | ms      | Chamadas de voz picotadas e robóticas      |
| Perda de pacotes | Quanto nunca chega?                       | %       | Engasgos, travamentos, quedas              |
| Largura de banda | Quanto cabe de uma vez?                   | Mbps    | Downloads lentos; vídeo de baixa qualidade |

## Por que a latência não é velocidade

Esta é a ideia mais útil da página.

Largura de banda e latência são independentes. Um link via satélite pode transportar uma largura de banda enorme enquanto cada ida e volta leva meio segundo, porque o sinal viaja fisicamente até a órbita e volta. Uma conexão doméstica modesta para um servidor próximo pode ter latência muito baixa e largura de banda modesta.

A latência é determinada principalmente por **distância e número de saltos**, e não por quanto você paga. A luz na fibra percorre aproximadamente 200 quilômetros por milissegundo, e cada roteador, cada rede intermediária, cada fila adiciona um pouco mais. Uma ida e volta através de um oceano não pode ser mais rápida do que a física permite, não importa qual plano você compre.

Então fazer upgrade para um plano mais rápido não vai resolver um jogo com atraso em um servidor distante. Isso vai fazer downloads grandes terminarem antes. São problemas diferentes.

## O que é considerado bom

Tenha cuidado com qualquer conjunto único de limites, inclusive estes. O que é aceitável depende muito do que você está fazendo, de quão longe está o outro lado e da tecnologia de conexão que você usa. Uma ida e volta de 60 ms para um servidor em outro continente é excelente; os mesmos 60 ms para um servidor na sua própria cidade sugerem um problema. Conexões móveis e via satélite operam em faixas totalmente diferentes das da fibra.

Com essa ressalva, uma orientação aproximada para uma conexão residencial fixa com um servidor razoavelmente próximo:

|                  | Bom               | Utilizável     | Problemático      |
| ---------------- | ----------------- | -------------- | ----------------- |
| Latência         | abaixo de \~30 ms | \~30–100 ms    | acima de \~150 ms |
| Jitter           | abaixo de \~10 ms | \~10–30 ms     | acima de \~30 ms  |
| Perda de pacotes | 0%                | abaixo de \~1% | acima de \~2–3%   |

Duas coisas importam mais do que os números exatos.

Primeiro, **compare com o seu próprio histórico**. Uma conexão que normalmente mostra 18 ms e hoje mostra 90 ms tem um problema, não importa o que uma tabela diga. Seu próprio ponto de referência é o benchmark mais informativo que você tem.

Segundo, **meça sob carga**. A latência medida em uma conexão ociosa pode parecer excelente e então despencar quando alguém começa um upload — um sintoma chamado bufferbloat, em que filas grandes demais nos equipamentos de rede atrasam tudo o que está atrás de uma transferência grande. A latência medida enquanto a conexão está ocupada é muito mais próxima do que você realmente experimenta.

## De onde o atraso realmente vem

Uma ida e volta não é um único atraso, mas vários, somados.

* **Distância.** A parte inevitável. Os sinais viajam a uma velocidade finita, e as rotas reais de fibra são mais longas do que a linha reta em um mapa.
* **Saltos.** Cada roteador ao longo do caminho leva um instante para inspecionar e encaminhar cada pacote. Um caminho com trinta saltos custa mais do que um caminho com oito.
* **Enfileiramento.** Quando um link está mais ocupado do que consegue atender, os pacotes esperam em uma fila. Este é o maior e mais variável contribuinte em uma conexão congestionada, e a principal fonte de jitter.
* **A última milha.** A tecnologia que conecta seu prédio importa. A fibra acrescenta muito pouco; tecnologias mais antigas de cobre e cabo acrescentam mais; conexões móveis e via satélite acrescentam bem mais.
* **A outra ponta.** O próprio servidor precisa de tempo para pensar antes de responder. Uma aplicação lenta pode parecer exatamente como uma rede lenta.

Só o primeiro desses é fixo. Todo o resto pode ser melhorado — é por isso que uma conexão que está lenta hoje pode estar boa amanhã sem nada mudar do seu lado.

## O que cada um estraga

**Jogos são destruídos pela latência, depois pela perda de pacotes.** Jogos competitivos precisam que sua entrada chegue ao servidor e que o resultado volte antes que o momento passe. Largura de banda é quase irrelevante — jogos enviam quantidades minúsculas de dados. É por isso que um jogador em uma conexão modesta e próxima do servidor vence um jogador em uma conexão muito rápida, mas distante. A perda de pacotes aparece como rubber-banding, quando as coisas voltam para onde estavam.

**Chamadas de voz e vídeo são destruídas pelo jitter, depois pela perda de pacotes.** O áudio precisa ser reproduzido em um ritmo constante. Os aplicativos mantêm um pequeno buffer para absorver a variação, mas se as chegadas forem erráticas o suficiente, o buffer esvazia e você obtém aquela voz robótica e picotada tão familiar. Pacotes perdidos não podem ser reenviados a tempo, então se tornam breves silêncios. Chamadas precisam de uma largura de banda surpreendentemente pequena, e é por isso que falham em conexões que testam como rápidas. Veja [O que é WebRTC?](/knowledge-base/pt-br/concepts/what-is-webrtc.md).

**Streaming de vídeo é destruído pela largura de banda, e só é levemente incomodado pela latência.** Um player de vídeo armazena vários segundos à frente, então absorve facilmente jitter e latência moderada. O que ele não consegue absorver é largura de banda insuficiente: ele reduz a qualidade e, se a situação piora, para para rebufferizar. Alguns segundos extras para iniciar são um sintoma de latência; uma imagem que fica borrada no meio da cena é um sintoma de largura de banda.

**A navegação comum na web é, em grande parte, um problema de latência.** Uma página carrega dezenas de recursos separados, cada um precisando de uma solicitação e uma resposta. A latência é paga repetidamente, então uma conexão de alta latência parece lenta mesmo quando a largura de banda bruta é abundante. Acima de cerca de 50 Mbps, largura de banda extra mal muda a sensação de rapidez das páginas.

## Equívocos comuns

**"Mais Mbps resolve o lag."** Não resolve. Lag é latência. Largura de banda e latência são propriedades separadas do caminho.

**"É necessário zero perda de pacotes."** Perdas ocasionais são normais e invisíveis. Perda consistente acima de um ou dois por cento é o que degrada as coisas — e perda que aparece apenas em um salto no traceroute muitas vezes é o roteador dando menor prioridade às próprias respostas, não uma perda real afetando seu tráfego.

**"Um único teste me diz a qualidade da minha conexão."** Uma medição é um instantâneo de um momento em um caminho. Repita, em horários diferentes, para destinos diferentes, antes de tirar qualquer conclusão.

**"Ping alto para um site significa que minha conexão é ruim."** Pode significar que aquele site fica longe, ou que uma rota está congestionada. Testar vários destinos separa um problema local de um problema de caminho.

{% hint style="info" %}
**Veja você mesmo no MyIP**

O [Teste de velocidade](/knowledge-base/pt-br/network-tests/speed-test.md) mostra mais do que números de download e upload: também exibe latência, jitter e latência medida *enquanto a conexão está carregada* — e então traduz tudo isso em pontuações de qualidade para streaming de vídeo, jogos e videochamadas. Essa última linha é o objetivo desta página em um único olhar.

Para ver como esses números mudam com a distância, o [Teste Global de Latência](/knowledge-base/pt-br/network-tests/global-latency-test.md) faz ping no seu endereço a partir de sondas ao redor do mundo. E, quando uma rota específica parece ruim, o [Teste MTR](/knowledge-base/pt-br/network-tests/mtr-test.md) divide o caminho em saltos e informa a latência e a perda em cada um, para que você veja onde o problema começa.
{% endhint %}

## Conceitos relacionados

* [O que é um ASN?](/knowledge-base/pt-br/concepts/what-is-an-asn.md) — por que a rota entre redes decide sua latência
* [O que é WebRTC?](/knowledge-base/pt-br/concepts/what-is-webrtc.md) — por que as chamadas são tão sensíveis ao jitter
* [Endereços Públicos, Privados e CGNAT](/knowledge-base/pt-br/concepts/public-private-cgnat.md) — saltos extras entre você e a internet
* [Por que minha internet está lenta?](/knowledge-base/pt-br/diagnose/why-is-my-internet-slow.md) — um diagnóstico passo a passo


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/pt-br/concepts/latency-jitter-packet-loss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.