ForHosting KIT · Utilidades de desarrollo

Calculadora de ventana TCP para rendimiento

100 Mbps con 50 ms de ida y vuelta exigen 625 000 bytes en tránsito, muy por encima de la ventana TCP clásica de 65 535 bytes: indique velocidad y RTT y obtenga la ventana y el factor de escala que llenan el enlace. Gratis en su navegador.

Gratis
Funciona en su navegador
Sin registro
Sus datos no salen de su equipo

Ejecutar — gratis Cómo funciona y API

Úselo desde WebAPIEmailTelegramApp pronto

Ejemplo resuelto

Si escribe

Rendimiento (Mbps): 100
Rtt ms: 50

Obtiene

Ventana (bytes): 625 000
Ventana (bits): 5 000 000
Ventana (KiB): 610,3515625
Ventana (MiB): 0,5960464478

Las redes largas y de alta capacidad —mucho ancho de banda por alta latencia— dejan a TCP sin aliento si la ventana de recepción no basta para mantener el conducto lleno durante un viaje de ida y vuelta. Ingenieros de red, SRE y estudiantes que dimensionan enlaces WAN, rutas satelitales o túneles en la nube entre regiones necesitan el producto ancho de banda-retardo, no una regla aproximada. Esta calculadora del tamaño de ventana TCP para rendimiento acepta el caudal objetivo en megabits por segundo y el RTT del camino en milisegundos, los multiplica por el factor exacto que produce bytes y devuelve la ventana requerida en bytes, bits, kibibytes y mebibytes. También indica cuándo la ventana TCP clásica de 65535 bytes sin escalado es insuficiente, recomienda el desplazamiento mínimo de Window Scale según RFC 1323 y muestra el caudal máximo que aún podría lograr sin escalado con el mismo RTT.

Por qué el tamaño de ventana es el ancho de banda por el retardo

TCP solo puede tener datos pendientes de reconocimiento hasta la ventana anunciada por el receptor (y la ventana de congestión del emisor). En un camino con capacidad C bits por segundo y tiempo de ida y vuelta R segundos, la cantidad de datos que debe estar en vuelo para aprovechar el enlace por completo es C por R: el producto ancho de banda-retardo.

Divídalo entre ocho para expresar ese producto en bytes; ese número es la ventana de recepción mínima para una transferencia a tasa plena en régimen permanente si el control de congestión no es el limitante. En unidades de ingeniería cómodas, megabits por segundo por milisegundos por ciento veinticinco producen bytes, porque un megabit por segundo son ciento veinticinco mil bytes por segundo y un milisegundo es una milésima de segundo. Ejemplo: cien megabits por segundo a cincuenta milisegundos necesitan seiscientos veinticinco mil bytes en vuelo.

Sin esa profundidad de búfer, el emisor vacía su ventana, se detiene y espera reconocimientos, de modo que el goodput medido cae muy por debajo de la tasa de línea aunque el enlace físico esté bien. Este extremo solo dimensiona la ventana a partir del BDP; no modela pérdida de paquetes, slow start ni bufferbloat, que son perillas distintas en la planificación de capacidad.

Dónde aporta valor una calculadora de ventana TCP y caudal

Los diseñadores de WAN y centros de datos usan una calculadora de tamaño de ventana TCP antes de ampliar circuitos para que los búferes de recepción y los valores por defecto del SO coincidan con el nuevo BDP en lugar de adivinar. Los arquitectos en la nube que dimensionan replicación de bases de datos entre regiones o transferencias de almacenamiento de objetos convierten el RTT publicado y los megabits objetivo en bytes de búfer concretos para planes de prueba de carga.

Los equipos de backhaul satelital y móvil muestran por qué enlaces de varios megabits aún se arrastran cuando el RTT es de cientos de milisegundos y Window Scale está desactivado. Laboratorios de clase y certificación necesitan un oráculo determinista para deberes sobre el producto ancho de banda-retardo que coincida con las unidades del libro sin errores de hoja de cálculo. La validación fallida no consume saldo.

Deje la pérdida, el pacing y el control de congestión en sus propias herramientas; use este extremo como única fuente de verdad para la aritmética del BDP, de modo que documentación, runbooks y workers de borde planifiquen igual.

Qué puede hacer con ella

Planificación de capacidad WAN y LFN

Convierta Mbps objetivo y RTT medido en la ventana de recepción (y el desplazamiento de escala) necesaria para llenar un camino de red larga y de alta capacidad.

Dimensionado de transferencias en la nube entre regiones

Ajuste los búferes de socket para replicación de bases de datos, copias de seguridad u objetos, de modo que el caudal no quede limitado por una ventana sin escalar de 64 KiB.

Preguntas frecuentes

¿Qué es el producto ancho de banda-retardo (BDP)?

El BDP es la tasa del enlace por el RTT: los datos que deben estar en vuelo para mantener el camino lleno. La ventana anunciada de TCP debe ser al menos esos bytes (si no hay límites de congestión).

¿Modela esto la pérdida de paquetes o el control de congestión?

No. Solo dimensiona la ventana a partir del BDP para que el conducto pueda llenarse. La pérdida, la variación del RTT y las ventanas de congestión son aparte; use otras herramientas para ello.

¿Cómo se calcula el tamaño de la ventana TCP a partir de Mbps y RTT?

Multiplique la velocidad en megabits por segundo por el tiempo de ida y vuelta en milisegundos y por 125 para obtener bytes. Con 100 Mbps y 50 ms salen 625 000 bytes que deben estar en tránsito para llenar el enlace.

¿Cuándo hace falta el escalado de ventana TCP?

Cuando el resultado supera los 65 535 bytes, el máximo que una ventana TCP puede anunciar sin escalado. Para 625 000 bytes, el desplazamiento mínimo de Window Scale es 4, que eleva el techo a 1 048 560 bytes.

¿Qué velocidad alcanza una transferencia sin escalado de ventana?

Como mucho 65 535 bytes por cada ida y vuelta. En un trayecto de 50 ms eso limita la transferencia a 10,4856 Mbps, por rápido que sea el enlace físico; por eso las copias a larga distancia se arrastran sin escalado.

Herramientas relacionadas

Para desarrolladores — acceso por API

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

Endpoint de API

POSThttps://api.kit.forhosting.com/dev/tcp-window-for-throughput

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

Llámela desde su stack

curl -X POST https://api.kit.forhosting.com/dev/tcp-window-for-throughput \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"throughput_mbps":100,"rtt_ms":50}'

const res = await fetch("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "throughput_mbps": 100,
    "rtt_ms": 50
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/tcp-window-for-throughput",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "throughput_mbps": 100,
    "rtt_ms": 50
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"throughput_mbps":100,"rtt_ms":50}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"throughput_mbps":100,"rtt_ms":50}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/tcp-window-for-throughput", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Ejemplo de solicitud

{
  "throughput_mbps": 100,
  "rtt_ms": 50
}

Ejemplo de respuesta

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.tcp_window_for_throughput",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Precio

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

Errores

HTTP	Código	Significado
`401`	`unauthorized`	API key ausente o inválida.
`402`	`insufficient_balance`	El saldo no cubre el precio de la tarea.
`404`	`unknown_type`	El tipo de tarea no existe.
`429`	`rate_limited`	Demasiadas peticiones. Use el webhook en vez de sondear.

Notas técnicas

Las entradas no positivas fallan con invalid_input y no se facturan.

Contrato de entrada, Window Scale y campos de respuesta

Combine el resultado con el sysctl o la opción de socket de su pila para el búfer de recepción y Window Scale; esta calculadora no empuja configuración a los hosts. Envíe un cuerpo JSON con POST con dos números finitos positivos obligatorios: throughput_mbps, el goodput o tasa de enlace objetivo en megabits por segundo, y rtt_ms, el tiempo de ida y vuelta de extremo a extremo en milisegundos. Cada campo puede llegar como número JSON o como cadena numérica. Campos ausentes, valores no finitos, cero y negativos fallan con invalid_input y un mensaje que nombra el campo; esos fallos no se facturan. En caso de éxito el cuerpo repite las entradas, devuelve window_bytes, window_bits, window_kib y window_mib para el BDP, classic_max_window_bytes igual a 65535, window_scale_needed en true cuando el BDP supera ese límite clásico, window_scale_shift como el menor desplazamiento RFC 1323 que multiplica la ventana de dieciséis bits lo bastante para cubrir el BDP (tope catorce), scaled_max_window_bytes como 65535 por dos elevado a ese desplazamiento, max_throughput_mbps_without_scale para el mismo RTT si permanece sin escalar, y una cadena de fórmula breve. Ejemplo: throughput_mbps cien y rtt_ms cincuenta producen seiscientos veinticinco mil window_bytes y window_scale_needed true.

Dónde aporta valor una calculadora de ventana TCP y caudal

Como la implementación es pure parse de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente.

Casos de integración

Enseñanza del producto ancho de banda-retardo

Ofrezca a los estudiantes un oráculo BDP determinista que devuelve window_bytes y explica cuándo Window Scale RFC 1323 es obligatorio.

Preguntas técnicas

¿Cómo calculo el tamaño de ventana TCP para un rendimiento objetivo?

Envíe throughput_mbps y rtt_ms positivos. La API devuelve window_bytes = throughput_mbps × rtt_ms × 125 (el producto ancho de banda-retardo en bytes), más bits, KiB y MiB.

¿Cuándo se requiere Window Scale?

Cuando window_bytes supera 65535, la ventana TCP clásica sin escalar. La respuesta pone window_scale_needed en true y da el window_scale_shift mínimo (RFC 1323).

¿Cuánto cuesta la calculadora de ventana TCP y rendimiento?

La herramienta del navegador es gratuita. Las peticiones API usan saldo KIT prepago a $0.002 por llamada exitosa; la entrada inválida no se factura.

Ver la documentación completa del KIT →

Ejecutar — gratis

Ejemplo resuelto

Por qué el tamaño de ventana es el ancho de banda por el retardo

Dónde aporta valor una calculadora de ventana TCP y caudal

Qué puede hacer con ella

Planificación de capacidad WAN y LFN

Dimensionado de transferencias en la nube entre regiones

Preguntas frecuentes

Herramientas relacionadas

Para desarrolladores — acceso por API

Endpoint de API

Llámela desde su stack

Ejemplo de solicitud

Ejemplo de respuesta

Precio

Errores

Notas técnicas

Contrato de entrada, Window Scale y campos de respuesta

Dónde aporta valor una calculadora de ventana TCP y caudal

Casos de integración

Enseñanza del producto ancho de banda-retardo

Preguntas técnicas

gracias