3. Capa de Transporte 3.1 Capa de transporte y sus servicios La capa de transporte brinda comunicación lógica entre procesos de de aplicación que se ejecutan en host diferentes. 3.1.1. Relaciones entre la capa de transporte y la capa de red Capa de transporte -> Comunicación lógica entre procesos de de hosts Capa de red -> Comunicación Comunicación lógica entre hosts Se da la similitud entre Capa Capa de red = servicio postal, capa de transporte = persona persona en la casa que realiza la tarea de repartir cada carta o correo a quien corresponda, el papá, la mamá, etc. En este caso los hosts serían las viviendas y los procesos las personas en especifico. 3.1.2. Capa de transporte en Internet 2 protocolos en la capa de transporte: -
UDP, Protocolo de datagramas de usuario, servicio sin conexión no fiable. TCP, Protocolo de control de transmisión, orientado a conexión fiable.
Segmentos, paquetes de la capa de transporte. Capa de red: Protocolo IP, es best effort, envía los segmentos pero no garantiza la entrega ni la integridad de los datos. El término multiplexación y demultiplexación de demultiplexación de la capa de transporte se refiere a extender la entrega host a host a una entrega proceso a proceso. UDP, solo ofrece 2 servicios: Entrega de datos proceso-proceso y comprobación de errores. TCP, ofrece múltiples servicios, transferencia de datos fiables mediante técnicas de control de flujo, números de secuencia, mensajes de reconocimiento y temporizadores, además de mecanismos de control de congestión. 3.2. Multiplexación y Demultiplezación Demultiplexación: Entregar los datos contenidos en un segmento de la capa de transporte al socket correcto (cada socket tiene un identificador para cada proceso). Multiplexación: Reunir los fragmentos de datos en el host de origen desde los diferentes sockets, encapsulando cada fragmento con la información de cabecera y asi crear los segmentos y pasarlos a la capa de red. Para esta operación se requiere que: -
Sockets con identificadores únicos
-
Campos especiales en el segmento que indiquen el socket al que tienen que entregarse el segmento. Estos campos especiales son: campo número de puerto de origen y el campo número de puerto de destino.
Los números de puertos son de 16 bits en el rango de 0 a 65535, del 0 al 1023 se conocen como puertos bien conocidos y son restringidos. Proceso general de demultiplexación: cada socket del host se puede asignar a un número de puerto y, al llegar un segmento al host, la capa de transporte examina el número de puerto de destino contenido en el segmento y lo envía al socket correspondiente, luego los datos del segmento pasan a través del socket y se entregan al proceso asociado.
Multiplexación y demultiplexación sin conexión La capa de transporte crea un segmento con el puerto de origen y el puerto de destino, entonces en cada host ocurre la multiplexación y demultiplexación según el socket con el puerto UDP asignado de destino o origen. ¿Por qué es necesario que se ponga el puerto de origen? Para que si el host receptor desee devolver el segmento sepa a donde enviarlo. Multiplexación y demultiplexación orientadas a conexión A diferencia del socket UDP, el socket TCP se identifica por una tupla de 4 elementos: IP de origen, puerto de origen, IP de destino, puerto de destino. El cliente TCP genera una segmento de establecimiento de conexión, este es enviado al servidor, el cual recibe el segmento e identifica el puerto de destino y asigna un socket al proceso, además también identifica los 4 elementos que contiene, y los relaciona a este socke8t de conexión, es entonces cuando ya se podrá enviar datos entre estos. Cada socket tiene asignado una única tupla de los 4 elementos. Servidores web y TCP El texto hace énfasis en la manera en que se establecen las conexiones cliente servidor, hace referencia al termino HTTP persistente y no persistente, persistente es cuando se establece la conexión de cliente servidor y se pueden transmitir todos los objetos o mensajes a través del mismo socket, pero cuando es no persistente, para cada petición/respuesta (osea para cada mensaje o objeto) se crea un nuevo socket, y esto último genera poca eficiencia. 3.3. Transporte sin conexión: UDP Se dice que es un protocolo sin conexión porque no establece conexión entre emisor y receptor antes de enviar el segmento a la capa de red. El proceso de UDP es simple, nunca toca IP, el que se encarga de comunicarse con IP es la capa de aplicación, UDP recpciona estos datos obtenidos por la capa de aplicación y coloca puerto de origen y destino para hacer el servicio de multiplexación/demultiplexación, añade 2 pequeños
campos más y envía el segmento resultante a la capa de red, la capa de red lo encapsula en un datagrama IP y hace el mayor esfuerzo por entregar el ssegmento al host receptor. Y luego de que llega, si es que llega, se encarga de enviar al proceso según el puerto de destino. Nunca hubo un proceso preliminar de establecimiento de la conexión. ¿Por qué preferir UDP en vez de TCP? Si todo parece indicar que UDP no parece ser para nada efectivo, las ventajas de usar UDP son: -
-
-
Sin establecimiento de la conexión: TCP realiza un proceso de 3 fases de establecimiento de la conexión, UDP no hace nada de esto, y esto sirve para que no hayan retardos en la transmisión, esto ayuda a tener respuestas rápidas como en el caso de los DNS, para paginas web(HTTP) si es importante TCP. Mejor control en el nivel de aplicación sobre que datos se envían y cuando: Esto quiere decir que UDP solo envía los datos y allí queda, y en TCP la capa de aplicación envía los datos y hay un proceso interno donde se pueden reenviar muchas veces el dato hasta que llegue, o talvez hay congestión y TCP tmbn realiza un proceso que genera colas, entonces para la capa de aplicación es un poco más complicado saber exactamente cuando fue que se logró envíar el mensaje, en cambio la aplicación en UDP solo envía y registra en ese momento la hora en que envió y qúe fue lo que se envió. Poca sobrecarga: la cabecera de TCP contiene 20bytes, la de UDP 8 bytes.
Telnet,SMTP, HTTP, FTP, son TCP SNMP, RIP, DNS, NFS, son normalmente UDP. TCP empieza cada vez más a desplazar a UDP, si bien es cierto que muchas aplicaciones multimedia, de videoconferencias, telefónica, etc, utilizan UDP por su velocidad, ya se están viendo cosas que algunas que usan TCP. Es posible que se puede transmitir datos de manera fiable usando UDP, y esto se consigue incorporando características de fiabilidad a la aplicación en si, es algo complicado pero da ENORMES ventajas, ya que no tendría las restricciones de velocidad de transmisión impuestas por TCP. 3.3.1 Estructuras de segmentos UDP Esta es la estructura:
La cabecera UDP solo tiene 4 campos y cada uno con 2 bytes, como ya se mencionó :el host de destino utiliza el puerto para asociarlo al proceso adecuado. El campo longitud especifica la longitud del segmento en bytes incluyendo la cabecera. 3.3.2. Suma de comprobación de UDP Sirve para detectar si el segmento UDP ha sido alterado durante la transmisión. En el lado emisor, UDP calcula el complemento a 1 de todas las palabras de 16 bits del segmento acarreando cualquier desbordamiento obtenido durante la operación de suma, sobre el bit de menor peso. Es mejor que lo entiendan (los que leen esto) con el ejemplo del libro:
Como se produjo desbordamiento el 1 pasó al bit de menor peso (osea el de la derecha), luego se saca complemento a 1 de este resultado y se obtiene la suma de comprobación, luego el receptor suma este valor con las otras 3 palabras y tiene que salir 11111111111111, si no, es que hay error. ¿Porqúe presenta detección de errores si ya hay en la capa de enlace uno? Es porque no es seguro que todos los encales presenten control de errores, además el error se puede producir luego que la capa de enlace termine su trabajo, osea se puede producir errores de bit cuando el segmento se almacena en la memoria del router. El principio terminal terminal, hace referencia a cuan importante es la comprobación de errores en una capa como la de transporte( terminal - terminal) ya que es una capa superior a las demás que ya presentan un proceso de comprobación, esto hace parecer que los procesos de comprobación de las capas inferiores sean redundantes o poco útiles. UDP al detectar error, simplemente descarta el segmento o lo envía a la aplicación junto con una advertencia. AQUÍ TERMINA UDP. 3.4 Principios de un servicio de transferencia de datos fiables Uno de los principales problemas es que si bien se puede tener una transferecnai de datos fiables en la capa de transporte (TCP), en las capas inferiores tal vez no presenten este servicio, como en de red terminal – terminal no fiable (IP).
Durante lo que sigue del capitulo solo se explicara todo desde la perspectiva unidireccional, porque la bidireccional es mas complicada de entender. 3.4.1. Construcción de un protocolo de transferencia de datos fiable A continuación se irán mostrando los protocolos, hasta llegar a uno que no tiene defectos. Transferencia de datos fiable sobre un canal totalmente fiable: rdt 1.0 (reialable data transfer)
Se muestran maquinas de estados finitos (FSM), en este caso solo tienen 1 estado, el suceso que provoca la transición se pondrá encima de la línea horizontal y los sucesos que provoca, debajo de la línea horizontal. Para este caso el receptor no necesitará de realimentación ya que dispone de un canal totalmente fiable, y además la velocidad con la que el receptor recibe el mensaje es igual a la que el emisor envía asi que tampoco habrá problemas con eso. Es un caso ideal en realidad, más que todo el autor lo usa para dar detalles de como funcionarán los procesos de las maquinas de estados que mostrará. Transferencia de datos fiables sobre un canal con errores de bit rdt 2.0 Este es un caso más real en donde el canal presenta errores y corrompe el paquete de datos, en este caso se relizan los procesos como cuando una persona esta hablando por teléfono con otra y cuando entiende algo dice: ok si, ok esta bien, pero cuando no entiende dice: que? Puedes repetir?, lo mismo ocurre aquí, cuando no se envía correctamente un paquete este envía automáticamente un ARQ, mediante protocolos ARQ (automatic repeat reQuest) en estos protocolos se necesitan 3 capcacidades de de protocolos adicionales para gestionar la detección de errores de bit: -
-
Detección de errores: Se necesita saber que hubo error, esto si tiene UDP, para esto se hace que el emisor envie unos datos adicionales al paquete que envía para el cáculo de suma de comprobación de paquete de datos rdt 2.0 Realimentación del receptor: para que el emisor sepa que su paquete se envio con errores necesita que el receptor le diga algo, para esto son el ACK y NAK (ACUSE DE
-
RECIBO POSITVO Y NEGATIVO), estos paquetes solo necesitan 1 bit, osea 0 para NAK y 1 PARA ACK. Retransmisión: su nombre lo dice, cuando el paquete tiene error, el receptor debe retransmitir.
Este es el diagrama de maquinas de estados finitos del protocolo rdt2.0, no es necesario que lo analicen, con los que les diré basta :v
Bueno resulta que el emisor recibe los datos de la capa superior y los empaqueta junto con la suma de comprobación y los envía, es entonces cuando pasa a otro estado, en donde solo se pone a esperar el ACK o NAK, si recibe el ACK recién pasa a su estado anterior donde puede recibir datos, por el contrario solo estará esperando a que el receptor envie NAK o ACK, esto se le llama protocolo de parada y espera (stop and wait protocol), obviamente si recibe un NAK tendrá que retransmitir el último paquete recibido. Por parte del receptor si recibe bien el paquete manda un ACK al emisor y extrae el paquete entrga los datos, si recibe mal envía un NAK. Posteriormente se plantean protocolos 2.1, donde se incluye un numero de secuencia en los paquetes a enviar del emisor, que sirven para saber si un paquete es uno retransmitido o es un paquete nuevo, por ejemplo se envía un paquete con numero de secuencia 0, y recibe un NAK vuelve a mandar con 0, entonces el receptor sabrá que es una retransmisión, ya que si detecta 1, es porque es un paquete nuevo, además las rspuestas ACK y NAK tendrán su propia suma de comprobación para saber si los ACK o NAK no son adulterados o incorrectos. Y el 2.2 consiste en que ahora los ACK/NAK incorporan el numero de secuencia en su nomencaltura, osea en vian ACK 1 o ACK0.
Transferencia de datos fiable sobre un canal con pérdidas y errores de bit: rdt3.0 Ahora se considera que el paquete puede perderse, ya no solo corromperse. Para esto se crean un temporizador con un promedio razonable de tiempo en que el paquete puede perderse, el emisor inicia su temporizador al enviar el paquete, si no recibe el ACK/NSK, en el tiempo indicado, vuelve a mandar el paquete, en este caso hay la posibilidad de que haya duplicado de paquetes enviados (en caso no se haya perdido el paquete sino solo se haya demorado un poco más), pero con las respuestas ACK 0 o ACK1 (0 y 1 los números de secuencias mencionados anteriomente), se puede determinar el duplicado y el sistema continuará funcionando normalmente. Este es el mejor diagrama para entenderlo: (si es que quieren)
A este tipo de protocolos se les llama de bit alternante, (por sus numros de secuncia 0 y 1).
3.4.2. Protocolo de transferencia de datos fiable con procesamiento en cadena (GBN) El protocolo rdt3.0 es muy bueno, pero lo malo es que es un protocolo de parada y espera, y esto afecta el rendimiento, para laas redes de alta velocidad actuales. Todo se resume en esta imagen:
En vez de estar esperando a que el paquete se envie y llegue la respuesta del ACK, se puede enviar paquetes simultáneamente. Esto implica algunas cosas adicionales como que se necesitará un rango mayor de números de secuencia, y que los buffer del emisor y receptor van a almacenar mas de un paquete. Estas implicancias dependerán de como responde el protocolo a las perdidas o r etrasos excesivos de paquetes, para ayudar en la recuperación de errores en los procesamiento en cadena se utilizan: Retroceder N y la repetición selectiva. 3.4.3 Retroceder N Este protocolo puede transmitir varios paquetes sin necesidad de ser reconocidos, pero tiene un límite, N, al cual se le llama ventana, este grafico resume todo:
Se asigna como base al numero de paquete mas antiguo no reconocido y signumsec como el numero de secuencia mas pequeño no enviado. A partir de aquí se definen 4 rangos de números de secuencia (los mostrados en “Clave” del gráfico).
A este protocolo se le llama de ventana deslizante, porque cada que los paquetes vayan reconociéndose y enviando otros la ventana se desplaza hacia adelante. El emisor responde a 3 sucesos:
-
Invocación desde la capa superior, este recibe el paquete y corrobora que la ventana no este llena. Recepción de un mensaje de reconocimiento ACK. También presenta temporizador para reenviar todos los paquetes enviados pero no reconocidos.
Con reconocidos se refiere a los respondidos con un ACK por parte del receptor. Una característica importante en este protocolo es que no recibe paquetes en desorden, los descarta, por ejemplo si se pierde el paquete con nro de secuencia 2, no va a recibir el 3 4 y 5 hasta que el emisor no vuelva a enviar y que el receptor reciba satisfactoriamente este paquete. 3.4.4. Repetición Selectiva (SR) El protocolo GBN, como se puede notar tiene un gran punto en contra y es que por el hecho de no aceptar paquetes en desorden genera muchas retransmisiones, ocasionando muchas transmisiones innecesarias. Este protocolo SR, subsana esto, cada vez que el receptor detecte que se perdió un paquete y esta recibiendo en desorden, los guarda en un buffer, y manda un aviso al emisor de cual es el paquete que se perdió, entonces el emisor solo manda el paquete perdido y cuando el receptor lo recibe bien, recién procesa los otros paquetes.
3.5. TCP
3.5.1. La conexión TCP
Tcp esta orientado a conexión ya que antes de que un proceso en un host trasmita datos hacia otro proceso en otro host se debe establecer comunicación entre ambos procesos. La comunicación en TCP es full dúplex, es decir ambos procesors pueden trasmitir datos hacia el otro en el mismo instante Un conexión TCP, es un enlace punto a punto dado que casi siempre permite una comunicación entre 1 proceso emisor y un proceso receptor Al establececimiento de una conexión TCP se le conoce como ACUERDO DE 3 FASES ya que el cliente (el que inicia la comunicación) envía un segmento especial,el recepto le responde con otro segmento y por ultimo el cliente le responde con con un 3er segmento que por lo general este ultimo segmento contiene la información de la capa de aplicación. Una vez establecida la conexión ya se puede comenzar a trasmitir datos, los datos primero pasan por un socket luego llegan a la capa de transporte (al protocolo tcp) ,tcp dirige los datos hacia un buffer de emisión para posteriormente tomar cuando sea conveniente fragmentos de datos para poder trasmitirlos MSS ( Tamaño máximo de segmento) nos indica la mayor cantidad de datos de la capa de aplicación que se pueden encapsular en un segmento.Utliza para definir ese valor el MTU(unidad máxima de trasnmision)
3.5.2 Estructura del segmento TCP Cabecera tcp : 20 bytes Cabecera udp : 8 bytes Longitud del segmento TELNET: 21 BYTES
NUMERO DE PUERTO DE ORIGEN Y DESTINO : Sirven para multiplexar y demultiplexar los segmentos NUMERO DE SECUENCIA Y RECONOCIMIENTO : son utilizados para brindar un servicio de trasferencia de datos fiable LONGITUD DE CABECERA: Nos indica la longitude cabezera del segmento (típica 20 bytes) CAMPO OPCIONES: OPCIONAL y de longitur variable CAMPO INDICADOR : 6 bits RST-SYN-FIN: establecimiento y cierre de conexione PSH:el receptor debe pasar los datos a la capa superior ACK: transmisión exitosa URG: nos indica que este segmento contiene datos URGENTES NUMERO DE SECUENCIA: nos indica la posición del primer byte de datos de un segmento dentro un flujo de bytes
NUMERO DE RECONOCIMIENTO:
Todos los segmentos que llegan procedentes del host B tienen un número de secuencia para los datos que fluyen de B a A. El número de reconocimiento que el host A incluye en su segmento es el número de secuencia del siguiente byte que el host A está esperando del host B.
Suponga que el host A ha recibido todos los bytes numerados de 0 a 535 procedentes de B y suponga también que está enviando un segmento al host B. El host A está esperando al 536 y todos los bytes que le siguen del flujo de datos del host B. Por tanto, el host A incluye 536 en el campo número de reconocimiento del segmento que envía a B.
PROTOCOLO TELNET Se ejecuta sobre tcp y permite el inicio de sesión remotos. cada vez que un cliente teclee un carácter este viaja al receptor y luego regresa al cliente para su visualización
3.5.3 Estimación del tiempo de ida y vuelta y fin de temporización Tcp utiliza un temporizador para recuperarse de la perdida de segmentos ,pero no se sabe cuánto tiene que ser ese tiempo necesario para afirmar que un segmento se ha perdido o dañado. ESTIMACION DEL TIEMPO DE IDA Y VUELTA (RTT)
PARA poder ponderar los rtt de cada conexión tcp en el tiempo se utiliza LA EWMA ( MEDIA MOVIL EXPONCENCIALMENTE PONDERADA) con eso recolectamos un RTTestimado Definicion y gestión del intervalo de fin de temporizacio para la restrasmision El intervalo que debe usarse para el fin de temporización TCP tiene que ser mayor que el rttestimado sino se producen retrasmisiones innecesarias pero tampoco muy mayor q el
rttestimado puesto que se tendría que esperar mucho para la restrasmision de un segmento perdido o corrompido .
3.5.4 TRANSFERENCIA DE DATOS FIABLE Tcp crea un servicio de trasnferencia de datos fiable sobre el servicio de mejro esfuerzo de ip,logrando que los segmentos que lleguen a los buffers de recepción TCP no se hayan perdido ,corrompido y que lleguen en orden. El protocolo TCP solo utiliza un temporizador para todo el flujo de datos trasnmitido y ya no para cada segmento ya que esto genera un sobrecarga a la red Sucesos en la emisión de un segmento : -Los datos son recibidos de la capa de aplicación ,se encapsula en ip y se llevan a la red - si sucede el fin de temporizacion,tcp retrasmite el segmento que ha causado dicho fin de la temporizacion -la llegada de un semneto de reconocimiento ACK,TCP usa una RECOCIMIENTOS ACUMULATIVOS: EJEMPLO SI EL ACK= 98 SIGNIFICA QUE HA RECIBIDO CORRECTAMENTE DESDE EL NUMERO INICIO DE SECUENCIA HASTA EL 98AVO BIT RECONOCIMIENTO ACUMULATIVO:
SIGNIFICA QUE SI ENVIAMOS 2 SEGMENTOS Y EL SEGMENTO DE RECOCIMIENTO DEL PRIMER SEGMENTO ENVIADO SE PIERDE PERO EL DEL 2DO SI LLEGA ESTO SIGNIFICA QUE TANTO EL PRIMER 1ER Y 2 SEGMENTO LLEGARON AL RECEPTOR Y YA NO ES NECESARIO RETRANSMITIR PERO EL SEGMENTO DE RECONOCIMIENTO DEL 2 SEGMENTO TIENE QUE LLEGAR ANTES DE QUE FINALIZE EL TEMPORIZADOR DEL 1ER SEGMENTO DE LO CONTRARIO RETRASMITIRA AMBOS SEGMENTOS
DUPLICACION DE INTERVALOS DE FIN DE TEMPORIZACION
CUANDO UN TEMPORIZADOR FINALIZA EL PROTOCOLO TCP ASIGNA UN NUEVO INTERVALO DE TEMPORIZACION MAYOR AL ANTERIOR ,CADA EMISOR RETRASMITE DESPUES DE INTERVALOS MAS GRANDES CADA VEZ RETRASMISION RAPIDA : AQUÍ SE RETRASMITEN LOS SEGMENTOS ANTES DE QUE FINALIZE EL TEMPORIZADOR DEL SEGMENTO ,SI LLEGA AL EMISOR 3 ACK DUPLICADOS REALIZA UNA RETRASMISION RAPIDA TCP ES UN HIBRIDO ENTRE GBN Y SR (RECONOCIMIENTO SELECTIVO)
3.5.5 CONTROL DE FLUJO TCP brinda un servicio de control de flujo a los procesos de las aplicaciones para que no desborden el buffer del receptor ,adapta la velocidad a la q el emiso esta trasmitiendo a la velocidad con la que la aplicación esta leyendo los datos )
Para ello utiliza una ventana de recépcion que le indica cuanto espacio disponible hay en el buffer de recepción Udp no implmenta ningún servicio de control de flujo
3.5.6 Gestion de la conexión ACUERDO DE 3 FASES : 1er paso CLIENTE TCP envía un segmento especial al SERVIDOR TCP ,este segmento especial no tiene datos pero tiene un bit SYN PUESTO A 1 2 DO PASO : Cuando llega el segmento SYN al receptor este asigna los buffer y las variables tcp y envía un segmento de respuesta indicando que se ha establecido la conexión (SEGMENTO SYNACK) 3ER PASO : el emisor al recibir el segmento SYNACK asigna también buffer y variables a la conexión,el emiso envía otro segmento confirmando la conexión En los segmentos enviados después el bit SYN esta puesto a 0 Completados los 3 pasos ya se puede comenzar a trasmitir los segmentos que contienen los datos Cuando se quiere abadonar una conexio el emisor manda un segmento especial con un bit FIN puesto a 1 ,asimismo el servidor responde con otro segmento con bit FIN PUESTO A 1 confirmando la desconexión del servidor
3.6 PRINCIPIOS DEL CONTROL DE CONGESTIÓN Métodos para controlar la congestion
CONTROL DE CONGESTION TERMINAL A TERMINAL: aquí la capa de red no proporciona soporte a la capa de trasnporte para el control de congestion Se basa en el comportamiento de la red ( perdida de paquetes,retardos) La perdida de paquetes se produce por ( fin de temporizacion y triple paquete ACK duplicado) TCP APLICA ESTE METODO DE CONTROL DE CONGESTION CONTROL DE CONGESTION ASISTIDO POR LA RED : LOS ROUTERS INFORMAN AL EMISOR SOBRE EL ESTADO DE CONGESTION DE LA RED. LOS ROUTER TIENE 2 FORMAS DE INFROMAR AL EMISOR , LA PRIMERA ES MEDIANTE UN PAQUETE DE ASFIXIA que indica que la red esta congestionada y la otra forma es marcando un campo del segmento el cual nos indica q existe congestion . Utilizado en atm
3.7 MECANISMO DE CONTROL DE CONGESTION DE TCP
Utiliza un control de congestion terminal a terminal,el método consiste en que cada emisor limita su velocidad a la que trasmite teniendo en cuenta la congestion de la red -Un segmento perdido implica congestion y por tanto la velocidad del emisor TCP debe reducirse cuadno se pierde un segmento -Un paquete q ha sido reconocido implica q la red esta entregando los segmentos correctamente por lo q la velocidad de trasmisión puede aumentarse -Incrementa su velocidad dependiendo de llegas de paquetes ACK
