¿Qué VPN no reduce la velocidad de la conexión a Internet o debe hacerlo por definición?

La única red privada que no se ralentizará en el uso es un enlace privado punto a punto, capa 2, entre dos o más sitios. La parte “virtual” de la red privada virtual requiere que emule ese enlace mediante encapsulación (y posible cifrado) a través de otro enlace. Esto a su vez requiere gastos generales.

La MTU (unidad de transmisión máxima) de un paquete de Ethernet es de 1500 bytes (aunque más típicamente con las conexiones PPPoE utilizadas por la mayoría de los ISP, esta será 1492), dentro de la cual debe incluir información de IP de capa 3 junto con las opciones de TCP / UDP de capa 4; solo entonces se incluirán los datos que está transmitiendo / recibiendo. Por lo tanto, de los 1500 con los que comenzó, puede enviar hasta 1460 bytes de datos.

Cuando necesita enviar a través de una VPN, esos 1500 bytes completos de encabezado y datos IP + TCP / UDP deben colocarse dentro de otro paquete, que a su vez tiene sus propios encabezados IP + TCP / UDP. Dado que no puede agrandar el paquete general, tiene dos opciones:

  1. Manipule el valor TCP MSS en todas las conexiones a través de la VPN, lo que requiere que la MTU de la conexión no sea superior a 1460 bytes (o 1452); o
  2. Divida el paquete en dos y envíe los 40 bytes restantes en su propio paquete separado.

Ambos tienen el mismo problema: gastos generales.

Con una MTU de 1500 y 1460 bytes de datos, tiene una sobrecarga de alrededor del 2.7%; por cada kilobyte de datos que desea enviar, deberá agregar al menos 27 bytes de “metadatos” para permitir el paquete para ser enrutado y asignado a la aplicación correcta en cualquier extremo.

Si divide el paquete en dos, debe usar 1540 bytes para enviar los mismos 1460 bytes de datos: su sobrecarga ahora es 5.2%. O, si reduce el valor de TCP MSS para garantizar que todos los datos estén correctamente encapsulados, la sobrecarga aumenta al 5,3% (1420 bytes dentro de 1500).

Independientemente de la forma en que lo haga, debe perder aproximadamente el 3% de la velocidad de su título para transmitir a través de VPN.

Pero, hay otros dos problemas:

  1. Cifrado / descifrado. Independientemente de si esto se hace en software o hardware, habrá una latencia adicional relacionada con el cifrado (aunque generalmente no es tan notable). Sin embargo, si el procesador en cualquiera de los extremos no es lo suficientemente potente, podría alcanzar el límite de la cantidad de datos por segundo que puede cifrar o descifrar antes de alcanzar la velocidad de línea máxima de su conexión (especialmente cierto para enrutadores domésticos / pequeños en cable / líneas de fibra sin cifrado de hardware).
  2. La ruta que toma: la IP generalmente se envía a lo largo de la ruta con el menor salto para llegar a su destino más rápido. Al usar una VPN, primero está enviando sus datos a una ubicación separada que a su vez los reenviará por usted. A menudo, esta no será la ruta más ideal a menos que el punto final de sus datos y el punto final de la VPN sean uno y el mismo (es decir, la red corporativa). Nuevamente, esto agrega latencia.

En ambos casos, la latencia puede hacer que se sienta más lento sin que sea (mucho) más lento en términos de ancho de banda, y es especialmente cierto con archivos pequeños (como HTML / CSS / JS / Images, etc.): no importa cómo Su conexión es rápida, si tarda más en comenzar a enviarle los datos, se sentirá más lento y, en casos extremos, puede enviar más tiempo esperando que se le envíen los datos de lo que realmente tarda en enviarlos una vez que comienza .

En general, las VPN no lo retrasarán tanto. Mientras usted y su VPN tengan una buena conectividad, ambos puntos finales tienen un buen hardware para procesar la conexión, y su punto final elegido está más o menos en línea con la ruta que desea tomar o reside en el país donde desea que termine la mayor parte de su tráfico dentro o alrededor, no lo notarás tanto. Sin embargo, cuanto más se desvíe de esto, más notable será su penalización de rendimiento en comparación con la transmisión nativa a través de su conexión típica.

Aparte : hay algunos casos muy pequeños en los que puede ser más rápido. Por ejemplo, los problemas recientes con Verizon / Netflix han demostrado que, en algunas situaciones, el enrutamiento del tráfico a través de una VPN puede brindarle una transmisión más rápida y receptiva. Esto se debe a la congestión en la ruta normal y al usar una VPN puede anular el enrutamiento típico y mover el tráfico a través de otro enlace ascendente. Sin embargo, este es un caso muy raro y extremo y ciertamente no es una experiencia típica.

La velocidad de la VPN depende de muchos factores.

  • ¿Qué tipo de VPN usan?
  • Qué tan congestionados están sus servidores (es decir, cuántas personas están conectadas / usan ancho de banda al mismo tiempo)
  • Qué tan lejos está de sus servidores y de los servidores del servicio al que está intentando acceder.

En general, conectarse a la puerta de enlace VPN más cercana le proporcionará la conexión más rápida. Pero, además de la distancia, el rendimiento también puede verse afectado por la forma en que los ISP que componen Internet se conectan entre sí y el tráfico en esas rutas.
Dependiendo de su conexión y otros factores, un protocolo VPN diferente puede funcionar mejor para usted. intente cambiar entre protocolos VPN (PPTP, L2TP, OpenVPN, ..). En general, pptp y openVPN tienden a ser los más rápidos.
Por cierto, el ajuste de MTU (como se menciona en el siguiente artículo) también podría ser útil:
http://www.purevpn.com/faq/14/i_

Puede utilizar la encapsulación de enrutamiento genérico (GRE) sin cifrar para construir un “túnel” de una red a otra. La sobrecarga de hacerlo es muy, muy baja. Bastante cerca de la velocidad de la línea.

Nota: esto es inseguro, y es por eso que la mayoría de las implementaciones de VPN incluyen alguna forma de cifrado. Pero funciona.

He trabajado en productos VPN de velocidad de cable, y todos requieren un aumento significativo de hardware para hacerlo posible, y generalmente solo hasta 10 Gbps más o menos. Más allá de eso no es económicamente factible en este momento. Y nunca podrá escapar del impuesto general del “paquete doble”: el envío de un paquete con un MTU máximo a la VPN dará como resultado dos paquetes de red subyacentes. Una solución más elegante es hacer que el VPN vuelva a marcar su MTU, que no soluciona el problema de “más paquetes”, pero lo hace de una manera más elegante y de mayor rendimiento.

Descargo de responsabilidad: originalmente desarrollé GRE (el código RFC e IOS fue escrito por Tony Li y Paul Traina)