Вы находитесь на странице: 1из 10

Capa de transporte

Este documento se realiz para el curso de Redes de Computadores, del departamento de Informtica, que se dicta en la Universidad Tcnica Federico Santa Mara. En l se encuentran algunos conceptos bsicos que el estudiante debe saber para poder aprobar el ramo, por lo que sirve de ayuda complementaria al momento de estudio. Este documento es entregado sin ninguna garanta, por lo que puede tener errores tanto ortogrficos como de materia, entre otros. Este documento es adems de libre uso, por lo que se puede hacer lo que se quiera con l (fotocopiar, distribuir, leer, modificar, etc.) sin necesidad de obtener ningn permiso ni reconocer o citar al creador del mismo. La nica excepcin de lo anterior es que en ningn caso se acepta que se use este documento, ni obras nacidas a partir de l, para fines comerciales o lucrativos.

Versiones v 1.0 primera versin

~1~

La capa de transporte es la que se preocupa de la comunicacin lgica que hay entre los distintos procesos que puede tener un host (lo que lo diferencia de la capa de red que es la que se ocupa de la comunicacin lgica entre host), y responde adems a la forma en que los mismos procesos pueden entenderse unos con otros aun estando en mquinas distintas. Mux y demux Ya que un host puede estar ejecutando varios procesos que estn comunicndose con la red en un mismo instante es necesario que los mensajes que enven sepan a que proceso tiene que dirigirse. Es por eso que se usan las ideas de multiplexar y demultiplexar. Cuando un host recibe un paquete debe analizar a que proceso est ste dirigido, y lo logra descubriendo el nmero de puerto que el segmento tiene. Recordamos de la capa de aplicacin que los puertos se asocian a un socket en especfico, y un socket siempre se asocia a un proceso nico, lo que hace que cada puerto est asociado a slo un proceso en un instante de tiempo. Por lo que finalmente para demultiplexar una cantidad de paquetes que llegan por una misma interfaz en un host simplemente se analiza el nmero de puerto al cual ste est dirigido. De forma similar para multiplexar un montn de paquetes de un host a varios host diferentes basta con dirigirlos a la IP especfica de tal host (y anlogamente como estar dirigido a un proceso, tambin debe dirigirse a un puerto especial). Todo lo anterior se reduce a que los paquetes tengan una 4-tupla en su informacin, donde los cuatro campos son IP origen/destino y puerto origen/destino. UDP User Datagram Protocol es un tipo de comunicacin donde el host que est creando los mensajes no se preocupa si el receptor est recibindolos. Al no gastar tiempo en tales consideraciones se logra que la comunicacin sea lo ms rpida posible. Los problemas entonces que pueden ocurrir es que los paquetes no lleguen a destino, o incluso que lleguen en distinto orden al cual fueron enviados. Este tipo de comunicacin se usa generalmente cuando interesa mayormente que el mensaje llegue lo ms rpido posible en supremaca a su coherencia lgica, tal como puede ser una consulta corta a un servidor, envo de informacin multimedia o streaming, entre otros. Pese a lo anterior UDP tiene comprobacin si el mensaje es correcto, con el campo checksum. Checksum es un campo de 16 bits (para este caso) en el cual se hace una serie de operaciones aritmticas al paquete que se desea enviar y el resultado se almacena en tal campo, entonces cuando el receptor, al recibir el mensaje, calcula por su cuenta el campo checksum y compara su resultado con el que viene en el paquete. Si stos resultados son distintos entonces ocurri un error en la transmicin, mientras que si son iguales entonces puede haber ocurrido un error. Para calcular este resultado lo que se hace es separar el paquete UDP en segmentos de 16 bits (el mensaje mnimo que se enva en UDP es de 8 bytes. Si falta se rellenan los espacios vacos con ceros) y se suman aritmticamente en binario con complemento uno. Esto significa que si al hacer la suma hay ms de 16 bits entonces se toma del bit 17 en adelante (contando de derecha a izquierda) y se le suma a los primeros 16, y as hasta obtener un nmero de mximo 16 bits. Finalmente se invierten los unos por ceros y los ceros por uno. Al iniciar el computo del checksum se tiene su campo respectivo sin el valor final, por lo que influye en el mismo clculo al deber considerarse el paquete por completo, razn por la cual para calcular el campo checksum se considera que los bits de tal espacio son ceros.

~2~

Ejemplo El siguiente es un paquete UDP expresado en nmeros hexadecimales. A18A B73D 7E6A 723E E58D D1 Corroborar checksum sabiendo que ste se inicia en el bit .49. NOTA: no es un paquete UDP real ya que tiene menos de 8 bytes, pero es ms simple para el ejemplo. Solucin: Cada dgito hexadecimal equivale a 4 bits, por lo que se separa en segmentos de 4 dgitos hexadecimales para equivaler a 16 dgitos binarios. Como la suma es independiente de la base en la cual se est trabajando se suma aritmticamente todos los segmentos y nos dar un resultado en base hexadecimal. Adems nos dice que el checksum comienza en el bit 49, lo que en hexadecimal equivale al dgito 13 en adelante. Tambin se sabe que el checksum son 16 bits, por lo que seran los 4 dgitos despus del dgito 13 los que se deben reemplazar por cero para hacer el clculo, y los que hay que corroborar. Finalmente se tiene tambin que el ltimo segmento no completa los 16 bits, por lo que se rellenan con ceros hasta completar. Se tiene entonces. A18A B73D 7E6A 0000 E58D D100 38DBE

38DBE [hexadecimal] = 111000110110111110 [binario] Como tiene ms de 16 bits se hace un corrimiento. + 1000110110111110 11 1000110111000001

Finalmente al invertir los bits resulta 0111001000111110 [binario] = 723E [hexadecimal]. Da que el checksum calculado es igual al que llego con el paquete, lo que no necesariamente indica que el paquete no contiene errores. RDT Reliable Dara Transfer es una forma de lograr que a travs de un medio de comunicacin no confiable se transfieran mensajes de manera segura. Para lograrlo se hacen dos consideraciones importantes, la primera es que la transferencia es unidireccional y la comunicacin es bidireccional (es decir que hay un emisor y un receptor siempre, y tanto el emisor como el receptor pueden usar el medio). Y la segunda es que los hosts involucrados en la transferencia pasan por diversos estados que condicionan sus acciones. Entonces ahora los sistemas de transporte si estn usando un sistema RDT le son interceptados los mensajes que envan y se le aaden leves modificaciones a lo que antes era simplemente despachar por el medio. Para que el sistema completo se entienda lo mejor es ir haciendo supuestos y complicando poco a poco las condiciones. ~3~

Para entender los distintos RDT a continuacin se harn las siguientes definiciones. Lo que est en una caja ser un estado en que puede estar el sistema. Las flechas son las posibles transiciones entre estados. Las flechas tienen una condicin (lo que est sobre la linea) y una accin (bajo la linea). Si la condicin no se cumple no se hace la accin y se busca otra condicin posible. En caso de no cumplirse ninguna condicin entonces se mantiene en el estado. El estado inicial es aquel al que le llega una flecha sin condicin ni accin. RDT 1.0 En este caso se asume que el medio no tiene perdida de paquetes ni errores en la transmisin.

Caso emisor Caso receptor Este es el caso ms simple, ya que para el emisor si le llega un mensaje entonces empaqueta la informacin y enva tal paquete, y en el caso del receptor si le llega un paquete le extrae la informacin e informa el mensaje. RDT 2.0 Ahora se considera que pueden haber errores en la transmisin y que los mensajes pueden llegar corruptos, por lo que el receptor debe revisar el mensaje y responder si lo recibi correctamente o no.

caso emisor

caso receptor

El emisor adems de empaquetar la informacin que le llega crea un checksum con el paquete, con lo que al receptor al recibirlo comprueba con el checksum si ste llego bien o est corrupto, con lo que si llega mal el receptor responde con un NAK, mientras que si est bien entonces responde con un ACK (adems de desempaquetar la informacin y usarla). El emisor por su lado una vez que enva el paquete se queda esperando la respuesta del receptor, si es NAK retransmite el mensaje mientras que si es ACK no hace nada y vuelve a su estado original.

~4~

RDT 2.1 El problema de RDT 2.0 es que no considera que los ACKs y NAKs pueden venir corruptos, por lo que se hacen dos modificaciones, la primera es que ahora los ACKs y NAKs vienen con checksum, y la segunda es que los mensajes irn con un nmero asociado, donde primero se enva el paquete con el nmero cero, el siguiente mensaje se enviar con uno, el siguiente con cero y as sucesivamente. sto ya que en el caso que el emisor reciba un ACK corrupto reenviar el mensaje anterior, pero el receptor recibi correctamente el mensaje y pensara que el paquete que recibir ser la continuacin del anterior, siendo que realmente es el mismo, por eso con el sistema de la numeracin evita que suceda ese tipo de problemas.

Caso emisor

Caso receptor ~5~

RDT 2.2 Parecido a RDT 2.1, donde ahora no se usa NAK ya que basta con enviar un paquete corrupto o un ACK con la numeracin equivocada para que el emisor se entere que el paquete no fue recibido correctamente. RDT 3.0 En este sistema se considera adems que los paquetes pueden perderse en la red, por lo que se agrega un contador de tiempo. Entonces en lo que lo diferencia de RDT 2.2 es que ahora el emisor al momento de enviar un paquete inicia un timer y pasa al estado de espera de ACK. Si en ese estado pasa el tiempo definido entonces retransmite el paquete. Esto puede ocasionar que el receptor reciba dos paquetes idnticos, lo que no es problema por el sistema de numeracin antes implementado. De igual forma el emisor puede recibir dos ACKs, lo que tampoco ocasiona inconvenientes por la misma razn anterior. Al sistema RDT 3.0 se le denomina Stop-and-Wait, bsicamente porque por cada mensaje se espera un tiempo antes de enviar el siguiente. El problema que surge con esta implementacin es que la comunicacin puede volverse muy lenta si el RTT (tiempo que tarda en ir y volver un pequeo paquete del emisor al receptor) es muy alto, ya que el tiempo que el emisor tiene que esperar antes de reenviar su paquete debe ser mayor que el RTT. Ventana deslizante Tambin llamado pipelining o segmentacin es una mejora a Stop-and-Wait. La idea del mtodo anterior se mantiene, la diferencia radica en que ahora se envan ms paquetes y se tiene menos tiempo ocioso el sistema. Esto se logra aumentando la numeracin de los paquetes. Antes al tener slo la opcin de numerar con cero u con uno se poda enviar slo un paquete por vez sino el sistema poda cometer errores. Al aumentar la numeracin entonces se pueden enviar ms paquetes por vez sin que el sistema falle. Supongamos entonces que tenemos una numeracin modulo 4, lo que quiere decir que podemos numerar con cero, uno, dos y tres. Entonces puedo enviar un mximo de 3 paquetes por vez.

Entonces a medida que el receptor reciba los paquetes ir mandando ACK. El emisor no avanzar la ventana hasta que reciba el ACK del primer paquete enviado. Para los paquetes que siguen al primero de la ventana se tienen bsicamente dos implementaciones para saber que hacer con ellos. Go Back N: Se envan N paquetes, si pasa el tiempo predefinido se recomienza a enviar desde el ltimo paquete no confirmado. El receptor slo enva ACK si logr enviar ACK del paquete anterior. Selective Repear: Similar al anterior slo que el receptor enva ACK del paquete que le llega y el emisor, pasado el tiempo, reenva slo los paquetes que no recibi ACK. ~6~

Para hacer que el sistema funciones se deben tener ciertos cuidados y considerar todos los casos posibles. El Tamao de la Ventana del Transmisor (TVT) y el Tamao de la Ventana del Receptor (TVR) pueden ser de diferente tamao. En general, para que no hayan problemas de reemplazo de paquetes. es bueno considerar que TVT TVR TVT + TVR MAX_SEQ Ejemplo1: (certamen 1, 2010 II, UTFSM Valparaso) Se tiene el protocolo de ventanas deslizantes de mdulo 8 con TVT = 3 y TVR = 1. En un momento dado la ventana del receptor espera recibir un paquete con numeracin 2. Indique todos los casos en que puede estar la ventana del transmisor. Solucin: Para lograr saber los casos se debe ir probando las opciones posibles. Lo mejor es comenzar con el caso ideal. El primer caso es cuando la ventana del transmisor comienza en dos, entonces en esta situacin se estn enviando los mensajes y el receptor no ha devuelto ningn ACK.

El segundo caso posible es cuando la ventana del transmisor comienza en uno. En este caso el receptor ha devuelto el ACK del uno pero ste no ha llegado o simplemente se perdi. Los siguientes dos casos simplemente se mostrarn ya simplemente son variantes de lo mismo.

Ejemplo2: Dado un protocolo de ventanas deslizantes de mdulo 5, indicar si las siguientes combinaciones de TVT y TVR son vlidas. a) TVT = 1 y TVR = 3. b) TVT = 4 y TVR = 2. Solucin: a) Si es vlido. b) No, ya que en el caso que el transmisor enve 2, 3, 4 y 0; y fallen todos las respuestas de ACK, el receptor quedara con 1 y 2, entonces pasado el timeout se retransmite el 2 y se considerara como otro. ~7~

TCP Transmission Control Protocol es un tipo de comunicacin confiable, es decir, que se preocupa de que los mensajes lleguen a destino. TCP tiene las siguientes caractersticas. Punto a punto: uno enva y uno recibe. Confiable: se asegura que los mensajes lleguen y en el orden que fueron enviados. Control de flujo: no congestiona ni la red ni al receptor. Tanto el receptor como el emisor tienen buffers de entrada y salida. Full duplex: comunicacin bidireccional (transmisor como receptor pueden usar el medio). Orientado a conexin: establece un camino antes de enviar mensajes. Cuando se menciona que tanto el emisor como escucha tienen buffers de entrada y salida quiere decir que cuando un proceso est enviando informacin a la red no es ste el que la despacha directamente por el medio, sino que el proceso va entregando los mensajes que tiene listos para ser despachados y stos se van almacenando en una memoria temporal que administra el sistema TCP, y es entonces esta capa (transporte) la que decide cuando son realmente despachados los mensajes enviados. De forma similar los mensajes que llegan a un proceso pasan primero por un buffer antes de que se entreguen al destino final.

TCP dentro de su estructura de paquete tiene un campo predefinido de 6 bits que indica cual es la operacin que se debe de hacer con el mensaje. Dependiendo si el bit es uno entonces se hace la operacin determinada. A continuacin se detalla cada accin en orden del bit correspondiente. URG: indica que es un mensaje urgente. ACK: indica que el campo de ACK es considerado. PSH: no espera a que se llene el buffer para emitir, sino que enva inmediatamente. RST: indica que termina la conexin sin esperar respuesta. SYN: activa la sincronizacin de los nmeros de secuncia. FIN: indica que se pide un fin de conexin. Entonces si por ejemplo se tiene que ese campo tiene el valor 101001 en binario est indicando que de forma urgente despachen el paquete para terminar la conexin.

~8~

La forma que tiene TCP para coordinar sus mensajes es por los campos SEQ y ACK. Si est el flag SYN activado entonces el campo SEQ contiene un nmero X que ser considerado como el nmero del primer byte de la transmisin. A su vez el receptor responder con los flags SYN y ACK, donde en el campo ACK estar el nmero del siguiente byte que espera el receptor, y el campo SEQ un nmero Y que indicar el nmero del primer byte por parte del receptor. Entonces se tiene por ejemplo que el transmisor enva flag SYN con SEQ = 32, con un mensaje de 8 bytes. El receptor responder flag SYN y ACK con SEQ = 96 y ACK = 40 (32 + 8), con un mensaje de 2 bytes. El prximo mensaje del emisor ser entonces flag ACK con SEQ = 40 y ACK = 98, y as sucesivamente. Notar que una vez establecido los nmeros SYN no se vuelve a marcar ese flag a no ser que se quiera resetear el conteo. Tambin notar que los contadores para cada proceso es independiente. Con lo anterior se puede asegurar entonces que los paquetes sern enviados todos en el orden correcto. Para iniciar y terminar una conexin TCP se hace un Handshake de tres fases. Esto quiere decir que tanto el transmisor como el escucha realizan una formalidad obligatoria establecida para iniciar su comunicacin. Originalmente se tiene que hay un punto (o proceso) abierto de forma pasiva y otro que se abrir de forma activa. Que est abierto en forma pasiva quiere decir que est conectado a la red esperando a que alguien le pida conectarse con l. De forma activa, al contrario, es al momento de conectarse es cuando pide conexin con algn punto en especfico. Para que se establezca la conexin debe necesariamente haber uno de cada uno. Entonces el que esta abierto de forma pasiva espera a que el que se abra de forma activa le enve un paquete con el flag SYN. El pasivo entonces le responde con los flag SYN y ACK. Finalmente el activo le responde con un ACK y entonces la conexin est establecida. Para finalizar la misma, el que quiera terminar la conexin enva el flag FIN activado, con lo que el que lo recibe responde con los flag FIN y ACK, y por ltimo el que quiso terminar primero le responde con un ACK y cierra su conexin. Con este sistema se puede entonces crear un camino entre ambos puntos. Para controlar no llenar de paquetes al receptor sin que ste pueda procesarlos correctamente entonces se tiene el campo Ventana en el paquete TCP donde se indica la cantidad de informacin que puede recibir el receptor. Esta ligado directamente con el espacio libre en el buffer de entrada del receptor. Se une tambin con el tema de Ventanas Deslizantes. Al inicio de la conexin el emisor enva pocos paquetes y aumenta en cantidad dependiendo del nmero de ventana que el receptor le diga en sus paquetes de respuesta. Por lo que si no recibe respuesta (el respectivo ACK) entonces disminuye la cantidad de paquetes que enva. sto puede producirse sea porque el receptor no puede procesar tantos paquetes al mismo tiempo, o porque la red se ha saturado. Tambin est el caso en que el buffer del receptor se ha llenado por completo, entonces enviar en su campo Ventana el valor cero. Si ocurre eso entonces, para no paralizar completamente la conexin, el emisor enva peridicamente un paquete con informacin nula para que el receptor le responda. Si el campo Ventana vuelve a ser cero entonces repite el procedimiento, en caso contrario contina con la comunicacin. De esta forma se controla el flujo y se evita congestionar ni la red ni al escucha.

~9~

Ejemplo1: Mostrar como se establece una conexin TCP con lineas de tiempo. Solucin:

Ejemplo2: Se tiene en un momento dado que en una conexin TCP el receptor tiene 3000 [B] libres en su buffer de escucha y que el emisor no puede enviar mensajes ms grandes que 2000 [B] por vez. Adems el receptor NO esta leyendo sus mensajes. Si el campo SEQ del emisor indica el nmero 14000, indique los campos SIZE y SEQ del transmisor y los campos ACK y VENTANA del receptor. Asuma que el transmisor slo enviar tres mensajes. Solucin: Transmisor SIZE 2000 1000 1 SEQ 14000 16000 17000 ---> <--- 16000 ---> <--- 17000 ---> <--- 17000 0 0 1000 ACK Receptor VENTANA

~ 10 ~

Вам также может понравиться