CAPITULO 4

Capa de Transporte del modelo OSI

La capa de Transporte permite la segmentacin de datos y brinda el control necesario para reensamblar las partes dentro de los distintos streams de comunicacin. Las responsabilidades principales que debe cumplir son: Seguimiento de la comunicacin individual entre aplicaciones en los hosts origen y destino, Segmentacin de datos y gestin de cada porcin, Reensamble de segmentos en flujos de datos de aplicacin, e Identificacin de las diferentes aplicaciones. Seguimiento de Conversaciones individuales Cualquier host puede tener mltiples aplicaciones que se estn comunicando a travs de la red. Cada una de estas aplicaciones se comunicar con una o ms aplicaciones en hosts remotos. Segmentacin de datos Debido a que cada aplicacin genera un stream de datos para enviar a una aplicacin remota, estos datos deben prepararse para ser enviados por los medios en partes manejables. Los protocolos de la capa de Transporte describen los servicios que segmentan estos datos de la capa de Aplicacin. Reensamble de segmentos En el host de recepcin, cada seccin de datos puede ser direccionada a la aplicacin adecuada. Adems, estas secciones de datos individuales tambin deben reconstruirse para generar un stream completo de datos que sea til para la capa de Aplicacin.

Identificacin de las aplicaciones

Para poder transferir los streams de datos a las aplicaciones adecuadas, la capa de Transporte debe identificar la aplicacin de destino. Para lograr esto, la capa de Transporte asigna un identificador a la aplicacin. Los protocolos TCP/IP denominan a este identificador nmero de puerto. La capa de Transporte es el enlace entre la capa de Aplicacin y las capas inferiores, que son responsables de la transmisin en la red. Esta capa acepta datos de distintas conversaciones y los transfiere a las capas inferiores como secciones manejables que puedan ser eventualmente multiplexadas a travs del medio.
La divisin de los datos en partes pequeas y el envo de estas partes desde el origen hacia el destino permiten que se puedan entrelazar (multiplexar) distintas comunicaciones en la misma red. La segmentacin de los datos, que cumple con los protocolos de la capa de Transporte, proporciona los medios para enviar y recibir datos cuando se ejecutan varias aplicaciones de manera concurrente en una computadora. Sin segmentacin, slo una aplicacin, la corriente de vdeo por ejemplo, podra recibir datos. No se podran recibir correos electrnicos, chats ni mensajes instantneos ni visualizar pginas Web y ver un vdeo al mismo tiempo. En la capa de Transporte, cada conjunto de secciones en particular que fluyen desde una aplicacin de origen a una de destino se conoce como conversacin. Control de las conversaciones Las funciones principales especificadas por todos los protocolos de la capa de Transporte incluyen: Segmentacin y reensamblaje: La mayora de las redes poseen una limitacin en cuanto a la cantidad de datos que pueden incluirse en una nica PDU (Unidad de datos del protocolo). La capa de Transporte divide los datos de aplicacin en bloques de datos de un tamao adecuado. En el destino, la capa de Transporte reensambla los datos antes de enviarlos a la aplicacin o servicio de destino.

Multiplexacin de conversaciones: A cada una de estas aplicaciones o servicios se les asigna una direccin conocida como puerto para que la capa de Transporte pueda determinar con qu aplicacin o servicio se identifican los datos.

Adems de utilizar la informacin contenida en los encabezados para las funciones bsicas de segmentacin y reensamblaje de datos, algunos protocolos de la capa de Transporte proveen: Conversaciones orientadas a la conexin, Entrega confiable, Reconstruccin ordenada de datos, y Control del flujo.

Un protocolo de la capa de Transporte puede implementar un mtodo para asegurar la entrega confiable de los datos. En trminos de redes, confiabilidad significa asegurar que cada seccin de datos que enva el origen llegue al destino. En la capa de Transporte, las tres operaciones bsicas de confiabilidad son: Seguimiento de datos transmitidos, Acuse de recibo de los datos recibidos, y Retransmisin de cualquier dato sin acuse de recibo. La capa de Transporte del host de recepcin tambin debe rastrear los datos a medida que se reciben y reconocer la recepcin de los datos. Estos procesos de confiabilidad generan un uso adicional de los recursos de la red debido al reconocimiento, rastreo y retransmisin. Para admitir estas operaciones de confiabilidad se intercambian ms datos de control entre los hosts emisores y receptores. Esta informacin de control est contenida en el encabezado de la Capa 4. Esto genera un equilibrio ("trade-off") entre el valor de confiabilidad y la carga que representa para la red. En el contexto de las redes, la entrega de mximo esfuerzo se considera no confiable, ya que no existe acuse de recibo de que los datos hayan llegado al destino.

TCP y UDP

Los dos protocolos ms comunes de la capa de Transporte del conjunto de protocolos TCP/IP son el Protocolo de control de transmisin (TCP) y el Protocolos de datagramas de usuario (UDP). Ambos protocolos gestionan la comunicacin de mltiples aplicaciones. Las diferencias entre ellos son las funciones especficas que cada uno implementa. Protocolo de datagramas de usuario (UDP) UDP es un protocolo simple, sin conexin, descrito en la RFC 768. Cuenta con la ventaja de proveer la entrega de datos sin utilizar muchos recursos. Las porciones de comunicacin en UDP se llaman datagramas. Este protocolo de la capa de Transporte enva estos datagramas como "mejor intento". Entre las aplicaciones que utilizan UDP se incluyen: Sistema de nombres de dominios (DNS), streaming de vdeo, y Voz sobre IP (VoIP). Protocolo de control de transmisin (TCP) TCP es un protocolo orientado a la conexin, descrito en la RFC 793. TCP incurre en el uso adicional de recursos para agregar funciones. Las funciones adicionales especificadas por TCP estn en el mismo orden de entrega, son de entrega confiable y de control de flujo. Cada segmento de TCP posee 20 bytes de carga en el encabezado, que encapsulan los datos de la capa de Aplicacin, mientras que cada segmento UDP slo posee 8 bytes de carga. Las aplicaciones que utilizan TCP son: Exploradores Web, e-mail, y Transferencia de archivos Los servicios basados en TCP y UDP mantienen un seguimiento de las varias aplicaciones que se comunican. Para diferenciar los segmentos y datagramas para cada aplicacin, tanto TCP como UDP cuentan con campos de encabezado que pueden identificar de manera exclusiva estas aplicaciones. Estos identificadores nicos son los nmeros de los puertos. En el encabezado de cada segmento o datagrama hay un puerto de origen y destino. El nmero de puerto de origen es el nmero para esta comunicacin asociado con la aplicacin que origina la comunicacin en el host local. El nmero de puerto de destino es el nmero para esta comunicacin asociado con la aplicacin de destino en el host remoto.

Los nmeros de puerto se asignan de varias maneras, en funcin de si el mensaje es una solicitud o una respuesta. Mientras que los procesos en el servidor poseen nmeros de puertos estticos asignados a ellos, los clientes eligen un nmero de puerto de forma dinmica para cada conversacin.
La combinacin del nmero de puerto de la capa de Transporte y de la direccin IP de la capa de Red asignada al host identifica de manera exclusiva un proceso en particular que se ejecuta en un dispositivo host especfico. Esta combinacin se denomina socket. Eventualmente, los trminos nmero de puerto y socket se utilizan en forma indistinta. En el contexto de este curso, el trmino socket hace referencia slo a la combinacin exclusiva de direccin IP y nmero de puerto. Un par de sockets, que consiste en las direcciones IP y los nmeros de puerto de origen y de destino, tambin es exclusivo e identifica la conversacin entre dos hosts. Por ejemplo, una solicitud de pgina Web HTTP que se enva a un servidor Web (puerto 80) y que se ejecuta en un host con una direccin IPv4 de Capa 3 192.168.1.20 ser destinada al socket 192.168.1.20:80. Si el explorador Web que solicita la pgina Web se ejecuta en el host 192.168.100.48 y el nmero de puerto dinmico asignado al explorador Web es 49.152, el socket para la pgina Web ser 192.168.100.48:49152. La Autoridad de nmeros asignados de Internet (IANA) asigna nmeros de puerto. IANA es un organismo de estndares responsable de la asignacin de varias normas de direccionamiento. Existen distintos tipos de nmeros de puerto: Puertos bien conocidos (Nmeros del 0 al 1 023): estos nmeros se reservan para servicios y aplicaciones. Por lo general, se utilizan para aplicaciones como HTTP (servidor Web), POP3/SMTP (servidor de email) y Telnet. Al definir estos puertos conocidos para las aplicaciones del servidor, las aplicaciones del cliente pueden ser programadas para solicitar una conexin a un puerto especfico y su servicio asociado. Puertos Registrados (Nmeros 1024 al 49151): estos nmeros de puertos estn asignados a procesos o aplicaciones del usuario. Estos procesos son principalmente aplicaciones individuales que el usuario elige instalar en lugar de aplicaciones comunes que recibira un puerto bien conocido. Cuando no se utilizan para un recurso del servidor, estos puertos tambin pueden utilizarse si un usuario los selecciona de manera dinmica como puerto de origen. Puertos dinmicos o privados (Nmeros del 49 152 al 65 535): tambin conocidos como puertos efmeros, suelen asignarse de manera dinmica a aplicaciones de cliente cuando se inicia una conexin. No es muy comn que un cliente se conecte a un servicio utilizando un puerto dinmico o privado (aunque algunos programas que comparten archivos punto a punto lo hacen). A veces es necesario conocer las conexiones TCP activas que estn abiertas y en ejecucin en el host de red. Netstat es una utilidad de red importante que puede usarse para verificar esas conexiones. Netstat indica el protocolo en uso, la direccin y el nmero de puerto locales, la direccin y el nmero de puerto ajenos y el estado de la conexin.

Las conexiones TCP no descritas pueden representar una importante amenaza a la seguridad. Esto se debe a que pueden indicar que algo o alguien est conectado al host local. Adems, las conexiones TCP innecesarias pueden consumir recursos valiosos del sistema y por lo tanto disminuir el rendimiento del host. Netstat debe utilizarse para determinar las conexiones abiertas de un host cuando el rendimiento parece estar comprometido. Dividir los datos de aplicacin en secciones garantiza que los datos se transmitan dentro de los lmites del medio y que los datos de distintas aplicaciones puedan ser multiplexados en el medio. TCP y UDP gestionan la segmentacin de forma distinta. Con TCP, cada encabezado de segmento contiene un nmero de secuencia. Este nmero de secuencia permite que las funciones de la capa de Transporte del host de destino reensamblen los segmentos en el mismo orden en el que fueron transmitidos. Esto asegura que la aplicacin de destino cuente con los datos en la forma exacta en la que se enviaron. A pesar de que los servicios que utilizan UDP tambin rastrean las conversaciones entre aplicaciones, no tienen en cuenta el orden en el que se transmiti la informacin ni el mantenimiento de la conexin. No existe nmero de secuencia en el encabezado UDP. UDP es un diseo simple y genera menos carga que TCP, lo que produce una transferencia de datos ms rpida. La informacin puede llegar en un orden distinto al que fue transmitida, ya que los paquetes pueden tomar diversas rutas a travs de la red. Una aplicacin que utiliza UDP debe tolerar el hecho de que los datos no lleguen en el orden en el que fueron enviados.

La diferencia clave entre TCP y UDP es la confiabilidad

La confiabilidad de la comunicacin TCP se lleva a cabo utilizando sesiones orientadas a la conexin. Antes de que un host que utiliza TCP enve datos a otro host, la capa de Transporte inicia un proceso para crear una conexin con el destino. Esta conexin permite el rastreo de una sesin o stream de comunicacin entre los hosts. Este proceso asegura que cada host tenga conocimiento de la comunicacin y se prepare. Una conversacin TCP completa requiere el establecimiento de una sesin entre los hosts en ambas direcciones.

Parte de la carga adicional que genera el uso de TCP es el trfico de red generado por los acuses de recibo y las retransmisiones. El establecimiento de las sesiones genera cargas en forma de segmentos adicionales intercambiados. Tambin existen cargas adicionales en los hosts individuales, generadas por la necesidad de mantener un seguimiento de los segmentos que esperan acuse de recibo y por el proceso de retransmisin. Esta confiabilidad se logra contando con campos en el segmento TCP, cada uno con una funcin especfica, como se muestra en la figura. Estos campos se explicarn ms adelante en esta seccin.

nmero de puerto, de forma predeterminada o manual. Un servidor individual no puede tener dos servicios asignados al mismo nmero de puerto dentro de los mismos servicios de la capa de Transporte. Un host que ejecuta una aplicacin de servidor Web y una de transferencia de archivos no puede configurar ambas para utilizar el mismo puerto (por ejemplo, el puerto TCP 8.080). Cuando una aplicacin de servidor activa se asigna a un puerto especfico, este puerto se considera "abierto" para el servidor. Esto significa que la capa de Transporte acepta y procesa segmentos direccionados a ese puerto.

Es comn que un servidor provea ms de un servicio, como un servidor Web y un servidor FTP, al mismo tiempo. Una manera de mejorar la seguridad en un servidor es restringir el acceso al servidor a slo aquellos puertos asociados con los servicios y aplicaciones accesibles a solicitantes autorizados.

Cada conexin representa dos streams de comunicacin de una va o sesiones. Para establecer la conexin los hosts realizan un intercambio de seales de tres vas. Los bits de control en el encabezado TCP indican el progreso y estado de la conexin. Enlace de tres vas: Establece que el dispositivo de destino est presente en la red. Verifica que el dispositivo de destino tenga un servicio activo y est aceptando las peticiones en el nmero de puerto de destino que el cliente que lo inicia intente usar para la sesin. Informa al dispositivo de destino que el cliente de origen intenta establecer una sesin de comunicacin en ese nmero de puerto.

En conexiones TCP, el host que brinde el servicio como cliente inicia la sesin al servidor. Los tres pasos para el establecimiento de una conexin TCP son: 1. El cliente que inicia la conexin enva un segmento que contiene un valor de secuencia inicial, que acta como solicitud para el servidor para comenzar una sesin de comunicacin. 2. El servidor responde con un segmento que contiene un valor de reconocimiento igual al valor de secuencia recibido ms 1, adems de su propio valor de secuencia de sincronizacin. El valor es uno mayor que el nmero de secuencia porque el ACK es siempre el prximo Byte u Octeto esperado. Este valor de reconocimiento permite al cliente unir la respuesta al segmento original que fue enviado al servidor. 3. El cliente que inicia la conexin responde con un valor de reconocimiento igual al valor de secuencia que recibi ms uno. Esto completa el proceso de establecimiento de la conexin. Para entender el proceso de enlace de tres vas, es importante observar los distintos valores que intercambian los dos hosts. Dentro del encabezado del segmento TCP, existen seis campos de 1 bit que contienen informacin de control utilizada para gestionar los procesos de TCP. Estos campos son los siguientes: URG: Urgente campo de sealizador significativo, ACK: Campo significativo de acuse de recibo,

PSH: Funcin de empuje, RST: Reconfiguracin de la conexin, SYN: Sincronizar nmeros de secuencia, FIN: No hay ms datos desde el emisor.

Protocolo TCP de enlace de tres vas

Un cliente TCP comienza el enlace de tres vas enviando un segmento con el sealizador de control SYN (Sincronizar nmeros de secuencia) establecido, indicando un valor inicial en el campo de nmero de secuencia del encabezado. Este valor inicial para el nmero de secuencia, conocido como nmero de secuencia inicial (ISN), se elige de manera aleatoria y se utiliza para comenzar a rastrear el flujo de datos desde el cliente al servidor para esta sesin. El ISN en el encabezado de cada segmento se incrementa en uno por cada byte de datos enviados desde el cliente hacia el servidor mientras contina la conversacin de datos.

Se establece el sealizador de control SYN y el nmero de secuencia relativa en 0. A pesar de que el analizador de protocolos en el grfico indica los valores relativos para los nmeros de secuencia y de acuse de recibo, los valores reales son nmeros binarios de 32 bits. Se pueden determinar los nmeros reales enviados en los encabezados de los segmentos examinando el panel de bytes del paquete. Aqu se pueden ver los cuatro bytes representados en hexadecimal.

Se puede aadir seguridad a la red de datos de la siguiente manera: denegar el establecimiento de sesiones TCP, slo permitir sesiones para ser establecidas por servicios especficos, o slo permitir trfico como parte de sesiones ya establecidas.

Terminacin de la sesin TCP

Para cerrar la conexin se debe establecer el sealizador de control FIN (Finalizar) en el encabezado del segmento. Para finalizar todas las sesiones TCP de una va, se utiliza un enlace de dos vas, que consta de un segmento FIN y un segmento ACK. Por lo tanto, para terminar una conversacin simple admitida por TCP, se requieren cuatro intercambios para finalizar ambas sesiones. 1. Cuando el cliente no tiene ms datos para enviar al stream, enva un segmento con el sealizador FIN establecido. 2.El servidor enva un ACK para acusar recibo de Fin y terminar la sesin del cliente al servidor. 3. El servidor enva un FIN al cliente para finalizar la sesin del servidor al cliente. 4. El cliente responde con un ACK para dar acuse de recibo de FIN desde el servidor.

Cuando los servicios envan datos utilizando TCP, los segmentos pueden llegar a destinos desordenados. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se reensamblan en el orden original. Para lograr esto, se asignan nmeros de secuencia en el encabezado de cada paquete. Durante la configuracin de la sesin, se establece un nmero de secuencia inicial (ISN). Este nmero de secuencia inicial representa el valor de inicio para los bytes de esta sesin que se transmitirn a la aplicacin receptora. A medida que se transmiten los datos durante la sesin, el nmero de secuencia se incrementa en el nmero de bytes que se han transmitido. Este rastreo de bytes de datos permite que cada segmento se identifique y se enve acuse de recibo de manera exclusiva. Se pueden identificar segmentos perdidos. Los nmeros de secuencia de segmento permiten la confiabilidad indicando cmo reensamblar y reordenar los segmentos recibidos, como se muestra en la figura. El proceso TCP receptor coloca los datos del segmento en un bfer de recepcin. Los segmentos se colocan en el orden de nmero de secuencia adecuado y se pasa a la capa de Aplicacin cuando son reensamblados. Todos los segmentos que llegan con nmeros de secuencia no contiguos se mantienen para su procesamiento posterior. Luego, se procesan los segmentos cuando llegan con los bytes perdidos.

Acuse de recibo de TCP con uso de ventanas

Confirmacin de recepcin de segmentos
Una de las funciones de TCP es asegurar que cada segmento llegue a su destino. Los servicios TCP en el host de destino envan a la aplicacin de origen un acuse de recibo de los datos recibidos. El nmero de secuencia y el nmero de acuse de recibo del encabezado del segmento se utilizan para confirmar la recepcin de los bytes de datos contenidos en los segmentos. El nmero de secuencia es el nmero relativo de bytes que ha sido transmitido en esta sesin ms 1 (que es el nmero del primer byte de datos en el segmento actual). TCP utiliza el nmero de reconocimiento en segmentos que se vuelven a enviar al origen para indicar el prximo byte de esta sesin que espera el receptor. Esto se llama acuse de recibo de expectativa.

Retransmisin de TCP
Manejo de la prdida de segmentos
Por ptimo que sea el diseo de una red, siempre se producirn prdidas ocasionales de datos. Por lo tanto, TCP cuenta con mtodos para gestionar dichas prdidas de segmentos. Entre los mismos existe un mecanismo para retransmitir segmentos con datos no reconocidos. Un servicio de host de destino que utiliza TCP, por lo general slo reconoce datos para secuencias de bytes contiguas. Si uno o ms segmentos se pierden, slo se acusa recibo de los datos de los segmentos que completan el stream.

Por ejemplo, si se reciben los segmentos con nmeros de secuencia de 1500 a 3000 y de 3400 a 3500, el nmero de acuse de recibo ser 3001. Esto sucede porque existen segmentos con nmeros de secuencia de 3001 a 3399 que no se recibieron. Cuando TCP en el host de origen no recibe un acuse de recibo pasado un tiempo predeterminado, volver al ltimo nmero de acuse de recibo que recibi y retransmitir los datos a partir de ste. El proceso de retransmisin no es especificado por RFC, sino que depende de la implementacin de TCP en particular. Para una implementacin de TCP tpica, un host puede transmitir un segmento, colocar una copia del segmento en una cola de retransmisin e iniciar un temporizador. Cuando se recibe el acuse de recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de que el temporizador venza, el segmento es retransmitido. La animacin demuestra la retransmisin de segmentos perdidos. Los hosts actuales tambin suelen emplear una funcin opcional llamada Acuses de recibo selectivos. Si ambos hosts admiten el Acuse de recibo selectivo, es posible que el destino reconozca los bytes de segmentos discontinuos y el host slo necesitar retransmitir los datos perdidos.

Control del flujo

TCP tambin provee mecanismos para el control del flujo. El control del flujo contribuye con la confiabilidad de la transmisin TCP ajustando la tasa efectiva de flujo de datos entre los dos servicios de la sesin. Cuando el origen advierte que se recibi la cantidad de datos especificados en los segmentos, puede continuar enviando ms datos para esta sesin. El campo Tamao de la ventana en el encabezado TCP especifica la cantidad de datos que puede transmitirse antes de que se reciba el acuse de recibo. El tamao de la ventana inicial se determina durante el comienzo de la sesin a travs del enlace de tres vas. El mecanismo de retroalimentacin de TCP ajusta la tasa de transmisin de datos efectiva al flujo mximo que la red y el dispositivo de destino pueden soportar sin sufrir prdidas. TCP intenta gestionar la tasa de transmisin de manera que todos los datos se reciban y se reduzcan las retransmisiones.

Reduccin del tamao de la ventana

Otra forma de controlar el flujo de datos es utilizar tamaos dinmicos de ventana. Cuando los recursos de la red son limitados, TCP puede reducir el tamao de la ventana para lograr que los segmentos recibidos sean reconocidos con mayor frecuencia. Esto disminuye de manera efectiva la tasa de transmisin, ya que el origen espera que los datos sean recibidos con ms frecuencia. El host receptor TCP enva el valor del tamao de la ventana al TCP emisor para indicar el nmero de bytes que est preparado para recibir como parte de la sesin. Si el destino necesita disminuir la tasa de comunicacin debido a

limitaciones de memoria del bfer, puede enviar un valor de tamao de la ventana menor al origen como parte de un acuse de recibo.

Protocolo UDP: Comunicacin con baja sobrecarga

4.4.1 UDP: Baja sobrecarga vs Confiabilidad
UDP es un protocolo simple que provee las funciones bsicas de la capa de Transporte. Genera mucho menos sobrecarga que TCP, ya que no es orientado a la conexin y no cuenta con los sofisticados mecanismos de retransmisin, secuenciacin y control del flujo. Esto no significa que las aplicaciones que utilizan UDP no sean confiables. Slo quiere decir que estas funciones no son contempladas por el protocolo de la capa de Transporte y deben implementarse aparte, si fuera necesario. Pese a que es relativamente baja la cantidad total de trfico UDP que puede encontrarse en una red tpica, entre los protocolos principales de la capa de Aplicacin que utilizan UDP se incluyen: sistema de denominacin de dominio (DNS), protocolo simple de administracin de red (SNMP), protocolo de configuracin dinmica de host (DHCP), protocolo de informacin de enrutamiento (RIP), protocolo trivial de transferencia de archivos (TFTP), y juegos en lnea.

La baja sobrecarga de UDP lo hacen deseable para dichas aplicaciones.

Reensamblaje de datagramas de UDP

Ya que UDP opera sin conexin, las sesiones no se establecen antes de que se lleve a cabo la comunicacin, como sucede con TCP. Se dice que UDP es basado en transacciones. En otras palabras, cuando una aplicacin posee datos para enviar, simplemente los enva. Muchas aplicaciones que utilizan UDP envan pequeas cantidades de datos que pueden ocupar un segmento. Sin embargo, algunas aplicaciones enviarn cantidades mayores de datos que deben dividirse en varios segmentos. La PDU de UDP se conoce como datagrama, pese a que los trminos segmento y datagrama a veces se utilizan de manera indistinta para describir una PDU de la capa de Transporte. Cuando se envan mltiples datagramas a un destino, los mismos pueden tomar rutas distintas y llegar en el orden incorrecto. UDP no mantiene un seguimiento de los nmeros de secuencia de la manera en que lo hace TCP. UDP no puede reordenar los datagramas en el orden de la transmisin

Procesos y solicitudes del servidor UDP

Al igual que las aplicaciones basadas en TCP, a las aplicaciones de servidor basadas en UDP se les asigna nmeros de puerto bien conocidos o registrados. Cuando se ejecutan estas aplicaciones o procesos, aceptan los datos que coincidan con el nmero de puerto asignado. Cuando UDP recibe un datagrama destinado a uno de esos puertos, enva los datos de aplicacin a la aplicacin adecuada en base a su nmero de puerto.

Procesos del cliente UDP

Como en TCP, la comunicacin cliente/servidor se inicia por una aplicacin cliente que solicita datos de un proceso del servidor. El proceso de cliente UDP selecciona al azar un nmero de puerto del rango dinmico de nmeros de puerto y lo utiliza como puerto de origen para la conversacin. El puerto de destino por lo general ser el nmero de puerto bien conocido o registrado asignado al proceso del servidor. Los nmeros de puerto de origen seleccionados al azar colaboran con la seguridad. Si existe un patrn predecible para la seleccin del puerto de destino, un intruso puede simular el acceso a un cliente de manera ms sencilla intentando conectarse al nmero de puerto que tenga mayor posibilidad de estar abierto. Ya que no se crean sesiones con UDP, tan pronto como los datos estn listos para ser enviados y los puertos estn identificados, UDP puede formar el datagrama y enviarlo a la capa de Red para direccionamiento y envo a la red

CAPITULO 5 Capa de red de OSI

Los protocolos de la capa de Red del modelo OSI especifican el direccionamiento y los procesos que permiten que los datos de la capa de Transporte sean empaquetados y transportados. La encapsulacin de la capa de Red permite que su contenido pase al destino dentro de una red o sobre otra red con una carga mnima.

Capa de Red: comunicacin de host a host

La Capa de red o Capa 3 de OSI provee servicios para intercambiar secciones de datos individuales a travs de la red entre dispositivos finales identificados. Para realizar este transporte de extremo a extremo la Capa 3 utiliza cuatro procesos bsicos: direccionamiento, encapsulamiento, enrutamiento , y desencapsulamiento.

Direccionamiento
Primero, la Capa de red debe proveer un mecanismo para direccionar estos dispositivos finales. Si las secciones individuales de datos deben dirigirse a un dispositivo final, este dispositivo debe tener una direccin nica. En una red IPv4, cuando se agrega esta direccin a un dispositivo, al dispositivo se lo denomina host.

Encapsulacin
Segundo, la capa de Red debe proveer encapsulacin. Los dispositivos no deben ser identificados slo con una direccin; las secciones individuales, las PDU de la capa de Red, deben, adems, contener estas direcciones. Durante el proceso de encapsulacin, la Capa 3 recibe la PDU de la Capa 4 y agrega un encabezado o etiqueta de Capa 3 para crear la PDU de la Capa 3. Cuando nos referimos a la capa de Red, denominamos paquete a esta PDU

Enrutamiento
Luego, la capa de red debe proveer los servicios para dirigir estos paquetes a su host destino. Los host de origen y destino no siempre estn conectados a la misma red. En realidad, el paquete podra recorrer muchas redes diferentes. A lo largo de la ruta, cada paquete debe ser guiado a travs de la red para que llegue a su destino final. Los dispositivos intermediarios que conectan las redes son los routers. La funcin del router es seleccionar las rutas y dirigir paquetes hacia su destino. A este proceso se lo conoce como enrutamiento. Durante el enrutamiento a travs de una internetwork, el paquete puede recorrer muchos dispositivos intermediarios. A cada ruta que toma un paquete para llegar al prximo dispositivo se la llama salto. A medida que el paquete es enviado, su contenido (la PDU de la Capa de transporte) permanece intacto hasta que llega al host destino.

Desencapsulamiento
Finalmente, el paquete llega al host destino y es procesado en la Capa 3. El host examina la direccin de destino para verificar que el paquete fue direccionado a ese dispositivo. Si la direccin es correcta, el paquete es desencapsulado por la capa de Red y la PDU de la Capa 4 contenida en el paquete pasa hasta el servicio adecuado en la capa de Transporte. A diferencia de la capa de Transporte (Capa 4 de OSI), que administra el transporte de datos entre los procesos que se ejecutan en cada host final, los protocolos especifican la estructura y el procesamiento del paquete utilizados para llevar los datos desde un host hasta otro host. Operar ignorando los datos de aplicacin llevados en cada paquete permite a la capa de Red llevar paquetes para mltiples tipos de comunicaciones entre hosts mltiples.

Protocolos de capa de Red

Los protocolos implementados en la capa de Red que llevan datos del usuario son: versin 4 del Protocolo de Internet (IPv4), versin 6 del Protocolo de Internet (IPv6), intetercambio Novell de paquetes de internetwork (IPX), AppleTalk, y servicio de red sin conexin (CLNS/DECNet). El Protocolo de Internet (IPv4 y IPv6) es el protocolo de transporte de datos de la capa 3 ms ampliamene utilizado y ser el tema de este curso.

El Protocolo de Internet fue diseado como un protocolo con bajo costo. Provee slo las funciones necesarias para enviar un paquete desde un origen a un destino a travs de un sistema interconectado de redes. El protocolo no fue diseado para rastrear ni administrar el flujo de paquetes. Estas funciones son realizadas por otros protocolos en otras capas. Caractersticas bsicas de IPv4: Sin conexin: No establece conexin antes de enviar los paquetes de datos. Mximo esfuerzo (no confiable): No se usan encabezados para garantizar la entrega de paquetes. Medios independientes: Operan independientemente del medio que lleva los datos

Protocolo IPv4: Sin conexin

conexin as como tambin los campos adicionales en el encabezado de la PDU. Como IP trabaja sin conexin, no requiere un intercambio inicial de informacin de control para establecer una conexin de extremo a extremo antes de que los paquetes sean enviados, ni requiere campos adicionales en el encabezado de la PDU para mantener esta

conexin. Este proceso reduce en gran medida la sobrecarga del IP. Sin embargo, la entrega del paquete sin conexin puede hacer que los paquetes lleguen a destino fuera de secuencia. Si los paquetes que no funcionan o estn perdidos crean problemas para la aplicacin que usa los datos, luego los servicios de las capas superiores tendrn que resolver estas cuestiones.

Protocolo IPv4: Mejor intento

Servicio de mejor intento (no confiable)
El protocolo IP no sobrecarga el servicio IP suministrando confiabilidad. Comparado con un protocolo confiable, el encabezado del IP es ms pequeo. Transportar estos encabezados ms pequeos genera una menor sobrecarga. Menor sobrecarga significa menos demora en la entrega. Esta caracterstica es preferible para un protocolo de Capa 3. La funcin de la Capa 3 es transportar los paquetes entre los hosts tratando de colocar la menor carga posible en la red. La Capa 3 no se ocupa de ni advierte el tipo de comunicacin contenida dentro de un paquete. Esta responsabilidad es la funcin de las capas superiores a medida que se requieren. Las capas superiores pueden decidir si la comunicacin entre servicios necesita confiabilidad y si esta comunicacin puede tolerar la sobrecarga que la confiabilidad requiere.

No confiable en este contexto no significa que el IP funciona adecuadamente algunas veces y no funciona bien en otras oportunidades. Tampoco significa que no es adecuado como protocolo de comunicaciones de datos. No confiable significa simplemente que IP no tiene la capacidad de administrar ni recuperar paquetes no entregados o corruptos. Como los protocolos en otras capas pueden administrar la confiabilidad, se le permite a IP funcionar con mucha eficiencia en la capa de Red. Si incluimos la sobrecarga de confiabilidad en el protocolo de la Capa 3, las comunicaciones que no requieren conexiones o confiabilidad se cargaran con el consumo de ancho de banda y la demora producida por esta sobrecarga.