Von VPS in Frankfurt: Latenz, DE-CIX und DSGVO
Erfahren Sie, für wen ein VPS in Frankfurt sinnvoll ist, welche Latenzen Nutzer in Deutschland und der EU erwarten und was ein EU-Standort bei der DSGVO leistet.
Für wen sich VPS-Hosting in Frankfurt eignet
VPS-Hosting in Frankfurt eignet sich für Projekte, deren Nutzer in Deutschland, im weiteren deutschsprachigen Markt oder verteilt in der Europäischen Union sitzen. Frankfurt ist einer der Orte, an denen europäische Netzwerke zusammentreffen und den Netzwerkverkehr direkt untereinander weiterleiten. Deshalb erreicht ein Server dort den größten Teil des Kontinents innerhalb weniger Dutzend Millisekunden. Wenn sich Ihre Nutzer überwiegend in Nordamerika befinden, wird sich ein europäischer Server für sie langsam anfühlen, unabhängig davon, wie schnell die Maschine ist. Die Entfernung setzt eine untere Grenze für die Latenz, die sich durch Optimierung nicht beseitigen lässt.
Für die Standortwahl sind zwei getrennte Fragen entscheidend. Ihre Vermischung führt zu ungeeigneten Entscheidungen. Die erste Frage lautet, wo sich Ihre Nutzer befinden. Dabei geht es um Entfernung und Round-Trip-Zeit. Die zweite Frage lautet, wo Ihre Daten gespeichert werden dürfen. Dabei handelt es sich um eine rechtliche und vertragliche Frage. Frankfurt bietet für europäische Zielgruppen eine gute Antwort auf die erste Frage. Für die zweite Frage beseitigt Frankfurt ein konkretes Problem, klärt aber keine weiteren Aspekte.
Warum ist Frankfurt so gut angebunden?
In Frankfurt befindet sich DE-CIX (Deutsche Commercial Internet Exchange), ein IXP (Internet Exchange Point), der gemessen am Spitzenverkehr und an der Anzahl der angeschlossenen Netzwerke zu den größten der Welt gehört. Ein IXP ist eine gemeinsam genutzte Switching-Infrastruktur in einem Rechenzentrum. Dort verbinden sich unabhängige Netzwerke direkt miteinander, statt ein größeres Netzwerk dafür zu bezahlen, den Verkehr zwischen ihnen zu übertragen. DE-CIX veröffentlicht die aktuellen Verkehrsstatistiken auf der eigenen Website. Diese Werte ändern sich, daher sollten Sie sie dort nachlesen und nicht einer Zahl vertrauen, die aus einem Artikel übernommen wurde.
In der Praxis geht es um die Pfade, nicht um die Gesamtwerte. Wenn das Netzwerk Ihres Providers und der ISP (Internet Service Provider) Ihres Besuchers am selben Austauschpunkt angeschlossen sind, durchläuft der Verkehr zwischen ihnen an diesem Austauschpunkt nur einen gerouteten Hop. Wenn sie nicht lokal peeren, muss der Verkehr ein drittes Netzwerk erreichen, das beide Netze transportiert. Der nächstgelegene Übergabepunkt dieses Netzwerks kann in einem anderen Land liegen. Tauschen zwei deutsche Netzwerke über Amsterdam oder London Verkehr aus, fällt die zusätzliche Entfernung zweimal an, einmal in jede Richtung. Netzwerkingenieure nennen das Tromboning. Es ist der übliche Grund dafür, dass ein Server in der Nähe aus Sicht des Netzwerks weit entfernt wirkt.
Sie können das messen, statt es nur anzunehmen. Führen Sie mtr von dem für Sie relevanten Netzwerk aus und prüfen Sie die Hop-Namen im Reverse DNS. Router-Hostnamen enthalten häufig IATA-Flughafencodes. Daher steht fra in einem Hop-Namen für Frankfurt, ams für Amsterdam und lhr für London. Ein Pfad von einem deutschen Verbraucheranschluss zu einem deutschen Server, der in der Mitte lhr enthält, zeigt genau, wo die zusätzlichen Millisekunden entstanden sind.
Wie weit ist Frankfurt von Ihren Benutzern entfernt?
Licht bewegt sich in Glasfasern mit ungefähr zwei Dritteln seiner Vakuumgeschwindigkeit, also mit knapp 200.000 Kilometern pro Sekunde. Bei einer Hin- und Rückstrecke wird der Weg zweimal zurückgelegt. Die schnellstmögliche Hin- und Rücklaufzeit über eine Entfernung von d Kilometern beträgt daher d/100 Millisekunden. Das ist eine Untergrenze. Sie ist nützlich, weil sie physikalisch nicht unterschritten werden kann.
The data behind this chart
[
{
"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
}
]Diese Werte werden aus der Luftlinienentfernung berechnet und nicht gemessen. Die letzte Spalte zeigt den physikalisch möglichen Bestwert. Tatsächliche Messungen liegen meist beim 1,5- bis 2-Fachen dieser Untergrenze. Glasfasern verlaufen nicht entlang von Großkreisen, sondern folgen Straßen und Flusstälern. Außerdem verursacht jeder Router auf dem Weg eine geringe Weiterleitungs- und Warteschlangenverzögerung.
Berlin ist 424 km von Frankfurt entfernt. Die Untergrenze beträgt 4.2 ms. Madrid ist 1,419 km entfernt. Die Untergrenze beträgt 14.2 ms. Madrid ist damit von hier aus der am weitesten entfernte Punkt in der EU. New York ist 6,206 km entfernt. Die Untergrenze beträgt 62.1 ms. Deshalb ist ein transatlantisches Publikum eine Standortentscheidung und kein Optimierungsproblem.
Was kostet eine langsame Round-Trip-Zeit beim Laden einer Seite?
Eine Round-Trip-Zeit ist selten nur eine Round-Trip-Zeit. Der Aufbau einer HTTPS-Verbindung kostet eine Round-Trip-Zeit für den TCP-(Transmission Control Protocol-)Handshake und eine weitere für den TLS-(Transport Layer Security-)1.3-Handshake. Die Anfrage kostet eine dritte Round-Trip-Zeit, bevor das erste Byte der Antwort zurückkommt. TLS 1.2 fügt eine vierte hinzu. Eine DNS-(Domain Name System-)Abfrage, die noch nicht im Cache liegt, kostet mindestens eine weitere Round-Trip-Zeit, diesmal zu einem anderen Server.
The data behind this chart
[
{
"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
}
]Die Spalte für die Round-Trip-Zeit basiert hier auf der Annahme eines plausiblen Pfads zu einem Server in Frankfurt. Die zweite Spalte ist daraus berechnet: drei Round-Trip-Zeiten bis zum ersten Byte. Ein Benutzer in Frankfurt wartet 15 ms. Ein Benutzer in Singapur wartet bei 170 ms Round-Trip-Zeit 510 ms auf dieselbe Antwort, bevor der Browser überhaupt etwas gezeichnet hat.
Der Multiplikator ist der entscheidende Punkt. Jede zusätzliche Millisekunde RTT (Round-Trip-Zeit) kostet bis zum ersten Byte ungefähr drei Millisekunden. Danach wirkt sie weiter. Das HTML benennt ein Stylesheet, und das Stylesheet benennt eine Schriftart. Jede dieser Entdeckungen verursacht eine weitere Round-Trip-Zeit über dieselbe Verbindung. Ein paar hundert Millisekunden zusätzliche Entfernung machen aus einer Seite, die sich sofort anfühlt, eine Seite, die sich langsam anfühlt. Der Server führt dabei exakt dieselbe Arbeit in exakt derselben Zeit aus.
Damit ist auch festgelegt, was ein CDN (Content Delivery Network) beheben kann. Statische Dateien aus einem Cache in der Nähe des Benutzers vermeiden den langen Pfad. Ein angemeldetes Dashboard, das eine Anfrage an Ihre Datenbank stellen muss, tut das nicht: Diese Anfrage muss die gesamte Entfernung weiterhin zweimal durchqueren. Den Origin-Server in der Nähe der Personen zu platzieren, die sich anmelden, kann Ihnen kein Cache abnehmen.
Wie messe ich das von dem Standort aus, an dem sich meine Benutzer befinden?
Führen Sie diese Befehle auf einem Rechner in dem Netzwerk aus, das Sie untersuchen möchten, idealerweise über einen privaten oder geschäftlichen Anschluss in dem Land, in dem Sie Ihren Dienst anbieten. Eine Messung von einem anderen Server in einem anderen Rechenzentrum zeigt die Pfade zum Rechenzentrum, nicht die Ihrer Benutzer. Die folgenden Befehle sind Beispiele, die Sie selbst ausführen sollten: Aussagekräftig sind nur die Latenzwerte, die Sie selbst gemessen haben.
ping -c 20 your-server.example.comDie Zusammenfassungszeile lautet rtt min/avg/max/mdev = .... Lesen Sie avg für den typischen Wert und mdev für den Jitter, also die Abweichung zwischen den Paketen. Ein normaler avg mit einem hohen mdev weist auf einen instabilen Pfad hin. Das beeinträchtigt interaktive Anwendungen wie SSH oder Sprachkommunikation stärker als ein geringfügig höherer Durchschnittswert.
sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com-r gibt einen Bericht statt der Live-Anzeige aus, -w behält lange Hostnamen bei, -z zeigt die AS-Nummer (Autonomous System) jedes Hops an, und -c 50 sendet fünfzig Zyklen. Paketverlust bei einem mittleren Hop ist normal und kein Fehler, wenn am letzten Hop kein Verlust auftritt: Viele Router begrenzen die Rate der ICMP-Antworten, die sie für sich selbst erzeugen, während sie den übrigen Verkehr problemlos weiterleiten. Verlust, der bei einem Hop beginnt und bei jedem folgenden Hop bestehen bleibt, ist echter Paketverlust.
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/Jedes Feld enthält die kumulierte Zeit in Sekunden seit dem Start der Anfrage. Sie lesen den jeweiligen Wert daher durch Subtraktion ab. time_namelookup ist DNS. time_connect minus diesem Wert ist der TCP-Handshake, also ungefähr eine Round-Trip-Zeit. time_appconnect minus time_connect ist der TLS-Handshake. time_starttransfer minus time_appconnect ist die eigene Verarbeitungszeit Ihrer Anwendung plus eine weitere Round-Trip-Zeit. Wenn die Differenzen klein sind und total trotzdem groß ist, liegt das Problem an Ihrem Code und nicht am Standort.
Messen Sie für den Durchsatz statt für die Latenz iperf3 -s auf dem VPS. Öffnen Sie dessen Port in der Firewall, und führen Sie iperf3 -c your-server.example.com -R auf dem Client aus, um die Download-Richtung zu testen. Für Messungen von Standorten, an denen Ihnen kein Rechner zur Verfügung steht, bietet RIPE Atlas Sonden in ganz Europa. Wenn Sie zwei Server statt zwei Netzwerke vergleichen, verwenden Sie eine feste Methode statt einzelner Messwerte. Dafür eignet sich ein reproduzierbarer VPS-Benchmark.
Macht ein Server in Frankfurt mein Projekt DSGVO-konform?
Nein. Der Grund sollte präzise formuliert werden. Die DSGVO (Datenschutz-Grundverordnung) gilt abhängig davon, wessen personenbezogene Daten Sie verarbeiten und wo Ihre Organisation niedergelassen ist, nicht davon, in welchem Land die Hardware steht. Wenn Sie einen Server nach Frankfurt verlagern, entsteht dadurch keine Konformität. Der Betrieb eines Servers außerhalb der EU verstößt dagegen nicht automatisch gegen die DSGVO. Der Standort ist nur ein Faktor unter mehreren.
Hosting innerhalb der EU oder des erweiterten EWR (Europäischer Wirtschaftsraum) beseitigt jedoch die Frage des internationalen Datentransfers. Die Verordnung enthält ein eigenes Kapitel zur Übermittlung personenbezogener Daten außerhalb des EWR. Dafür ist ein Rechtsinstrument wie ein Angemessenheitsbeschluss oder Standardvertragsklauseln erforderlich. Daten, die in Frankfurt bleiben, werden auf diesem Übertragungsweg nicht übermittelt. Dieses Kapitel gilt daher für diesen Übertragungsweg nicht. Das ist eine echte Vereinfachung. Mehr ist der Vorteil jedoch nicht.
Alles Weitere bleibt Ihre Aufgabe. Sie benötigen für jeden Zweck eine Rechtsgrundlage, funktionierende Auskunfts- und Löschrechte für die Personen in Ihrer Datenbank, eine tatsächlich durchgesetzte Aufbewahrungsfrist, dem Risiko angemessene Sicherheitsmaßnahmen sowie eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden, nachdem Sie von einer Verletzung des Schutzes personenbezogener Daten Kenntnis erlangt haben. Außerdem benötigen Sie mit Ihrem Hosting-Anbieter einen Auftragsverarbeitungsvertrag, in Deutschland auch AVV genannt. Beachten Sie außerdem, dass ein Server in Frankfurt trotzdem einen Datentransfer umfassen kann, wenn Supportmitarbeiter außerhalb des EWR darauf zugreifen können. Prüfen Sie daher, wer Zugriff auf die kryptografischen Schlüssel hat.
Deutschland ergänzt die DSGVO um eine eigene Ebene: Das Bundesdatenschutzgesetz (BDSG) ergänzt die Verordnung durch nationale Regelungen. Beschäftigtendaten sind dabei der Bereich, der am häufigsten für Überraschungen sorgt. Dieser Abschnitt dient als allgemeiner Hintergrund und stellt keine Rechtsberatung dar. Der Europäische Datenschutzausschuss veröffentlicht die offiziellen Leitlinien unter edpb.europa.eu. Bei Angelegenheiten mit tatsächlichen rechtlichen Folgen sollten Sie eine qualifizierte Beratung in Anspruch nehmen und sich nicht auf ein Tutorial verlassen.
Was sollte ich direkt auf dem Server ändern?
Stellen Sie die Systemzeit auf UTC (koordinierte Weltzeit) ein und formatieren Sie Zeitstempel in Ihrer Anwendung. In Deutschland gilt die Sommerzeit. Die lokale Zeit wird daher zweimal jährlich um eine Stunde verschoben, und Ende Oktober wiederholt sich eine Stunde. In dieser Nacht enthalten Logs in lokaler Zeit zwei Einträge für 02:30. Die Zuordnung dieser Einträge über mehrere Regionen hinweg wird dadurch zur Raterei. Wenn Sie auf dem Server trotzdem die lokale Zeit verwenden möchten, setzen Sie sie explizit und prüfen Sie sie:
sudo timedatectl set-timezone Europe/Berlin
timedatectlDie Ausgabe sollte im Sommer Time zone: Europe/Berlin (CEST, +0200) und im Winter +0100 anzeigen.
Deutsche Texte werden unter dem Standardgebietsschema C falsch sortiert, weil die Sortierung in C rohe Bytes vergleicht. Erzeugen Sie das Gebietsschema und prüfen Sie den Unterschied:
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 sortBei der ersten Sortierung steht Äpfel hinter Zebra, weil sein erstes Byte in UTF-8 größer ist als jedes ASCII-Zeichen. Bei der zweiten Sortierung steht es neben Apfel, wo ein deutscher Leser es erwartet. Das ist wichtiger, als es zunächst wirkt. PostgreSQL und MySQL legen die Sortierung beim Erstellen der Datenbank fest. Eine spätere Änderung erfordert den Neuaufbau der Indizes. Legen Sie die Sortierung fest, bevor Sie Daten laden.
Ein deutscher Paket-Mirror verkürzt apt-Läufe. Unter Ubuntu 24.04 liegen die Quellen im deb822-Format in /etc/apt/sources.list.d/ubuntu.sources. Ändern Sie dort die Zeile URIs: in http://de.archive.ubuntu.com/ubuntu/, statt eine zweite Datei hinzuzufügen. Eine zusätzliche Datei erzeugt Target Packages ... is configured multiple times. Das ist der Fehler wegen doppelter deb822-Quellen und verhindert Aktualisierungen, bis Sie ihn beheben.
Veröffentlichen Sie einen AAAA-Record. Einige deutsche ISPs stellen Privatanschlüssen ein DS-Lite-Setup (Dual-Stack Lite) bereit. Dabei hat der Kunde überhaupt keine öffentliche IPv4-Adresse. Sein IPv4-Verkehr läuft stattdessen über das Übersetzungs-Gateway des Providers. Dieses Gateway erhöht die Latenz und ist zu Spitzenzeiten überlastet. IPv6-Verkehr läuft dagegen direkt nach außen. Prüfen Sie beide Pfade, nachdem Sie den Record gesetzt haben:
dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/Ein 200 des zweiten Befehls bedeutet, dass IPv6 durchgängig funktioniert. Could not resolve host oder ein Verbindungsfehler bedeutet, dass der Record oder der Listener fehlt. Besucher über DS-Lite verwenden dann den langsameren Pfad.
Wenn Frankfurt die falsche Wahl ist
- Ihre Benutzer befinden sich in den Vereinigten Staaten. Hosten Sie den Dienst dort: ein VPS in Dallas liegt nahe dem geografischen Zentrum des Landes, und VPS-Hosting in New York bietet für die Ostküste sowie für Datenverkehr, der ohnehin den Atlantik überquert, den kürzeren Weg.
- Ihre Benutzer befinden sich in Lateinamerika. Frankfurt ist weiter von São Paulo entfernt als von New York. Für diese Zielgruppe ist daher ein VPS in Brasilien die sachgerechte Wahl.
- Ihre Daten müssen innerhalb eines bestimmten Landes außerhalb der EU verbleiben. Der öffentliche Sektor in Kanada ist ein typischer Anwendungsfall. Was beim VPS-Hosting in Kanada tatsächlich wichtig ist behandelt die Datenresidenz dort.
- Sie betreiben einen Gameserver. Spieler nehmen jede Millisekunde der Round-Trip-Zeit wahr. Die Nähe zu den Spielern ist daher wichtiger als jede andere Spezifikation: die Auswahl eines VPS für Gameserver erklärt dieses Vorgehen.
Für eine über mehrere Länder verteilte europäische Zielgruppe ist Frankfurt die sichere Einzelwahl. Diese Wahl bleibt auch bei wachsender Infrastruktur sinnvoll, weil die benötigten Netzwerke bereits am Internetknoten erreichbar sind. Messen Sie die Werte vor dem Umzug und erneut danach vom Standort Ihrer Benutzer aus. Bewahren Sie beide Messreihen auf.
FAQ
Reicht ein VPS in Frankfurt für ganz Europa aus?
Für die meisten Projekte: ja. Die Luftlinienentfernung ergibt einen Mindestwert von 12.0 ms bis Stockholm und 14.2 ms bis Madrid. Reale Pfade erreichen etwa das 1,5- bis 2-Fache dieses Mindestwerts. Damit bleibt fast die gesamte EU innerhalb weniger niedriger zweistelliger Millisekunden von einem Server in Frankfurt. Fügen Sie einen zweiten Standort hinzu, wenn Sie eine konkrete Beschwerde aus einem bestimmten Land gemessen haben oder Failover statt höherer Geschwindigkeit benötigen.
Macht das Hosting in Frankfurt mein Projekt DSGVO-konform?
Nein. Die DSGVO richtet sich danach, wessen personenbezogene Daten Sie verarbeiten und wo Sie niedergelassen sind, nicht danach, wo der Server steht. Das Hosting in der EU beseitigt für diesen Übertragungsweg die Frage des internationalen Datentransfers. Das ist eine echte Vereinfachung und der gesamte daraus entstehende Vorteil. Sie benötigen weiterhin eine Rechtsgrundlage, funktionierende Betroffenenrechte, eine Aufbewahrungsfrist, Sicherheitsmaßnahmen, eine Meldung von Datenschutzverletzungen innerhalb von 72 Stunden sowie einen Auftragsverarbeitungsvertrag mit Ihrem Anbieter, in Deutschland AVV genannt. Dies sind allgemeine Informationen und keine Rechtsberatung.
Welche Latenz ist zwischen Frankfurt und Berlin zu erwarten?
Die beiden Städte liegen 424 km auseinander. Daraus ergibt sich ein physikalischer Mindestwert von 4.2 ms für die Round-Trip-Zeit. Ein gut angebundener Pfad misst typischerweise das 1,5- bis 2-Fache dieses Mindestwerts. Prüfen Sie dies mit ping -c 20 your-server.example.com über eine Verbindung aus Berlin und lesen Sie den Wert avg in der Zeile rtt min/avg/max/mdev ab. Ein deutlich höherer Wert bedeutet meist, dass der Netzwerkverkehr Deutschland verlassen hat und zurückgekehrt ist. mtr -rwzc 50 zeigt dies anhand der Namen der Hops.
Sollte ich die Zeitzone meines Frankfurter Servers auf Europe/Berlin setzen?
In der Regel nein. Lassen Sie das System auf UTC, damit Logs vergleichbar bleiben und kein Zeitstempel mehrdeutig ist. Deutschland wechselt im Frühjahr zu CEST und im Herbst zurück zu CET. In der Nacht der Umstellung im Herbst tritt eine lokale Stunde zweimal auf. Daher können zwei verschiedene Ereignisse denselben lokalen Zeitstempel tragen. Formatieren Sie Zeiten in Ihrer Anwendung in der lokalen Zeitzone. Dort verfügen Sie über den erforderlichen Kontext für eine korrekte Verarbeitung. Wenn der gesamte Server dennoch die lokale Zeit verwenden soll, führen Sie sudo timedatectl set-timezone Europe/Berlin aus und prüfen Sie das Ergebnis mit timedatectl.
Ist ein Server nur mit IPv4 ein Problem für Besucher aus Deutschland?
Er wird funktionieren, ist für einige Besucher jedoch langsamer. Mehrere deutsche ISPs stellen Privatkundenanschlüsse mit DS-Lite und ohne öffentliche IPv4-Adresse bereit. Diese Kunden erreichen einen Server nur mit IPv4 über das Übersetzungs-Gateway des Providers. Das erhöht die Latenz und führt zu Engpässen bei hoher Auslastung. Wenn Sie einen AAAA-Record veröffentlichen und auf IPv6 lauschen, erhalten diese Kunden einen direkten Pfad. Testen Sie dies mit dig AAAA your-server.example.com +short und einer curl -6-Anfrage. Von beiden Adressfamilien sollte eine HTTP-200-Antwort zurückgegeben werden.