Un cliente estrenó su enlace dedicado de 1 Gbps hacia el datacenter donde respalda todo. Primera noche de gloria: el respaldo avanza a 100 Mbps clavados. Reclamo al proveedor, el proveedor corre un iperf con ocho flujos en paralelo y marca 940 Mbps. "El enlace está perfecto." Y es verdad. También es verdad que el respaldo va a un décimo de lo contratado. Nadie miente y nada está malo: es TCP haciendo su trabajo. TCP despacha carga solo cuando le devuelven el recibo firmado, y entre esa oficina y ese datacenter el recibo demora 20 ms en ir y volver. Esta guía es la cuenta de ese recibo.
El recibo firmado: por qué TCP espera
TCP promete algo casi milagroso: entrega completa y en orden sobre una red que pierde paquetes y los desordena. Su método es de encargado de almacén antiguo: numera cada byte y exige acuse de recibo (el ACK). Y como no puede mandar carga infinita sin saber si llegó, existe un tope de datos que pueden viajar sin confirmar: la ventana. Piensa en un servicio de mensajería estricto: despacha hasta N cajas y, mientras no vuelva el recibo firmado del destinatario, no despacha ni una más.
Si el almacén de destino está al lado, el recibo vuelve de inmediato y el flujo es continuo. Si está a 20 ms de ida y vuelta, pasa esto: enviar una ventana de 64 KB por un enlace de 1 Gbps toma apenas 0,52 ms… y esperar el ACK toma 20 ms. El emisor trabaja el 2,6 % del tiempo y espera de brazos cruzados el 97,4 % restante. El enlace no está lento: está ocioso.
De ahí sale la fórmula más importante de esta guía: throughput máximo = ventana ÷ RTT. Fíjate en lo que no aparece en esa fórmula: el ancho de banda del enlace. Puedes contratar 10 Gbps y la cuenta no cambia ni un bit. Por eso el primer paso ante un "anda lento" nunca es mirar el contrato: es medir el RTT.
Los tres retardos que componen tu RTT
Ese RTT de 20 ms no es un castigo divino: es la suma de tres retardos con personalidades muy distintas.
1. Serialización: el tiempo de poner los bits en el cable, uno tras otro. Un paquete de 1500 bytes a 1 Gbps son 12.000 bits ÷ 10⁹ bps = 12 µs. A 100 Mbps, 120 µs; a 10 Gbps, 1,2 µs. Se paga en cada salto que recibe el paquete completo antes de reenviarlo (store-and-forward), así que un camino con ocho saltos la cobra ocho veces.
2. Propagación: pura física. La luz en fibra no viaja a la velocidad de la luz en el vacío, sino a unos 204.000 km/s (el vidrio frena, índice de refracción ≈ 1,47). Eso da la regla de oro: ≈ 5 µs por kilómetro. 100 km de fibra = 0,5 ms de ida = 1 ms de RTT sin que nadie haya hecho nada malo. 2.000 km = 20 ms de RTT. Y 8.000 km hasta un datacenter en Miami = 80 ms de RTT solo en propagación. Contra esto no hay upgrade que valga: es distancia, no equipamiento.
3. Cola y procesamiento: el retardo veleidoso. Buffers llenos en un router congestionado, inspección profunda del firewall, un switch barato con la CPU al 100 %. Es el único de los tres que puedes pelear con QoS y buen dimensionamiento — y el único que produce jitter.
La consecuencia incómoda: subir de 1 a 10 Gbps solo mejora la serialización, que pasa de 12 µs a 1,2 µs. En un RTT de 20 ms, eso es redondeo. Puedes sumar los tres retardos de tu camino, salto por salto, con el presupuesto de latencia.
BDP: tu enlace es una tubería (y la ventana, la tapa)
Ahora juntemos las piezas. Un enlace se comporta como una tubería: el ancho es el ancho de banda (cuántos bits por segundo caben) y el largo es el RTT (cuánto demoran en cruzar y confirmar). El volumen de esa tubería se llama producto ancho de banda–retardo (BDP, bandwidth-delay product): cuántos bytes tienen que estar "en vuelo" — enviados y aún sin confirmar — para que la tubería trabaje llena. Si tu ventana es menor que el BDP, la tubería viaja con aire.
Hagamos la cuenta completa, con los números exactos:
- Quieres sostener 100 Mbps por un camino con RTT de 20 ms. BDP = 100.000.000 bits/s × 0,020 s = 2.000.000 de bits.
- 2.000.000 ÷ 8 = 250.000 bytes = 250 KB. Eso es lo que debe viajar sin confirmar, en todo momento, para que la tubería nunca se vacíe.
- El campo ventana original de TCP tiene 16 bits: máximo 64 KB (65.536 bytes). Throughput techo = 65.536 × 8 ÷ 0,020 s = 26.214.400 bps ≈ 26,2 Mbps.
- Y aquí lo decisivo: da exactamente lo mismo que el enlace sea de 1 Gbps. Con 64 KB de ventana y 20 ms de RTT, el techo sigue siendo 26,2 Mbps. Para llenar 1 Gbps × 20 ms necesitas 2,5 MB en vuelo — 38 ventanas clásicas.
- El rescate se llama window scaling (RFC 7323): una opción negociada en el handshake que multiplica la ventana por hasta 2¹⁴, permitiendo ventanas de ~1 GB. Todo sistema operativo de este siglo la trae activada — pero basta un middlebox prehistórico que borre la opción del SYN para devolverte a 1994.
¿Con cuánta ventana y cuánto RTT alcanzas tu meta? Esa es exactamente la cuenta que hace la calculadora de throughput TCP: le das RTT, ventana y pérdida, y te dice el techo real de un flujo.
MTU y MSS: cuánto cabe en cada caja
Hasta aquí hablamos de cuántas cajas van en vuelo. Ahora, el tamaño de cada caja. En Ethernet la carga útil máxima de una trama — el MTU — es de 1500 bytes. De esos, la cabecera IP se lleva 20 y la TCP otros 20: quedan 1460 bytes de payload real, el famoso MSS (maximum segment size). Hasta ahí, limpio.
El problema es que cada túnel del camino cobra peaje en bytes. PPPoE — el clásico de las conexiones GPON residenciales — mete 8 bytes de sesión y deja el MTU en 1492. GRE roba 24. VXLAN, el estándar de los datacenters, se lleva 50. Y como el límite físico del camino sigue siendo 1500, todo lo que agregan las cabeceras se lo descuentan a tu carta.
| Camino | MTU útil | MSS (IPv4) | Peaje |
|---|---|---|---|
| Ethernet directo | 1500 | 1460 | — |
| PPPoE (GPON típico) | 1492 | 1452 | 8 B |
| GRE | 1476 | 1436 | 24 B |
| VXLAN (sobre MTU 1500) | 1450 | 1410 | 50 B |
| IPsec túnel (típico) | ≈1400 | ≈1360 | 50–73 B según cifrado |
¿Y si el paquete sale más grande de lo que aguanta el camino? Dos escenarios, ambos feos. Con fragmentación, el router parte el paquete en pedazos: si se pierde un fragmento, TCP retransmite el paquete completo, y el reensamblado quema CPU en el destino. La fragmentación no es una solución: es veneno lento. Y con el bit DF activado (el default de TCP moderno), el router descarta el paquete y avisa por ICMP para que el emisor pruebe con uno más pequeño — el mecanismo llamado Path MTU Discovery.
Encontrar el MTU real de un camino toma treinta segundos con ping y el bit DF:
$ ping -M do -s 1472 vps.ejemplo.cl From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1492) $ ping -M do -s 1464 vps.ejemplo.cl 1472 bytes from vps.ejemplo.cl: icmp_seq=1 ttl=55 time=19.8 ms
1464 de payload + 8 de ICMP + 20 de IP = 1492: hay PPPoE en el camino. La cuenta completa de cabeceras, para cualquier combinación de túneles, la hace la calculadora de MTU y MSS.
El firewall no muere por Gbps: muere por pps
Última pieza del rompecabezas, y la que más dinero cuesta cuando se ignora. Un equipo de red no procesa "megabits": procesa paquetes. Cada paquete — pequeño o grande — exige la misma coreografía: lookup de ruta, sesión, políticas, NAT. Por eso la métrica que mata firewalls es pps (paquetes por segundo), no Gbps.
Los números son elocuentes. A 1 Gbps con tramas mínimas de 64 bytes (cada una ocupa 84 B en el cable, contando preámbulo e interframe gap), el equipo enfrenta 1,49 Mpps. Con tramas llenas de 1518 bytes, apenas 81.274 pps: 18 veces menos trabajo por el mismo "ancho de banda". El datasheet que dice "firewall de 1 Gbps" casi siempre midió con paquetes grandes; tu tráfico real — VoIP, DNS, juegos, ACKs de TCP — está lleno de paquetes pequeños.
Para dimensionar sin engañarse existe el IMIX, una mezcla estadística de tráfico real: 7 tramas de 64 B + 4 de 570 + 1 de 1518, promedio 353,83 bytes. A 1 Gbps son unos 334.000 pps — cuatro veces más exigente que el escenario de tramas llenas. Puedes desmenuzar el overhead por trama en la calculadora de trama Ethernet y PPS y dimensionar el equipo de borde con la de dimensionamiento de firewall.
Recetas: latencia primero, paralelismo después
Con toda la física sobre la mesa, las recetas de terreno son tres.
Para aplicaciones interactivas, RTT bajo le gana a ancho de banda alto. Abrir una sesión HTTPS cuesta unas 4 idas y vueltas antes del primer byte útil: con 10 ms de RTT son 40 ms y se siente instantáneo; con 150 ms son 600 ms y el usuario ya está reclamando. Escritorio remoto, ERP, videollamadas: todos viven del RTT. Elegir el datacenter más cercano vale más que duplicar el enlace.
Cuando el RTT es inevitable, paraleliza. La limitación ventana ÷ RTT es por flujo: cuatro conexiones TCP en paralelo, cada una con su ventana de 64 KB, mueven 104,9 Mbps donde una sola mueve 26,2. Por eso el iperf del proveedor con -P 8 marcaba 940 Mbps mientras el respaldo mono-flujo arrastraba los pies — y por eso las herramientas serias de transferencia (rsync en paralelo, robocopy multihilo, los navegadores con sus 6 conexiones) abren varios flujos.
Y dimensiona con las tres unidades. Un enlace se compra en Gbps, se llena en pps y se aprovecha según ventana ÷ RTT. Antes de firmar un upgrade, pasa la transferencia por la calculadora de tiempo de transferencia y confirma cuál de las tres te está frenando de verdad.
La próxima vez que un enlace "ande lento", no partas por el contrato: mide el RTT, calcula el BDP y revisa el MSS del camino. En ese orden. Nueve de cada diez veces, el gigabit estaba intacto — lo que faltaba era ventana.