Por Matt Connor
VPS en Frankfurt: latencia y GDPR en la UE
Comprueba quién se beneficia de un VPS en Frankfurt, la latencia real para Alemania y la UE, el peering de DE-CIX y qué implica para el GDPR.
Para quién es el alojamiento VPS en Frankfurt
El alojamiento VPS en Frankfurt es adecuado para proyectos cuyos usuarios se encuentran en Alemania, en el mercado germanoparlante más amplio o distribuidos por la Unión Europea. Frankfurt es uno de los puntos donde se conectan las redes europeas y se intercambian directamente el tráfico, por lo que un servidor ubicado allí llega a la mayor parte del continente en unas pocas decenas de milisegundos. Si la mayoría de sus usuarios está en Norteamérica, un servidor europeo les parecerá lento por muy rápida que sea la máquina, porque la distancia establece un límite mínimo que ningún ajuste puede eliminar.
Dos preguntas independientes determinan la ubicación, y mezclarlas es lo que lleva a tomar malas decisiones. La primera es dónde están sus usuarios; es una cuestión de distancia y tiempo de ida y vuelta. La segunda es dónde puede almacenarse legalmente sus datos; es una cuestión jurídica y contractual. Frankfurt ofrece una respuesta sólida a la primera pregunta para las audiencias europeas. Para la segunda, elimina un problema concreto, pero no resuelve nada más.
¿Por qué Frankfurt tiene una conectividad tan buena?
Frankfurt alberga DE-CIX (Deutsche Commercial Internet Exchange), un IXP (punto de intercambio de Internet) que se encuentra entre los mayores del mundo por tráfico máximo y por número de redes conectadas. Un IXP es una infraestructura de conmutación compartida dentro de un centro de datos, donde redes independientes se conectan entre sí en lugar de pagar a una red más grande para transportar el tráfico entre ellas. DE-CIX publica sus estadísticas de tráfico actuales en su propio sitio, y esas cifras cambian. Consulte allí los datos en lugar de confiar en una cifra copiada en un artículo.
El efecto práctico depende de las rutas, no de los totales. Cuando la red de su proveedor y el ISP (proveedor de servicios de Internet) de su visitante están conectados al mismo intercambio, el tráfico entre ellos atraviesa un único salto de enrutamiento en ese intercambio. Si no intercambian tráfico localmente, el tráfico debe llegar a una tercera red que transporte el tráfico de ambas, y el punto de interconexión más cercano de esa red puede estar en otro país. Dos redes alemanas que intercambian tráfico a través de Ámsterdam o Londres recorren dos veces la distancia adicional, una en cada dirección. Los ingenieros de redes llaman a esto tromboning, y suele ser la razón por la que un servidor cercano parece estar muy lejos.
Puede comprobarlo en lugar de suponerlo. Ejecute mtr contra su servidor desde la red que le interese y lea los nombres de los saltos en el DNS inverso. Los nombres de host de los routers suelen incluir códigos de aeropuerto IATA. Por eso, fra en un nombre de salto significa Frankfurt, ams significa Ámsterdam y lhr significa Londres. Una ruta desde una conexión de consumidor alemana hasta un servidor alemán que muestre lhr en el centro indica exactamente dónde se produjeron esos milisegundos adicionales.
¿Qué distancia hay entre Frankfurt y sus usuarios?
La luz en la fibra óptica viaja aproximadamente a dos tercios de su velocidad en el vacío, cerca de 200,000 kilómetros por segundo. Un viaje de ida y vuelta recorre la distancia dos veces, por lo que el tiempo mínimo posible de ida y vuelta para una distancia de d kilómetros es d/100 milisegundos. Ese es el límite inferior y resulta útil porque no es posible superarlo.
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
}
]Estos valores se calculan a partir de la distancia en línea recta, no mediante mediciones. Interprete la última columna como el mejor caso que permite la física. Las mediciones reales suelen situarse entre 1.5 y 2 veces ese límite inferior, porque la fibra sigue carreteras y valles fluviales en lugar de grandes círculos, y porque cada router de la ruta añade un pequeño retraso de reenvío y encolado.
Berlín está a 424 km de Frankfurt, con un límite inferior de 4.2 ms. Madrid está a 1,419 km, con un límite inferior de 14.2 ms, y es el extremo más alejado de la UE desde aquí. Nueva York está a 6,206 km, con un límite inferior de 62.1 ms. Por eso, atender a usuarios transatlánticos es una decisión de ubicación y no un problema de ajuste.
¿Qué coste tiene un tiempo de ida y vuelta alto en la carga de una página?
Un viaje de ida y vuelta rara vez es sólo uno. Abrir una conexión HTTPS cuesta un viaje de ida y vuelta para el protocolo de enlace de TCP (transmission control protocol) y otro para el protocolo de enlace de TLS (transport layer security) 1.3. La petición requiere después un tercero antes de que llegue el primer byte de la respuesta. TLS 1.2 añade un cuarto. Una consulta DNS (domain name system) que no esté en caché añade al menos otro, además a un servidor diferente.
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
}
]La columna de viajes de ida y vuelta supone una ruta plausible hasta un servidor en Frankfurt, y la segunda columna hace la aritmética correspondiente: tres viajes de ida y vuelta antes del primer byte. Un usuario en Frankfurt espera 15 ms. Un usuario en Singapur, con un tiempo de ida y vuelta de 170 ms, espera 510 ms la misma respuesta, antes de que el navegador haya dibujado nada.
El multiplicador es el aspecto fundamental. Cada milisegundo adicional de RTT (round-trip time) cuesta aproximadamente tres milisegundos antes del primer byte, y el coste continúa después. El HTML indica una hoja de estilos, y la hoja de estilos indica una fuente. Cada uno de esos descubrimientos añade otro viaje de ida y vuelta en la misma conexión. Añadir un par de cientos de milisegundos de distancia convierte una página que parecía instantánea en una página lenta, aunque el servidor haga exactamente el mismo trabajo en exactamente el mismo tiempo.
Esto también muestra el límite de lo que puede solucionar una CDN (content delivery network). Los archivos estáticos servidos desde una caché cercana al usuario evitan la ruta larga. Un panel autenticado que tiene que consultar la base de datos no: esa petición sigue recorriendo toda la distancia dos veces. Colocar el origen cerca de las personas que inician sesión es algo que ninguna caché puede hacer por usted.
¿Cómo mido esto desde donde están mis usuarios?
Ejecute estos comandos desde una máquina de la red que le interesa, preferiblemente una conexión doméstica o de oficina del país al que presta servicio. Medir desde otro servidor ubicado en otro centro de datos le informa sobre las rutas de los centros de datos, no sobre las de sus usuarios. Los comandos siguientes son ejemplos para ejecutarlos usted mismo: las únicas cifras de latencia sobre las que conviene actuar son las que ha medido.
ping -c 20 your-server.example.comLa línea de resumen muestra rtt min/avg/max/mdev = .... Consulte avg para el caso típico y mdev para el jitter, es decir, la variación entre paquetes. Un avg normal con un mdev alto indica que la ruta es inestable. Esto afecta más a las tareas interactivas, como SSH o la voz, que un promedio ligeramente superior.
sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com-r muestra un informe en lugar de la vista en tiempo real, -w mantiene intactos los nombres de host largos, -z muestra el número de AS (sistema autónomo) de cada salto y -c 50 envía cincuenta ciclos. Es normal que se muestre pérdida en un salto intermedio si no hay pérdida en el salto final; no es un fallo. Muchos routers limitan la tasa de las respuestas ICMP que generan para sí mismos, aunque reenvían correctamente el resto del tráfico. La pérdida que comienza en un salto y continúa en todos los saltos posteriores es una pérdida 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 contiene los segundos acumulados desde que comenzó la solicitud, por lo que debe interpretarlo mediante restas. time_namelookup corresponde a DNS. time_connect menos ese valor corresponde al handshake TCP, que se aproxima a un viaje de ida y vuelta. time_appconnect menos time_connect corresponde al handshake TLS. time_starttransfer menos time_appconnect corresponde al tiempo de procesamiento de la propia aplicación más otro viaje de ida y vuelta. Si las diferencias son pequeñas y total sigue siendo grande, el problema está en su código, no en la ciudad.
Para medir el rendimiento en lugar de la latencia, ejecute iperf3 -s en el VPS, abra su puerto en el firewall y ejecute iperf3 -c your-server.example.com -R desde el cliente para probar la dirección de descarga. Para medir desde lugares donde no tiene una máquina, RIPE Atlas proporciona sondas distribuidas por Europa. Al comparar dos servidores en lugar de dos redes, utilice un método fijo y no cifras aisladas; para eso sirve una prueba de rendimiento de VPS reproducible.
¿Un servidor en Frankfurt hace que mi proyecto cumpla el RGPD?
No, y conviene explicar el motivo con precisión. El RGPD (Reglamento General de Protección de Datos) se aplica en función de los datos personales que procesa y del lugar donde está establecida su organización, no del país donde se encuentra el hardware. Mover un servidor a Frankfurt no garantiza el cumplimiento, y ejecutar uno fuera de la UE no lo incumple automáticamente. La ubicación es uno de varios factores.
El alojamiento dentro de la UE o del EEE (Espacio Económico Europeo) elimina la cuestión de las transferencias internacionales. El reglamento dedica un capítulo completo al envío de datos personales fuera del EEE, que requiere un instrumento jurídico como una decisión de adecuación o cláusulas contractuales tipo. Los datos que permanecen en Frankfurt no se transfieren, por lo que ese capítulo no se aplica a ese tramo. Esta es una simplificación real y representa exactamente el alcance del beneficio.
Todo lo demás sigue siendo responsabilidad suya. Necesita una base jurídica para cada finalidad, derechos de acceso y supresión operativos para las personas de su base de datos, un límite de conservación que aplique realmente, medidas de seguridad adecuadas al riesgo y una notificación a la autoridad de control en un plazo de 72 horas desde que tenga conocimiento de una violación de datos personales. También necesita un acuerdo de encargado del tratamiento con su proveedor de hosting, conocido en Alemania como Auftragsverarbeitungsvertrag o AVV. Tenga en cuenta que un servidor en Frankfurt todavía puede implicar una transferencia si el personal de soporte situado fuera del EEE puede acceder a él, así que compruebe quién controla las claves.
Alemania añade su propia capa: la BDSG (Bundesdatenschutzgesetz) federal complementa el reglamento con normas nacionales, y los datos de empleados son el ámbito que más suele sorprender. Esta sección ofrece información general y no constituye asesoramiento jurídico. El Comité Europeo de Protección de Datos publica las directrices oficiales en edpb.europa.eu, y cualquier asunto con consecuencias reales merece la revisión de un asesor cualificado, no sólo la de un tutorial.
¿Qué debo cambiar en el propio servidor?
Mantenga el reloj del sistema en UTC (tiempo universal coordinado) y dé formato a las marcas de tiempo en la aplicación. Alemania aplica el horario de verano, por lo que la hora local cambia una hora dos veces al año y una hora se repite a finales de octubre. Los registros escritos en hora local contienen dos entradas de las 02:30 esa noche, y correlacionarlas entre regiones se convierte en una tarea de suposición. Si aun así quiere usar la hora local en el equipo, configúrela explícitamente y compruébela:
sudo timedatectl set-timezone Europe/Berlin
timedatectlLa salida debe mostrar Time zone: Europe/Berlin (CEST, +0200) en verano y +0100 en invierno.
El texto alemán se ordena incorrectamente con la configuración regional C predeterminada, porque la ordenación C compara bytes sin procesar. Genere la configuración regional y observe la diferencia:
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 sortLa primera ordenación coloca Äpfel después de Zebra, porque su primer byte en UTF-8 es mayor que el de cualquier letra ASCII. La segunda lo coloca junto a Apfel, donde lo espera un lector alemán. Esto importa más de lo que parece, porque PostgreSQL y MySQL fijan una intercalación cuando se crea la base de datos, y cambiarla después implica reconstruir los índices. Decídalo antes de cargar los datos.
Un mirror de paquetes alemán acorta las descargas de apt. En Ubuntu 24.04, las fuentes se encuentran en /etc/apt/sources.list.d/ubuntu.sources con formato deb822, así que cambie la línea URIs: por http://de.archive.ubuntu.com/ubuntu/ en lugar de añadir un segundo archivo. Añadir uno produce Target Packages ... is configured multiple times, que es el error de fuentes duplicadas de deb822 y detiene las actualizaciones hasta que lo resuelva.
Publique un registro AAAA. Algunos ISP alemanes proporcionan a las conexiones residenciales una configuración DS-Lite (dual-stack lite), en la que el cliente no tiene ninguna dirección IPv4 pública y su tráfico IPv4 atraviesa la gateway de traducción del operador. Esa gateway añade latencia y se congestiona en las horas punta, mientras que el tráfico IPv6 sale directamente. Compruebe ambas rutas después de configurar el registro:
dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/Un 200 del segundo comando significa que IPv6 funciona de extremo a extremo. Could not resolve host o un error de conexión significa que falta el registro o el listener, y que los visitantes con DS-Lite están usando la ruta lenta.
Cuando Frankfurt no es la opción adecuada
- Sus usuarios están en Estados Unidos. Sírvalos desde allí: un VPS en Dallas está cerca del centro del país, y el alojamiento VPS en Nueva York ofrece la ruta más corta para la costa este y para el tráfico que de todos modos cruza el Atlántico.
- Sus usuarios están en Latinoamérica. Frankfurt está más lejos de São Paulo que de Nueva York, por lo que un VPS en Brasil es la respuesta adecuada para ese público.
- Sus datos deben permanecer dentro de un país específico fuera de la UE. El trabajo para el sector público canadiense es el caso habitual, y lo que realmente importa del alojamiento VPS en Canadá explica los requisitos de residencia allí.
- Ejecuta un servidor de juegos. Los jugadores perciben cada milisegundo del tiempo de ida y vuelta, por lo que la proximidad a ellos tiene prioridad sobre cualquier otra especificación: elegir un VPS para servidores de juegos lo explica.
Para un público europeo distribuido entre varios países, Frankfurt es la opción única más segura y sigue siéndolo a medida que crece, porque las redes a las que necesita llegar ya están conectadas al punto de intercambio. Mida desde la ubicación de sus usuarios antes de realizar el cambio y vuelva a medir después. Conserve ambos conjuntos de valores.
FAQ
¿Es suficiente un VPS en Frankfurt para toda Europa?
Para la mayoría de los proyectos, sí. La distancia en línea recta establece un mínimo de 12.0 ms hasta Estocolmo y de 14.2 ms hasta Madrid. Las rutas reales suelen alcanzar entre 1.5 y 2 veces ese mínimo, por lo que casi toda la UE queda a una latencia de pocas decenas de milisegundos de un único servidor en Frankfurt. Añada una segunda ubicación cuando haya medido una incidencia real en un país concreto o cuando necesite conmutación por error en lugar de más velocidad.
¿Alojar mi proyecto en Frankfurt hace que cumpla el RGPD?
No. El RGPD se aplica según los datos personales que procese y el lugar donde esté establecido, no según la ubicación del servidor. Alojar el servicio en la UE elimina la cuestión de las transferencias internacionales para ese tramo, lo que supone una simplificación real y todo el beneficio que aporta. Aun así, necesita una base jurídica, mecanismos funcionales para ejercer los derechos de los interesados, un límite de conservación, medidas de seguridad, notificación de brechas en un plazo de 72 horas y un acuerdo de encargado del tratamiento con el proveedor, denominado AVV en Alemania. Esta es información general, no asesoramiento jurídico.
¿Qué latencia debo esperar entre Frankfurt y Berlín?
Las dos ciudades están separadas por 424 km. Esto establece un mínimo estricto de 4.2 ms de tiempo de ida y vuelta. Una ruta con buenas interconexiones suele medir entre 1.5 y 2 veces ese mínimo. Confírmelo con ping -c 20 your-server.example.com desde una conexión en Berlín y lea el valor de avg en la línea rtt min/avg/max/mdev. Un resultado muy superior a ese intervalo suele indicar que el tráfico salió de Alemania y regresó. mtr -rwzc 50 lo mostrará en los nombres de los saltos.
¿Debo configurar la zona horaria del servidor de Frankfurt como Europe/Berlin?
Normalmente no. Mantenga el sistema en UTC para que los registros sean comparables y ninguna marca de tiempo resulte ambigua. Alemania cambia a CEST en primavera y vuelve a CET en otoño. Durante la noche del cambio de otoño, una hora local ocurre dos veces, por lo que dos eventos distintos pueden tener la misma marca de tiempo local. Formatee las horas en la zona local desde la aplicación, donde dispone del contexto necesario para hacerlo correctamente. Si quiere que todo el sistema use la hora local, ejecute sudo timedatectl set-timezone Europe/Berlin y compruébelo con timedatectl.
¿Será un problema que el servidor sólo use IPv4?
Funcionará, pero será más lento para algunos usuarios. Varios ISP alemanes proporcionan a las conexiones residenciales una configuración DS-Lite sin una dirección IPv4 pública. Esos clientes llegan a un servidor que sólo usa IPv4 a través de la pasarela de traducción del operador, lo que añade latencia y provoca congestión en los periodos de mayor demanda. Publicar un registro AAAA y escuchar en IPv6 les proporciona una ruta directa. Pruébelo con dig AAAA your-server.example.com +short y una petición curl -6, y espere un HTTP 200 con ambas familias de direcciones.