Protocolos de Transporte

Sesin 5

George Romero Velazco

Setiembre 2012

Maestra en Ingeniera de Sistemas

Universidad Nacional de Ingeniera Facultad de Ingeniera Industrial y de Sistemas

TCP/IP y OSI

Introduccin
Los objetivos del Nivel de Transporte son:
Responsable de la entrega de un mensaje entero de proceso

a proceso. Un proceso es un programa de aplicacin que se ejecuta en una estacin. El nivel de red se encarga de la entrega de paquetes individuales desde el origen al destino El nivel de transporte, por otro lado, asegura que el mensaje completo llega intacto y en orden, supervisando el control de errores y el control de flujo en el nivel origen a destino.

4/67

Comunicacin Procesos a Proceso

El nivel de Enlace es responsable de la entrega de tramas entre dos nodos vecinos en un enlace (comunicacin nodo-a-nodo). El nivel de Red es el responsable de la comunicacin computadora-a-computadora. La comunicacin real (en Internet) tiene lugar entre dos procesos (programas de aplicacin). Por tanto, se necesita una comunicacin Proceso-a-proceso. En un momento determinado puede haber varios procesos ejecutndose en la PC origen y destino. Para completar la comunicacin hace falta un mecanismo para entregar los datos desde uno de los procesos en ejecucin en la PC origen a uno de los procesos de la PC destino.

5/67

Tipos de Comunicacin de Datos

El nivel de transporte es responsable de la comunicacin proceso a proceso

6/67

Paradigma Cliente/Servidor
Un proceso en una PC local, denominado cliente, necesita servicio desde un proceso que habitualmente est situado en un proceso remoto, denominado un servidor. Ambos procesos tienen el mismo nombre. Por ejemplo, para obtener la fecha y hora de una mquina remota se usa un proceso cliente Daytime en la computadora cliente y un proceso servidor Daytime en la mquina remota. Los SO actuales son multiusuario y multiproceso. Una PC puede ejecutar varios programas a la vez. Para la comunicacin es necesario definir:
La computadora local Proceso local Computadora remota Proceso remoto

7/67

Direccionamiento
Cada vez que es necesario enviar algo a un destino especfico entre muchos otros, es necesario tener una direccin. En el nivel de enlace se usa la direccin MAC para distinguir entre varios nodos si la conexin no es punto a punto Una trama del nivel de enlace necesita una direccin MAC destino para su envo y una direccin MAC origen para permitir respuesta.

8/67

Direccionamiento
A nivel de red se necesita una direccin IP para elegir una computadora entre millones. A nivel de transporte es necesario tener una direccin de nivel de transporte, denominada nmero de puerto, para elegir entre mltiples procesos que ejecutan en la PC destino. El nmero de puerto de destino, es necesario para la entrega; el nmero de puerto origen es necesario para la respuesta.

9/67

Direccionamiento
En el modelo de internet, los nmeros de puerto son enteros de 16 bits entre 0 y 65535. El programa cliente define su propio puerto, elegido aleatoriamente por el software de nivel de transporte que se ejecuta en el cliente. Este es el nmero de puerto efmero. El proceso servidor tambin debe definir su propio puerto. Sin embargo, este tipo de puerto no se puede elegir aleatoriamente. Si la PC donde se ejecuta el servidor ejecuta un # de puerto aleatorio, el proceso cliente que quiere acceder al servidor para usar sus servicios no conocera el nmero de puerto En Internet se ha decidido utilizar nmeros de puerto universales para algunos servidores; son los denominados nmeros de puerto bien conocidos.

10/67

Nmeros de Puerto

11/67

Direcciones IP y nmeros de puerto

Las direcciones IP y los nmeros de puerto juegan papeles distintos para seleccionar el destino final de los datos. La direccin IP destino define la PC entre todas las del mundo. Despus de seleccionar la computadora, el numero de puerto define un proceso en particular de esta computadora.

12/67

Rangos IANA
La IANA (Internet Assigned Number Authority) ha divido los nmeros de puerto en 3 rangos: Bien conocidos, registrados y dinmicos (o privados).

13/67

Direcciones de Sockets
La comunicacin proceso a proceso necesita dos identificadores, direccin IP y nmero de puerto, en cada extremo para poder crear una conexin
La combinacin de una direccin IP y un nmero de puerto se denomina direccin de socket.

La direccin del socket cliente define al proceso cliente de forma nica, al igual que la del socket del servidor define al proceso servidor

14/67

Direcciones de Sockets
Un protocolo de nivel de transporte necesita un par de direcciones de sockets: socket cliente y socket servidor. Estas cuatro piezas de informacin son parte de la cabecera IP y de la cabecera del protocolo de transporte La cabecera IP contiene las direcciones IP; la cabecera UDP o TCP contienen los nmeros de puerto.

15/67

Multiplexacin y Demultiplexacin
Multiplexacin. En el lado del emisor, puede haber varios procesos que necesitan enviar paquetes. Sin embargo, hay un nico nivel de transporte. Existe una relacin muchos a uno y necesita multiplexacin. El protocolo acepta mensajes de distintos procesos diferenciados por los nmeros de puerto que tienen asignados. Demultiplexacin. En el lado del receptor, la relacin es uno a muchos y necesita demultiplexacin.

16/67

Servicios sin conexin frente servicios orientados a conexin

Servicio sin conexin
Los paquetes son enviados de una parte a la otra sin

necesidad de establecer o liberar una conexin. Los paquetes no estn numerados; pueden retrasarse, perderse o llegar fuera de orden. No hay ningn tipo de confirmacin. En el modelo de Internet, UDP es el protocolo de transporte de estas caractersticas.

Servicio orientado a conexin

Se establece 1ero una conexin entre emisor y receptor. Los datos se transfieren. Al final, se libera la conexin

TCP y SCTP son protocolos de este tipo

17/67

Fiable frente a no fiable

El servicio de nivel de transporte puede ser fiable o no fiable. Si el programa de nivel de transporte necesita fiabilidad, se usa un protocolo fiable de nivel de transporte implementando control de error y de flujo a nivel de transporte. Esto significa servicio ms lento y ms complejo. Por otro lado, si el programa de aplicacin no necesita fiabilidad porque usa sus propios mecanismos de control de flujo o error o necesita servicio rpido o la naturaleza del servicio no demanda control de flujo y errores (aplicaciones de tiempo real), entonces se puede usar un protocolo no fiable. UDP es sin conexin y no fiable; TCP y SCTP son orientados a conexin y fiables. Estos 3 pueden responder a las demandas de los programas de nivel de aplicacin.
18/67

UDP
Sesin 5

George Romero Velazco

Setiembre 2012

Maestra en Ingeniera de Sistemas

Universidad Nacional de Ingeniera Facultad de Ingeniera Industrial y de Sistemas

User Datagram Protocol (UDP)

El protocolo de Datagrama de Usuario es un protocolo sin conexin y no fiable. No aade nada a los servicios IP excepto proporcionar comunicacin proceso a proceso en lugar de comunicaciones PC a PC. Tambin lleva a cabo comprobacin de error muy limitada. UDP es un protocolo muy sencillo que aade un mnimo de sobrecarga. Si un proceso quiere enviar un mensaje pequeo y no le preocupa mucho la fiabilidad, puede usar UDP.
20/67

Puertos bien conocidos en UDP

21/67

Datagramas de Usuario
Los paquetes UDP, tienen una cabecera de tamao fijo de 8 bytes. A continuacin se describen los campos:
Numero de puerto origen. Este es el nmero de puerto usado

por el proceso que se ejecuta en la computadora origen. Tiene 16 bits de longitud, lo que significa que el nmero de puertos puede variar entre 0 y 65535. Si la PC origen es el cliente, el nmero de puerto en la mayora de los casos es un nmero de puerto efmero pedido por el proceso y elegido por el software UDP que se ejecuta en la computadora origen. Nmero de puerto destino. Es el nmero de puerto usado por el proceso que se ejecuta en la computadora destino. Su longitud es tambin de 16 bits.
22/67

Datagramas de Usuario

23/67

Datagramas de Usuario
Si la computadora destino es el servidor (un cliente enviando una

peticin), el nmero de puerto es en la mayora de los casos un puerto bien conocido. Si la computadora destino es el cliente (un servidor enva una respuesta), el nmero de puerto es en la mayora de los casos un puerto efmero.

Longitud. Campo de 16 bits que define la longitud total del datagrama de usuario, cabecera y datos.
El campo de longitud de un datagrama UDP no es realmente

necesario. Un datagrama de usuario es encapsulado en un datagrama IP. Hay un campo de longitud total en el datagrama IP. Hay otro campo que define la longitud de la cabecera. Si se restan ambos, se deduce la longitud del datagrama UDP.

Suma de Comprobacin. Se usa para detectar los errores en el datagrama de usuario (cabecera y datos).
24/67

Funcionamiento de UDP
UDP usa conceptos transporte. Servicios sin conexin. comunes para el nivel de

UDP proporciona un servicio sin conexin. Esto significa

que cada datagrama de usuario enviado por UDP es un datagrama independiente. No hay relacin entre los distintos datagramas de usuario incluso si vienen desde el mismo proceso origen y van al mismo destino. Los datagramas de usuario NO estn numerados. Igualmente, no hay establecimiento de conexin ni terminacin de conexin, como ocurre en TCP. Esto significa que cada datagrama de usuario puede viajar por una ruta distinta.
25/67

Funcionamiento de UDP
Una de las ramificaciones de ser un protocolo sin conexin es que el proceso que usa UDP no puede olvidar un flujo de datos a UDP y esperar que UDP los parta en varios datagramas de usuario relacionados. En lugar de eso, cada peticin debe ser lo suficientemente pequea para caber dentro de un datagrama de usuario. Slo aquellos procesos que envan mensajes cortos deberan usar UDP.

26/67

Control de Flujo y Error

UDP es un protocolo de transporte muy sencillo y poco fiable. No hay control de flujo y no hay mecanismo de ventana. El receptor puede desbordarse con los mensajes que lleguen. En UDP no hay otro mecanismo de control de error ms que la suma de comprobacin. Esto significa que el emisor no sabe si existen mensajes perdidos o duplicados. Cuando el receptor detecta un error mediante la suma de comprobacin, el datagrama de usuario se descarta silenciosamente. La falta de control de flujo y control de error significa que el proceso que use UDP debera proporcionar estos mecanismos.
27/67

Encapsulamiento
Para enviar un mensaje de un proceso a otro, el protocolo UDP encapsula y desencapsula los mensajes en un datagrama IP.

28/67

Encolamiento
En UDP, existen colas asociadas con puertos. Cuando un proceso arranca, en el lado del cliente, pide un nmero de puerto al sistema operativo. Algunas implementaciones crean colas asociadas a los datos de entrada y a los datos de salida de cada proceso. Otras implementaciones crean slo una cola de entrada asociada con cada proceso. Incluso si un proceso quiere comunicarse con muchos procesos, obtiene slo un nmero de puerto y eventualmente una cola de entrada y una cola de salida. Las colas abiertas por el cliente son, en la mayora de los casos, identificados con nmeros de puerto efmeros. Las colas funcionan mientras se ejecute el proceso. Cuando termina el proceso, las colas son destruidas.
29/67

Encolamiento
El proceso cliente puede enviar mensajes a la cola de salida usando el nmero de puerto origen especificado en la peticin. UDP extrae los mensajes uno por uno y, despus de aadir la cabecera UDP, los entrega a IP. Una cola de salida puede tener desbordamiento. Si esto ocurre, el sistema operativo puede pedir al proceso cliente que espere antes de enviar ms mensajes. Cuando llega un mensaje para un cliente, UDP comprueba si existe una cola de entrada para el nmero de puerto especificado en el campo de nmero de puerto destino del datagrama de usuario.
30/67

Encolamiento
Si la cola existe, UDP enva el datagrama de usuario recibido al final de la cola. Si no existe dicha cola, UDP descarta el datagrama y le pide al protocolo ICMP que envi un mensaje de puerto inalcanzable al servidor. Todos los mensajes que llegan para un programa cliente particular, tanto si vienen del mismo o de varios servidores, se envan a la misma cola. La cola de entrada se puede llenar. Si esto ocurre, UDP tira los datagramas de usuario y pide que se enve un mensaje de puerto inalcanzable al servidor.
31/67

Encolamiento
En el lado del servidor, el mecanismo para crear las colas es distinto. En su forma ms simple, un servidor pide colas de entrada y de salida, usando nmeros de puerto bien conocidos, cuando arranca. Las colas permanecen abiertas mientras que el servidor est en ejecucin. Cuando llega un mensaje para un servidor, UDP comprueba que existe una cola de entrada para el nmero de puerto especificado en el campo nmero de puerto destino del datagrama de usuario. Si dicha cola existe, UDP enva el datagrama de usuario recibido al final de la cola.
32/67

Encolamiento
Si no existe dicha cola, UDP descarta el datagrama y le pide al protocolo ICMP que enve un mensaje de puerto inalcanzable al cliente. Todos los mensajes que llegan para un programa servidor particular, tanto si vienen del mismo o de varios clientes, se envan a la misma cola. La cola de entrada se puede llenar. Si esto ocurre, UDP elimina los datagramas de usuario y enva un mensaje de puerto inalcanzable. Cuando un servidor quiere responder a un cliente, enva los mensajes a la cola de salida, usando el nmero de puerto origen especificado en la peticin. UDP extrae los mensajes uno por uno y, despus de aadir la cabecera UDP, se los enva a IP.

33/67

Encolamiento

34/67

Uso de UDP
UDP es adecuado para un proceso que necesita comunicacin peticin-respuesta sencilla y al cual le preocupa poco el control de flujo y error. UDP es adecuado para procesos con mecanismos internos de control de flujo y error. Por ejemplo, el Trivial File Transfer Protocol (TFTP). UDP es un protocolo de transporte adecuado para multienvo. La capacidad de multienvo est empotrada en el software UDP, pero no en el TCP. UDP se usa para procesos de gestin como SNMP UDP se usa para algunos protocolos de actualizacin de ruta, como el Routing Information Protocol (RIP).
35/67

TCP
Sesin 6

George Romero Velazco

Setiembre 2012

Maestra en Ingeniera de Sistemas

Universidad Nacional de Ingeniera Facultad de Ingeniera Industrial y de Sistemas

Protocolo de Control de Transmisin

(Transmission Control Protocol)

TCP, a diferencia de UDP, es un protocolo proceso a proceso (programa a programa). TCP, como UDP usa nmeros de puertos. A diferencia de UDP, TCP es un protocolo orientado a conexin; crea una conexin virtual entre dos TCP para enviar datos. Adems, TCP usa mecanismos de control de flujo y error a nivel de transporte. Resumiendo, se dice que TCP es un protocolo de transporte orientado a conexin y fiable. Aade a IP las caractersticas de orientacin a conexin y fiabilidad
37/67

Comunicacin Proceso a Proceso

Tanto TCP como UDP, proporcionan comunicacin entre procesos usando nmeros de puerto

38/67

Comunicacin Proceso a Proceso

39/67

Servicios de Transmisin de Flujos

TCP es un protocolo orientado a flujo. En UDP, un proceso (un programa de aplicacin) enva mensajes con fronteras presididas a UDP para que los enve. UDP aade su propia cabecera a c/u de estos mensajes y los entrega a IP para su transmisin Cada mensaje del proceso se denomina un datagrama de usuario y habitualmente se convierte en un datagrama IP. Ni IP ni UDP reconocen ninguna relacin entre los datagramas.
40/67

Servicios de Transmisin de Flujos

TCP, por otro lado, permite al proceso emisor enviar datos como un Flujo de Bytes y permite al proceso receptor obtener los datos como un flujo de Bytes. TCP crea un entorno en el cual ambos procesos parecen estar conectados por un tubo imaginario que transporta sus datos a travs de Internet. El proceso emisor produce (escribe) el flujo de Bytes y el proceso receptor consume (lee) el flujo.

41/67

Envo y Recepcin de Buffers

Debido a que los procesos emisor y receptor pueden no escribir o leer datos a la misma velocidad, TCP necesita buffers para almacenamiento. Hay 2 almacenes, el del emisor y el del receptor, uno para c/direccin. Una forma de implementar un buffer es usar un vector circular con entradas de un Byte
42/67

Envo y Recepcin de Buffers

En el emisor, el almacn tiene 3 tipos de elementos. La seccin blanca contiene elementos vacos que pueden ser rellenados por el proceso emisor (productor). El rea gris ms oscura mantiene bytes que han sido enviados pero no estn todava confirmados. TCP mantiene estos bytes en el buffer hasta que recibe una confirmacin. El rea gris clara contiene los bytes a ser enviados por el TCP emisor. Sin embargo, TCP puede ser capaz de enviar slo parte de esta seccin gris clara. Esto podra deberse a la lentitud del proceso receptor o quiz a congestin en la red. Despus de que los bytes son confirmados, los elementos son reciclados y quedan disponibles para el proceso emisor.

43/67

Envo y Recepcin de Buffers

El funcionamiento del almacn en el receptor es ms sencillo. El almacn circular se divide en 2 reas. El rea blanca contiene cmaras vacas que pueden ser llenadas por los bytes recibidos de la red. La seccin gris clara contiene los bytes recibidos que pueden ser ledos por el proceso receptor. Cuando se lee un byte por el proceso remoto, se recicla el elemento y se aade al conjunto de elementos vacos.

44/67

Segmentos
Aunque el uso de almacenes gestiona las disparidades entre la velocidad del proceso productor y consumidor, es necesario un paso ms antes de poder enviar datos. La capa IP, como proveedor de servicios para TCP, necesita enviar datos en paquetes, no como flujo de bytes. En el nivel de transporte, TCP agrupa un nmero de bytes en un paquete denominado segmento. TCP aade una cabecera a cada segmento (con finalidad de control) y entrega el segmento al nivel IP para su transmisin.
45/67

Segmentos
Los segmentos son encapsulados en datagramas IP y transmitidos. Toda la operacin es transparente al proceso emisor. Los segmentos se pueden recibir fuera de orden, perderse o estar corrompidos y ser reenviados. Todo esto es gestionado por TCP sin que el proceso receptor sea consciente de estas actividades.
46/67

Comunicacin Full Duplex

TCP ofrece servicio full duplex, con el cual los datos pueden viajar en ambas direcciones al mismo tiempo. Cada TCP tiene entonces un almacn de recepcin y emisin y los segmentos se mueven en ambas direcciones.

47/67

Servicio Orientado a Conexin

A diferencia de UDP, TCP es un protocolo orientado a conexin. Cuando un proceso A quiere enviar y recibir datos de otro proceso en el sitio B, ocurre lo siguiente:
Ambos TCP establecen una conexin entre ellos. Se intercambian datos en ambas direcciones Se cierra la conexin

Observe que es una conexin virtual, no fsica. El segmento TCP es encapsulado en un datagrama IP y se puede enviar fuera de orden, perderse o corromperse, en cuyo caso es reenviado. Cada segmento puede usar una ruta distinta hasta el destino. No hay conexin fsica. TCP crea un entorno orientado a flujo en el cual acepta la responsabilidad de entregar los bytes en orden en el lugar contrario.

48/67

Servicio Fiable
TCP es un protocolo fiable. Usa mecanismo de confirmacin para comprobar que los datos han llegado completamente y seguros.

49/67

Caractersticas de TCP
Sistema de Numeracin
Aunque puede que TCP siga la pista de los segmentos que

estn siendo transmitidos o recibidos, no hay un campo para el nmero de segmento. En lugar de esto, hay 2 campos denominados nmero de secuencia y nmero de confirmacin. Estos 2 campos se refieren al nmero de Byte y no al nmero de segmento

50/67

Caractersticas de TCP
Nmero de Byte
TCP numera todos los Bytes de datos que se transmiten en

una conexin. La numeracin es independiente en cada direccin. Cuando TCP recibe Bytes de datos de un proceso, los almacena en el almacn de envo y los numera. La numeracin no comienza necesariamente desde cero. En lugar de eso, TCP genera un nmero aleatorio entre cero y 232-1 para el nmero del 1er Byte. Por ejemplo, si el nmero aleatorio es 1057, y el total de datos a enviar es 6000 bytes, los bytes se enumeran desde 1057 hasta 7056.

51/67

Caractersticas de TCP
Nmero de Secuencia
Despus de numerar los Bytes, TCP asigna un nmero de

secuencia a c/segmento que enva. El nmero de secuencia para cada segmento es el nmero del Primer Byte que transporta este segmento.

Ejemplo:
Suponga que una conexin TCP transfiere un fichero de 5000 Bytes. El 1er Byte tiene el nmero 10.001 Cules son los nmeros de secuencia para c/segmento si los datos se envan en 5 segmentos, c/u de los cuales lleva 1000 Bytes? Segmento 1nmero de secuencia: 10.001 (rango: 10.001- 11.000) Segmento 2nmero de secuencia: 11.001 (rango: 11.001- 12.000) Segmento 3nmero de secuencia: 12.001 (rango: 12.001- 13000) Segmento 4nmero de secuencia: 13.001 (rango: 13.001- 14.000) Segmento 5nmero de secuencia: 14.001 (rango: 14.001- 15.000)

52/67

Caractersticas de TCP
Cuando un segmento lleva una combinacin de datos e informacin de control (piggybacking), usa un nmero de secuencia. Si un segmento no lleva datos de usuario, no define lgicamente un nmero de secuencia. El campo esta ah, pero el valor no es valido. Algunos segmentos, aunque slo llevan informacin de control, necesitan de un nmero de secuencia para permitir la recepcin de una confirmacin desde el receptor. Cada uno de estos segmentos consume un nmero de secuencia como si llevara un byte, pero realmente no tiene datos. Si el nmero de secuencia generado aleatoriamente es X, el primer byte dato se enumera X + 1.

53/67

Caractersticas de TCP
Nmero de Confirmacin
La comunicacin en TCP es full dplex; cuando se establece una

conexin, ambas partes pueden enviar y recibir datos al mismo tiempo. Cada parte numera los Bytes, habitualmente con un nmero de Byte inicial distinto El nmero de secuencia de c/direccin muestra el nmero del 1er Byte transportado por c/segmento Cada parte usa tambin un nmero de confirmacin para confirmar los Bytes que ha recibido. El nmero de confirmacin define el nmero del Siguiente Byte que una parte espera recibir. Es acumulativo, lo que significa que esa parte pone el nmero del ltimo Byte que recibido correctamente, le suma 1 y enva esta suma como nmero de confirmacin.
54/67

Caractersticas de TCP
Control de Flujo
TCP, a diferencia de UDP, proporciona control de flujo. El receptor de los datos controla la cantidad de datos que deben ser

enviados por el emisor. Esto se hace para evitar que el receptor sea desbordado con datos. El sistema de numeracin permite a TCP usar un control de flujo orientado a byte.

Control de Error
Para proporcionar un servicio fiable, TCP implementa mecanismos de

control de error. Aunque el control de error considera el segmento como la unidad de datos para la deteccin de error (segmentos perdidos o corruptos), el control de error es orientado a byte.

Control de Congestin
TCP, a diferencia de UDP, tiene en cuenta la congestin en la red. La cantidad de datos enviados por el emisor no slo es controlado por el

receptor (control de flujo), sino que tambin se determina por el nivel de congestin de la red.
55/67

Formato de los Segmentos

Un paquete en TCP se denomina segmento. El segmento esta formado por una cabecera (20 - 60 bytes), seguida por los datos del programa de aplicacin. La cabecera tiene 20 Bytes si no hay opciones y hasta 60 Bytes si contiene opciones.

56/67

Una conexin TCP

TCP es un protocolo orientado a conexin que establece un camino virtual entre el origen y el destino. Se necesitan 3 fases.

Establecimiento de la conexin
Se denomina negociacin en 3 pasos (three-way handshaking). El proceso comienza en el servidor. El programa servidor le dice a

su TCP que esta listo para aceptar una conexin A esto se llama apertura pasiva. El cliente emite una peticin para una apertura activa. Un cliente que quiere conectarse a un servidor abierto le dice a su TCP que necesita conectarse a ese servidor particular. Ahora TCP puede empezar la negociacin en 3 pasos.
57/67

Negociacin en 3 pasos
El cliente enva el 1er segmento, con segmento SYN, en el cual slo el campo SYN est activo. Este segmento es para sincronizar los nmeros de secuencia. Consume un nmero de secuencia. El servidor enva un 2do segmento, un segmento SYN + ACK, con 2 bits de flags activos: SYN y ACK. Consume nmero de secuencia. El cliente enva el 3er segmento. Es slo un segmento ACK. Confirma la recepcin del 2do segmento con el flag ACK y el campo del nmero de confirmacin.
58/67

Transferencia de Datos
Despus del establecimiento de conexin, se puede efectuar transmisin de datos bidireccional. Tanto el cliente como el servidor pueden enviar datos y confirmaciones As, en la figura, el cliente enva 2000 bytes de datos en 2 segmentos. El servidor enva 2000 Bytes en un segmento. El cliente enva un segmento ms. Los 3 1eros segmentos transportan datos y confirmaciones. El ltimo segmento slo lleva una confirmacin porque no hay ms datos.
59/67

Liberacin de Conexin
Cualquiera de las 2 partes involucradas en un intercambio de datos (cliente o servidor) puede cerrar la conexin, aunque normalmente suele ser el cliente. La mayora de las implementaciones actuales tienen 2 opciones para terminar la conexin: Negociacin en 3 pasos y negociacin en 4 pasos con una opcin de semi-cierre.
60/67

Control de Flujo
TCP usa una ventana deslizante para gestionar el control de flujo. El protocolo de ventana deslizante usado por TCP est entre la ventana deslizante compuesta atrs N y la ventana deslizante con repeticin selectiva. Hay 2 grandes diferencias entre la ventana deslizante TCP y la que usa el nivel de enlace:
La ventana deslizante TCP es orientada a byte; la del nivel de

enlace es orientada a trama. La ventana deslizante de TCP es de tamao variable; la del nivel de enlace es de tamao fijo.

61/67

Control de Flujo
La ventana se extiende a una parte del almacn que contiene los bytes recibidos del proceso. Los bytes dentro de la ventana son los bytes que pueden estar en trnsito; se pueden enviar sin preocuparse de la confirmacin. La ventana imaginaria tiene 2 paredes: una izquierda y una derecha. La ventana puede estar abierta, cerrada o reducida. Estas 3 actividades, estn bajo el control del receptor, no del emisor.

62/67

Control de Flujo
Abrir una ventana significa mover la pared derecha a la derecha. Esto permite tener nuevos bytes listos para enviar en el almacn. Cerrar la ventana significa mover la pared izquierda a la derecha, esto significa que algunos bytes han sido confirmados y el emisor no tiene que preocuparse por ellos nunca ms. Reducir la ventana significa mover la pared derecha hacia la izquierda, esto se desaconseja fuertemente y no se permite en algunas implementaciones. La pared izquierda no se puede mover a la izquierda porque revocara algunas de las confirmaciones ya enviadas.

63/67

Control de Flujo
El tamao de la ventana en un lado es determinado por el menor de estos valores: ventana de recepcin (rwnd) o ventana de congestin (cwnd). La ventana de recepcin es el valor notificado por el extremo opuesto en un segmento que contiene una confirmacin. Es el nmero de bytes que el otro extremo puede aceptar antes de que su almacn se desborde y tenga que descartar datos. La ventana de congestin es un valor determinado por la red para evitar la congestin.
64/67

Control de Flujo
Algunos puntos acerca de la ventana deslizante en TCP:
El tamao de la ventana es el mnimo de rwnd y cwnd. El origen no tiene que enviar una ventana entera llena de datos. La ventana puede ser abierta o cerrada por el receptor, pero no

debera ser reducida. El destino puede enviar una confirmacin en cualquier momento siempre que eso nos d como resultado una reduccin de ventana. El receptor puede cerrar temporalmente la ventana; sin embargo, el emisor siempre puede enviar un segmento de un byte despus de que la ventana haya sido cerrada.

65/67

Control de Flujo
La figura muestra un ejemplo de una ventana deslizante. El emisor ha enviado hasta 202 bytes. Se asume que cwnd es 20. El receptor ha enviado un nmero de confirmacin de 200 con un rwnd de 9. El tamao de la ventana de emisin es el mnimo entre rwnd y cwnd, es decir 9 bytes. Se envan los bytes 200 a 202, pero no se recibe confirmacin. Los bytes 203 a 208 se pueden enviar sin preocuparse de la confirmacin. El byte 209 y posteriores NO se pueden enviar.

66/67

Control de Flujo

67/67

Muchas gracias por su atencin

MsC. Ing. George Romero george.romero@gmail.com

68