Latência e ping: por que a localização do servidor importa

Você clica em um botão e nada acontece por meio segundo. A conexão não está lenta no sentido de "poucos megabits": o pedido simplesmente leva tempo para chegar ao servidor e voltar. Esse tempo é a latência, e ela é o motivo de um bot responder com atraso ou de uma página abrir devagar mesmo em fibra de 500 Mbps.

Latência é diferente de banda. Banda diz quanto cabe no cano por segundo, latência diz quanto tempo uma gota leva para atravessá-lo. Para sites, APIs e bots, que trocam muitas mensagens pequenas, a latência costuma pesar mais do que a banda.

O que é latência e o que é ping?#

Segundo a MDN, latência é o tempo que um pacote de dados leva para ir da origem ao destino. Na prática, ela quase sempre é medida de ida e volta (RTT, round-trip time): o tempo entre sair a requisição e chegar a resposta.

O ping é a ferramenta mais comum para medir isso. Ele envia uma mensagem ICMP de "echo request" e espera o "echo reply". O número que aparece, em milissegundos (ms), é o RTT até aquele endereço.

ping -c 4 example.com

O ping mede só a rede até o servidor. Ele não inclui TLS, nem o tempo que sua aplicação gasta para montar a resposta. Alguns servidores também bloqueiam ICMP, então um ping sem resposta não prova que o servidor está fora do ar. No Windows, a opção é -n 4 em vez de -c 4.

Por que a distância impõe um piso de latência?#

Nenhum sinal viaja mais rápido que a luz. Na fibra, a luz é mais lenta que no vácuo: com índice de refração perto de 1,5, o atraso é de cerca de 5 µs por quilômetro, segundo a Wikipedia (no vácuo seriam 3,33 µs por km).

Isso dá uma conta simples de piso. São Paulo fica a cerca de 7.700 km de Nova York em linha reta:

• 7.700 km x 5 µs = 38,5 ms só na ida
• Ida e volta: cerca de 77 ms, no melhor caso teórico

Os cabos reais não seguem linha reta e passam por roteadores, então o valor medido é maior. Nenhuma otimização de código passa abaixo desse piso. Por isso a localização do servidor em relação aos seus usuários é a primeira decisão, e a mais difícil de desfazer depois.

O que compõe a latência de uma requisição web?#

Uma única requisição HTTPS a um site novo para você passa por várias etapas, cada uma com pelo menos uma ida e volta:

1. DNS: descobrir o IP do domínio (veja o que é DNS).
2. Conexão TCP: o handshake para abrir o canal.
3. TLS: a negociação da conexão segura.
4. Requisição e espera: o servidor recebe, processa e começa a responder.
5. Download: a resposta chega, e o tempo depende da banda e do tamanho do arquivo.

A MDN destaca que na primeira requisição a latência é maior justamente por somar DNS, TCP e TLS, e que as requisições seguintes ficam mais rápidas porque a conexão já está aberta. Por isso reaproveitar conexões (keep-alive, HTTP/2, HTTP/3) ajuda tanto.

A soma disso até o primeiro byte é o TTFB. O web.dev considera um TTFB de até 0,8 s como bom e acima de 1,8 s como ruim, como guia aproximado, e lembra que ele inclui redirecionamentos, DNS, conexão, TLS e a espera pela resposta.

Como medir a latência de cada etapa com curl?#

O curl consegue separar os tempos com -w. Esse comando funciona em Linux, macOS e no Git Bash do Windows:

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconexao: %{time_connect}s\ntls: %{time_appconnect}s\nprimeiro byte: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

Os valores são acumulados desde o início. Para achar o tempo de cada etapa, subtraia o valor anterior:

• time_connect - time_namelookup é o handshake TCP, aproximadamente uma ida e volta até o servidor.
• time_appconnect - time_connect é o TLS.
• time_starttransfer - time_appconnect é a requisição mais o processamento do servidor.

Se a conexão TCP já leva dezenas de ms, o gargalo é distância. Se o TCP é rápido e o intervalo até o primeiro byte é grande, o gargalo está no código ou no banco de dados do servidor, e mover o servidor não resolve.

Como reduzir a latência?#

Em ordem de impacto, para a maioria dos projetos:

• Aproxime o servidor dos usuários. É a única forma de baixar o piso físico.
• Aproxime os componentes entre si. Um app que faz 10 consultas ao banco paga 10 idas e voltas. Banco e aplicação na mesma região tornam isso quase irrelevante, e distantes multiplicam o atraso.
• Use CDN para o que é cacheável. Imagens, CSS e JS saem de um ponto próximo do visitante. Veja o que é uma CDN.
• Reduza o número de idas e voltas. Menos redirecionamentos, menos domínios diferentes, conexões reaproveitadas, consultas agrupadas.
• Distribua a carga. Vários servidores atrás de um load balancer tiram a fila de espera, embora não diminuam a distância.
• Meça de onde seus usuários estão. O ping do seu computador só vale para o seu computador.

Quando a latência importa mais?#

Aplicações que trocam mensagens o tempo todo sofrem mais: jogos, chamadas de voz, bots de Discord com comandos interativos, painéis em tempo real. Um site estático com cache sofre menos. Já um backend que faz várias chamadas sequenciais a outros serviços sente cada ida e volta somada.

Vale também separar latência de jitter, que é a variação do atraso de um pacote para o outro. Latência média baixa com jitter alto ainda gera travadas em voz e vídeo.

Como fazer isso na Square Cloud#

Na Square Cloud, as aplicações rodam em containers isolados num datacenter Tier 3 parceiro em Nova York (Telehouse). Na frente delas fica uma CDN Anycast com mais de 200 pontos de presença, HTTP/3 e WebSockets.

Dois números ajudam a planejar. Um bot de Discord hospedado na Square Cloud tem latência média de cerca de 30 ms até o Gateway do Discord. Já a hospedagem de bancos de dados, a partir do plano Standard, provisiona o banco no mesmo datacenter das suas aplicações, com cerca de 1 ms de latência média, o que torna baratas as consultas em sequência. Esses são valores médios observados, não garantias.

Se um único servidor não basta, o load balancing permite servir o mesmo domínio personalizado por várias aplicações, com round-robin e failover passivo. Não há autoscaling: você decide quantas aplicações entram e a RAM de cada uma. Para usuários distantes de Nova York, o piso físico calculado acima continua valendo, e a CDN ajuda no conteúdo que pode ser guardado em cache, seguindo o Cache-Control da sua aplicação.

Os detalhes da rede estão em Rede e CDN da Square Cloud.