Latência no link dedicado para data centers: como avaliar RTT, jitter e perda de pacotes antes de contratar

Por Equipe Técnica JCM TELCOM · Publicado em 2025/06 · Leitura: ~8 min

Para gestores de infraestrutura de data centers, a latência não é apenas um número no relatório de SLA — é um fator determinante para a viabilidade de arquiteturas de alta disponibilidade, replicação síncrona de banco de dados e clustering ativo-ativo entre sites. Avaliar corretamente RTT, jitter e perda de pacotes antes de contratar um link dedicado evita surpresas operacionais custosas.

Por que latência importa mais em data centers

Em ambientes corporativos comuns, latência de 50ms é imperceptível para o usuário. Em data centers, cada milissegundo conta. Replicação síncrona de banco de dados (Oracle Data Guard, MySQL Group Replication) exige latência abaixo de 5ms para não impactar o throughput de transações. Clustering ativo-ativo (VMware vSAN, Nutanix) exige latência abaixo de 2ms entre nós. Latência acima desses thresholds força o uso de replicação assíncrona, que introduz risco de perda de dados em caso de falha.

Thresholds de latência por aplicação de data center

Como medir antes de contratar

Solicite ao provedor um PoC (Proof of Concept) com acesso temporário a um servidor de teste na rede deles. Execute os seguintes testes:

1. Ping estendido: 1000 pacotes de 1400 bytes para medir RTT médio, mínimo, máximo e desvio padrão (jitter)
2. iPerf3 bidirecional: teste de throughput em ambas as direções por 60 segundos para validar o CIR
3. MTR (My Traceroute): 500 pacotes para identificar onde a latência é introduzida no caminho
4. Teste em horário de pico: repetir os testes entre 9h e 11h e entre 14h e 16h para detectar congestionamento

Impacto do IX.br na latência

O IX.br (PTT Metro) é o ponto de troca de tráfego da NIC.br presente em 37 cidades brasileiras. Provedores com presença no IX.br trocam tráfego diretamente com outros provedores e com grandes CDNs (Google, Cloudflare, AWS) sem sair para o exterior, reduzindo a latência para tráfego nacional em 50–200ms em relação a provedores sem presença no IX.br.

Para data centers, isso significa que o link dedicado do provedor deve ter presença no IX.br da cidade onde o data center está localizado. Verifique no portal do IX.br (ix.br/ptt) se o provedor está listado como participante.

Perguntas Frequentes

Qual a latência aceitável para interconexão de data centers?

Mesma cidade: abaixo de 2ms (RTT). Mesmo estado: abaixo de 10ms. Entre estados do Sudeste: abaixo de 20ms.

Como medir a latência antes de contratar?

Solicite PoC com servidor de teste. Use ping com 1000 pacotes, iPerf3 bidirecional e MTR. Repita em horário de pico para detectar congestionamento.

O que causa jitter alto em links dedicados?

Congestionamento em equipamentos intermediários, filas de QoS mal configuradas, variação de rota BGP e problemas físicos na fibra. Links dedicados de qualidade têm jitter abaixo de 1ms.

Qual a perda de pacotes aceitável para data center?

Zero. Links dedicados de qualidade devem ter perda de pacotes de 0% em condições normais. Qualquer perda acima de 0,01% indica problema na infraestrutura.

Como o IX.br afeta a latência?

Provedores com presença no IX.br trocam tráfego nacional diretamente, reduzindo latência em 50–200ms em relação a provedores sem presença. Verifique em ix.br/ptt.

Latência e replicação de banco de dados: o impacto no RPO e RTO

Para data centers com estratégia de DR (Disaster Recovery), a latência entre o site principal e o site de DR determina diretamente o RPO (Recovery Point Objective) — quanto de dados pode ser perdido em caso de desastre. Replicação síncrona de banco de dados (RPO = 0, zero perda de dados) só é viável com latência abaixo de 5ms entre os sites. Acima disso, o banco de dados força replicação assíncrona, que introduz um lag de segundos a minutos no site de DR.

Para empresas com RPO = 0 (zero tolerância a perda de dados), o link dedicado entre os sites de DR deve ter latência garantida abaixo de 5ms, com SLA contratual que inclua penalidade por violação desse parâmetro. Isso é possível apenas entre data centers na mesma cidade ou em cidades próximas (São Paulo e Campinas, por exemplo).

Interconexão de data centers: LAN to LAN vs link dedicado

Para interconexão de data centers na mesma cidade ou entre cidades próximas, a alternativa ao link dedicado padrão é o serviço LAN to LAN (Layer 2 WAN), que estende a rede local entre dois pontos como se fossem o mesmo segmento de rede. LAN to LAN oferece latência menor que link dedicado padrão (pois não há roteamento IP no caminho) e é ideal para clustering ativo-ativo e replicação síncrona.

A escolha entre link dedicado (Layer 3) e LAN to LAN (Layer 2) depende da arquitetura de rede: se os dois data centers precisam ser o mesmo segmento de rede (mesmo VLAN, mesmo broadcast domain), LAN to LAN é a solução correta. Se os data centers são redes independentes que precisam se comunicar via roteamento, link dedicado com BGP é mais adequado.

Monitoramento proativo de latência

Latência não é estática — varia ao longo do dia conforme o volume de tráfego na rede do provedor. Um link que entrega 3ms de latência às 3h da manhã pode entregar 15ms às 14h em dia útil. Monitoramento proativo com alertas automáticos quando a latência supera o threshold contratual é essencial para detectar degradação antes que impacte aplicações críticas.

Latência e experiência do usuário: o impacto nos SLAs de aplicação

Para data centers que hospedam aplicações SaaS ou sistemas acessados por usuários finais, a latência do link dedicado impacta diretamente o SLA de aplicação prometido aos clientes. Uma aplicação web hospedada em data center com link de 20ms de latência para o IX.br entrega experiência significativamente pior que a mesma aplicação em data center com link de 2ms — especialmente para usuários que fazem muitas requisições pequenas (APIs REST, consultas de banco de dados).

O impacto da latência é amplificado pelo protocolo TCP: cada requisição HTTP/1.1 exige múltiplos round-trips (TCP handshake + TLS handshake + requisição + resposta). Com latência de 20ms, uma página web com 50 objetos pode levar 2–3 segundos a mais para carregar do que com latência de 2ms. HTTP/2 e HTTP/3 reduzem esse impacto com multiplexação, mas não o eliminam completamente.

Certificações e conformidade para data centers

Data centers com certificação Tier III ou Tier IV (Uptime Institute) têm requisitos específicos de redundância de conectividade que o link dedicado deve atender. A certificação Tier III exige N+1 de redundância em todos os sistemas, incluindo conectividade; a Tier IV exige 2N (dois sistemas completamente independentes). O link dedicado contratado deve ser documentado como parte da infraestrutura de conectividade no processo de certificação.

Latência e edge computing: o próximo desafio

A adoção de edge computing — processamento de dados próximo à fonte, em vez de no data center central — está criando novos requisitos de latência para links dedicados. Aplicações de edge computing exigem latência ultra-baixa entre o dispositivo de borda e o servidor de processamento: manufatura com controle de processo em tempo real exige latência abaixo de 1ms; varejo com checkout sem atrito exige abaixo de 5ms; saúde com monitoramento contínuo de pacientes exige abaixo de 10ms.

Para data centers que hospedam workloads de edge computing, o link dedicado deve ter latência garantida para os pontos de presença dos principais provedores de cloud (AWS, Azure, GCP) — que frequentemente hospedam os serviços de edge computing. Verifique a latência do link para os POPs desses provedores antes de contratar.

O futuro da conectividade para data centers é a combinação de link dedicado de alta capacidade com baixa latência garantida, presença no IX.br para tráfego nacional, e peering direto com os principais provedores de cloud para workloads híbridos. Data centers que investem nessa infraestrutura hoje estarão melhor posicionados para atender a demanda crescente por edge computing nos próximos anos.