Por qué su velocidad a servidores UE cae frente a Speedtest

Speedtest informa de 290 Mbit/s. Su velocidad real cuando trabaja con servidores de la UE sale más bien en 38 Mbit/s. Una diferencia de unas ocho veces cuesta pasarla por alto. Casi siempre se remonta a la larga ruta internacional, no a su equipo ni a nuestro servicio.

La versión corta

Speedtest y una conexión real con un servidor lejano miden cosas distintas. Speedtest comprueba la capacidad bruta de su línea por una ruta muy corta. El trabajo real con servidores de la UE depende de otra cosa. De la latencia y del estado de los enlaces internacionales que cruza su tráfico. Así que un resultado alto de Speedtest solo habla de la salud de su línea. La velocidad baja hacia la UE tiene otras dos raíces. La física de las conexiones a distancia y la carga de las redes de tránsito.

Qué aspecto tiene la diferencia

Aquí tiene una línea medida dos veces, con minutos de diferencia. Primero Speedtest, contra un servidor que eligió él solo.

Dos detalles de ese panel explican casi todo el número. En "Connections" pone "Multi", así que la cifra suma varios flujos a la vez. Y el servidor elegido está en su país. Ahora la misma línea contra los servidores que de verdad llevan los webinars. La medición sale del paso "Speed" de nuestro verificador de equipo.

La bajada cae unas ocho veces. La subida solo se desliza de 26 a 16, un descenso mucho más suave. Ninguna de las dos cifras habla de una línea averiada, y adónde va cada una lo explica el resto del artículo.

El segundo panel pide una lectura atenta. "TO YOU" es lo que recibe y "FROM YOU" lo que envía. ¿Presenta usted el webinar? Entonces la cifra que importa es "FROM YOU", porque su cámara, su micrófono y su pantalla viajan hacia arriba. Un asistente que solo mira depende de "TO YOU". En la medición de arriba la subida da 15,98 Mbit/s. Son unas diez veces lo que necesita un ponente.

Los rótulos de las capturas van en inglés, porque la interfaz se fotografió en su versión inglesa. En un Speedtest y un sistema en español llevan nombres en español y están en los mismos sitios.

Qué mide en realidad Speedtest

Speedtest está hecho para enseñar el número más alto que pueda. Su resultado solo refleja en parte el trabajo con servidores lejanos.

• Coge el servidor más cercano. Speedtest elige el nodo de menor latencia, casi siempre dentro de la red de su propio proveedor o en su ciudad. El tráfico hasta ahí va por una ruta corta y no toca ningún enlace internacional.
• Abre muchas conexiones a la vez. Speedtest levanta varios flujos TCP de golpe, normalmente de 4 a 16, y suma su velocidad. Así esquiva el límite de una sola conexión en las rutas largas, cosa que explica el apartado siguiente. Los programas reales trabajan a menudo con uno o dos flujos, y de esa ayuda no ven nada.
• La latencia es mínima. En una ruta corta el tiempo de ida y vuelta, o RTT, son unos pocos milisegundos, y TCP tiene tiempo de acelerar hasta la velocidad plena de la línea.

Speedtest enseña, pues, la capacidad de laboratorio de su línea. Lo que va a obtener intercambiando datos con un servidor de otro país no lo enseña.

Producto de ancho de banda por retardo y ventana TCP

La mayor parte de la diferencia se apoya en un solo mecanismo.

TCP envía los datos por ventanas. El emisor suelta un trozo de datos y espera la confirmación de que llegó antes de seguir. La velocidad máxima de una sola conexión TCP sale de una fórmula sencilla.

Velocidad = tamaño de ventana / latencia (RTT)

Para llenar la línea entera hace falta una ventana mayor. Tiene que igualar al menos el producto del ancho de banda por el retardo, o BDP.

BDP = ancho de banda × RTT

Pongamos los números de aquella línea de 290 Mbit/s. La latencia hasta un servidor de la UE ronda los 50 ms.

BDP = 290 000 000 bit/s × 0,05 s = 14 500 000 bits = 1,81 MB

O sea que en cada instante deben ir en vuelo unos 1,8 MB de datos para saturar la línea. ¿Uno de los dos lados se ha quedado con una ventana limitada, es decir los clásicos 64 KB sin escalado de ventana? Entonces el techo de una sola conexión sale así.

Velocidad = 65 536 bytes × 8 bit / 0,05 s ≈ 10,5 Mbit/s

Por eso una sola conexión con un servidor lejano se topa con un techo de 10 a 20 Mbit/s. Y eso aunque la línea esté valorada en cientos de megabits. En una ruta corta con un RTT de 2 ms esa misma ventana daría más de 260 Mbit/s. Por eso el problema nunca asoma en Speedtest. Cuanto mayor es la latencia, más fuerte es el efecto. Aquí no hay nada roto, el protocolo funciona así.

Latencia y física de los enlaces largos

La latencia de una ruta larga se compone de varias partes, y algunas no hay forma de quitarlas.

La luz viaja por la fibra óptica a unos 200 000 km/s. Va bastante más despacio que en el vacío por el índice de refracción del vidrio. Cada mil kilómetros de ruta añaden unos 5 ms en un sentido, o sea unos 10 ms de ida y vuelta. Además, las rutas reales rara vez van en línea recta, así que suelen ser más largas que la distancia geográfica.

Luego está el retardo de cada nodo intermedio. Cada router procesa el paquete, lo pone en cola y lo manda adelante. Camino de un servidor de la UE suele haber de 10 a 20 nodos de estos, llamados saltos. Cada uno pone su parte. Cuanto mayor es el RTT resultante, más bajo queda el techo de una sola conexión según la fórmula de arriba.

Pérdida de paquetes y su efecto en TCP

Incluso una pérdida pequeña de paquetes en un enlace internacional recorta con dureza la velocidad final. TCP lee un paquete perdido como señal de congestión, así que baja el ritmo y luego vuelve a subirlo. Esa relación la describe la ecuación de Mathis.

Velocidad ≈ MSS / (RTT × √p)

MSS es el tamaño máximo de segmento, unos 1460 bytes por lo común. RTT es la latencia y p es la fracción de paquetes perdidos. La velocidad cae de forma inversa a la raíz cuadrada de la tasa de pérdida, y depende directamente de la latencia.

En la práctica las cifras asustan. Tome un RTT de 50 ms y un MSS normal. Ya un 0,1 por ciento de pérdida deja una sola conexión en unos 7 Mbit/s. Un uno por ciento la baja hasta unos 2,3 Mbit/s. Un dos por ciento la hunde por debajo de 1,7 Mbit/s. En las rutas largas de tránsito, una pérdida del 1 al 2 por ciento en hora punta es de lo más normal. Donde llega a esos valores, muerde más fuerte que el límite de ventana de arriba. De ahí que una ruta apenas lenta por la mañana se vuelva inservible por la tarde.

Enrutamiento y peering

El camino que toma su tráfico hasta un servidor de la UE no es directo. Pasa por una cadena de operadores y por el protocolo de enrutamiento BGP. Ese protocolo elige ruta por motivos comerciales y técnicos, no por la distancia más corta.

De ahí salen varios problemas típicos. Una ruta puede irse por un tercer país habiendo un camino más corto. Suben entonces la latencia y el riesgo de pérdida. El tráfico cruza además las junturas entre redes, es decir puntos de peering y enlaces de tránsito. Una juntura saturada es justo donde cae la velocidad. También abunda el enrutamiento asimétrico, con paquetes que salen por un camino y vuelven por otro, y eso enturbia cualquier diagnóstico. La capacidad internacional, encima, se compra, así que al proveedor que ahorró le falta en la hora punta.

Saturación de los enlaces internacionales de su proveedor

El tráfico local, por la ciudad y por el país, va sobrado de capacidad en casi todos los proveedores. Por eso Speedtest contra un servidor cercano siempre saca un número alto. Los enlaces internacionales son más caros y se compran en volumen limitado. En la punta de la tarde se convierten en el cuello de botella. Eso explica que la velocidad hacia la UE dé bandazos a lo largo del día. El Speedtest local, mientras tanto, se mantiene alto.

Otros factores técnicos

Además de las causas principales, unas cuantas cosas más afectan a la velocidad hacia un servidor lejano.

MTU y fragmentación. Si el MTU de la ruta es menor de lo esperado, los paquetes se fragmentan y la eficiencia baja. Un PMTUD mal configurado, es decir el descubrimiento del MTU del camino, lleva a agujeros negros y a transferencias colgadas.

Bufferbloat. Los búferes inflados de los nodos intermedios suben la latencia bajo carga. Además despistan a los algoritmos de control de flujo de TCP. La velocidad real baja todavía más.

Modelado y priorización, o QoS. Algunos proveedores recortan o postergan a propósito el tráfico internacional, o un tipo concreto de tráfico. Eso se ve directamente en su velocidad.

Sobrecarga de los protocolos. Las cabeceras de TCP, IP y del cifrado se comen parte del ancho de banda. En una ruta corta esto no se ve. Junto con la pérdida y la latencia de una ruta larga, suma bastante.

Su propio entorno. Wi-Fi en vez de cable, un router doméstico sobrecargado, un antivirus o una VPN en el equipo bajan la velocidad real. Descarte eso primero, antes de buscar la avería lejos.

Por qué esto no es un problema del equipo ni del servicio

Un resultado alto de Speedtest demuestra que su equipo y su línea local están sanos y dan la velocidad debida. La caída al trabajar con servidores de la UE viene de otro sitio. La culpa es de la latencia de la ruta larga. Y del límite de ventana de una sola conexión TCP. También de la pérdida de paquetes y del estado de los enlaces internacionales de su proveedor. Todo eso queda fuera de nuestro servicio y fuera de su equipo. Vive en el tramo de red entre su proveedor y los operadores troncales.

Y una cosa más antes de correr detrás de las cifras. Un webinar necesita mucho menos que una transferencia de archivos, así que 20 Mbit/s hacia la UE nos valen de sobra. Un ponente necesita unos 1,6 Mbit/s de subida, o 3,2 mientras comparte pantalla. Un asistente necesita bastante para recibir a cada ponente en el aire. Todo eso lo desglosan los requisitos técnicos. Aquí la estabilidad importa más que la velocidad bruta. ¿Sus eventos van sobre ruedas? Entonces la diferencia con Speedtest es una curiosidad, no una avería que arreglar.

Cómo comprobarlo usted

Unas cuantas comprobaciones señalan la causa.

• Lance Speedtest a mano y elija un servidor de Alemania o de Finlandia. Todos nuestros servidores están en la UE, entre Alemania, Francia, los Países Bajos y Finlandia. El tráfico de los webinars lo llevan las máquinas alemanas y finlandesas. Las neerlandesas y las francesas envían los correos de invitación a los eventos próximos, así que medir contra ellas le habla de una ruta por la que sus webinars no pasan. Alemania y Finlandia le enseñan la velocidad real por la ruta de trabajo, no la que hay hasta el servidor local más cercano.
• Siga la ruta. El comando tracert en Windows, o traceroute en macOS y Linux, contra nuestro servidor le da la cadena de nodos con la latencia de cada uno. La pérdida y la latencia se ven mejor con la utilidad mtr, o WinMTR en Windows, y vale la pena dejarla trabajando unos minutos en hora punta.
• Compare una conexión con varias. ¿La descarga en varios flujos va rápida y en uno solo va lenta? Eso confirma el límite de ventana TCP en la ruta larga.
• ¿Tiene medios técnicos? Mida el caudal hasta el nodo lejano directamente con iperf3, primero con un flujo y luego con varios.

Nuestro verificador de equipo enlaza además con una prueba aparte de calidad de internet, donde se ven velocidad, ping y jitter. Es una forma rápida de dejar constancia del estado de su línea en un momento dado.

Qué hacer

¿Sus comprobaciones muestran latencia alta o pérdida de paquetes en el tramo internacional? Vaya a su proveedor con datos concretos. Le harán falta la traza de la ruta y una lectura de mtr con la hora anotada. Corregir la ruta o ampliar la conectividad internacional es trabajo del proveedor. Por nuestra parte le damos las direcciones de nuestros servidores para un diagnóstico dirigido y le ayudamos a leer los resultados. Escríbanos por el chat en línea y se las enviamos.

En resumen

Un resultado de Speedtest cercano a 290 Mbit/s confirma que su línea está sana. La caída por debajo de 40 Mbit/s con los servidores de la UE es de esperar. Se apoya en la latencia de la ruta larga y en el límite de ventana de una sola conexión TCP. También en la pérdida de paquetes y en la carga de los enlaces internacionales de su proveedor. Esas causas se sientan en la red entre usted y nosotros, no en su equipo ni en nuestro servicio. Un diagnóstico simple de la ruta enseñará cuál de las cuatro hace el daño.

Preguntas frecuentes

¿Debo pagar por una línea más rápida para arreglar esto?

No. Un webinar necesita mucho menos que una transferencia de archivos, y 20 Mbit/s hacia la UE nos valen de sobra. Un ponente necesita unos 1,6 Mbit/s de subida, o 3,2 mientras comparte pantalla. Las cifras las desglosan los requisitos técnicos. Aquí la estabilidad importa más que la velocidad bruta. ¿Sus eventos van sobre ruedas? Entonces la diferencia con Speedtest es una curiosidad, no una avería que arreglar.

Mi bajada cayó ocho veces y mi subida apenas se movió. ¿Cuál importa?

La subida, si el que presenta es usted. Su cámara, su micrófono y su pantalla viajan hacia arriba, y esa es la cifra "FROM YOU". Un asistente que solo mira depende de "TO YOU". Una medición se lee distinto según su papel en el evento. En la lectura de arriba la subida solo se deslizó de 26 a 16 Mbit/s. Son unas diez veces lo que necesita un ponente.

¿Qué servidor de Speedtest elijo para una comparación justa?

Uno de Alemania o de Finlandia. Todos nuestros servidores están en la UE, entre Alemania, Francia, los Países Bajos y Finlandia. El tráfico de los webinars lo llevan las máquinas alemanas y finlandesas. Las neerlandesas y las francesas envían los correos de invitación a los eventos próximos. Medir contra ellas le habla de una ruta por la que sus webinars no pasan.

¿Hay algo de esto que pueda arreglar yo?

Empiece por su lado. Wi-Fi en vez de cable, un router doméstico sobrecargado, un antivirus o una VPN en el equipo bajan la velocidad real. ¿Está limpio y las comprobaciones siguen mostrando latencia alta o pérdida en el tramo internacional? Entonces el arreglo le toca a su proveedor. Vaya con datos concretos, es decir la traza de la ruta y una lectura de mtr con la hora anotada. Las direcciones de nuestros servidores para un diagnóstico dirigido se las damos nosotros, solo tiene que escribir al chat en línea.

¿Por qué la ruta va bien por la mañana y es inservible por la tarde?

Los enlaces internacionales se compran en volumen limitado y en la punta de la tarde se vuelven el cuello de botella. El tráfico local va sobrado. Por eso Speedtest contra un servidor cercano se mantiene alto todo el día. La pérdida de paquetes sigue la misma curva. Del 1 al 2 por ciento en rutas largas de tránsito durante la hora punta es de lo más normal. Con un RTT de 50 ms, un uno por ciento de pérdida sujeta una sola conexión en unos 2,3 Mbit/s. Eso convierte una ruta apenas lenta en una inservible.