CON · Concepto 4 · Transporte (Transporte)

28.Control de flujo y ventanas

Mecanismos de TCP para no saturar al receptor ni a la red: la ventana deslizante, el escalado de ventana y el control de congestión.

¿Qué es?

El control de flujo es la forma en que TCP evita enviar más datos de los que el receptor puede procesar. El control de congestión hace lo mismo, pero para no saturar la red. Las dos cosas se manejan con ventanas: cuántos datos se pueden enviar sin esperar confirmación.

Imagina que alguien te pasa cajas para acomodar en un estante. Le dices: «puedes pasarme hasta cinco sin esperar a que te diga que ya las acomodé». Si te atrasas, le dices «solo dos más»; si el pasillo está lleno de gente, él mismo decide ir más despacio.

En términos técnicos

  • Pertenece a TCP, en la capa 4 (Transporte).
  • La ventana de recepción (rwnd) la anuncia el receptor en cada segmento: «tengo espacio para N bytes más».
  • La ventana de congestión (cwnd) la calcula el emisor según cómo responde la red.
  • El emisor puede tener en vuelo, sin confirmar, el mínimo de las dos.
  • Se llama ventana deslizante porque, a medida que llegan los acuses, la ventana «avanza» sobre el flujo de datos.

¿Dónde lo vas a encontrar?

En toda conexión TCP. Se nota cuando una descarga empieza lenta y va acelerando, o cuando un enlace con mucha latencia (satélite, otro continente) rinde menos de lo que debería.

¿Cómo funciona?

La ventana deslizante, paso a paso

El receptor anuncia una ventana de 4000 bytes y el emisor envía segmentos de 1000:

Paso Qué pasa Bytes en vuelo
1 El emisor envía los bytes 1–4000 (cuatro segmentos) sin esperar 4000 (ventana llena)
2 Llega ACK 2001 con ventana 4000 2000
3 La ventana «se desliza»: ahora puede enviar hasta el byte 6000 —
4 Envía 4001–6000 4000

Si la aplicación del receptor se atrasa y su memoria se llena, anuncia una ventana menor; si se llena por completo, anuncia ventana 0 y el emisor se detiene, enviando pequeñas pruebas hasta que se abra de nuevo.

El escalado de ventana

El campo de ventana mide 16 bits: como máximo 65 535 bytes. Hoy no alcanza, así que en el saludo se negocia el escalado de ventana (RFC 7323): un factor que multiplica el valor por una potencia de 2, hasta ventanas de cerca de 1 GB.

¿Qué ventana necesita un enlace? (producto ancho de banda × retardo)

ventana necesaria = ancho de banda × tiempo de ida y vuelta (RTT)
  • Enlace de 100 Mb/s con RTT de 50 ms: 100 000 000 × 0.05 = 5 000 000 bits = 625 KB.
  • Sin escalado (64 KB), en ese mismo enlace solo podrías llegar a unos 10 Mb/s, aunque tengas 100.

Control de congestión

Fase Qué hace la ventana de congestión
Arranque lento Empieza pequeña y se duplica en cada ida y vuelta
Evitar congestión Al llegar a un umbral, crece poco a poco (lineal)
Pérdida detectada Se reduce (a la mitad o más) y vuelve a crecer
Retransmisión rápida Con tres ACK duplicados, reenvía sin esperar el tiempo límite

Verificación y diagnóstico

Prueba Qué debes ver
Wireshark, columna Win= de cada segmento La ventana que anuncia cada lado
Wireshark, SYN: opción WS= El factor de escalado negociado
Wireshark, filtro tcp.analysis.zero_window Momentos en que el receptor se llenó
Wireshark, Estadísticas → Gráficas de flujo TCP → tcptrace La ventana y los datos en vuelo a lo largo del tiempo
ping al servidor El RTT, para calcular la ventana necesaria
ss -ti (Linux) Para cada conexión: cwnd, rtt y retransmisiones

Para tomar en cuenta

  • Más ancho de banda no siempre es más velocidad: con mucha latencia, la ventana es el límite.
  • Los sistemas actuales ajustan la ventana solos (autotuning); casi nunca hay que tocarla a mano.
  • Pérdidas = menos velocidad: cada pérdida reduce la ventana de congestión. Un Wi-Fi con interferencia hace que TCP vaya lento aunque haya señal.
  • UDP no tiene nada de esto: una aplicación UDP mal hecha puede saturar un enlace sin darse cuenta.
  • Algoritmos distintos, resultados distintos: CUBIC reacciona a las pérdidas; BBR intenta medir el ancho de banda y el retardo reales.
  • Buffers demasiado grandes en los routers causan bufferbloat: la latencia sube mucho cuando el enlace se llena (se nota en videollamadas mientras alguien descarga).

Material descargable

Aún no hay material descargable para este tema. Pronto habrá cuadernillos, manuales o laboratorios.

Referencias (RFC / estándar)

© solutions_ · Redes informáticas · 28 Control de flujo y ventanas