VPS à Francfort : latence, peering et RGPD

Pour qui l’hébergement VPS à Francfort convient

L’hébergement VPS à Francfort convient aux projets dont les utilisateurs se trouvent en Allemagne, sur l’ensemble du marché germanophone ou répartis dans l’Union européenne. Francfort est l’un des points de rencontre des réseaux européens, qui y échangent directement le trafic. Un serveur situé à Francfort atteint donc la majeure partie du continent en quelques dizaines de millisecondes. Si vos utilisateurs se trouvent principalement en Amérique du Nord, un serveur européen leur semblera lent, quelle que soit la rapidité de la machine, car la distance impose une latence minimale que l’optimisation ne peut pas supprimer.

Deux questions distinctes déterminent le choix d’un emplacement. Les mélanger conduit à de mauvais choix. La première concerne l’emplacement de vos utilisateurs : c’est une question de distance et de temps aller-retour. La seconde concerne l’endroit où vos données peuvent légalement être stockées : c’est une question juridique et contractuelle. Francfort répond bien à la première question pour un public européen. Pour la seconde, il élimine un problème précis, mais ne règle rien d’autre.

Pourquoi Francfort est-il si bien connecté ?

Francfort héberge le DE-CIX (Deutsche Commercial Internet Exchange), un IXP (internet exchange point) qui figure parmi les plus importants au monde en matière de trafic de pointe et de nombre de réseaux connectés. Un IXP est une infrastructure de commutation partagée dans un datacenter, où des réseaux indépendants se connectent directement au lieu de payer un réseau plus important pour acheminer le trafic entre eux. Le DE-CIX publie ses statistiques de trafic actuelles sur son propre site. Ces chiffres évoluent. Consultez donc cette page plutôt que de vous fier à une valeur reprise dans un article.

L’effet pratique concerne les chemins réseau, pas les volumes totaux. Lorsque le réseau de votre fournisseur et l’ISP (internet service provider) de votre visiteur sont tous deux connectés au même exchange, le trafic entre eux traverse un seul saut routé au niveau de cet exchange. S’ils n’échangent pas leur trafic localement, celui-ci doit atteindre un troisième réseau qui les dessert tous les deux. Le point d’interconnexion le plus proche de ce réseau peut se trouver dans un autre pays. Deux réseaux allemands qui échangent leur trafic via Amsterdam ou Londres parcourent deux fois la distance supplémentaire, une fois dans chaque direction. Les ingénieurs réseau parlent alors de tromboning. C’est généralement la raison pour laquelle un serveur proche semble être très éloigné.

Vous pouvez le vérifier directement. Exécutez mtr vers votre serveur depuis le réseau qui vous intéresse, puis examinez les noms des sauts dans le reverse DNS. Les noms d’hôte des routeurs contiennent généralement des codes d’aéroport IATA. Ainsi, fra dans le nom d’un saut signifie Francfort, ams signifie Amsterdam et lhr signifie Londres. Un chemin entre une connexion grand public allemande et un serveur allemand qui contient lhr au milieu vous indique exactement où les millisecondes supplémentaires ont été consommées.

Quelle est la distance entre Francfort et vos utilisateurs ?

La lumière se propage dans la fibre à environ deux tiers de sa vitesse dans le vide, soit près de 200,000 kilomètres par seconde. Un aller-retour couvre deux fois la distance. Le temps minimal théorique d’un aller-retour sur une distance de d kilomètres est donc de d/100 millisecondes. Il s’agit d’une limite incompressible, utile parce qu’aucune optimisation ne peut la dépasser.

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

Ces valeurs sont calculées à partir de la distance en ligne droite, et non mesurées. Considérez la dernière colonne comme le meilleur cas autorisé par les lois de la physique. Les mesures réelles se situent généralement entre 1.5 et 2 fois cette limite, car les fibres suivent les routes et les vallées fluviales plutôt que les grands cercles, et parce que chaque routeur traversé ajoute un faible délai de forwarding et de mise en file d’attente.

Berlin se trouve à 424 km de Francfort, avec un temps minimal théorique de 4.2 ms. Madrid est à 1,419 km, avec un temps minimal théorique de 14.2 ms. C’est le point le plus éloigné de l’Union européenne depuis Francfort. New York se trouve à 6,206 km, avec un temps minimal théorique de 62.1 ms. C’est pourquoi une audience transatlantique relève d’un choix d’emplacement, et non d’un problème de tuning.

Quel coût représente un aller-retour lent pour le chargement d’une page ?

Un aller-retour n’est que rarement un seul aller-retour. L’ouverture d’une connexion HTTPS coûte un aller-retour pour le handshake TCP (transmission control protocol), puis un autre pour le handshake TLS (transport layer security) 1.3. La requête en nécessite ensuite un troisième avant la réception du premier octet de la réponse. TLS 1.2 en ajoute un quatrième. Une résolution DNS (domain name system) qui n’est pas déjà en cache en ajoute au moins un autre, vers un serveur différent.

[
  {
    "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 colonne des allers-retours repose ici sur l’hypothèse d’un chemin plausible vers un serveur situé à Francfort, et la deuxième colonne en applique le calcul : trois allers-retours avant le premier octet. Un utilisateur à Francfort attend 15 ms. Un utilisateur à Singapour, avec un temps aller-retour de 170 ms, attend 510 ms la même réponse, avant même que le navigateur n’ait affiché quoi que ce soit.

C’est le multiplicateur qui compte. Chaque milliseconde supplémentaire de RTT (round-trip time) coûte environ trois millisecondes avant le premier octet, puis continue de coûter du temps. Le HTML référence une feuille de style, la feuille de style référence une police, et chacune de ces découvertes ajoute un autre aller-retour sur la même connexion. Ajouter quelques centaines de millisecondes de distance transforme une page qui semblait instantanée en une page qui semble lente, alors que le serveur effectue exactement le même travail en exactement le même temps.

Cela fixe aussi la limite de ce qu’un CDN (content delivery network) peut résoudre. Les fichiers statiques servis depuis un cache proche de l’utilisateur évitent le long trajet. Un tableau de bord nécessitant une authentification, qui doit interroger votre base de données, ne l’évite pas : cette requête traverse toujours toute la distance deux fois. Placer l’origine près des utilisateurs qui se connectent est la seule partie qu’aucun cache ne peut prendre en charge à votre place.

Comment mesurer cela depuis l’emplacement de vos utilisateurs ?

Exécutez ces commandes depuis une machine située sur le réseau qui vous intéresse, idéalement une connexion domestique ou professionnelle dans le pays que vous desservez. Une mesure effectuée depuis un autre serveur, dans un autre datacenter, renseigne sur les chemins réseau vers les datacenters, pas sur ceux de vos utilisateurs. Les commandes ci-dessous sont des exemples à exécuter vous-même : les seules valeurs de latence qui méritent une action sont celles que vous avez mesurées.

ping -c 20 your-server.example.com

La ligne récapitulative affiche rtt min/avg/max/mdev = .... Consultez avg pour le cas habituel et mdev pour le jitter, c’est-à-dire la variation entre les paquets. Un avg normal avec un mdev élevé indique que le chemin est instable. Cela pénalise les usages interactifs, comme SSH ou la voix, davantage qu’une moyenne légèrement plus élevée.

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

-r affiche un rapport au lieu de l’affichage en temps réel, -w conserve les noms d’hôte longs dans leur intégralité, -z affiche le numéro d’AS (système autonome) de chaque saut et -c 50 envoie cinquante cycles. Une perte affichée sur un saut intermédiaire, sans perte sur le saut final, est normale et ne constitue pas une panne : de nombreux routeurs limitent le débit des réponses ICMP qu’ils génèrent eux-mêmes, tout en continuant à transmettre correctement le reste du trafic. Une perte qui commence sur un saut et se poursuit sur tous les sauts suivants est une perte réelle.

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/

Chaque champ correspond au nombre cumulé de secondes depuis le début de la requête. Il faut donc le lire par soustraction. time_namelookup correspond au DNS. time_connect moins cette valeur correspond à l’établissement de la connexion TCP, soit environ un aller-retour. time_appconnect moins time_connect correspond à l’établissement de la connexion TLS. time_starttransfer moins time_appconnect correspond au temps de traitement de votre application, auquel s’ajoute un aller-retour. Si les écarts sont faibles et que total reste élevé, le problème vient de votre code, pas de la ville.

Pour mesurer le débit plutôt que la latence, exécutez iperf3 -s sur le VPS, ouvrez son port dans le firewall, puis exécutez iperf3 -c your-server.example.com -R depuis le client pour tester le sens descendant. Pour mesurer depuis des emplacements où vous ne disposez pas de machine, RIPE Atlas fournit des probes réparties en Europe. Pour comparer deux serveurs plutôt que deux réseaux, utilisez une méthode fixe au lieu de mesures ponctuelles : c’est l’objectif d’un benchmark VPS reproductible.

Un serveur à Francfort rend-il mon projet conforme au RGPD ?

Non. La raison doit être formulée précisément. Le RGPD (Règlement général sur la protection des données) s’applique en fonction des personnes dont vous traitez les données personnelles et du lieu d’établissement de votre organisation, pas du pays où se trouve le matériel. Déplacer un serveur à Francfort ne crée pas la conformité. Exploiter un serveur en dehors de l’Union européenne ne constitue pas automatiquement une infraction. L’emplacement est un facteur parmi d’autres.

Héberger vos données dans l’Union européenne ou dans l’EEE (Espace économique européen) supprime toutefois la question du transfert international. Le règlement comporte tout un chapitre consacré à l’envoi de données personnelles en dehors de l’EEE. Un tel transfert nécessite un instrument juridique, comme une décision d’adéquation ou des clauses contractuelles types. Les données qui restent à Francfort ne sont pas transférées : ce chapitre ne s’applique donc pas à ce trajet. C’est une simplification réelle, et c’est l’ampleur exacte de cet avantage.

Tout le reste relève de votre responsabilité. Vous devez toujours disposer d’une base légale pour chaque finalité, garantir aux personnes enregistrées dans votre base l’exercice effectif de leurs droits d’accès et d’effacement, appliquer une durée de conservation que vous faites réellement respecter, mettre en place des mesures de sécurité adaptées au risque et notifier l’autorité de contrôle dans les 72 heures suivant la prise de connaissance d’une violation de données personnelles. Vous devez également conclure un accord de sous-traitance avec votre hébergeur, appelé en Allemagne Auftragsverarbeitungsvertrag ou AVV. Notez aussi qu’un serveur à Francfort peut tout de même faire intervenir un transfert si des membres du support situés en dehors de l’EEE peuvent y accéder. Vérifiez donc qui détient les clés.

L’Allemagne ajoute sa propre couche : la loi fédérale BDSG (Bundesdatenschutzgesetz) complète le règlement par des règles nationales, et les données des salariés sont le domaine qui surprend le plus souvent. Cette section fournit des informations générales et ne constitue pas un conseil juridique. Le Comité européen de la protection des données publie les lignes directrices officielles sur edpb.europa.eu. Pour toute décision ayant de réelles conséquences, consultez un conseiller qualifié plutôt que de vous limiter à un tutoriel.

Que dois-je modifier directement sur le serveur ?

Conservez l’horloge système en UTC (temps universel coordonné) et formatez les horodatages dans votre application. L’Allemagne applique l’heure d’été : l’heure locale change donc de 1 heure deux fois par an, et une heure se répète fin octobre. Les journaux écrits en heure locale contiennent deux entrées 02:30 cette nuit-là. Les corréler entre plusieurs régions devient alors aléatoire. Si vous voulez malgré tout utiliser l’heure locale sur le serveur, définissez-la explicitement et vérifiez-la :

sudo timedatectl set-timezone Europe/Berlin
timedatectl

La sortie doit afficher Time zone: Europe/Berlin (CEST, +0200) en été et +0100 en hiver.

Le tri du texte allemand est incorrect avec la locale C par défaut, car celle-ci compare les octets bruts. Générez la locale et observez la différence :

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

Le premier tri place Äpfel après Zebra, car son premier octet en UTF-8 est supérieur à celui de toute lettre ASCII. Le second le place à côté de Apfel, comme le prévoit un lecteur allemand. Ce point est plus important qu’il n’y paraît : PostgreSQL et MySQL définissent une collation lors de la création de la base de données, et la modifier ensuite impose de reconstruire les index. Prenez cette décision avant de charger les données.

Un miroir de paquets allemand raccourcit les téléchargements de apt. Sur Ubuntu 24.04, les sources se trouvent dans /etc/apt/sources.list.d/ubuntu.sources au format deb822. Modifiez donc la ligne URIs: pour utiliser http://de.archive.ubuntu.com/ubuntu/, au lieu d’ajouter un second fichier. En ajouter un vous donne Target Packages ... is configured multiple times, c’est-à-dire l’erreur de sources deb822 en double, et bloque les mises à jour jusqu’à sa résolution.

Publiez un enregistrement AAAA. Certains FAI allemands fournissent aux connexions grand public une configuration DS-Lite (dual-stack lite), dans laquelle le client ne possède aucune adresse IPv4 publique et où son trafic IPv4 traverse la passerelle de translation de l’opérateur. Cette passerelle ajoute de la latence et sature aux heures de pointe, tandis que le trafic IPv6 sort directement. Vérifiez les deux chemins après avoir créé l’enregistrement :

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

Un 200 dans la sortie de la seconde commande signifie que l’IPv6 fonctionne de bout en bout. Could not resolve host ou une erreur de connexion indique que l’enregistrement ou le listener est absent. Vos visiteurs utilisant DS-Lite empruntent alors le chemin lent.

Quand Francfort n’est pas le bon choix

• Vos utilisateurs se trouvent aux États-Unis. Hébergez le service sur place : un VPS à Dallas se trouve près du centre du pays, tandis que un hébergement VPS à New York offre le trajet le plus court vers la côte Est et pour le trafic qui traverse de toute façon l’Atlantique.
• Vos utilisateurs se trouvent en Amérique latine. Francfort est plus éloigné de São Paulo que de New York. Pour ce public, un VPS au Brésil est donc le choix logique.
• Vos données doivent rester dans un pays précis situé hors de l’UE. Les projets du secteur public canadien sont le cas le plus courant. Ce qui compte réellement pour un hébergement VPS au Canada traite de la résidence des données dans ce pays.
• Vous exploitez un game server. Les joueurs ressentent chaque milliseconde de latence aller-retour. La proximité avec eux prime donc sur toute autre caractéristique : choisir un VPS pour des game servers permet de le déterminer.

Pour un public européen réparti dans plusieurs pays, Francfort est le choix unique le plus sûr. Ce choix reste pertinent à mesure que vous grandissez, car les réseaux que vous devez atteindre sont déjà présents au point d’échange. Mesurez la latence depuis l’emplacement de vos utilisateurs avant le changement, puis de nouveau après. Conservez les deux séries de mesures.

FAQ

Un seul VPS à Francfort suffit-il pour toute l’Europe ?

Pour la plupart des projets, oui. La distance à vol d’oiseau donne un minimum de 12.0 ms jusqu’à Stockholm et de 14.2 ms jusqu’à Madrid. Les chemins réels représentent environ 1.5 à 2 fois ce minimum. Presque toute l’UE reste donc à quelques dizaines de millisecondes d’un serveur situé à Francfort. Ajoutez un deuxième site lorsque vous avez mesuré une plainte réelle dans un pays donné, ou lorsque vous avez besoin de failover plutôt que de vitesse.

Héberger mon projet à Francfort le rend-il conforme au RGPD ?

Non. Le RGPD s’applique selon les personnes dont vous traitez les données personnelles et selon le lieu où vous êtes établi, pas selon l’emplacement du serveur. Héberger dans l’UE supprime la question du transfert international pour ce tronçon. C’est une simplification réelle, mais c’est tout le bénéfice obtenu. Vous devez toujours disposer d’une base légale, garantir l’exercice effectif des droits des personnes concernées, définir une durée de conservation, appliquer des mesures de sécurité, notifier les violations dans un délai de 72 heures et conclure un accord de sous-traitance avec votre fournisseur, appelé AVV en Allemagne. Ces informations sont générales et ne constituent pas un avis juridique.

Quelle latence dois-je prévoir entre Francfort et Berlin ?

Les deux villes sont séparées de 424 km. Cela fixe un minimum incompressible de 4.2 ms pour le round-trip time. Un chemin correctement interconnecté mesure généralement 1.5 à 2 fois ce minimum. Vérifiez-le avec ping -c 20 your-server.example.com depuis une connexion située à Berlin et lisez la valeur avg sur la ligne rtt min/avg/max/mdev. Un résultat nettement supérieur à cette plage signifie généralement que le trafic a quitté l’Allemagne avant d’y revenir. mtr -rwzc 50 vous l’indiquera dans les noms des hops.

Dois-je régler le fuseau horaire de mon serveur de Francfort sur Europe/Berlin ?

En général, non. Laissez le système en UTC afin que les journaux restent comparables et qu’aucun timestamp ne soit ambigu. L’Allemagne passe à l’heure d’été CEST au printemps, puis revient à l’heure normale CET en automne. Pendant la nuit du changement d’automne, une heure locale se produit deux fois. Deux événements différents peuvent donc avoir le même timestamp local. Formatez les heures dans le fuseau local au niveau de votre application, où vous disposez du contexte nécessaire pour le faire correctement. Si vous souhaitez régler toute la machine sur l’heure locale, exécutez sudo timedatectl set-timezone Europe/Berlin et vérifiez avec timedatectl.

Un serveur IPv4 uniquement posera-t-il un problème aux visiteurs allemands ?

Il fonctionnera, mais il sera plus lent pour certains d’entre eux. Plusieurs FAI allemands fournissent aux connexions grand public une configuration DS-Lite sans adresse IPv4 publique. Ces clients accèdent donc à un serveur IPv4 uniquement via la passerelle de translation de l’opérateur, ce qui ajoute de la latence et crée de la congestion aux heures de pointe. Publier un enregistrement AAAA et écouter sur IPv6 leur fournit un chemin direct. Testez avec dig AAAA your-server.example.com +short et une requête curl -6, puis vérifiez que vous obtenez un HTTP 200 avec les deux familles d’adresses.