La pérdida de velocidad de las VPN, explicada: cuánto ralentiza realmente una VPN la conexión

Una VPN siempre cuesta algo de velocidad —unos pocos puntos porcentuales con un servidor cercano y un protocolo moderno, y un tercio o más con uno lejano y saturado y un protocolo antiguo—, pero el porcentaje que importa no es el del titular; es lo que queda de la propia conexión después del costo, medido frente a lo que realmente se hace en línea.

Una VPN siempre cuesta algo de velocidad, y la respuesta honesta es un rango, no una cifra: con un servidor cercano y un protocolo moderno como WireGuard, cabe esperar una pérdida de un solo dígito hasta aproximadamente un diez por ciento; con un servidor en otro continente, un servidor gratuito saturado o un protocolo antiguo, cabe esperar entre un veinte y un cincuenta por ciento, y en ocasiones más. Tres costos separados se suman hasta ese total: el desvío que el tráfico hace para llegar al servidor VPN y volver, el cifrado y la sobrecarga de paquetes que añade el túnel, y la cola que se forma cuando demasiados suscriptores comparten un mismo servidor. La explicación de Cloudflare sobre la velocidad de las VPN nombra las mismas tres causas: el tiempo de viaje adicional que denomina efecto trombón, la carga del servidor y el tiempo que lleva el cifrado. Qué costo domina en una conexión decide qué hay que corregir, y por eso nuestra clasificación de VPN pondera la velocidad tal como la encuentra un suscriptor en la práctica —primero el protocolo y después la distancia al servidor— en lugar de citar la mejor cifra de un proveedor.

Los tres costos, en el orden en que aparecen

El primer costo, y por lo general el mayor, es la geografía. Sin una VPN, una solicitud viaja hasta la copia más cercana de lo que se pidió, a menudo dentro del propio estado. Con una VPN, la descripción de la Comisión Federal de Comercio (FTC) se aplica al pie de la letra: los datos se dirigen primero a través de servidores controlados por el proveedor de la VPN, y solo después a su destino. Si ese servidor está en otro estado —u otro país, porque se eligió por su ubicación—, cada solicitud y cada respuesta hace el viaje dos veces: del usuario al servidor, del servidor al sitio, y de vuelta. Cloudflare llama a esto el efecto trombón, y señala que castiga con más fuerza en el caso absurdo: contactar con un centro de datos a pocos kilómetros de casa pasando por un servidor a mil millas. El segundo costo es el propio túnel: cifrar y descifrar cada paquete consume tiempo de procesador, y el túnel envuelve cada paquete en cabeceras adicionales, de modo que menos bytes de los que cruzan la línea son datos del usuario. El tercer costo es la compañía. Un servidor VPN es hardware compartido, y en el ejemplo de Cloudflare, un servidor capaz de atender 300 solicitudes a la vez, cuando se le pide servir a 1.000 usuarios a la vez, empieza a hacer cola y a descartarlas: todos los conectados se ralentizan. Los servicios gratuitos y de descuento concentran el mayor número de usuarios en el menor hardware, y de ahí suelen salir los porcentajes de horror.

El protocolo decide cuánto pesa el costo del túnel

La comparación publicada más clara procede del propio artículo técnico de WireGuard, que midió el protocolo frente a OpenVPN y dos configuraciones de IPsec con la herramienta estándar iperf3, sobre un enlace Ethernet gigabit, con un promedio de treinta minutos. WireGuard movió 1.011 megabits por segundo —saturando el cable en la práctica— mientras que OpenVPN, que se ejecuta en el espacio de usuario y copia cada paquete varias veces entre el núcleo y el espacio de usuario, alcanzó 258 megabits por segundo con el procesador del equipo de prueba al 100 por ciento. El ping contó la misma historia: 0,403 milisegundos para WireGuard, 1,541 para OpenVPN. Conviene leer esas cifras como lo que son —una medición cuidadosa de los protocolos, no del servicio de ninguna empresa— y la lección se mantiene: el protocolo fija el techo, y el techo de un protocolo moderno en el espacio del núcleo está muy por encima del de uno antiguo en el espacio de usuario. Las cuentas de los paquetes lo confirman. Un paquete de WireGuard lleva unos 60 bytes de sobrecarga sobre IPv4 —las cabeceras externas IP y UDP, los 16 bytes de campos de cabecera propios de WireGuard y una etiqueta de autenticación de 16 bytes—, y por eso su interfaz de túnel usa por defecto una MTU de 1.420 bytes dentro de un paquete estándar de 1.500. Sesenta bytes de 1.500 son el cuatro por ciento: el suelo bajo cualquier pérdida de WireGuard, la parte que ningún proveedor puede eliminar por ingeniería. Los protocolos más antiguos llevan más sobrecarga y gastan más tiempo de procesador por paquete; las aplicaciones que ejecutan OpenVPN sobre TCP, retransmitiendo los paquetes perdidos dos veces —una dentro del túnel y otra fuera—, muestran las pérdidas más pronunciadas en el uso ordinario, e IKEv2/IPsec, que según Cloudflare negocia las conexiones algo más rápido que las VPN basadas en SSL, se sitúa entre ambos.

La distancia es el costo que no se negocia

El rendimiento es solo la mitad de lo que significa «lento», y para gran parte de lo que se hace en línea es la mitad menor. El blog de ingeniería de Cloudflare lo plantea con claridad: los datos viajan por los cables troncales de fibra óptica a casi 200.000 kilómetros por segundo, y ninguna ingeniería lo acelera; la única forma de reducir el retraso es acortar la distancia. Esa misma publicación cita un estudio de simulación de Google que todo usuario de VPN debería conocer: una vez que una conexión supera unos 5 megabits por segundo, las páginas web apenas cargan más rápido aunque aumente el ancho de banda, mientras que la latencia sigue pagando: cada 20 milisegundos de tiempo de ida y vuelta eliminados mejoraron los tiempos de carga de las páginas en alrededor de un diez por ciento. Una VPN mueve ambas cifras en la dirección equivocada, pero no por igual. Un servidor cercano puede costar un cinco por ciento de un rendimiento que nunca se usaba y dos o tres milisegundos que nunca se notarán. Un servidor al otro lado de un océano puede añadir de cincuenta a ciento cincuenta milisegundos a cada clic, llamada y partida —un retraso que los ojos y los oídos notan al instante—, mientras el porcentaje de rendimiento, la cifra que titulan las pruebas de velocidad, sigue pareciendo respetable. Esa es la razón práctica del consejo habitual de conectarse al servidor más cercano que cumpla la función: no se persiguen megabits, se rehúsa pagar a precio de luz un desvío. A una videollamada no le importa que se conserve el 92 por ciento de la velocidad de descarga; le importa que la voz llegue ahora una décima de segundo más tarde, en cada sentido.

Cuándo importa el porcentaje y cuándo es un error de redondeo

Que una pérdida dada importe depende de lo que queda, y esa es una pregunta sobre la casa, no sobre la VPN. Haga las cuentas frente a lo que las actividades requieren en realidad. Las páginas de ayuda de YouTube recomiendan 5 megabits por segundo sostenidos para vídeo de 1080p y 20 para 4K. Un hogar con una conexión de 300 megabits que pierde un quince por ciento conserva unos 255 megabits —el equivalente a doce transmisiones 4K— y nunca verá la pérdida fuera de una prueba de velocidad. Ese mismo quince por ciento sobre una conexión rural de 25 megabits deja unos 21 megabits: una transmisión 4K, sin nada de sobra para la persona que está en una videollamada en la habitación de al lado. Ahí, la pérdida es la diferencia entre una configuración que funciona y una que se detiene a la hora de la cena. La subida merece la misma comprobación: las conexiones por cable suelen subir a una décima parte de su velocidad de bajada, y el porcentaje de la VPN se descuenta también de esa cifra pequeña, que es donde quienes trabajan desde casa enviando archivos grandes notan primero una VPN. Quienes juegan o hacen llamadas deberían vigilar del todo la otra cifra, la latencia añadida, porque su tráfico es escaso y sensible al tiempo. Y un caso va en dirección contraria: Cloudflare señala que una VPN puede ocasionalmente acelerar un servicio concreto, cuando un proveedor está limitando ese servicio, porque el cifrado lo oculta de la limitación. Una VPN no puede superar la línea sin limitar; solo puede superar una ruta limitada.

Medir la pérdida propia, con honestidad

Para saber qué cuesta una VPN, hay que medir la conexión que se tiene, no la de un anuncio. Haga una prueba de velocidad con la VPN desactivada y luego activada, una tras otra, a la misma hora del día, desde el mismo dispositivo, idealmente con cable al rúter para que la propia red Wi-Fi no sea la variable, y anote la latencia junto a la descarga y la subida, porque las dos pérdidas tienen correcciones distintas. Compare el servidor más cercano con el lejano que realmente se usa: si la pérdida cercana es pequeña y la lejana es grande, el problema es la geografía, y ningún cambio de proveedor la deroga. Si incluso el servidor más cercano cuesta un tercio de la velocidad, cambie el protocolo de la aplicación a WireGuard o a un modo basado en WireGuard antes de culpar al servicio —ese ajuste es el factor controlable mayor de este artículo— y repita la prueba a una hora más tranquila para separar el costo de carga del servidor del resto. Juzgue el resultado por el criterio de nuestra metodología: una pérdida es un problema cuando lo que queda no cumple una tarea que el hogar hace de verdad —una transmisión 4K que no se mantiene, una subida que pierde una fecha de entrega, una llamada que se pisa a sí misma—, no cuando un porcentaje simplemente parece grande. Quien compare servicios con ese criterio encontrará las mediciones, los protocolos y las redes de servidores en nuestra clasificación de VPN, dentro de las clasificaciones de software y servicios digitales completas.

Fuentes

• Donenfeld, Jason A. — «WireGuard: Next Generation Kernel Network Tunnel» (artículo de NDSS 2017, borrador de junio de 2020): WireGuard implementado para Linux en menos de 4.000 líneas de código; prueba iperf3 con promedio de treinta minutos sobre Ethernet gigabit: WireGuard, 1.011 Mbps de rendimiento y 0,403 ms de ping; IPsec, 881 y 825 Mbps; OpenVPN, 258 Mbps y 1,541 ms de ping, con la CPU al 100 % durante las pruebas de rendimiento de OpenVPN e IPsec: https://www.wireguard.com/papers/wireguard.pdf
• Cloudflare Learning Center — «How VPNs affect Internet speed»: las VPN añaden latencia por el efecto trombón (distancia de viaje adicional), la carga del servidor (con los servicios gratuitos y de descuento como los más afectados) y el cifrado; IKEv2/IPsec negocia algo más rápido que las VPN SSL; una VPN puede eludir la limitación que un proveedor aplique a un servicio concreto porque el cifrado oculta qué servicio se usa: https://www.cloudflare.com/en-ca/learning/access-management/vpn-speed/
• Cloudflare Blog — «Making home Internet faster has little to do with 'speed'»: los datos viajan a casi 200.000 kilómetros por segundo por los cables troncales de fibra óptica; la latencia se reduce acortando la distancia, no añadiendo ancho de banda; citando una simulación de Google de 2010, por encima de unos 5 Mbps las páginas web apenas cargan más rápido con más ancho de banda, mientras que cada 20 ms de reducción del tiempo de ida y vuelta mejoró los tiempos de carga en torno a un 10 %: https://blog.cloudflare.com/making-home-internet-faster
• Comisión Federal de Comercio (FTC) — «In the market for a VPN app?»: una VPN dirige los datos del dispositivo a través de servidores controlados por el proveedor de la VPN y puede cifrar los datos entre el dispositivo y el servidor, de modo que otros en una red pública solo ven galimatías; una VPN traslada la confianza al proveedor en lugar de volver anónimo al usuario: https://www.ftc.gov/business-guidance/blog/2018/02/market-vpn-app
• Ayuda de YouTube (Google Support) — «System requirements and supported devices for YouTube»: velocidades sostenidas recomendadas: 4K UHD, 20 Mbps; HD 1080p, 5 Mbps; HD 720p, 2,5 Mbps: https://support.google.com/youtube/answer/78358?hl=en-WS
• WireGuard — referencia de MTU y sobrecarga de paquetes (vía el artículo de Wikipedia sobre WireGuard): la sobrecarga se descompone en una cabecera IPv4 de 20 bytes (40 bytes en IPv6), una cabecera UDP de 8 bytes, 4 bytes de tipo, 4 bytes de índice de clave, 8 bytes de nonce y una etiqueta de autenticación de 16 bytes —60 bytes en total sobre IPv4, 80 sobre IPv6—, con una MTU de interfaz de 1.420 bytes recomendada en una red de 1.500 bytes: https://en.wikipedia.org/wiki/wireguard