VPS a Francoforte: latenza, peering e GDPR

Per chi è adatto il VPS hosting a Francoforte

Il VPS hosting a Francoforte è adatto ai progetti i cui utenti si trovano in Germania, nel più ampio mercato di lingua tedesca oppure distribuiti nell'Unione Europea. Francoforte è uno dei punti in cui le reti europee si incontrano e si scambiano direttamente il traffico, quindi un server situato in questa città raggiunge gran parte del continente in poche decine di millisecondi. Se la maggior parte degli utenti si trova in Nord America, un server europeo risulterà lento indipendentemente dalla velocità della macchina, perché la distanza stabilisce un limite minimo che l'ottimizzazione non può eliminare.

Due domande distinte determinano la scelta della posizione, e confonderle porta a decisioni errate. La prima riguarda la posizione degli utenti ed è una questione di distanza e tempo di andata e ritorno. La seconda riguarda il luogo in cui i dati possono essere conservati ed è una questione legale e contrattuale. Francoforte offre una risposta solida alla prima domanda per il pubblico europeo. Per la seconda risolve un problema specifico, ma non stabilisce nient'altro.

Perché Francoforte è così ben collegata?

A Francoforte ha sede DE-CIX (Deutsche Commercial Internet Exchange), un IXP (internet exchange point) che rientra tra i più grandi al mondo per traffico di picco e numero di reti connesse. Un IXP è un’infrastruttura di switching condivisa all’interno di un data center, dove reti indipendenti si collegano direttamente tra loro invece di pagare una rete più grande per trasportare il traffico tra le rispettive reti. DE-CIX pubblica le statistiche aggiornate sul traffico sul proprio sito; questi valori cambiano, quindi consultali direttamente invece di considerare attendibile un dato copiato in un articolo.

L’effetto pratico riguarda i percorsi, non i volumi complessivi. Quando la rete del tuo provider e l’ISP (internet service provider) del visitatore sono collegati allo stesso exchange, il traffico tra loro attraversa un solo hop instradato presso quell’exchange. Quando non esiste peering locale, il traffico deve raggiungere una terza rete che trasporta entrambe le reti, e il punto di interconnessione più vicino di quella rete può trovarsi in un altro Paese. Due reti tedesche che si scambiano traffico tramite Amsterdam o Londra percorrono due volte la distanza aggiuntiva, una volta in ciascuna direzione. I tecnici di rete chiamano questo fenomeno tromboning ed è il motivo abituale per cui un server vicino risulta lontano nelle misurazioni.

Puoi verificarlo direttamente invece di darlo per scontato. Esegui mtr verso il tuo server dalla rete che ti interessa e leggi i nomi degli hop nel DNS inverso. I nomi host dei router contengono spesso i codici aeroportuali IATA; quindi fra in un nome di hop indica Francoforte, ams indica Amsterdam e lhr indica Londra. Un percorso da una connessione consumer tedesca a un server tedesco che mostra lhr al centro indica esattamente dove sono finiti i millisecondi aggiuntivi.

Quanto dista Francoforte dai tuoi utenti?

La luce nella fibra viaggia a circa due terzi della velocità che ha nel vuoto, cioè quasi 200.000 chilometri al secondo. Un percorso di andata e ritorno copre due volte la distanza, quindi il tempo minimo teorico per un round trip su una distanza di d chilometri è d/100 millisecondi. Questo è un limite inferiore utile, perché nulla può fare meglio.

[
  {
    "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
  }
]

Questi valori sono calcolati sulla base della distanza in linea d'aria, non sono misurati. Considera l'ultima colonna come il caso migliore consentito dalla fisica. Le misurazioni reali sono in genere comprese tra 1,5 e 2 volte questo limite, perché la fibra segue strade e vallate fluviali invece di percorrere archi di cerchio massimo e perché ogni router lungo il percorso aggiunge un piccolo ritardo di inoltro e accodamento.

Berlino si trova a 424 km da Francoforte, con un limite inferiore di 4.2 ms. Madrid dista 1,419 km, con un limite inferiore di 14.2 ms, ed è l'angolo più lontano dell'UE rispetto a qui. New York dista 6,206 km, con un limite inferiore di 62.1 ms: per questo un pubblico transatlantico richiede una decisione sulla posizione, non un intervento di ottimizzazione.

Quanto costa un round trip lento nel caricamento di una pagina?

Un round trip raramente è un solo round trip. L'apertura di una connessione HTTPS richiede un round trip per l'handshake TCP (transmission control protocol) e un altro per l'handshake TLS (transport layer security) 1.3. La richiesta ne richiede poi un terzo prima che arrivi il primo byte della risposta. TLS 1.2 ne aggiunge un quarto. Una ricerca DNS (domain name system) non già presente nella cache ne aggiunge almeno un altro, questa volta verso un server diverso.

[
  {
    "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
  }
]

La colonna dei round trip si basa qui su un percorso plausibile verso un server a Francoforte, mentre la seconda colonna è il calcolo corrispondente: tre round trip prima del primo byte. Un utente a Francoforte attende 15 ms. Un utente a Singapore, con un tempo di andata e ritorno di 170 ms, attende 510 ms per la stessa risposta, prima ancora che il browser visualizzi qualcosa.

Il moltiplicatore è il punto centrale. Ogni millisecondo aggiuntivo di RTT (round-trip time) costa circa tre millisecondi prima del primo byte, e continua a incidere anche dopo. L'HTML indica un foglio di stile, il foglio di stile indica un font e ciascuna di queste scoperte richiede un altro round trip sulla stessa connessione. Aggiungere un paio di centinaia di millisecondi dovuti alla distanza trasforma una pagina che sembrava istantanea in una pagina che sembra lenta, mentre il server esegue esattamente lo stesso lavoro nello stesso tempo.

Questo definisce anche il limite di ciò che risolve una CDN (content delivery network). I file statici serviti da una cache vicina all'utente evitano il percorso lungo. Una dashboard per utenti autenticati che deve interrogare il database non lo evita: quella richiesta deve comunque attraversare l'intera distanza due volte. Posizionare l'origine vicino alle persone che effettuano l'accesso è l'unica parte che nessuna cache può gestire al posto tuo.

Come posso effettuare la misurazione dalla posizione dei miei utenti?

Eseguire questi comandi da una macchina sulla rete interessata, idealmente da una connessione domestica o aziendale nel Paese in cui si offre il servizio. Una misurazione eseguita da un altro server in un altro data centre descrive i percorsi del data centre, non quelli degli utenti. I comandi seguenti sono esempi da eseguire direttamente: gli unici valori di latenza su cui intervenire sono quelli misurati.

ping -c 20 your-server.example.com

La riga di riepilogo è rtt min/avg/max/mdev = .... Leggere avg per il caso tipico e mdev per il jitter, cioè la variazione tra i pacchetti. Un avg normale con un mdev elevato indica che il percorso è instabile. Questo penalizza le attività interattive, come SSH o le chiamate vocali, più di una media leggermente superiore.

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

-r stampa un report invece di mostrare i dati in tempo reale, -w mantiene integri i nomi host lunghi, -z mostra il numero AS (sistema autonomo) di ogni hop e -c 50 invia cinquanta cicli. Una perdita rilevata su un hop intermedio, ma non sull'hop finale, è normale e non indica un guasto: molti router applicano un rate limiting alle risposte ICMP generate per il proprio indirizzo, continuando però a inoltrare correttamente tutto il resto. Una perdita che inizia su un hop e continua su tutti gli hop successivi è una perdita reale.

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/

Ogni campo indica i secondi cumulativi trascorsi dall'inizio della richiesta, quindi va letto per sottrazione. time_namelookup è il DNS. time_connect meno quel valore corrisponde all'handshake TCP, che è vicino a un round trip. time_appconnect meno time_connect corrisponde all'handshake TLS. time_starttransfer meno time_appconnect è il tempo di elaborazione dell'applicazione, più un altro round trip. Se gli intervalli sono brevi e total è ancora elevato, il problema è nel codice, non nella città.

Per misurare il throughput anziché la latenza, eseguire iperf3 -s sul VPS, aprire la relativa porta nel firewall ed eseguire iperf3 -c your-server.example.com -R dal client per testare la direzione del download. Per misurare da località in cui non si dispone di una macchina, RIPE Atlas mette a disposizione probe distribuite in tutta Europa. Quando si confrontano due server anziché due reti, usare un metodo fisso invece di valori ottenuti una sola volta: è questo lo scopo di un benchmark VPS ripetibile.

Un server a Francoforte rende il mio progetto conforme al GDPR?

No. Il motivo va precisato. Il GDPR (Regolamento generale sulla protezione dei dati) si applica in base alle persone a cui appartengono i dati personali trattati e al luogo in cui è stabilita l’organizzazione, non al Paese in cui si trova l’hardware. Spostare un server a Francoforte non rende il progetto conforme. Eseguire un server fuori dall’UE non lo rende automaticamente non conforme. La posizione geografica è solo uno dei diversi elementi da considerare.

L’hosting all’interno dell’UE o del più ampio SEE (Spazio economico europeo) elimina il problema dei trasferimenti internazionali. Il regolamento contiene un intero capo dedicato all’invio di dati personali al di fuori del SEE. Questi trasferimenti richiedono uno strumento giuridico, ad esempio una decisione di adeguatezza o clausole contrattuali standard. Se i dati restano a Francoforte, non vengono trasferiti durante quel passaggio e il relativo capo non si applica. Questa è una semplificazione concreta, e rappresenta l’effettiva portata del vantaggio.

Tutto il resto resta a tuo carico. Devi comunque avere una base giuridica per ogni finalità, garantire alle persone presenti nel tuo database diritti effettivi di accesso e cancellazione, applicare e far rispettare un limite di conservazione, adottare misure di sicurezza adeguate al rischio e notificare la violazione dei dati personali all’autorità di controllo entro 72 ore da quando ne vieni a conoscenza. Devi inoltre stipulare un accordo sul trattamento dei dati con il provider di hosting, noto in Germania come Auftragsverarbeitungsvertrag o AVV. Tieni presente anche che un server a Francoforte può comunque comportare un trasferimento se il personale di supporto al di fuori del SEE può accedervi. Verifica quindi chi dispone delle chiavi.

La Germania aggiunge un ulteriore livello normativo: il BDSG federale (Bundesdatenschutzgesetz) integra il regolamento con disposizioni nazionali, e i dati dei dipendenti sono l’ambito che sorprende più spesso. Questa sezione fornisce informazioni generali e non costituisce consulenza legale. Il Comitato europeo per la protezione dei dati pubblica le linee guida ufficiali all’indirizzo edpb.europa.eu. Per le questioni con conseguenze concrete è opportuno rivolgersi a un consulente qualificato, non affidarsi a un tutorial.

Che cosa devo modificare direttamente sul server?

Mantieni l'orologio di sistema su UTC (tempo coordinato universale) e formatta i timestamp nell'applicazione. La Germania osserva l'ora legale, quindi l'ora locale cambia di un'ora 2 volte all'anno e, alla fine di ottobre, un'ora viene ripetuta. I log scritti con l'ora locale contengono 2 voci 02:30 quella notte; correlare questi eventi tra regioni diventa quindi un'ipotesi. Se vuoi comunque usare l'ora locale sul server, impostala esplicitamente e verificala:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

L'output dovrebbe mostrare Time zone: Europe/Berlin (CEST, +0200) in estate e +0100 in inverno.

Il testo tedesco viene ordinato in modo errato con la locale C predefinita, perché l'ordinamento C confronta i byte grezzi. Genera la locale e osserva la differenza:

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

Il primo ordinamento colloca Äpfel dopo Zebra, perché il suo primo byte in UTF-8 è maggiore di quello di qualsiasi lettera ASCII. Il secondo lo colloca accanto a Apfel, dove un lettore tedesco se lo aspetta. Questo aspetto è più importante di quanto sembri, perché PostgreSQL e MySQL fissano una collation quando il database viene creato e modificarla in seguito richiede la ricostruzione degli indici. Decidi prima di caricare i dati.

Un mirror tedesco dei pacchetti riduce la durata dei download apt. Su Ubuntu 24.04, le sorgenti si trovano in /etc/apt/sources.list.d/ubuntu.sources nel formato deb822; modifica quindi la riga URIs: impostandola su http://de.archive.ubuntu.com/ubuntu/ invece di aggiungere un secondo file. Aggiungerne uno genera Target Packages ... is configured multiple times, ovvero l'errore di sorgenti duplicate in formato deb822, e interrompe gli aggiornamenti finché non lo risolvi.

Pubblica un record AAAA. Alcuni ISP tedeschi forniscono ai clienti consumer una configurazione DS-Lite (dual-stack lite), in cui il cliente non dispone affatto di un indirizzo IPv4 pubblico e il traffico IPv4 attraversa il gateway di traduzione dell'operatore. Questo gateway aggiunge latenza e si congestiona nelle ore di punta, mentre il traffico IPv6 esce direttamente. Dopo aver configurato il record, verifica entrambi i percorsi:

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

Un 200 dal secondo comando indica che IPv6 funziona end-to-end. Could not resolve host o un errore di connessione indicano che manca il record o che il servizio non è in ascolto; i visitatori DS-Lite stanno quindi usando il percorso più lento.

Quando Francoforte non è la scelta giusta

• I tuoi utenti si trovano negli Stati Uniti. Servili da lì: un VPS a Dallas si trova vicino al centro del Paese, mentre il VPS hosting a New York offre il percorso più breve verso la costa orientale e per il traffico che attraversa comunque l'Atlantico.
• I tuoi utenti si trovano in America Latina. Francoforte è più lontana da São Paulo rispetto a New York, quindi un VPS in Brasile è la scelta corretta per questo pubblico.
• I tuoi dati devono restare in uno specifico Paese fuori dall'UE. Il settore pubblico canadese è il caso più comune; ciò che conta davvero per il VPS hosting canadese spiega i requisiti di residenza dei dati.
• Gestisci un game server. I giocatori percepiscono ogni millisecondo del tempo di andata e ritorno, quindi la vicinanza a loro è più importante di qualsiasi altra specifica: come scegliere un VPS per i game server spiega come procedere.

Per un pubblico europeo distribuito in più Paesi, Francoforte è la scelta singola più sicura e resta una scelta sicura anche quando cresci, perché le reti che devi raggiungere sono già collegate al punto di interscambio. Misura la latenza dalla posizione dei tuoi utenti prima del trasferimento e di nuovo dopo, quindi conserva entrambi gli insiemi di dati.

FAQ

Una sola VPS a Francoforte è sufficiente per tutta l'Europa?

Per la maggior parte dei progetti, sì. La distanza in linea d'aria stabilisce un limite teorico di 12.0 ms verso Stoccolma e 14.2 ms verso Madrid. I percorsi reali sono circa da 1.5 a 2 volte superiori rispetto a questo limite. Per questo motivo, quasi tutta l'UE resta entro poche decine di millisecondi da un unico server a Francoforte. Aggiungete una seconda posizione quando avete misurato un problema reale segnalato da un paese specifico o quando vi serve il failover, non una latenza inferiore.

L'hosting a Francoforte rende il mio progetto conforme al GDPR?

No. Il GDPR si applica in base ai dati personali trattati e al luogo in cui siete stabiliti, non in base alla posizione del server. L'hosting nell'UE elimina la questione del trasferimento internazionale per quel passaggio. Si tratta di una semplificazione concreta e dell'unico vantaggio rilevante sotto questo aspetto. Servono comunque una base giuridica, procedure funzionanti per i diritti degli interessati, un limite di conservazione, misure di sicurezza, la notifica delle violazioni entro 72 ore e un accordo sul trattamento con il provider, chiamato AVV in Germania. Queste sono informazioni generali e non costituiscono consulenza legale.

Quanta latenza devo aspettarmi tra Francoforte e Berlino?

Le due città distano 424 km. Questo stabilisce un limite teorico di 4.2 ms per il tempo di andata e ritorno. Un percorso con buone connessioni di peering misura in genere da 1.5 a 2 volte questo limite. Verificatelo con ping -c 20 your-server.example.com da una connessione a Berlino e leggete il valore avg nella riga rtt min/avg/max/mdev. Un risultato molto superiore a questo intervallo indica in genere che il traffico è uscito dalla Germania ed è rientrato. mtr -rwzc 50 lo mostrerà nei nomi degli hop.

Devo impostare il fuso orario del server di Francoforte su Europe/Berlin?

Di norma, no. Lasciate il sistema su UTC, così i log restano confrontabili e nessun timestamp è ambiguo. La Germania passa a CEST in primavera e torna a CET in autunno. Durante la notte del passaggio autunnale, un'ora locale si verifica due volte. Di conseguenza, due eventi distinti possono avere lo stesso timestamp locale. Formattate gli orari nel fuso locale all'interno dell'applicazione, dove avete il contesto necessario per farlo correttamente. Se volete impostare l'ora locale sull'intero sistema, eseguite sudo timedatectl set-timezone Europe/Berlin e verificate con timedatectl.

Un server solo IPv4 sarà un problema per i visitatori tedeschi?

Funzionerà, ma per alcuni visitatori sarà più lento. Diversi ISP tedeschi forniscono ai clienti consumer una configurazione DS-Lite senza un indirizzo IPv4 pubblico. Questi clienti raggiungono un server solo IPv4 tramite il gateway di traduzione dell'operatore, che aumenta la latenza e può congestionarsi nei periodi di maggiore utilizzo. La pubblicazione di un record AAAA e l'ascolto su IPv6 forniscono loro un percorso diretto. Eseguite il test con dig AAAA your-server.example.com +short e una richiesta curl -6. Dovreste ricevere un HTTP 200 da entrambe le famiglie di indirizzi.