Tu dirección IP es

Control de Flujo en TCP

Si la red no proporciona ningún mecanismo para controlar la congestión, éste ha de llevarse a cabo con los protocolos de la arquitectura de red.

El protocolo de la capa de transporte TCP es un protocolo que presenta las características de:

a) Protocolo fiable con confirmación de paquetes.
b) Transmisión orientada a conexión.
c) Control del flujo de bytes.

El control del flujo de bytes permite un control de la congestión, adaptándose TCP al retardo en el envío de la información en la red.

TCP emplea números de secuencia de bytes y tamaños de ventana en bytes.

El control del flujo se realiza variando el tamaño de la ventana del receptor (campo window en cabecera TCP):

a) Si la ventana del receptor aumenta, el emisor puede enviar más información sin esperar a recibir ACK (aumenta ventana del emisor).
b) Si la ventana del receptor disminuye, el emisor envía menos información sin esperar a recibir ACK (disminuye ventana del emisor). Caso límite: window=0.

Establecimiento y cierre de la conexion. Mecanismo: Three way handshake

- Lado cliente (socket que hace connect) envía un paquete sin datos con el flag SYN. Establece el numero de secuencia inicial.
- Lado servidor (socket que hace accept) responde con un paquete sin datos con ACK y SYN. Establece el numero de secuencia inicial.
- Lado cliente reconoce este paquete con un ACK. Este paquete ya puede llevar datos. Al recibir el ACK el servidor puede enviar ya datos.
- Los SYNs gastan un número de secuencia para poder confirmarse con ACKs.

Abrir y cerrar conexion TCP

Cualquiera de los dos extremos puede iniciarlo:

- Envia un paquete sin datos con el flag FIN. Consume tambien un numero de secuencia.
- El otro extremo, confirma enviando un ACK e indica que cierra tambien con otro FIN. Este segundo FIN puede ir en el mismo paquete o en otro.
- El extremo original confirma con un ACK.

Abortar una conexión. Paquete RST (reset)

- Se envía cuando TCP recibe un paquete que es inconsistente con su estado de la conexiónrecibir datos sin tener conexión abierta.
- Le dice al otro extremo que esa conexión no existe y que destruya toda la información de ese estado de conexión.
- También se usa para decir que no hay nadie escuchando un puerto.
- También se puede usar por el nivel de aplicación para cerrar una conexión de forma rápida.
- El otro extremo no hace falta que conteste nada.

Control de flujo

Pérdida de segmentos. Reenvío de la información.

Cada vez que TCP recibe un ACK, la ventana del emisor permite enviar un nuevo fragmento.

Si un segmento no llega al receptor o llega con errores, el receptor no enviará ACK. Los siguientes segmentos que envíe el emisor (hasta su tamaño de ventana máximo) se almacenarán en el buffer del receptor pero éste enviará ACK de la secuencia previa al paquete erróneo.

El emisor tiene especificado un tiempo de espera de ACK para cada segmento. Si el ACK no llega se procede con el reenvío del primer segmento sin ACK en la ventana del emisor.

Para evitar reenvío inútiles se espera al ACK del reenvío, así se vera que hay que continuar con otro segmento distinto del siguiente en espera.

Cálculo del tiempo de espera de ACK. Algoritmo de Karn.

El tiempo de espera de un ACK (Timeout) debe ser calculado de forma que:

• Sea lo suficientemente grande para evitar que los retardos en la red no provoquen reenvío innecesarios por retardos en el envío del ACK.
• Sea lo suficientemente pequeño para que no haya periodos de inactividad en el envío de datos en la red.

El valor del timeout se calcula de forma dinámica durante el funcionamiento de TCP a partir del RTT (Round Trip Time) o tiempo de ida y vuelta. Este RTT se calcula como el tiempo transcurrido desde el envío de un segmento y la llegada de su ACK.
El timeout se calcula como Timeout=ß*RTT. El RTT se actualiza en cada envío de segmento, por lo que el timeout se adapta a los retardos en la red. El factor ß se establece entre 1 y 2, de forma que se consiga un reenvío adecuado. (La especificación original recomienda el valor de 2).

Este mecanismo presenta un problema: ¿ que ocurre si un ACK llega demasiado tarde ?
Al reenviar el paquete y llegar el ACK del primero, el RTT se actualiza al nuevo valor. Este será demasiado pequeño, y se producirán reenvíos inútiles, afectando a la fluidez de la comunicación.

Esta situación se resuelve con el algoritmo de Karn.
Cuando se produce un reenvío, el valor del timeout se incrementa en función del último timeout calculado: nuevo_Timeout=?*Timeout. ? toma el valor de 2 para evitar inestabilidades. El timeout se volverá a calcular en función del RTT cuando se envíe un nuevo segmento que no haya sido reenviado.

Ver mi IP - Enlaces
Control de Flujo en TCP - Aviso Legal