Cargando tu IP...

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