Por qué la penalización del VPN parece peor en la red móvil que en Ethernet

El mismo portátil, el mismo servidor y el mismo túnel pueden perder una quinta parte de su rendimiento en Ethernet y tres cuartas partes en la red móvil, y ninguna de las dos cifras significa que el VPN esté roto. Cada red de acceso proporciona una ruta distinta, y el túnel añade una segunda ruta por encima de ella. Comparar una cifra con túnel con una cifra sin túnel no responde nada, porque las dos cifras describen denominadores distintos. Cuatro celdas y una fracción de retención por fila le dirán qué pregunta plantear después.

Cuatro celdas, no una penalización

Mida la línea base directa y el resultado con túnel en cada red de acceso, y manténgalos como una matriz en lugar de como un veredicto único. La base es la misma tarea realizada en esa red sin el túnel; el resultado con túnel es la misma tarea con él.

Utilice una carga de trabajo autorizada para las pruebas directas y mantenga los controles de privacidad que exige el entorno. Una prueba que infringe la política produce una cifra que no puede publicar y que no debería repetir.

Mantenga quietas las variables

Mantenga fijos el dispositivo, la aplicación, el destino, la dirección de transferencia y el extremo del VPN en las cuatro celdas. Si un servicio cambia en silencio su servidor de pruebas entre ejecuciones, registre el cambio y trate el par como no controlado en lugar de diluir la diferencia con un promedio.

Repita la matriz en ambos sentidos y a horas del día comparables. Las condiciones de una radio móvil y la carga de su celda cambian en minutos, así que una única base excepcionalmente buena puede exagerar la penalización aparente. Registre la dispersión de los resultados junto a un valor representativo, y anote si las ejecuciones con túnel se intercalaron con las bases o se hicieron en bloque.

El intercalado importa más de lo que la mayoría espera. Una base medida antes de comer y una ejecución con túnel medida después son dos redes distintas que llevan el mismo nombre.

Mantenga visible el denominador

Informe de la fracción de retención además de la tasa absoluta: E1 dividido por E0, y C1 dividido por C0. Un enlace rápido que conserva una parte pequeña de su rendimiento y un enlace lento que conserva la mayor parte son hallazgos distintos, y solo la fracción muestra la diferencia.

El rendimiento absoluto sigue decidiendo qué puede hacer un usuario. La fracción decide dónde mirar. Cuando Ethernet conserva la mayor parte de su base y la red móvil conserva mucho menos, la variable interesante está en la ruta móvil y no dentro del cifrado.

Ambas cifras pertenecen al informe, porque cada una por sí sola sostiene una conclusión que los datos no sostienen.

Lea el patrón antes de cambiar nada

Unos techos con túnel parecidos en ambas redes apuntan a algo compartido: el extremo, su CPU, un límite de velocidad o un solo salto congestionado. Un descenso que solo aparece en la red móvil apunta a la ruta de esa red, a la pérdida, a la latencia y al tamaño efectivo del paquete.

Estas son pistas, no diagnósticos, y la diferencia importa cuando escribe el tique. Un techo compartido no mejorará cuando cambie el módem móvil, y un descenso solo móvil no mejorará cuando redimensione el extremo. Indique cuál de los dos patrones vio antes de proponer un cambio. Así el cambio lleva una predicción, y la siguiente medición puede confirmarla o matarla.

La propia guía de rendimiento de OpenVPN separa las restricciones de ancho de banda, CPU, transporte y tamaño de paquete por las mismas líneas, lo que recuerda de forma útil que el túnel rara vez es una sola variable.

Cuando el tamaño de paquete es el sospechoso

La encapsulación consume espacio del paquete, así que el tamaño efectivo en una ruta móvil puede ser menor que el que anuncia la interfaz. Conserve las pruebas de tamaño de paquete para la ruta que compara en lugar de suponer un valor a partir del nombre de la tecnología de acceso.

Datagram packetization-layer path MTU discovery describe cómo descubrir el tamaño efectivo en lugar de fijarlo. Utilice las observaciones que admite la implementación, y no imponga un MTU bajo arbitrario a cada cliente como precaución, porque eso cambia un problema por uno peor en rutas que estaban bien.

Una hipótesis de tamaño necesita sus propias pruebas: la misma transferencia con dos tamaños, con el patrón de pérdida registrado.

Añada una variable cada vez

Compare un transporte alternativo solo después de guardar la matriz de base. Eso mantiene en juego una variable deliberada y le permite atribuir el cambio en lugar de adivinarlo.

Mantenga el dimensionamiento de la carga útil de TCP separado del comportamiento de los datagramas UDP, ya que ambos reaccionan de forma distinta a la pérdida y al tamaño de la ruta. Una mejora procedente de un cambio de transporte es una prueba sobre ese transporte, no una prueba de que el cifrado o la cobertura fueran la causa original.

Orden de trabajo: rellene las cuatro celdas, calcule ambas fracciones, intercale las ejecuciones, luego elija una hipótesis y pruébela con un solo cambio. Cualquier otra cosa es una comparación de dos incógnitas.