Por qué una descarga por VPN está limitada por la subida del servidor

El cliente muestra un enlace de bajada rápido, el servidor está en una conexión de fibra y la transferencia sigue arrastrándose. El número que la gente compara suele ser el impreso en el plan del cliente, mientras que el paquete cruza primero el enlace de salida del servidor. Ese enlace es el presupuesto en el que la transferencia debe encajar. En una conexión doméstica pequeña es el número más pequeño del camino.

El número que leyó estaba en la dirección equivocada

Una descarga hacia un cliente remoto consume capacidad de subida en el extremo del servidor del túnel. Las velocidades de bajada anunciadas del servidor describen la dirección contraria y no dicen nada sobre esta. La misma asimetría se invierte cuando el cliente sube, y por eso una dirección puede sentirse bien mientras la otra es inutilizable.

El sobrecosto de encapsulación y cualquier tráfico competidor gastan parte de ese mismo presupuesto. Ninguno de los dos es visible en una prueba de velocidad que mide solo al cliente.

Escriba el camino como un presupuesto

Enumere cada frontera que el paquete debe cruzar y dé a cada una un número en la misma unidad. La entrega desde el origen, el procesamiento del servidor, el enlace de subida del servidor, el camino intermedio, el enlace de bajada del cliente y el procesamiento del cliente se aplican todos. La velocidad utilizable es la menor de ellas menos el sobrecosto, y ningún ajuste por encima de ese techo cambia el resultado. Escriba la lista antes de medir, porque le dice a qué número no creer.

Con un enlace de subida del servidor de 20 Mbit/s y un enlace de bajada del cliente de 100 Mbit/s, el servidor limita la transferencia mucho antes de que el cliente lo note. El sobrecosto y cualquier transferencia simultánea toman otra porción, y un enlace de subida saturado también retrasa las confirmaciones, lo que ralentiza una transferencia TCP por debajo del techo bruto. Ninguno de los dos efectos aparece en una comparación de planes.

Mantenga los megabits y los megabytes separados, y diga si cada cifra mide tráfico de enlace cifrado o carga útil de la aplicación. Mezclar esos dos es la razón más común por la que un presupuesto parece no cuadrar. Etiquete cada cifra con su unidad y su punto de medición.

Dónde la placa realmente le cuesta

Una vez que el enlace de acceso es lo bastante grande, el hardware del extremo se vuelve visible, y solo entonces importa el procesador. Identifique el modelo, la disposición de interfaces y la implementación en uso. Una observación sobre el bus compartido de una placa temprana no describe cada revisión posterior.

Compare rutas de procesamiento individuales en lugar de un promedio único de CPU. Una carga global moderada puede ocultar un núcleo saturado que hace todo el trabajo por paquete, y la frecuencia de reloj no se transfiere entre diseños de procesador como una puntuación de rendimiento. La tasa de paquetes importa tanto como el caudal, porque los paquetes pequeños cuestan más por byte que los grandes. Mida con los tamaños de paquete que su carga de trabajo realmente usa.

Los límites térmicos y de potencia también deciden el comportamiento sostenido. Una ráfaga corta puede verse excelente mientras una transferencia de diez minutos se limita, y por eso una prueba de pocos segundos es una mala guía para una copia de seguridad nocturna.

Las guías de rendimiento del fabricante separan el ancho de banda de acceso, la CPU, el procesamiento de paquetes, el transporte y el tamaño de paquete en restricciones distintas. Vale la pena leerlas antes de cambiar un cifrado, porque un cambio de cifrado rara vez mueve una frontera que nunca fue el límite.

Mida antes de cambiar un cifrado

Ejecute una prueba direccional que informe la velocidad realmente alcanzada a través del túnel y luego ejecute la misma prueba en la interfaz sin procesar para comparar. La diferencia entre esos dos números es el costo del túnel, y el menor de los dos techos le dice qué frontera atacar.

Mantenga intacta la política de seguridad mientras compara. Un resultado antiguo obtenido con un cifrado débil o una placa con overclock no es un plan para el despliegue actual.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Guarde los resultados direccionales junto a las observaciones del extremo de la misma ejecución. El próximo cambio debería apuntar al techo medido en lugar del componente que parece más pequeño en la hoja de especificaciones.