Calculadora de latencia y ancho de banda de red

Determinación de los límites de rendimiento en flujos TCP

El rendimiento real de una conexión de red no depende únicamente de la velocidad nominal del enlace contratado. Cuando se transmite información a través de un único flujo TCP, la velocidad efectiva se ve condicionada por una serie de factores físicos y de protocolo, principalmente la latencia de la ruta, el tamaño de las ventanas de memoria intermedia y la pérdida de paquetes.

La herramienta calcula el límite máximo teórico en estado estacionario para un único flujo TCP basándose en las condiciones de contorno de la ruta de red. Al introducir la velocidad del enlace, el tiempo de ida y vuelta y el tamaño de la transferencia, es posible identificar de forma matemática cuál es el cuello de botella activo que restringe la velocidad de transmisión, estimar el rendimiento TCP esperado y calcular el tiempo total que requerirá la transferencia de los datos.

Configuración de los parámetros de entrada

Para realizar el cálculo de la ruta de red y el comportamiento del protocolo TCP, se deben definir las siguientes variables en la interfaz de la herramienta:

• Velocidad del enlace: Representa el salto más lento de la ruta, que a menudo coincide con la velocidad contratada de tu plan. Debe ser un valor mayor que cero. Se selecciona junto con su correspondiente unidad de velocidad.
• Tiempo de ida y vuelta (RTT): El tiempo de ping al extremo lejano, utilizando el valor más alto que se espere bajo carga. Debe ser estrictamente mayor que cero.
• Tamaño de datos: La carga útil que se va a transferir, como un archivo, una copia de seguridad o un conjunto de datos. Debe ser mayor que cero.
• Ventana de recepción: Los bytes que el receptor puede almacenar en búfer. Un valor de 65,535 bytes representa el máximo sin escalar. Si se deja este campo vacío, se asume que no existe un límite de ventana. El valor máximo admitido es de 1,073,725,440 bytes.
• Tamaño máximo de segmento (MSS): Los bytes de carga útil por paquete. Por ejemplo, 1,460 bytes llenan una trama Ethernet estándar. Debe ser un número entero de bytes situado entre 1 y 65,495. Si se deja vacío, el sistema ignorará la sobrecarga y la pérdida de paquetes en los cálculos.
• Pérdida de paquetes (%): La probabilidad media de pérdida de paquetes en la ruta. Debe ser un valor entre 0 y 100 por ciento. Dejarlo vacío o en 0 indica que no hay límite por pérdida.
• Decimales mostrados: Controla la precisión decimal de los resultados de salida en la pantalla.

La interfaz cuenta con el botón Cargar ejemplo para rellenar automáticamente los campos con valores de prueba, y el botón Borrar para restablecer todos los parámetros de entrada.

Resultados del rendimiento y tiempos de transferencia

Una vez procesados los datos, la herramienta desglosa los resultados en diferentes secciones métricas:

Rendimiento y tiempo de transferencia

• Rendimiento TCP esperado: Muestra la velocidad de transferencia final estimada, acompañada de la etiqueta dinámica que identifica el cuello de botella activo: la capacidad del enlace, la ventana de recepción o la pérdida de paquetes.
• Tiempo de transferencia: El tiempo total estimado para completar la transmisión.
• Tiempo hasta el primer byte (1 RTT): El retardo inicial antes de que comience la transferencia de datos masiva.
• Tiempo de transferencia masiva: El tiempo empleado puramente en la transmisión del volumen de datos.
• Producto de ancho de banda y retraso: El volumen total de datos que pueden estar en tránsito en la ruta de red simultáneamente.
• Ventana para llenar la ruta: El tamaño de ventana de recepción necesario para aprovechar al máximo la capacidad del enlace.
• Rendimiento limitado por ventana: El límite de velocidad impuesto por el tamaño de la ventana de recepción y el RTT.
• Rendimiento limitado por pérdida (Mathis): El límite de velocidad calculado según la tasa de pérdida de paquetes.
• Límite del enlace tras sobrecarga: La velocidad máxima del enlace una vez descontada la sobrecarga de los protocolos de red.
• Eficiencia del protocolo: El porcentaje de ancho de banda del enlace físico que se destina a la carga útil de los datos.

Existe un botón para Copiar resultado que permite exportar cómodamente todos los valores calculados al portapapeles.

Notas dinámicas del sistema

El motor de cálculo genera avisos específicos según los valores introducidos:

• Si la ventana necesaria para llenar la ruta supera los 65,535 bytes, se muestra el aviso "Llenar esta ruta requiere una ventana de ‹window›, por encima del máximo sin escalar de 65,535 bytes, de modo que ambos extremos deben negociar el escalado de ventana TCP (RFC 7323).".
• Si la ventana requerida supera el límite absoluto de escalado de TCP, se muestra el aviso "Llenar esta ruta requiere ‹window›, lo que supera la ventana más grande que TCP puede negociar (1,073,725,440 bytes). Un único flujo en esta ruta nunca podrá superar ‹value›.".
• Si la ventana de recepción configurada limita el rendimiento por debajo de la capacidad del enlace, se muestra el aviso "Aumentar la ventana de recepción a ‹window› permitiría que esta transferencia alcanzara hasta ‹value›.".
• Si la pérdida de paquetes es superior al 1%, se muestra el aviso "La pérdida superior al 1% queda fuera del rango fiable del modelo de Mathis; considera el límite por pérdida como optimista.".

Fórmulas matemáticas y sustitución de variables

La herramienta expone de forma transparente el desarrollo matemático empleado para obtener los resultados a través de las siguientes ecuaciones:

• Fórmula general: rendimiento = min(velocidad × eff, ventana ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = velocidad × RTT
• Eficiencia del protocolo: Eficiencia del protocolo = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B de cabeceras de paquete + 38 B de sobrecarga de cable)
• Límite del enlace: Límite del enlace = velocidad × eficiencia = ‹rate› × ‹eff› = ‹value›
• BDP: BDP = velocidad × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
• Ventana para llenar la ruta: Ventana para llenar la ruta = BDP ÷ 8 = ‹bdp› → ‹window›
• Límite de la ventana: Límite de la ventana = ventana ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
• Límite por pérdida (Mathis): Límite por pérdida (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
• Rendimiento esperado: Rendimiento esperado = el menor de estos límites = ‹value› → limitado por ‹constraint›
• Tiempo de transferencia: Tiempo de transferencia = RTT + 8 × tamaño ÷ rendimiento = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

Reglas de cálculo y limitaciones del modelo

Para interpretar correctamente los resultados, se deben tener en cuenta las siguientes reglas de diseño y simplificaciones del modelo:

1. Unidades decimales: Todas las unidades de red empleadas son decimales (por ejemplo, 1 kbit = 1,000 bits, 1 MB = 1,000,000 bytes). Los sistemas operativos y administradores de archivos suelen utilizar unidades binarias basadas en 1024 (donde un archivo de "100 MB" equivale realmente a 100 MiB, o aproximadamente 104.86 megabytes decimales).
2. Sobrecarga de red: Se asume una sobrecarga estándar de Ethernet de 78 bytes por paquete, desglosada en 40 bytes para las cabeceras TCP/IP y 38 bytes de sobrecarga física del cable. Otras tecnologías de enlace de datos pueden diferir ligeramente.
3. Modelo de Mathis: La fórmula de Mathis para la pérdida de paquetes asume que las pérdidas ocurren de manera uniforme e independiente. Este modelo solo es fiable para tasas de pérdida inferiores al 1%. Las pérdidas en ráfagas del mundo real suelen degradar el rendimiento de forma más severa de lo que predice esta aproximación matemática.
4. Exclusiones del modelo: Los cálculos representan un flujo TCP único en estado estacionario. No se consideran factores dinámicos como la fase de inicio lento (slow start), el ajuste del control de congestión de los sistemas operativos, las limitaciones de procesamiento de un receptor lento o el intercambio de claves en conexiones TLS. Por tanto, las transferencias reales comenzarán más despacio y sus velocidades medias pueden situarse por debajo de los límites calculados.

Gestión de errores en la entrada de datos

Si se introducen valores no válidos, la herramienta mostrará alguno de los siguientes mensajes de error específicos:

• Si un campo no se puede procesar: "‹field›: «‹token›» no es un número.".
• Si la velocidad del enlace es igual o menor a cero: "La velocidad del enlace debe ser mayor que cero.".
• Si el tiempo de ida y vuelta es igual o menor a cero: "El tiempo de ida y vuelta debe ser mayor que cero.".
• Si el tamaño de los datos es igual o menor a cero: "El tamaño de los datos debe ser mayor que cero.".
• Si la ventana de recepción es igual o menor a cero: "La ventana de recepción debe ser mayor que cero.".
• Si la ventana supera el límite de la especificación RFC 7323: "TCP no puede negociar una ventana superior a 1,073,725,440 bytes (escalado de ventana RFC 7323).".
• Si el MSS está fuera de rango: "El MSS debe ser un número entero de bytes entre 1 y 65,495.".
• Si la tasa de pérdida está fuera de rango: "La tasa de pérdida debe estar entre 0 y 100 por ciento.".
• Si los cálculos desbordan la capacidad del sistema: "Un valor o resultado intermedio supera el rango de números admitido.".

Privacidad y procesamiento de datos

Cada valor que introduces se calcula en este navegador; no se envía nada a ningún sitio. El procesamiento se realiza de manera local en el dispositivo del usuario, garantizando que los datos de red y tamaños de transferencia no se transmitan a servidores externos.

---

Preguntas frecuentes

¿Qué es el producto de ancho de banda y retraso, y por qué determina el tamaño de la ventana?

El BDP (velocidad del enlace × tiempo de ida y vuelta) es la cantidad de datos en tránsito en cualquier momento. TCP solo puede tener como máximo una ventana sin confirmar pendiente, por lo que una ventana menor que el BDP deja el canal parcialmente vacío: a 100 Mbit/s con un RTT de 50 ms, el canal alberga 625 kB, y una ventana de 65,535 bytes apenas llena una décima parte. Por eso las rutas rápidas y largas necesitan el escalado de ventana TCP (RFC 7323), que eleva el máximo negociable de 65,535 bytes a aproximadamente 1 GB.

¿Por qué mi transferencia es más lenta que la velocidad de enlace por la que pago?

Un único flujo TCP se enfrenta a tres límites independientes y el más bajo es el que manda. La sobrecarga del protocolo reduce el propio enlace en torno a un 5%: una trama Ethernet estándar transporta 1,460 bytes de carga útil de los 1,538 que viajan por el cable. La ventana de recepción limita el rendimiento a ventana ÷ RTT, por lo que la clásica ventana de 65,535 bytes limita una ruta de 50 ms a unos 10.5 Mbit/s por muy rápido que sea el enlace. Y la pérdida lo limita a (MSS ÷ RTT) ÷ √pérdida. El resultado de arriba indica qué límite está condicionando tus números.

¿Cómo limita la pérdida de paquetes el rendimiento de TCP?

TCP trata la pérdida como congestión y reduce a la mitad su velocidad de envío con cada evento de pérdida, por lo que incluso tasas de pérdida minúsculas importan en rutas rápidas. El modelo de Mathis estima el límite como (MSS ÷ RTT) ÷ √p; con una pérdida del 0.01% en una ruta de 50 ms con un MSS de 1,460 bytes, esto equivale a unos 23 Mbit/s, independientemente de la velocidad del enlace. El modelo asume eventos de pérdida independientes y distribuidos uniformemente; por debajo de aproximadamente el 1% se ajusta bien a la realidad, y para pérdidas en ráfagas resulta optimista.

¿Son los megabytes de aquí los mismos que los de mi administrador de archivos?

No del todo. Esta página utiliza unidades decimales, la convención de las redes: 1 kbit = 1,000 bits y 1 MB = 1,000,000 bytes. La mayoría de los administradores de archivos cuentan en unidades basadas en 1024, a menudo mal etiquetadas como MB: un archivo de «100 MB» allí suele ser de 100 MiB ≈ 104.86 MB decimales, por lo que tarda aproximadamente un 5% más en transferirse de lo que sugiere la cifra decimal. Introduce 104.86 MB aquí para que coincida exactamente.