Por qué las velocidades de VPN WireGuard disminuyen con una latencia elevada

Introducción

Muchos usuarios se sorprenden al conectarse desde otro país al servidor WireGuard de su router GL.iNet y descubrir que las velocidades de Internet son considerablemente inferiores a las velocidades simétricas de gigabit de su hogar o a las velocidades igualmente rápidas de su ubicación en el extranjero (p. ej., Airbnb). Por lo general, el responsable puede ser el ISP del servidor o del cliente. Sin embargo, la latencia suele pasarse por alto, pese a tener un impacto muy real y significativo en el rendimiento o en las velocidades de descarga/subida. Esta publicación pretende establecer expectativas realistas y explicar por qué disminuyen las velocidades cuando hay una latencia elevada (es decir, resultados de ping altos).

¿Qué es la latencia y por qué importa?

La latencia es el tiempo que tardan los datos en viajar desde tu dispositivo hasta el servidor VPN y regresar. Suele medirse en milisegundos (ms). Por ejemplo, si tu router GL.iNet en Vietnam se conecta a un servidor VPN en Texas, el tiempo de ida y vuelta (RTT) puede alcanzar fácilmente los 250-300 ms.

Aunque tu velocidad de Internet sea técnicamente «rápida», una latencia elevada puede limitar gravemente el rendimiento real de descarga y subida, especialmente al utilizar protocolos basados en TCP (como HTTPs, transferencias de archivos o la mayoría de las aplicaciones). Recuerda que, aunque WireGuard utiliza UDP, el tráfico que pasa por el túnel VPN (tráfico web, streaming, etc.) suele basarse en TCP. WireGuard encapsula esos datos TCP en UDP y los envía por Internet.

El cuello de botella de TCP: la capacidad de transferencia depende de la latencia

Esta es la fórmula clave que determina el rendimiento de TCP:

Tamaño de la ventana TCP = Velocidad de transferencia x RTT
Primero, algunas definiciones:

• Tamaño de ventana TCP es la cantidad de datos que tu sistema permite tener «en tránsito» (sin confirmar) antes de exigir una confirmación.
• Capacidad de transferencia es tu velocidad efectiva, es decir, la cantidad de datos por segundo que puedes enviar o recibir.
• RTT (tiempo de ida y vuelta) es el retraso entre el envío y la recepción de paquetes.

Un ejemplo real de un miembro del subreddit de GL.iNet

Supongamos que se encuentra en Vietnam y se conecta a tu servidor VPN WireGuard de casa, en Texas, que funciona en un router GL.iNet Flint 2.

• Ubicación del servidor: Texas, EE. UU.
  
  • Velocidades locales (fibra simétrica) 700 Mbps de descarga / 940 Mbps de subida
• Ubicación del cliente: Vietnam
  
  • Velocidades locales (sin VPN): 455 Mbps de descarga / 634 Mbps de subida
    
  • Velocidades locales (con el cliente VPN WireGuard activado): 47.3 Mbps de descarga / 12.1 Mbps de subida, 288 ms de ping

Primero, identifiquemos algunas limitaciones habituales de cualquier conexión de red:

1. Variaciones en el rendimiento del ISP y congestión en tu vecindario: podría observar variaciones de velocidad de 100 o más Mbps
2. Rendimiento de Wi-Fi: muy variable según el entorno físico, las interferencias de otros dispositivos inalámbricos, las capacidades del dispositivo cliente y la naturaleza inherentemente semidúplex del Wi-Fi (a diferencia de Ethernet, que es dúplex completo)
   • Para una explicación detallada del rendimiento real del Wi-Fi, lee aquí: https://www.wiisfi.com/ La 1.ª limitación está fuera de tu control. La 2.ª limitación también está en gran medida fuera de tu control, aunque podría eliminarse utilizando conexiones Ethernet por cable siempre que sea posible.

El producto ancho de banda-retardo

A primera vista, los resultados de las pruebas de velocidad VPN del lado del cliente pueden parecer decepcionantes, pero en realidad son bastante buenos dada la latencia. Esta es la explicación, utilizando la fórmula anterior:
Tamaño de ventana TCP = 47.3 Mbps x 0.288 segundos
　 　 　 　    = 13.6 Mb, o ~1.7 MB

Una ventana TCP de 1.7 MB es bastante grande, y alcanzarla en una conexión con una latencia de 288 ms significa que TCP funciona razonablemente bien. Pero ¿cómo es posible, si el campo original del tamaño de ventana TCP está limitado a tan solo 65,535 bytes (unos 64 KB)?

Escalado de ventana TCP para mejorar el rendimiento

La respuesta está en una función llamada TCP Window Scaling, introducida para admitir las redes modernas de gran ancho de banda y alta latencia. Como describe Microsoft en este artículo, el campo de tamaño de ventana TCP solo tiene 16 bits, lo que limita la ventana sin escalar a 65,535 bytes. Para superar este límite, RFC 7323 introdujo la opción de escalado de ventana TCP, que permite desplazar el tamaño de ventana hasta 14 bits a la izquierda, aumentando efectivamente el tamaño máximo de ventana a 1 GB. El factor de escalado se negocia durante el establecimiento de conexión TCP de tres pasos. Una vez habilitado, permite a los extremos multiplicar el tamaño original de ventana. Los algoritmos de control de congestión de los sistemas operativos de los dispositivos cliente trabajan constantemente para determinar el escalado correcto del tamaño de ventana. En algunos casos, como en el sistema operativo Microsoft Windows, el «ajuste automático» del tamaño de ventana funciona especialmente mal a la hora de maximizar el rendimiento de las descargas.

Ejemplo del efecto del tamaño de ventana TCP negociado por el OS y la latencia en el rendimiento Fuente: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Por qué no puedes seguir aumentando el tamaño de la ventana TCP sin más

En definitiva, el tamaño de la ventana TCP depende del ancho de banda disponible y del tiempo de ida y vuelta. Sin embargo, no basta con aumentar el tamaño de la ventana para obtener una mayor velocidad de transferencia. A partir de cierto punto, las ventanas más grandes requieren más memoria y capacidad de procesamiento tanto en el emisor como en el receptor, lo que puede sobrecargar los dispositivos y las redes y provocar una mayor pérdida de paquetes y una reducción del rendimiento.

Por tanto, en el escenario anterior, un tamaño de ventana TCP de unos 1.7 MB es bastante normal y refleja una conexión con buen rendimiento dada la elevada latencia. El límite superior general de aproximadamente 2 MB puede actuar como un límite práctico para muchos sistemas modernos, equilibrando el rendimiento y el uso de recursos. Con una ventana de 2 MB y una latencia de 288 ms, el rendimiento teórico máximo sería de aproximadamente 55.5 Mbps, lo que explica por qué resulta difícil superar esta velocidad aunque las conexiones a Internet de ambos extremos sean mucho más rápidas (servidor y cliente). Si reorganizamos las variables de la ecuación anterior para calcular el rendimiento, observará que con una latencia de 80 ms y una ventana de 2 MB podríamos alcanzar teóricamente unos 200 Mbps. Sin embargo, lamentablemente, las leyes de la física impiden alcanzar esa latencia debido a la distancia física (Texas <-> Vietnam).

Conclusión

Esperamos que la explicación de este artículo le ayude a tener expectativas más realistas sobre las velocidades de descarga y subida la próxima vez que utilices tu VPN WireGuard en el extranjero. Por último, recuerda que los routers gestionan muchas sesiones TCP simultáneas. Aunque el apreciado GL.iNet Flint 2 cuenta con una generosa RAM DDR4 de 1 GB, el router del lado del cliente conectado a ese Flint 2 puede tener mucha menos RAM y, por tanto, actuar como factor limitante del escalado del tamaño de la ventana TCP.

Para obtener más información y consejos sobre cómo resolver problemas y comprender tu configuración VPN de WireGuard, consulta la siguiente publicación del foro de GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Presentamos los routers domésticos GL.iNet