Latência de rede explicada: para onde vão os milissegundos

A latência de rede é o tempo que um pacote demora a chegar ao destino e a voltar, ou seja, o tempo de ida e volta (RTT), em milissegundos. Compõem-na quatro coisas: a distância que o sinal percorre, a rota que as redes escolhem, as filas em que espera e as idas e voltas que os protocolos das camadas superiores acrescentam. Só a primeira é imposta pela física. Este guia analisa cada uma, por ordem, com medições reais feitas a partir dos nossos servidores em Falkenstein (Alemanha) e Gravelines (França) a 7 de outubro de 2026.

De que é feita uma ida e volta

Componente	O que é	Valor típico
Propagação	A luz na fibra ótica viaja a cerca de 200.000 km/s, dois terços da sua velocidade no vácuo: 1 ms de ida e volta por cada 100 km de cabo	Menos de 1 ms numa cidade, 60 a 90 ms através do Atlântico, 160 ms ou mais até ao outro lado do mundo
Serialização	Pôr os bits de um pacote na linha: 1.500 bytes levam 12 µs a 1 Gbit/s	Desprezável, exceto em ligações lentas: 1,2 ms por pacote completo a 10 Mbit/s
Filas de espera	A espera no buffer de um router ou de um modem quando uma ligação está ocupada	Zero num caminho sem carga, centenas de milissegundos quando um buffer enche
Processamento	O router a decidir para onde enviar o pacote	Microssegundos no hardware atual

É comum pensar-se que «cada salto acrescenta alguns milissegundos». Não é assim: encaminhar um pacote demora microssegundos. Quando os tempos de um traceroute crescem de um salto para o seguinte, é a distância, ou uma fila, ou o router a demorar a responder à sonda enquanto encaminha todo o resto à velocidade máxima.

A distância impõe um mínimo

A ida e volta mais curta possível corresponde à distância pelo círculo máximo, percorrida à velocidade da luz na fibra. Os cabos reais nunca seguem o círculo máximo, e as rotas reais raramente usam o cabo mais curto. Eis quão longe desse mínimo ficaram as nossas medições (média de 60 a 100 sondas por destino, com o mtr):

De → para	Distância	Mínimo em fibra	Medido	Rácio
Gravelines → Cloudflare 1.1.1.1 (Paris)	237 km	2,4 ms	4,9 ms	2,0×
Falkenstein → Cloudflare 1.1.1.1 (Frankfurt)	265 km	2,6 ms	5,9 ms	2,3×
Gravelines → Nova Jérsia	5.779 km	57,8 ms	71,7 ms	1,2×
Falkenstein → Nova Jérsia	6.462 km	64,6 ms	86,4 ms	1,3×
Falkenstein → Singapura	9.994 km	99,9 ms	165,5 ms	1,7×
Falkenstein → Tóquio	9.134 km	91,3 ms	273,6 ms	3,0×
Falkenstein → Sydney	16.220 km	162,2 ms	341,2 ms	2,1×

Em distâncias curtas, dominam os custos fixos (o equipamento, os últimos metros de cablagem, o tempo que o destino demora a responder), e o rácio parece mau, embora os valores absolutos sejam ínfimos. Em distâncias longas, o que conta é a rota. Para Tóquio, a latência é o triplo do mínimo porque os pacotes não vão para lá diretamente: o rastreio sai da Europa pela rede da Arelion, chega a Singapura aos 169 ms e depois a Tóquio, aos 246 ms. No nosso estudo da latência cloud a partir de 33 cidades, de Joanesburgo a São Paulo foram precisos 351 ms no melhor dos casos, para um mínimo de 74 ms: os pacotes passaram pela Europa.

O mesmo destino, duas rotas

O mesmo host da Vultr em Nova Jérsia, medido no mesmo minuto a partir dos nossos dois servidores:

A partir de Falkenstein (Hetzner, AS24940)
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

A partir de Gravelines (OVHcloud, AS16276)
 10. AS16276  be102.lon-drch-sbb1-nc5.uk.eu         1.0%   100    3.8   3.7   3.5   4.1   0.1
 11. AS16276  nyc-ny1-sbb2-8k.nj.us                 0.0%   100   73.0  73.4  71.6  76.0   0.8
 13. AS???    nyiix.gi3-6.cr1.nyc1.choopa.net       0.0%   100   72.7  72.5  72.3  73.0   0.1
 17. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   71.7  71.7  71.5  73.0   0.2

Dos 14,7 ms de diferença, só metade se deve à distância (os mínimos diferem 6,8 ms). O resto é a rota: a partir de Gravelines, a OVH transporta o tráfego na sua própria rede, via Londres, até Nova Iorque e entrega-o à Vultr no NYIIX, um ponto de troca de tráfego de Nova Iorque; a partir de Falkenstein, a Hetzner entrega-o à Core-Backbone em Nuremberga, que atravessa o Atlântico. Escolher um alojamento, ou um fornecedor, é também escolher as respetivas rotas.

Filas de espera: a latência que vai e vem

A propagação não muda. As filas, sim. Nos caminhos acima, sem carga, a dispersão nos destinos ficou entre 0,1 e 2,1 ms em 100 sondas. Numa ligação doméstica, um único upload grande pode encher o buffer do modem e acrescentar centenas de milissegundos a tudo o resto: é o bufferbloat.

Para o testar, execute ping 1.1.1.1 e, enquanto decorre, inicie um upload grande e depois um download grande. Se os tempos subirem de 15 ms para 200 ms ou mais e voltarem a descer quando a transferência terminar, o problema é o buffer. A solução está no router: gestão inteligente de filas (fq_codel ou CAKE, disponíveis no OpenWrt e em muitos routers recentes), ou limitar o débito da ligação um pouco abaixo da velocidade nominal.

Os protocolos multiplicam as idas e voltas

Uma nova ligação HTTPS paga várias idas e voltas antes de chegar o primeiro byte da página: uma consulta DNS, se o nome não estiver em cache, uma para o handshake TCP, uma para o TLS 1.3 (duas para o TLS 1.2) e uma para o próprio pedido. Contando quatro:

Ida e volta	4 idas e voltas
6 ms (um servidor próximo)	24 ms
86 ms (da Alemanha a Nova Jérsia)	344 ms
341 ms (da Alemanha a Sydney)	1,4 s

A mesma aritmética aplica-se a tudo o que é sequencial: uma aplicação que faz 20 consultas, uma após a outra, a uma base de dados a 80 ms de distância espera 1,6 segundos. O HTTP/2 e o HTTP/3 reutilizam ligações, o TLS 1.3 e o QUIC encurtam os handshakes, e menos pedidos sequenciais reduzem o resto.

Quanto é demasiado

Utilização	Confortável	Percetível
Chamadas de voz e vídeo	Menos de 150 ms num só sentido, a recomendação ITU-T G.114	Acima disso, as pessoas começam a falar umas por cima das outras
Jogos online rápidos	Abaixo de uns 50 ms de ida e volta	Acima de 100 ms, a maioria dos jogadores sente-o
Páginas web e APIs	Depende do número de idas e voltas sequenciais	Cada ida e volta a mais soma-se ao tempo até ao primeiro byte

Meça por si

• ping -c 20 host: o mínimo é o seu limite inferior nesse caminho, a média a sua latência habitual e o mdev o jitter.
• mtr -rwz -c 100 host: em que ponto do caminho se acrescenta o tempo (veja como ler um relatório mtr).
• A partir de vários locais: o nosso teste de latência cloud mede a latência do seu navegador até 36 regiões da AWS, OVHcloud, Vultr e Akamai, e o TraceMapper rastreia a mesma rota a partir de mais de 30 locais.

O que pode mudar e o que não pode

• Distância: só aproximando o servidor dos utilizadores, ou acrescentando uma região ou uma CDN. No nosso estudo de 33 cidades, Frankfurt, sozinha, servia 14 cidades em menos de 100 ms; Frankfurt e Singapura em conjunto, 27.
• Rota: escolhendo um fornecedor cuja rede e cujo peering se adequem aos seus utilizadores. Não pode mudar a política de roteamento de outra rede.
• Filas: gestão inteligente de filas em casa e, num centro de dados, não pôr as ligações a 100%.
• Idas e voltas: reutilização de ligações, TLS 1.3, cache de DNS, menos chamadas sequenciais.

Para a parte prática, veja como reduzir a latência de rede.