Elementos de los protocolos de transporte

El servicio de transporte se implementa mediante un protocolo de transporte entre dos entidades de transporte. En ciertos aspectos, los protocolos de transporte se parecen a los protocolos de red. Ambos se encargan del control de errores, la secuenciacin y el control del flujo. Pero tambin existen diferencias importantes entre ambas, como los entornos en que operan, la capa transporte necesita el direccionamiento explcito de los destinos, mientras que la capa de red no, otra diferencia es la cantidad de datos, mucho mayor en la capa de transporte.

Direccionamiento
Cuando un proceso desea establecer una conexin con un computador de aplicacin remoto, debe especificar a cul se conectar (a quin le mensaje?). El mtodo que normalmente se emplea es definir direcciones de transporte en las que los procesos pueden estar a la escucha de solicitudes de conexines. En Internet, estos puntos terminales se denominan puertos, pero usaremos el trmino genrico de TSAP (Punto de Acceso al Servicio de Transporte). Los puntos terminales anlogos de la capa de red se llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones IP son ejemplos de NSAPS.

Establecimiento de una conexin

El establecimiento de una conexin parece fcil, pero en realidad es sorprendentemente difcil. A primera vista, parecera que es suficiente con mandar una TPDU (Unidad de Datos del Protocolo de Transporte) con la peticin de conexin y esperar a que el otro acepte la conexin. El problema viene cuando la red puede perder, almacenar, o duplicar paquetes. El principal problema es la existencia de duplicados retrasados. Esto puede solucionarse de varias maneras (ninguna es muy satisfactoria). Una es utilizar direcciones de transporte desechables. En este enfoque cada vez que necesitemos una direccin la creamos. Al liberarse la conexin descartamos la direccin y no se vuelve a utilizar. O tambin asignar una secuencia dentro de los datos transmitidos, pero estos plantean el problema de que si se pierde la conexin perdemos el orden del identificador y ya no funciona. La solucin seria ms fcil si los paquetes viejos se eliminaran de la subred cada cierto tiempo de vida. Para ello podemos utilizar las siguientes tcnicas: Un diseo de subred Restringido. Colocar un contador de saltos en cada paquete. Marcar el tiempo de cada paquete. Pero en la prctica no vale solo con hacer esto sino que tenemos que garantizar que todas las confirmaciones de los paquetes tambin se eliminan.

Liberacin de una conexin

La liberacin de una conexin es ms fcil que su establecimiento. No obstante, hay ms escollos de los que uno podra imaginar. Hay dos estilos de terminacin de una conexin: liberacin asimtrica y liberacin simtrica. La liberacin asimtrica es la manera en que funciona el mecanismo telefnico: cuando una parte cuelga, se interrumpe la conexin. La liberacin simtrica trata la conexin como dos conexiones

unidireccionales distintas, y requiere que cada una se libere por separado. La liberacin asimtrica es abrupta y puede resultar en la perdida de datos. Por lo que es obvio que se requiere un protocolo de liberacin ms refinado para evitar la perdida de datos. Una posibilidad es usar la liberacin simtrica, en la que cada direccin se libera independientemente de la otra. Aqu, un host puede continuar recibiendo datos aun tras haber enviado una TPDU de desconexin. La liberacin simtrica es ideal cuando un proceso tiene una cantidad fija de datos por enviar y sabe con certidumbre cundo los ha enviado. En otras situaciones, la determinacin de si se ha efectuado o no todo el trabajo y se debe terminarse o no la conexin no es tan obvia. Podramos pensar en un protocolo en el que el host 1 diga:Ya termine, Terminaste tambin?. Si el host 2 responde Ya termine tambin. Adis, la conexin puede liberarse con seguridad. Pero no es tan fiable por el problema de que siempre tendremos que esperar la confirmacin de los mensajes recibidos y si esta confirmacin no llega no libera la conexin y despus puede que necesite la confirmacin de que llego la confirmacin y entraramos en un bucle del que no podemos salir. Podemos hacer que al host 1 si no le llega la confirmacin despus de N intentos (es que quiere la desconexin), se libere. Esto produce una conexin semiabierta en la que el host 1 est desconectado pero el host 2 no como no le llega la confirmacin no se desconecta nunca. Para solucionar esto creamos una regla por la cual si al host 2 no le llega ninguna TPDU durante cierta cantidad de segundos, se libera automticamente.

Control de Flujo y almacenamiento en buffer

Respecto de la manera en que se manejan las conexiones mientras estn en uso, uno de los aspectos clave es el control de flujo. Se necesita un esquema para evitar que un emisor rpido desborde a un receptor lento. La diferencia principal es que un enrutador por lo regular tiene relativamente pocas lneas, y un host puede tener numerosas conexiones. Esta diferencia hace poco prctico emplear la implementacin que se hace en la capa de enlace. En esta capa lo que se hace es que si el servicio de red no es confiable, el emisor debe almacenar en un buffer todas las TPDUs enviadas, igual que en la capa enlace de datos. Sin embargo, con un servicio de red confiable son posibles otros arreglos. En particular, si el emisor sabe que el receptor siempre tiene espacio de buffer, no necesita tener copias de las TPDUs que enva. Sin embargo, si el receptor no garantiza que se aceptar cada TPDU que llegue, el emisor tendr que usar buffers de todas maneras. En el ltimo caso, el emisor no puede confiar en la confirmacin de recepcin de la capa red porque esto slo significa que ha llegado la TPDU, no que ha sido aceptada. Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos cuando ms nos convenga. El equilibrio ptimo entre el almacenamiento del buffer en el origen y en el destino depende del tipo de trfico transportado por la conexin.

Multiplexin

La multiplexin de varias conversaciones en conexiones, circuitos virtuales o enlaces fsicos desempea un papel importante en diferentes capas de la arquitectura de red. En la capa de transporte puede surgir la necesidad de multiplexin por varias razones. Por ejemplo, si en un host slo se dispone de una direccin de red, todas las conexiones de transporte de esa maquina tendrn que utilizarla. Cuando llega una TPDU, se necesita algn mecanismo para saber a cul proceso asignarla. Esta situacin se conoce como multiplexin hacia arriba. La multiplexin tambin puede ser til en la capa transporte para la utilizacin de circuitos virtuales, que dan ms ancho de banda cuando se reasigna a cada circuito una tasa mxima de datos. La solucin es abrir mltiples conexiones de red y distribuir el trfico entre ellas. Esto se denomina multiplexin hacia abajo..

Recuperacin de cadas
Si los hosts y los enrutadores estn sujetos a cadas, la recuperacin es fundamental. Si la entidad de transporte est por entero dentro de los hosts, la recuperacin de cadas de red y de enrutadores es sencilla. Si la capa de red proporciona servicio de datagramas, las entidades de transporte esperan prdida de algunas TPDUs todo el tiempo, y saben cmo manejarla. Si la capa de red proporciona servicio orientado a la conexin, entonces la prdida de un circuito virtual se maneja estableciendo otro nuevo y sondeando la entidad de transporte remota para saber cuales TPDUs ha recibido y cuales no. Un problema ms complicado es la manera de recuperarse de cadas del host. Al reactivarse, sus tablas estn en el estado inicial y no sabe con precisin donde estaba. En un intento por recuperar su estado previo, el servidor podra enviar una TPDU de difusin a todos los dems host, anunciando que se acaba de caer y solicitando a todos sus clientes que le informen el estado de todas la conexiones abiertas.

Protocolos de transporte de internet

Internet tiene dos protocolos principales en la capa de transporte, uno orientado a la conexin y otro no orientado a la conexin. El protocolo no orientado a la conexin es el UDP y el orientado es el TCP.

UDP
Artculo principal: UDP.

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexin UDP (protocolo de datagramas de usuario). Este protocolo proporciona una forma para que las aplicaciones enven datagramas IP encapsulados sin tener una conexin.

TCP
Artculo principal: TCP.

 TCP (protocolo de control de transmisin) se dise especficamente para proporcionar un flujo de bytes confiable de extremo a extremo a travs de una interred no confiable. Una interred difiere de una sola red debido a que diversas partes podran tener diferentes topologas, anchos de banda, retardos, tamaos de paquete TCP tiene un diseo que se adapta de manera dinmica a las propiedades de la interred y que se sobrepone a muchos tipos de situaciones.
La capa de transporte La capa de transporte es la encargada de controlar el flujo de datos entre los nodos que establecen una comunicacin; los datos no solo deben entregarse sin errores, sino adems en la secuencia que proceda. La capa de transporte se ocupa tambin de evaluar el tamao de los paquetes con el fin de que estos Tengan el tamao requerido por las capas inferiores del conjunto de protocolos. El tamao de los paquetes 10 dicta la arquitectura de red que se utilice. PROTOCOLOS QUE TRABAJAN CON EL MODELO OSI Protocolos: TCP: Los protocolos orientados a la conexin operan de forma parecida a una llamada telefnica: UDP: El funcionamiento de los protocolos sin conexin se parece ms bien a un sistema de correo regular.

CAPA DE TRANSPORTE
La capa de transporte garantiza que los mensajes se entregan sin errores, en secuencia y sin prdidas ni las duplicaciones. Libera a los protocolos de nivel superior de cualquier problema con la transferencia de datos entre ellos y sus colegas. El tamao y la complejidad de un protocolo de transporte depende del tipo de servicio puede obtener de la capa de red. Para btener una capa de red confiable con capacidad de circuito virtual, se requiere una capa de transporte mnima. Si la capa de red no es confiable o slo admite datagramas, debe incluir el protocolo de transporte, recuperacin y deteccin de errores extensa. Proporciona la capa de transporte:

Segmentacin del mensaje: acepta un mensaje de la capa (sesin) por encima de l, el mensaje se divide en unidades ms pequeas (si no ya pequeo) y las pasa las unidades ms pequeas hacia abajo hasta la capa de red. La capa de transporte en la estacin de destino permite volver a montar el mensaje. Mensaje de confirmacin: proporciona la entrega de mensajes confiable de extremo a extremo con las confirmaciones. Control de trfico de mensajes: indica a la estacin transmisora que "d marcha atrs" cuando no hay bferes de mensajes disponibles. Multiplexin de sesin: Multiplexa varias secuencias de mensajes, o las sesiones en un vnculo lgico y realiza un seguimiento de los mensajes que pertenecen a las sesiones (consulte la capa de sesin).

Normalmente, la capa de transporte puede aceptar mensajes relativamente grandes, pero hay capa de mensaje strict tamao lmite impuesto por la red (o menos). En consecuencia, la capa de transporte debe dividir los mensajes en unidades ms pequeas, o tramas, anteponindole un encabezado a cada trama. La informacin de encabezado de la capa de transporte, a continuacin, debe incluir la informacin de control, como el inicio de mensaje y marcas de final del mensaje, para habilitar la capa de transporte en el otro extremo a reconocer los lmites de mensajes. Adems, si las capas inferiores no mantienen la secuencia, el encabezado de transporte debe contener informacin de secuencia para permitir que la capa de transporte en el extremo receptor para obtener las piezas volver juntos en el orden correcto antes de entregar el mensaje recibido hasta la capa superior.