VPS hosting in Frankfurt: voordelen en latency

Voor wie VPS-hosting in Frankfurt bedoeld is

VPS-hosting in Frankfurt is geschikt voor projecten waarvan de gebruikers zich in Duitsland, de bredere Duitstalige markt of verspreid over de Europese Unie bevinden. Frankfurt is een van de knooppunten waar Europese netwerken samenkomen en verkeer direct aan elkaar overdragen. Hierdoor bereikt een server op deze locatie het grootste deel van het continent binnen enkele tientallen milliseconden. Als uw gebruikers zich grotendeels in Noord-Amerika bevinden, zal een Europese server voor hen traag aanvoelen, ongeacht hoe snel de machine zelf is. De fysieke afstand legt namelijk een ondergrens aan de latentie die met optimalisatie niet kan worden weggenomen.

Twee afzonderlijke vragen bepalen de keuze voor een locatie; het vermengen van deze vragen leidt vaak tot verkeerde beslissingen. De eerste vraag is waar uw gebruikers zich bevinden, wat een kwestie is van afstand en round-trip time. De tweede vraag is waar uw data mag worden opgeslagen, wat een juridische en contractuele kwestie is. Frankfurt biedt een sterk antwoord op de eerste vraag voor een Europees publiek. Voor de tweede vraag lost het één specifiek probleem op, maar het biedt geen uitsluitsel over andere juridische aspecten.

Waarom is Frankfurt zo goed verbonden?

Frankfurt huisvest DE-CIX (Deutsche Commercial Internet Exchange), een IXP (internet exchange point) dat qua piekverkeer en aantal verbonden netwerken tot de grootste ter wereld behoort. Een IXP is een gedeelde switching-infrastructuur binnen een datacenter waar onafhankelijke netwerken met elkaar verbinden, in plaats van te betalen aan een groter netwerk om verkeer tussen hen te transporteren. DE-CIX publiceert zijn actuele verkeersstatistieken op zijn eigen website. Omdat deze cijfers veranderen, kunt u ze daar het beste raadplegen in plaats van te vertrouwen op een getal dat in een artikel is gekopieerd.

Het praktische effect heeft betrekking op paden, niet op totalen. Wanneer het netwerk van uw provider en de ISP (internet service provider) van uw bezoeker beide op hetzelfde knooppunt zijn aangesloten, legt het verkeer tussen hen slechts één gerouteerde hop af op dat knooppunt. Wanneer zij niet lokaal peeren, moet het verkeer een derde netwerk bereiken dat beide partijen bedient, en het dichtstbijzijnde overdrachtspunt van dat netwerk kan zich in een ander land bevinden. Twee Duitse netwerken die verkeer uitwisselen via Amsterdam of Londen betalen de extra afstand dubbel, één keer in elke richting. Netwerkengineers noemen dit tromboning, en dit is de gebruikelijke reden waarom een nabijgelegen server ver weg lijkt te staan bij metingen.

U kunt dit zien in plaats van het aan te nemen. Voer mtr uit naar uw server vanaf het netwerk dat voor u relevant is en lees de hopnamen in de reverse DNS. Hostnamen van routers bevatten meestal IATA-luchthavencodes, dus fra in een hopnaam betekent Frankfurt, ams betekent Amsterdam en lhr betekent Londen. Een pad van een Duitse consumentenverbinding naar een Duitse server dat halverwege lhr toont, laat u precies zien waar de extra milliseconden verloren gaan.

Hoe ver ligt Frankfurt van uw gebruikers vandaan?

Licht in glasvezel reist met ongeveer tweederde van de snelheid in een vacuüm, oftewel bijna 200.000 kilometer per seconde. Een retourtje legt de afstand twee keer af, dus de snelst mogelijke retour over een afstand van d kilometer is d/100 milliseconden. Dit is een ondergrens, en deze is nuttig omdat niets sneller kan.

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

Deze waarden zijn berekend op basis van de hemelsbrede afstand, niet gemeten. Lees de laatste kolom als het best haalbare scenario volgens de natuurkunde. Echte metingen vallen meestal tussen 1,5 en 2 keer de ondergrens, omdat glasvezel wegen en rivierdalen volgt in plaats van grootcirkels, en omdat elke router op het pad een kleine vertraging toevoegt voor het doorsturen en in de wachtrij plaatsen van pakketten.

Berlijn ligt 424 km van Frankfurt, met een ondergrens van 4.2 ms. Madrid ligt op 1,419 km afstand, met een ondergrens van 14.2 ms, en dit is vanuit hier de verste uithoek van de EU. New York ligt op 6,206 km afstand met een ondergrens van 62.1 ms; daarom is een transatlantisch publiek een locatiebeslissing en geen kwestie van optimalisatie.

Wat is de impact van een trage round-trip op het laden van een pagina?

Eén round-trip is zelden daadwerkelijk één round-trip. Het openen van een HTTPS-verbinding kost één round-trip voor de TCP (transmission control protocol) handshake en nog een voor de TLS (transport layer security) 1.3 handshake. Het verzoek kost vervolgens een derde voordat de eerste byte van het antwoord terugkomt. TLS 1.2 voegt daar een vierde aan toe. Een DNS (domain name system) lookup die nog niet in de cache staat, voegt er ten minste nog een toe, naar weer een andere server.

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

De kolom voor round-trip is hier een aanname over een aannemelijk pad naar een server in Frankfurt, en de tweede kolom is een berekening daarvan: drie round-trips voordat de eerste byte arriveert. Een gebruiker in Frankfurt wacht 15 ms. Een gebruiker in Singapore, met een round-trip tijd van 170 ms, wacht 510 ms op hetzelfde antwoord, voordat de browser ook maar iets heeft getekend.

De vermenigvuldiger is precies waar het om gaat. Elke extra milliseconde aan RTT (round-trip time) kost ongeveer drie milliseconden voordat de eerste byte arriveert, en daarna blijven de kosten oplopen. De HTML benoemt een stylesheet, het stylesheet benoemt een lettertype, en elk van die ontdekkingen is weer een nieuwe round-trip over dezelfde verbinding. Het toevoegen van een paar honderd milliseconden aan afstand verandert een pagina die direct aanvoelde in een pagina die traag aanvoelt, terwijl de server exact hetzelfde werk in exact dezelfde tijd uitvoert.

Dit bepaalt ook de grens van wat een CDN (content delivery network) kan oplossen. Statische bestanden die vanuit een cache dicht bij de gebruiker worden geserveerd, slaan het lange pad over. Een ingelogd dashboard dat een vraag aan uw database moet stellen, doet dat niet: dat verzoek legt de volledige afstand nog steeds twee keer af. Het plaatsen van de origin dicht bij de mensen die inloggen, is het deel dat geen enkele cache voor u kan doen.

Hoe meet ik dit vanaf de locatie van mijn gebruikers?

Voer deze commando's uit vanaf een machine in het netwerk dat voor u relevant is, bij voorkeur een thuis- of kantoorverbinding in het land dat u bedient. Meten vanaf een andere server in een ander datacenter geeft inzicht in datacenter-paden, niet in de ervaring van uw gebruikers. De onderstaande commando's zijn voorbeelden die u zelf kunt uitvoeren: de enige latentiecijfers waar u actie op moet ondernemen, zijn de cijfers die u zelf heeft gemeten.

ping -c 20 your-server.example.com

De samenvattingsregel leest rtt min/avg/max/mdev = .... Lees avg voor het standaardgeval en mdev voor jitter, de variatie tussen pakketten. Een normale avg met een hoge mdev betekent dat het pad instabiel is, wat schadelijker is voor interactief werk zoals SSH of spraakverkeer dan een iets hogere gemiddelde latentie.

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

-r genereert een rapport in plaats van een live weergave, -w behoudt lange hostnamen, -z toont het AS-nummer (autonomous system) van elke hop, en -c 50 verstuurt vijftig cycli. Pakketverlies bij een tussenliggende hop, zonder verlies bij de eindbestemming, is normaal en duidt niet op een fout: veel routers beperken de snelheid van ICMP-antwoorden die ze zelf genereren, terwijl ze al het overige verkeer correct doorsturen. Verlies dat begint bij een bepaalde hop en aanhoudt bij alle daaropvolgende hops, is daadwerkelijk verlies.

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/

Elk veld is cumulatief in seconden sinds de start van het verzoek; u leest dit door middel van aftrekking. time_namelookup is DNS. time_connect minus die waarde is de TCP-handshake, wat ongeveer gelijk is aan één round trip. time_appconnect minus time_connect is de TLS-handshake. time_starttransfer minus time_appconnect is de verwerkingstijd van uw applicatie plus nog één extra round trip. Als de tussenliggende intervallen klein zijn en total desondanks groot is, ligt het probleem bij uw code en niet bij de locatie.

Voor doorvoer in plaats van latentie voert u iperf3 -s uit op de VPS, opent u de bijbehorende poort in de firewall en voert u iperf3 -c your-server.example.com -R uit vanaf de client om de downloadsnelheid te testen. Om te meten vanaf locaties waar u geen machine heeft, biedt RIPE Atlas u probes door heel Europa. Wanneer u twee servers vergelijkt in plaats van twee netwerken, gebruik dan een vaste methode in plaats van eenmalige cijfers; daarvoor is een reproduceerbare VPS-benchmark bedoeld.

Maakt een server in Frankfurt mijn project AVG-compliant?

Nee, en de reden hiervoor is nauwkeurig te benoemen. De AVG (Algemene Verordening Gegevensbescherming) is van toepassing op basis van wiens persoonsgegevens u verwerkt en waar uw organisatie is gevestigd, niet op het land waar de hardware staat. Het verplaatsen van een server naar Frankfurt zorgt niet voor compliance, en het draaien van een server buiten de EU betekent niet automatisch dat u niet compliant bent. De locatie is slechts één van de vele factoren.

Wat hosting binnen de EU of de bredere EER (Europese Economische Ruimte) wel wegneemt, is de vraag over internationale doorgifte. De verordening bevat een volledig hoofdstuk over het versturen van persoonsgegevens buiten de EER, waarvoor een juridisch instrument nodig is, zoals een adequaatheidsbesluit of standaardcontractbepalingen. Gegevens die in Frankfurt blijven, worden niet doorgegeven, dus dat hoofdstuk is niet van toepassing op die stap. Dat is een reële vereenvoudiging, en dat is de werkelijke omvang van het voordeel.

Al het overige blijft uw verantwoordelijkheid. U heeft nog steeds een wettelijke grondslag nodig voor elk doel, werkende inzage- en verwijderingsrechten voor de personen in uw database, een bewaartermijn die u daadwerkelijk handhaaft, beveiligingsmaatregelen die passend zijn bij het risico, en een melding aan de toezichthouder binnen 72 uur nadat u op de hoogte bent van een inbreuk in verband met persoonsgegevens. U heeft ook een verwerkersovereenkomst nodig met uw hostingprovider, in Duitsland bekend als een Auftragsverarbeitungsvertrag of AVV. Let er ook op dat een server in Frankfurt nog steeds een doorgifte kan inhouden als ondersteunend personeel buiten de EER toegang heeft; controleer dus wie de sleutels beheert.

Duitsland voegt daar een eigen laag aan toe: de federale BDSG (Bundesdatenschutzgesetz) vult de verordening aan met nationale regels, en werknemersgegevens zijn het gebied dat mensen het vaakst verrast. Deze sectie is algemene achtergrondinformatie, geen juridisch advies. De European Data Protection Board publiceert de officiële richtlijnen op edpb.europa.eu, en voor zaken met werkelijke gevolgen verdient het de voorkeur om een gekwalificeerd adviseur in te schakelen in plaats van een handleiding te volgen.

Wat moet ik op de server zelf aanpassen?

Houd de systeemklok op UTC (Coordinated Universal Time) en formatteer tijdstempels in uw applicatie. Duitsland hanteert zomertijd, waardoor de lokale tijd twee keer per jaar een uur verspringt en een uur eind oktober wordt herhaald. Logs die in lokale tijd zijn geschreven, bevatten op die nacht twee keer een 02:30-vermelding, waardoor het correleren van logs tussen regio's giswerk wordt. Als u toch lokale tijd op de server wilt, stel deze dan expliciet in en controleer het:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

De uitvoer hoort Time zone: Europe/Berlin (CEST, +0200) in de zomer en +0100 in de winter te tonen.

Duitse tekst sorteert onjuist onder de standaard C-locale, omdat C-sortering ruwe bytes vergelijkt. Genereer de locale en bekijk het verschil:

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

De eerste sortering plaatst Äpfel na Zebra, omdat de eerste byte in UTF-8 hoger is dan elke ASCII-letter. De tweede plaatst het naast Apfel, waar een Duitse lezer het verwacht. Dit is belangrijker dan het lijkt, aangezien PostgreSQL en MySQL een collation vastleggen bij het aanmaken van de database; deze later wijzigen betekent dat indexen opnieuw moeten worden opgebouwd. Beslis dit voordat u data laadt.

Een Duitse pakket-mirror verkort apt-runs. Op Ubuntu 24.04 staan de bronnen in /etc/apt/sources.list.d/ubuntu.sources in deb822-formaat, dus wijzig de URIs:-regel naar http://de.archive.ubuntu.com/ubuntu/ in plaats van een tweede bestand toe te voegen. Het toevoegen van een bestand levert Target Packages ... is configured multiple times op, wat leidt tot de deb822 duplicate sources error, waardoor updates stoppen totdat u dit oplost.

Publiceer een AAAA-record. Sommige Duitse ISP's leveren consumentenverbindingen met een DS-Lite (Dual-Stack Lite) opstelling, waarbij de klant helemaal geen publiek IPv4-adres heeft en het IPv4-verkeer via de vertaalgateway van de provider verloopt. Die gateway voegt latentie toe en raakt tijdens piekuren overbelast, terwijl IPv6-verkeer direct verloopt. Controleer beide paden nadat u het record heeft ingesteld:

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

Een 200 bij het tweede commando betekent dat IPv6 end-to-end werkt. Could not resolve host of een verbindingsfout betekent dat het record of de listener ontbreekt, waardoor uw DS-Lite-bezoekers het trage pad nemen.

Wanneer Frankfurt de verkeerde keuze is

• Uw gebruikers bevinden zich in de Verenigde Staten. Bedien hen vanaf die locatie: een VPS in Dallas bevindt zich nabij het centrum van het land, en VPS-hosting in New York is de kortste route voor de oostkust en voor verkeer dat sowieso de Atlantische Oceaan oversteekt.
• Uw gebruikers bevinden zich in Latijns-Amerika. Frankfurt ligt verder van São Paulo dan van New York, dus een VPS in Brazilië is het eerlijke antwoord voor die doelgroep.
• Uw data moet binnen een specifiek land buiten de EU blijven. Overheidsprojecten in Canada zijn een veelvoorkomend voorbeeld, en wat werkelijk van belang is voor Canadese VPS-hosting behandelt de vereisten voor gegevensresidentie aldaar.
• U beheert een gameserver. Spelers merken elke milliseconde aan round-trip time, dus nabijheid tot de spelers is belangrijker dan elke andere specificatie: het kiezen van een VPS voor gameservers gaat hier dieper op in.

Voor een Europees publiek dat verspreid is over meerdere landen, is Frankfurt de veilige keuze voor één locatie. Deze keuze blijft veilig naarmate u groeit, omdat de netwerken die u moet bereiken zich al op het knooppunt bevinden. Meet de prestaties vanaf de locatie van uw gebruikers voordat u migreert en doe dit opnieuw erna; bewaar beide sets cijfers.

FAQ

Is één VPS in Frankfurt voldoende voor heel Europa?

Voor de meeste projecten wel. De hemelsbrede afstand legt een ondergrens van 12.0 ms naar Stockholm en 14.2 ms naar Madrid, en werkelijke verbindingen zijn ongeveer 1,5 tot 2 keer zo traag als deze ondergrens. Hierdoor blijft vrijwel de gehele EU binnen een bereik van enkele tientallen milliseconden van een server in Frankfurt. Voeg pas een tweede locatie toe wanneer u daadwerkelijke klachten uit een specifiek land heeft gemeten, of wanneer u failover nodig heeft in plaats van snelheid.

Maakt hosting in Frankfurt mijn project AVG-compliant?

Nee. De AVG is van toepassing op basis van wiens persoonsgegevens u verwerkt en waar u bent gevestigd, niet op de locatie van de server. Hosting in de EU neemt de vraag over internationale doorgifte voor die specifieke stap weg; dit is een vereenvoudiging en het enige voordeel. U heeft nog steeds een wettelijke grondslag, werkende rechten voor betrokkenen, een bewaartermijn, beveiligingsmaatregelen, een meldplicht bij datalekken binnen 72 uur en een verwerkersovereenkomst met uw provider nodig (in Duitsland een AVV genoemd). Dit is algemene informatie, geen juridisch advies.

Welke latency kan ik verwachten tussen Frankfurt en Berlijn?

De twee steden liggen 424 km uit elkaar, wat een harde ondergrens van 4.2 ms aan round-trip time oplevert. Een goed verbonden pad meet doorgaans 1,5 tot 2 keer deze ondergrens. Controleer dit met ping -c 20 your-server.example.com vanaf een verbinding in Berlijn en lees de avg-waarde in de rtt min/avg/max/mdev-regel. Een resultaat dat ver boven dit bereik ligt, betekent meestal dat het verkeer Duitsland heeft verlaten en weer is teruggekeerd, wat mtr -rwzc 50 u zal tonen in de namen van de hops.

Moet ik de tijdzone van mijn server in Frankfurt instellen op Europe/Berlin?

Doorgaans niet. Houd het systeem op UTC zodat logs vergelijkbaar blijven en tijdstempels niet dubbelzinnig zijn. Duitsland schakelt in het voorjaar over naar CEST en in het najaar terug naar CET; in de nacht van de herfstschakeling komt een lokaal uur twee keer voor, waardoor twee verschillende gebeurtenissen hetzelfde lokale tijdstempel kunnen krijgen. Formatteer tijden in de lokale zone binnen uw applicatie, waar u de context heeft om dit correct te doen. Als u de gehele server toch op lokale tijd wilt instellen, voer dan sudo timedatectl set-timezone Europe/Berlin uit en verifieer dit met timedatectl.

Is een server met alleen IPv4 een probleem voor Duitse bezoekers?

Het zal werken, maar voor sommigen is het trager. Verschillende Duitse ISP's voorzien consumentenverbindingen van een DS-Lite-configuratie zonder publiek IPv4-adres. Deze klanten bereiken een IPv4-only server via de vertaal-gateway van de provider, wat latency toevoegt en op drukke momenten voor opstoppingen zorgt. Het publiceren van een AAAA-record en het luisteren op IPv6 biedt hen een direct pad. Test dit met dig AAAA your-server.example.com +short en een curl -6-verzoek; verwacht een HTTP 200 van beide adresfamilies.