VPS em Frankfurt: latência, DE-CIX e GDPR

Para quem serve o alojamento VPS em Frankfurt

O alojamento VPS em Frankfurt é adequado para projetos cujos utilizadores estão na Alemanha, no mercado de língua alemã em geral ou distribuídos pela União Europeia. Frankfurt é um dos pontos onde as redes europeias se interligam e trocam tráfego diretamente. Por isso, um servidor nessa cidade chega à maior parte do continente em algumas dezenas de milissegundos. Se a maioria dos utilizadores estiver na América do Norte, um servidor europeu parecerá lento, por mais rápida que seja a máquina. A distância impõe um limite mínimo que nenhum ajuste consegue eliminar.

Duas perguntas distintas determinam a localização. Confundi-las é o que leva a más escolhas. A primeira é onde estão os utilizadores. Esta é uma questão de distância e tempo de ida e volta. A segunda é onde os dados podem ser armazenados. Esta é uma questão legal e contratual. Frankfurt oferece uma resposta forte à primeira questão para públicos europeus. Quanto à segunda, elimina um problema específico, mas não resolve mais nada.

Por que Frankfurt tem conectividade tão boa?

Frankfurt abriga o DE-CIX (Deutsche Commercial Internet Exchange), um IXP (ponto de troca de tráfego da Internet) que está entre os maiores do mundo em tráfego de pico e em número de redes conectadas. Um IXP é uma infraestrutura de comutação partilhada dentro de um data center, onde redes independentes se ligam umas às outras, em vez de pagarem a uma rede maior para transportar o tráfego entre elas. O DE-CIX publica as estatísticas atuais de tráfego no seu próprio site, e esses números mudam. Por isso, consulte-os no site em vez de confiar num valor copiado de um artigo.

O efeito prático está relacionado com os caminhos, não com os totais. Quando a rede do seu provedor e o ISP (provedor de serviços de Internet) do visitante estão ligados ao mesmo ponto de troca, o tráfego entre eles atravessa um único salto roteado nesse ponto. Quando não fazem peering local, o tráfego precisa chegar a uma terceira rede que transporte ambos, e o ponto de interligação mais próximo dessa rede pode estar noutro país. Duas redes alemãs que trocam tráfego por Amsterdã ou Londres percorrem a distância adicional duas vezes, uma em cada direção. Os engenheiros de rede chamam a isso tromboning, e essa é a razão habitual para um servidor próximo parecer distante nas medições.

É possível observar isso em vez de presumir. Execute mtr contra o seu servidor a partir da rede que pretende analisar e leia os nomes dos saltos no DNS reverso. Os nomes de host dos roteadores normalmente incluem códigos de aeroportos IATA. Assim, fra num nome de salto significa Frankfurt, ams significa Amsterdã e lhr significa Londres. Um caminho entre uma conexão de consumidor alemã e um servidor alemão que mostre lhr no meio indica exatamente onde foram gastos os milissegundos adicionais.

Qual é a distância entre Frankfurt e os seus utilizadores?

A luz numa fibra viaja a aproximadamente dois terços da velocidade que tem no vácuo, perto de 200,000 quilómetros por segundo. Uma ida e volta cobre o percurso duas vezes. Por isso, o tempo mínimo possível de uma ida e volta numa distância de d quilómetros é d/100 milissegundos. Este é um limite inferior útil, porque nada o consegue superar.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

Estes valores são calculados a partir da distância em linha reta, não são medidos. Leia a última coluna como o melhor caso permitido pela física. As medições reais normalmente ficam entre 1.5 e 2 vezes esse limite, porque as fibras seguem estradas e vales de rios em vez de grandes círculos e porque cada router no percurso acrescenta um pequeno atraso de encaminhamento e de fila.

Berlim fica a 424 km de Frankfurt, com um limite inferior de 4.2 ms. Madrid fica a 1,419 km, com um limite inferior de 14.2 ms, e é o ponto mais distante da UE a partir daqui. Nova Iorque fica a 6,206 km, com um limite inferior de 62.1 ms. É por isso que uma audiência transatlântica é uma decisão de localização, não um problema de otimização.

Quanto custa uma viagem de ida e volta lenta no carregamento de uma página?

Uma viagem de ida e volta raramente é apenas uma viagem de ida e volta. Abrir uma ligação HTTPS custa uma viagem de ida e volta para o handshake do TCP (protocolo de controlo de transmissão) e outra para o handshake do TLS (segurança da camada de transporte) 1.3. O pedido custa depois uma terceira viagem antes de chegar o primeiro byte da resposta. O TLS 1.2 acrescenta uma quarta. Uma consulta de DNS (sistema de nomes de domínio) que ainda não esteja em cache acrescenta pelo menos mais uma, novamente para um servidor diferente.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

A coluna de viagens de ida e volta parte do pressuposto de um caminho plausível até um servidor em Frankfurt, e a segunda coluna é o cálculo com base nesse caminho: três viagens de ida e volta antes do primeiro byte. Um utilizador em Frankfurt espera 15 ms. Um utilizador em Singapura, com 170 ms de tempo de ida e volta, espera 510 ms pela mesma resposta, antes de o browser desenhar qualquer elemento.

O multiplicador é o ponto principal. Cada milissegundo adicional de RTT (tempo de ida e volta) custa cerca de três milissegundos até ao primeiro byte, e continua a ter impacto depois disso. O HTML referencia uma folha de estilos, e a folha de estilos referencia um tipo de letra. Cada uma dessas descobertas exige outra viagem de ida e volta na mesma ligação. Acrescentar algumas centenas de milissegundos de distância transforma uma página que parecia instantânea numa página lenta, embora o servidor faça exatamente o mesmo trabalho no mesmo tempo.

Isto também define o limite do que uma CDN (rede de distribuição de conteúdo) consegue resolver. Ficheiros estáticos servidos a partir de uma cache próxima do utilizador evitam o caminho longo. Um dashboard com sessão iniciada que precisa de consultar a base de dados não o evita: esse pedido continua a atravessar toda a distância duas vezes. Colocar a origem perto das pessoas que iniciam sessão é algo que nenhuma cache pode fazer por si.

Como medir isto a partir do local onde estão os meus utilizadores?

Execute estes comandos numa máquina da rede que pretende avaliar, idealmente numa ligação doméstica ou de escritório no país onde presta o serviço. Medir a partir de outro servidor, noutro data center, mostra os caminhos até ao data center, não os caminhos usados pelos seus utilizadores. Os comandos abaixo são exemplos para executar por si: os únicos valores de latência que justificam ações são os que mediu.

ping -c 20 your-server.example.com

A linha de resumo é apresentada como rtt min/avg/max/mdev = .... Consulte avg para o caso típico e mdev para o jitter, ou seja, a variação entre pacotes. Um avg normal com um mdev elevado indica que o caminho é instável. Isto prejudica mais as tarefas interativas, como SSH ou voz, do que uma média ligeiramente superior.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r apresenta um relatório em vez da visualização em tempo real, -w mantém os nomes de host longos completos, -z mostra o número do AS (sistema autónomo) de cada salto e -c 50 envia cinquenta ciclos. A perda apresentada num salto intermédio, sem perda no salto final, é normal e não indica uma falha: muitos routers limitam a taxa das respostas ICMP que geram para si próprios, embora encaminhem corretamente todo o restante tráfego. A perda que começa num salto e continua em todos os saltos seguintes é perda real.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

Cada campo representa segundos cumulativos desde o início do pedido, por isso deve ser lido por subtração. time_namelookup é o DNS. time_connect menos esse valor corresponde ao handshake TCP, próximo de uma ida e volta. time_appconnect menos time_connect corresponde ao handshake TLS. time_starttransfer menos time_appconnect corresponde ao tempo de processamento da própria aplicação mais uma ida e volta. Se os intervalos forem pequenos e total continuar elevado, o problema está no seu código, não na cidade.

Para medir o throughput em vez da latência, execute iperf3 -s no VPS, abra a respetiva porta na firewall e execute iperf3 -c your-server.example.com -R a partir do cliente para testar a direção de download. Para medir a partir de locais onde não tem uma máquina, o RIPE Atlas disponibiliza probes em toda a Europa. Ao comparar dois servidores, e não duas redes, utilize um método fixo em vez de valores isolados. É esse o objetivo de um benchmark de VPS reproduzível.

Um servidor em Frankfurt torna o meu projeto compatível com o RGPD?

Não. Vale a pena explicar precisamente porquê. O RGPD (Regulamento Geral sobre a Proteção de Dados) aplica-se com base nos dados pessoais que processa e no local onde a sua organização está estabelecida, não no país onde o hardware está instalado. Mover um servidor para Frankfurt não cria conformidade, e executar um servidor fora da UE não a elimina automaticamente. A localização é apenas um dos vários fatores.

O alojamento dentro da UE ou do EEE (Espaço Económico Europeu) elimina a questão das transferências internacionais. O regulamento tem um capítulo completo sobre o envio de dados pessoais para fora do EEE, que exige um instrumento jurídico, como uma decisão de adequação ou cláusulas contratuais-tipo. Os dados que permanecem em Frankfurt não estão a ser transferidos, pelo que esse capítulo não se aplica a essa etapa. Essa é uma simplificação real e representa, de forma honesta, o alcance do benefício.

Tudo o resto continua a ser da sua responsabilidade. Ainda precisa de uma base legal para cada finalidade, de direitos funcionais de acesso e eliminação para as pessoas na sua base de dados, de um limite de retenção que seja efetivamente aplicado, de medidas de segurança adequadas ao risco e de comunicar a violação de dados pessoais à autoridade de controlo no prazo de 72 horas após tomar conhecimento dela. Também precisa de um acordo de tratamento de dados com o seu fornecedor de alojamento, conhecido na Alemanha como Auftragsverarbeitungsvertrag ou AVV. Tenha também em conta que um servidor em Frankfurt pode continuar a envolver uma transferência se membros da equipa de suporte fora do EEE puderem aceder-lhe. Verifique quem controla as chaves.

A Alemanha acrescenta a sua própria camada: a BDSG (Bundesdatenschutzgesetz) federal complementa o regulamento com regras nacionais, e os dados dos trabalhadores são a área que mais frequentemente surpreende as pessoas. Esta secção apresenta informação geral e não constitui aconselhamento jurídico. O Comité Europeu para a Proteção de Dados publica as orientações oficiais em edpb.europa.eu, e qualquer questão com consequências reais deve ser analisada por um consultor qualificado, não apenas por um tutorial.

O que devo alterar no próprio servidor?

Mantenha o relógio do sistema em UTC (tempo universal coordenado) e formate os carimbos de data e hora na aplicação. A Alemanha aplica o horário de verão, por isso a hora local avança ou recua uma hora duas vezes por ano, e uma hora no final de outubro ocorre duas vezes. Os logs gravados na hora local contêm duas entradas 02:30 nessa noite, e correlacioná-las entre regiões passa a ser uma questão de adivinhação. Se ainda quiser usar a hora local no servidor, configure-a explicitamente e confirme o resultado:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

O resultado deve mostrar Time zone: Europe/Berlin (CEST, +0200) no verão e +0100 no inverno.

O texto alemão é ordenado incorretamente com a locale C predefinida, porque a ordenação C compara bytes brutos. Gere a locale e observe a diferença:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

A primeira ordenação coloca Äpfel depois de Zebra, porque o seu primeiro byte em UTF-8 é superior ao de qualquer letra ASCII. A segunda coloca-o junto de Apfel, onde um leitor alemão espera encontrá-lo. Isto é mais importante do que parece, porque PostgreSQL e MySQL fixam uma collation quando a base de dados é criada, e alterá-la mais tarde implica reconstruir os índices. Decida antes de carregar os dados.

Um mirror alemão de pacotes reduz a duração das execuções de apt. No Ubuntu 24.04, as fontes estão em /etc/apt/sources.list.d/ubuntu.sources no formato deb822. Por isso, altere a linha URIs: para http://de.archive.ubuntu.com/ubuntu/ em vez de adicionar um segundo ficheiro. Adicionar um ficheiro cria Target Packages ... is configured multiple times, que é o erro de fontes duplicadas deb822 e interrompe as atualizações até o resolver.

Publique um registo AAAA. Alguns ISPs alemães fornecem ligações de consumidores com DS-Lite (dual-stack lite), em que o cliente não tem qualquer endereço IPv4 público e o tráfego IPv4 atravessa o gateway de tradução do operador. Esse gateway acrescenta latência e fica congestionado nos períodos de maior utilização, enquanto o tráfego IPv6 sai diretamente. Verifique ambos os caminhos depois de configurar o registo:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

Um 200 no segundo comando significa que o IPv6 funciona de ponta a ponta. Could not resolve host ou um erro de ligação significa que falta o registo ou o listener, e os visitantes com DS-Lite estão a seguir o caminho mais lento.

Quando Frankfurt não é a escolha certa

• Os seus utilizadores estão nos Estados Unidos. Aloje o serviço nesse país: um VPS em Dallas fica perto do centro do país, e alojamento VPS em Nova Iorque oferece o caminho mais curto para a costa leste e para o tráfego que atravessa o Atlântico de qualquer forma.
• Os seus utilizadores estão na América Latina. Frankfurt fica mais longe de São Paulo do que de Nova Iorque, por isso um VPS no Brasil é a resposta adequada para esse público.
• Os seus dados têm de permanecer num país específico fora da UE. O trabalho para o setor público canadiano é o caso mais comum, e o que realmente importa no alojamento VPS no Canadá explica os requisitos de residência nesse país.
• Gere um servidor de jogos. Os jogadores sentem cada milissegundo do tempo de ida e volta, por isso a proximidade em relação a eles é mais importante do que qualquer outra especificação: escolher um VPS para servidores de jogos explica como fazer essa escolha.

Para um público europeu distribuído por vários países, Frankfurt é a escolha única mais segura e continua a sê-lo à medida que cresce, porque as redes que precisa de alcançar já estão ligadas ao ponto de troca. Meça a partir da localização dos seus utilizadores antes da mudança e novamente depois, e guarde ambos os conjuntos de valores.

FAQ

Um VPS em Frankfurt é suficiente para toda a Europa?

Para a maioria dos projetos, sim. A distância em linha reta estabelece um limite mínimo de 12.0 ms até Estocolmo e de 14.2 ms até Madrid. Os trajetos reais demoram cerca de 1.5 a 2 vezes esse limite. Assim, quase toda a UE fica a poucas dezenas de milissegundos de um único servidor em Frankfurt. Adicione uma segunda localização quando tiver medido uma reclamação real de um país específico ou quando precisar de failover, e não de mais velocidade.

Alojar o meu projeto em Frankfurt torna-o compatível com o RGPD?

Não. O RGPD aplica-se com base nos dados pessoais que processa e no local onde está estabelecido, e não no local do servidor. Alojar o serviço na UE elimina a questão da transferência internacional nesse trajeto. Essa é uma simplificação real e todo o benefício obtido. Continua a precisar de uma base legal, de mecanismos funcionais para os direitos dos titulares dos dados, de um limite de retenção, de medidas de segurança, de comunicação de violações no prazo de 72 horas e de um acordo de tratamento de dados com o fornecedor, chamado AVV na Alemanha. Esta é uma informação geral, não aconselhamento jurídico.

Que latência devo esperar entre Frankfurt e Berlim?

As duas cidades ficam a 424 km de distância. Isso estabelece um limite mínimo de 4.2 ms para o tempo de ida e volta. Um trajeto com boas ligações entre redes normalmente mede 1.5 a 2 vezes esse limite. Confirme com ping -c 20 your-server.example.com a partir de uma ligação em Berlim e leia o valor de avg na linha rtt min/avg/max/mdev. Um resultado muito acima desse intervalo normalmente significa que o tráfego saiu da Alemanha e voltou. O comando mtr -rwzc 50 mostra isso nos nomes dos saltos.

Devo configurar o fuso horário do meu servidor em Frankfurt como Europe/Berlin?

Normalmente, não. Mantenha o sistema em UTC para que os logs possam ser comparados e nenhum timestamp seja ambíguo. A Alemanha muda para CEST na primavera e volta para CET no outono. Na noite da mudança de outono, uma hora local ocorre duas vezes. Por isso, dois eventos diferentes podem ter o mesmo timestamp local. Formate as horas no fuso local na aplicação, onde tem o contexto necessário para o fazer corretamente. Se quiser configurar todo o sistema com a hora local, execute sudo timedatectl set-timezone Europe/Berlin e confirme com timedatectl.

Um servidor apenas com IPv4 será um problema para visitantes alemães?

O serviço funcionará, mas será mais lento para alguns visitantes. Vários ISPs alemães fornecem ligações de consumidor com uma configuração DS-Lite sem um endereço IPv4 público. Esses clientes chegam a um servidor apenas com IPv4 através do gateway de tradução do operador. Isso aumenta a latência e pode causar congestionamento nos períodos de maior utilização. Publicar um registo AAAA e fazer o serviço escutar em IPv6 proporciona-lhes um caminho direto. Teste com dig AAAA your-server.example.com +short e um pedido curl -6. Espere receber HTTP 200 de ambas as famílias de endereços.