Tu descarga es rápida, entonces ¿por qué cada clic se siente lento?

Descargar un archivo grande rápidamente y luego encontrar que cada clic es lento no es una contradicción. La capacidad dice cuánto puede moverse por segundo; el tiempo de ida y vuelta dice cuánto dura un intercambio antes de que ocurra algo útil. Mejorar lo primero no hace nada por lo segundo, y lo segundo es lo que nota una persona mientras escribe, hace clic o habla. Mide la queja, no la conexión.

Archivo rápido, clic lento: dos números distintos

Una transferencia masiva mantiene los datos en movimiento continuo, así que puede informar una velocidad saludable incluso cuando cada solicitud individual espera. Muchos benchmarks también abren varias conexiones a la vez, lo que eleva la cifra agregada mientras una sola solicitud sigue lenta. Los dos resultados son compatibles, y citar el más alto a un usuario que se queja de retraso es como se pierde la confianza.

La carga de una página es una cadena de pequeños intercambios: resolución de nombres, establecimiento de conexión, una solicitud, una respuesta y luego solicitudes dependientes. Cada paso vuelve a pagar el viaje de ida y vuelta, así que un camino con mucho retraso se siente lento aunque tenga capacidad de sobra.

El túnel añade su propio recorrido y procesamiento, y la ruta importa más que la etiqueta en un mapa. Dos salidas en el mismo país pueden tener caminos muy distintos hacia un destino. Una diferencia de veinte milisegundos basta para cambiar cómo se siente una página, aunque apenas mueva una cifra de rendimiento. Por eso la selección de salida debe seguir una muestra de latencia y no un icono de bandera.

Mide la queja, no la conexión

Elige la medición que coincida con la frase que dijo el usuario. Una descarga lenta necesita una velocidad sostenida en la dirección correcta; una llamada con retraso necesita las estadísticas propias de esa aplicación; una página que arranca despacio necesita tiempos de resolución y establecimiento.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

El primer comando da una muestra de ida y vuelta hacia un host que responde de forma predecible, el segundo informa el tiempo hasta el primer byte y la velocidad sostenida de una conexión, y el tercero mide el rendimiento agregado con cuatro flujos paralelos. Ejecútalos contra el mismo destino a la misma hora del día, porque comparar una muestra matinal con una nocturna produce una historia en lugar de una medición.

Mantén fijo el destino cuando compares salidas. Cambiar tanto el servidor como el túnel convierte una variable en dos, y el resultado no puede decirte cuál importó. Ejecuta cada salida al menos tres veces, porque una sola muestra suele caer durante un cambio de enrutamiento o un minuto ruidoso. La mediana es más útil que el mejor caso.

Trata el ICMP como una pista y no como la respuesta. Un host que responde puede manejar las solicitudes de eco por un camino distinto del que usa tu aplicación, y una respuesta perdida no es prueba de que todas las aplicaciones estén perdiendo paquetes.

La latencia bajo carga es un problema de colas

El patrón que más confunde a la gente es una conexión que se siente bien en reposo y resulta inservible durante una copia de seguridad. Eso son colas, no capacidad. Un enlace de subida saturado construye un búfer delante de cada otro paquete, así que una pulsación de tecla espera detrás de un trozo de la subida.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

El primer comando muestrea la latencia en segundo plano mientras el segundo satura la dirección inversa. Si los tiempos de ping saltan durante la transferencia y se recuperan después, has reproducido bufferbloat en lugar de descubrir un fallo de enrutamiento. La solución suele ser un ajuste de gestión de colas, una velocidad de fondo más baja o sacar la transferencia masiva del camino interactivo.

Reducir el tráfico de fondo opcional suele ayudar más que cambiar de país de salida. También es más barato, reversible y comprobable en un minuto. Programa las subidas grandes fuera del horario laboral si la cola no se puede gestionar, y limita su velocidad si deben funcionar de día. Un ajuste de gestión de colas es la mejor solución cuando el router admite uno.

Cambia una cosa y compara lo igual con lo igual

Para un retraso alto en reposo, compara salidas manteniendo fijo el destino y luego compara rutas para el mejor candidato. Para un rendimiento bajo y estable, mira en cambio la capacidad, la carga del servidor y el procesamiento del cliente, porque son límites distintos.

Anota qué mediste, contra qué destino, a qué hora y con qué ajustes. Una comparación sin esos cuatro hechos no se puede repetir, y la siguiente persona empezará de cero.

Luego ajusta la herramienta a la afirmación del ticket. "Internet lento" no es una medición; "el primer byte tardó 900 ms hasta este host mientras el rendimiento era bueno" sí lo es, y apunta directamente al retraso y no a la capacidad.