la capa de transporte (pt. 1)cs.uns.edu.ar/~ags/rc/downloads/handouts/módulo 03 - la capa de... ·...

Redes de ComputadorasRedes de ComputadorasDepto. de Cs. e Ing. de la Comp.Depto. de Cs. e Ing. de la Comp.

Universidad Nacional del SurUniversidad Nacional del Sur

Módulo 03Módulo 03La Capa de TransporteLa Capa de Transporte

(Pt. 1)(Pt. 1)

Redes de Computadoras - Mg. A. G. StankeviciusRedes de Computadoras - Mg. A. G. Stankevicius 22

CopyrightCopyrightCopyright © 2010-2020 A. G. Stankevicius

Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, versión 1.2 o cualquiera posterior publicada por la Free Software Foundation,sin secciones invariantes ni textos de cubierta delantera o trasera

Una copia de esta licencia está siempre disponibleen la página http://www.gnu.org/copyleft/fdl.html

La versión transparente de este documento puedeser obtenida de la siguiente dirección:

http://cs.uns.edu.ar/~ags/teaching

http://www.gnu.org/copyleft/fdl.html

http://cs.uns.edu.ar/~ags/teaching


ContenidosContenidosServicios y protocolos de la capa de transporte

Multiplexado y demultiplexado de segmentos

Transporte no orientado a la conexión (UDP)

Teoría de transporte confiable de datos

Transporte orientado a la conexión (TCP)

Establecimiento y cierre de conexiones

Teoría de control de congestión

Control de congestión en TCP


ISO/OSI - TCP/IPISO/OSI - TCP/IP

7

6

5

4

3

2

1 físicaenlace

redtransporte

sesiónpresentación

aplicación

Usted está aquí

5

4

3

2

1

transporte


Servicios de transporteServicios de transporteLa capa de transporte provee la comunicación lógica entre las diversasaplicaciones de red

El servicio brindado seimplementa a travésde los protocolos dela capa de transporte

Por caso en internet secuenta con TCP y UDP

aplicacióntransporte

redenlacefísica

aplicacióntransporte

redenlacefísica


Protocolos de transporteProtocolos de transporteLos protocolos de la capa de transporte corren en las computadoras de la frontera de la red

Cabe enfatizar que los routers en el núcleo de la red usualmente sólo implementan hasta la capa de red

El lado emisor de una comunicación corta los mensajes de las aplicaciones en segmentos,los que son pasados a la capa de red

El lado receptor rearma los mensajes a partirde los segmentos recibidos, que son luego pasados a la capa de aplicaciones


Transporte vs. RedTransporte vs. RedLa capa de red y la de transporte parecen ser similares, pero en realidad brindan serviciosun tanto diferentes:

Por un lado, la capa de red brinda una conexión lógica punta a punta entre computadoras

Pero por otro lado, la capa de transporte brinda una conexión lógica punta a punta entre procesos

La capa de transporte no sólo hace uso de los servicios provistos por la capa de red sino que además los perfecciona y extiende


Transporte en internetTransporte en internetInternet cuenta con dos servicios de transporte:

TCP, orientado a la conexión, que brinda un envío confiable y ordenado de datos e implementa control de flujo y de congestión

UDP, no orientado a la conexión, que brinda un envío de datos no confiable ni ordenado y tampoco implementa control de flujo ni de congestión

El servicio de transporte de internet no tiene forma de asegurar ni un ancho de banda mínimo ni un retardo máximo


Multiplexado y demultiplexadoMultiplexado y demultiplexadoLa capa de transporte es la encargada de generalizar el servicio de conexión entre computadoras provisto por la capa de red

Para la capa de transporte no basta con identificar a una computadora en particular, debe poder identificar a un dado proceso

El mecanismo que lleva a cabo esta generalización se denomina multiplexadodel lado del emisor y demultiplexadodel lado del receptor


aplicaciónaplicación

transportetransporte

redred

enlaceenlace

físicafísica

Multiplexado y demultiplexadoMultiplexado y demultiplexado

Bruno



redred

enlaceenlace

físicafísica



redred

enlaceenlace

físicafísica

Alicia Carlos

socket socket socketP3 P4 P5

Multiplexado: se realiza en el emisor al juntar mensajes de los sockets con un encabezado adicional, el cual contiene información extraque será usada luego para demultiplexar

socket socketP1 P2


Multiplexado y demultiplexadoMultiplexado y demultiplexadoDemultiplexado: tiene a lugar en el receptor al determinar a qué socket corresponde entregar cada uno de los datos recibidos por un host



redred

enlaceenlace

físicafísica

Bruno



redred

enlaceenlace

físicafísica



redred

enlaceenlace

físicafísica

Alicia Carlos

socket socket socketP3 P4 P5

socket socketP1 P2


DemultiplexadoDemultiplexadoEl proceso de demultiplexado comienzaal recibir un datagrama IP:

Cada datagrama tiene un IPde origen y de destino

Contiene exactamenteun segmento de la capade transporte

Cada segmento especificaun puerto origen y destino

El IP y puerto destino identificaunívocamente a un socket

formato de un segmentoTCP/UDP

puerto origen puerto dest.

otros campos del encabezado

cuerpo delmensaje

32 bits


Demultiplexado UDPDemultiplexado UDPCada sockets UDP se asocia a un númerode puerto local determinado

Para identificar un socket UDP arbitrario sólohace falta una dirección IP y un puerto

Al recibir un segmento UDP se verifica el puerto destino indicado en el segmento y se entrega su contenido al socket asociado a ese puerto

Segmentos originados en máquinas con diversas direcciones IP o bien distintos puertos de origen pueden ser entregados al mismo socket UDP


Demultiplexado UDPDemultiplexado UDPSupongamos que el proceso P2 crea un socket UDP en el puerto 6428:

servidor(IP: B)

socketP2

cliente(IP: A)

socketP1

cliente(IP: C)

socketP3

SP: 9157DP: 6428

SIP: ADIP: B

SP: 5775DP: 6428

SIP: CDIP: B

SP: 6428DP: 5775

DIP: CSIP: B

SP: 6428DP: 9157

DIP: ASIP: B


Demultiplexado TCPDemultiplexado TCPCada socket TCP se asocia a cuatro valores,la dirección IP y puerto de origen por un ladoy la dirección IP y puerto destino por el otro

La computadora que recibe un segmento TCP hace uso de esos cuatro valores para determinar cuálde los sockets TCP debe recibirlo

Los servidores naturalmente hacen usode múltiples sockets, uno para cada unode los clientes conectados


Demultiplexado TCPDemultiplexado TCPEl proceso P2 ahora necesita un socket TCP independiente para cada cliente:

servidor(IP: B)

cliente(IP: A)

socketP1

cliente(IP: C)

socketP3

socketsocketP2

SP: 9157DP: 80SIP: ADIP: B

SP: 5775DP: 80SIP: CDIP: B

SP: 51112DP: 5775

DIP: CSIP: B

SP: 51211DP: 9157

DIP: ASIP: B


Protocolo UDPProtocolo UDPEl protocolo UDP representa el servicio de transporte más elemental que brinda internet

Se define formalmente en el RFC 768

Se basa en el principio “best effort”,propio del protocolo IP de la capa de red

Se trata de un protocolo no orientadoa la conexión:

Cada segmento UDP se puede manipularde manera independiente del resto


Protocolo UDPProtocolo UDP¿Habiendo TCP, hace falta UDP?

UDP no necesita establecer una conexión antesde comenzar a enviar información

Es extremadamente simple, no necesita almacenar información acerca del intercambio en curso

Su encabezado es mucho más sencillo y ocupa menor cantidad de bytes que un encabezado TCP

No implementa control de flujo ni de congestión,el emisor puede enviar la información al ritmoque le plazca, sin limitaciones de ningún tipo


Protocolo UDPProtocolo UDPEl protocolo se suele utilizar para hacer streaming de audio y video

El streaming es tolerantea pérdidas pero requiereretardos acotados

Otros usos:

DNS

SMNP

Juegos en línea formato deun segmento UDP

puerto origen puerto dest.

cuerpo delmensaje

32 bits

longitud checksum

largo en bytesdel segmento UDP,incluyendo encabezado


Checksum UDPChecksum UDPEl propósito del campo checksum es detectarla aparición de bits en error

El emisor calcula el checksum correcto:

Considera el contenido del segmento comouna secuencia de enteros de 16 bits

El checksum consiste de la suma en 1-complemento de esta secuencia de enteros

Una vez obtenido el checksum correcto lo escribeen el campo correspondiente del encabezado UDP


Checksum UDPChecksum UDPEl receptor debe verificar el checksum:

Recomputa el checksum del segmentoque acaba de recibir

Compara el valor obtenido con el checksumregistrado en el campo del encabezado

Si difieren se detectó uno o más erroresen la transmisión

En contraste, si son iguales no se han detectados errores en la transmisión (¡lo cual no significaque no se hayan producido uno o más errores!)


Comunicación confiableComunicación confiable

Aplicación

Transporte

Red

P2

canal confiable

servicio provisto implementación

canal no confiable

P1

datos datos datos datos

paquete paquete

envio_rdt() entregar()

protocolo rdt(emisor)

protocolo rdt(receptor)

envio_udt() recep_rdt()

P2P1


Comunicación confiableComunicación confiable

canal no confiable

envio_rdt() entregar()datos datos

protocolo rdt(emisor)

protocolo rdt(receptor)

paquete paqueteenvio_udt() recep_rdt()

envio_rdt(): invocado desdearriba, suministra los datosa ser enviados

envio_rdt(): invocado desdearriba, suministra los datosa ser enviados

entregar(): invocado porel protocolo para entregarlos datos recibidos

entregar(): invocado porel protocolo para entregarlos datos recibidos

envio_udt(): invocado porel protocolo para transferirun paquete a través del canalno confiable

envio_udt(): invocado porel protocolo para transferirun paquete a través del canalno confiable

recep_rdt(): invocado porel protocolo cuando llegaun nuevo paquete al receptor

recep_rdt(): invocado porel protocolo cuando llegaun nuevo paquete al receptor

P2P1


Protocolo RDTProtocolo RDTA continuación analizaremos cómo se debería definir el protocolo RDT para poder brindarun servicio de transferencia confiable de datos

La idea es comenzar con un protocolo básico para luego ir considerando un escenario más realista

Emisor y receptor tienen responsabilidades diferentes

Sólo consideraremos una comunicación unidireccional

Las distintas iteraciones del protocolo RDT serán definidas a través de autómatas finitos


RDT/1.0RDT/1.0El protocolo RDT/1.0 permite el envío confiable de datos a través de un canal confiable

El canal no pierde información ni introduce errores

Un autómata para el emisor y otro para el receptor

paqenv = empaq(datos)envio_udt(paqenv)

envio_rdt(datos)esperarllamada

de arriba datos = desempaq(paqrec)entregar(datos)

recep_rdt(paqrec)esperarllamadade abajo

emisor receptor


RDT/2.0RDT/2.0El protocolo RDT/2.0 permite envío confiablede datos a través de un canal que puede causar errores a nivel de los bits

El canal sigue sin perder información, sólo introduce errores a nivel de bit

Los errores pueden ser detectados por el campo checksum del encabezado UDP

No obstante, con detectar el error no basta,se debe incorporara al protocolo algún mecanismode recuperación ante la detección de un error

¿Qué hacen los humanos ante este tipo de error?


RDT/2.0RDT/2.0La nueva versión del protocolo hará usode confirmaciones de recepción (ACK) paraindicar que el paquete fue recibido sin errores

Si el paquete llega con errores, se solicitala retransmisión del mismo haciendo usode un mensaje específico (NAK)

El emisor reenvía el último paquete enviadoal recibir un NAK en vez de un ACK

¿Existe alguna situación involucrando humanos enla que se haga uso de mensajes de ACK y/o NAK?


Emisor RDT/2.0Emisor RDT/2.0

envio_udt(paqenv)

recep_rdt(paqrec) &&esNAK(paqrec)

esperarllamada

de arriba

esperar porACK/NAK

recep_rdt(paqrec) &&esACK(paqrec)

envio_rdt(datos)

paqenv = empaq(datos,checksum)envio_udt(paqenv)


Receptor RDT/2.0Receptor RDT/2.0

esperarllamadade abajo

paqenv = crearpaqNAK()envio_udt(paqenv)

recep_rdt(paqrec) &&corrupto(paqrec)

paqenv = crearpaqACK()envio_udt(paqenv)datos = desempaq(paqrec)entregar(datos)

recep_rdt(paqrec) &&!corrupto(paqrec)


RDT/2.0 envío sin erroresRDT/2.0 envío sin errores

envio_udt(paqenv)


esperarllamada

de arriba

esperar porACK/NAK

envio_rdt(datos)









RDT/2.0 envío con erroresRDT/2.0 envío con errores

envio_udt(paqenv)


esperarllamada

de arriba

esperar porACK/NAK


envio_rdt(datos)








Análisis de RDT/2.0Análisis de RDT/2.0RDT/2.0 es un protocolo tipo “stop and wait”

El emisor envía un paquete y queda a la esperade que le confirmen su correcta recepción

No obstante, RDT/2.0 tiene un defecto fatal:

¿Qué sucede si el canal corrompe el paquete enviado por el receptor conteniendo un ACK o un NAK?

El problema es que el receptor desconoce qué está pasando con el emisor

Asumir que se trataba de un NAK no es suficiente, puede causar que el receptor acepte un duplicado


Posibles solucionesPosibles solucionesUna posibilidad consiste en enviar un ACK oun NAK adicional para que el receptor sepasi el emisor recibió correctamente el mensaje

¿Qué pasa si se corrompe el ACK/NAK del ACK/NAK?

Otra posibilidad es agregar suficientes bits de código como para poder corregir estos errores

Podría funcionar, pero no se puede aplicar a canales que pierdan paquetes

La única solución viable parece ser numerarlos paquetes


Paquetes duplicadosPaquetes duplicadosIncorporar un esquema de numeración delos paquetes implica que el emisor marque cada paquete que envía con un cierto número

En el escenario que se corrompía el ACK/NAKenviado por el receptor, el emisor simplementeasume que se trataba de un NAK y reenvíael último paquete (usando el mismo númerode paquete que la vez anterior)

El receptor en caso de recibir por segunda vezel mismo paquete simplemente lo descarta



envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || esNAK(paqrec))

paqenv = empaq(0,datos,checksum)envio_udt(paqenv)

envio_rdt(datos)

recep_rdt(paqrec) &&!corrupto(paqrec) &&

esACK(paqrec))

esperarllamada 0de arriba

esperar porACK/NAK 0

esperar porACK/NAK 1



envio_rdt(datos)


esACK(paqrec))

envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) ||

esNAK(paqrec))



esperarllamada 0de abajo


paqenv = empaq(NAK,checksum)envio_udt(paqenv)


paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec1(paqrec)paqenv = empaq(NAK,checksum)envio_udt(paqenv)


paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec1(paqrec)


Análisis de RDT/2.1Análisis de RDT/2.1RDT/2.1 incorpora números de secuenciaen los paquetes enviados por el emisor

Con sólo dos números de paquete es suficiente

El emisor verifica la correcta recepción delos mensajes de ACK/NAK

Los autómatas finitos que definen el protocolo requieren el doble de estados que en RDT/2.0

Los estados distinguen el número de secuenciadel próximo paquete a ser enviado o recibido


Análisis de RDT/2.1Análisis de RDT/2.1El receptor debe verificar que los paquetes recibidos tengan el número de secuencia esperado

Caso contrario, se trata de un paquete duplicado,el cual debe ser descartado

El receptor no tiene forma de saber si el emisor recibió correctamente el último ACK/NAK

Se dará cuenta implícitamente que el emisor recibió correctamente el ACK cuando vea un paquete numerado con el próximo valor de la secuencia


RDT/2.2RDT/2.2El protocolo RDT/2.1 admite ser optimizado evitando tener que hacer uso de los mensajes NAK de reconocimiento negativo

La idea es que el receptor indique qué paquete está reconociendo al enviar un ACK

Debemos incorporar el número de secuenciaen los mensajes enviados por el receptor

La recepción por parte del emisor deun segundo ACK hace las veces de NAK

En ambos casos se debe reenviar el último paquete



envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || esACK1(paqrec))


envio_rdt(datos)


esACK0(paqrec)


esperar porACK 0

esperar porACK 1



envio_rdt(datos)


esACK1(paqrec))

envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) ||

esACK0(paqrec))





paqenv = empaq(0,ACK,checksum)envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(0,ACK,checksum)envio_udt(paqenv)almenosunoenv = false

recep_rdt(paqrec) &&!corrupto(paqrec) && nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(1,ACK,checksum)envio_udt(paqenv)

recep_rdt(paqrec) &&!corrupto(paqrec) && nrosec1(paqrec)if(!almenosunoenv)

paqenv = empaq(1,ACK,checksum) envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || nrosec1(paqrec))

almenosunoenv = true


RDT/3.0RDT/3.0El protocolo RDT/3.0 permite envío confiable de datos a través de un canal que puede causar errores a nivel de los bits y/o perder en su totalidad alguno de los mensajes enviados

El protocolo debe contemplar que se pierdaun paquete o un mensaje de ACK

Se deben resolver dos problemas: cómo detectarlas pérdidas y qué hacer cuando se produzca una

Los mecanismos presentes en RDT/2.2 no permiten detectar que se produjo una pérdida


RDT/3.0RDT/3.0Un posible solución es quedar a la espera deun paquete o un mensaje ACK y cuando se tenga la certeza de que se perdió reenviarlo

¿Cuánto hay que esperar para tener la certezaque se perdió el último mensaje enviado?

Esta alternativa funciona, pero implica pagar un costo muy alto en eficiencia al perderse un mensaje

Una mejor opción es quedar a la espera de una respuesta por un tiempo razonable y si no llega asumir que se perdió y reenviarlo


RDT/3.0RDT/3.0¿Qué sucede si en realidad el paquete estaba retrasado, pero no se había perdido?

El reenvió generará un mensaje duplicado, peroel protocolo ya maneja correctamente esa situación

Emisor y receptor deben indicar el númerode secuencia en sus mensajes

Para implementar esta política hace falta contar con un temporizador programable


Emisor RDT/3.0Emisor RDT/3.0paqenv = empaq(0,datos,checksum)envio_udt(paqenv)poner(alarma)

envio_rdt(datos)

recep_rdt(paqrec) &&(corrupto(paqrec) ||nrosec1(paqrec))



esperar porACK 0

esperar porACK 1

disparo(alarma)

envio_udt(paqenv)poner(alarma)

sacar(alarma)


nrosec0(paqrec)

recep_rdt(paqrec)

recep_rdt(paqrec)

paqenv = empaq(1,datos,checksum)envio_udt(paqenv)poner(alarma)

envio_rdt(datos)

recep_rdt(paqrec) &&(corrupto(paqrec) ||nrosec0(paqrec))

disparo(alarma)

envio_udt(paqenv)poner(alarma)

sacar(alarma)


nrosec1(paqrec)


RDT/3.0 idealRDT/3.0 ideal

envío paq. 0recep. paq. 0envío ACK 0

recep. ACK 0envío paq. 1 recep. paq. 1

envío ACK 1recep. ACK 1envío paq. 0 recep. paq. 0

envío ACK 0recep. ACK 0

emisor receptor


Pérdida de un paquetePérdida de un paquete

envío paq. 0recep. paq. 0envío ACK 0

recep. ACK 0envío paq. 1

disparo de alarmareenvío paq. 1 recep. paq. 1


emisor receptor

paquetepérdido


Pérdida de un ACKPérdida de un ACK

recep. paq. 1envío ACK 1

disparo de alarmareenvío paq. 1 recep. paq. 1 (duplicado detec.)

reenvío ACK 1recep. ACK 1

emisor receptor

ACKpérdido


recep. ACK 0envío paq. 1

envío paq. 0


Reenvío prematuroReenvío prematuro

disparo de alarmareenvío paq. 0 recep. paq. 0 (duplicado detec.)

reenvío ACK 0recep. ACK 0

(duplicado detec.)

emisor receptor


envío paq. 0

recep. ACK 0envío paq. 1 recep. paq. 1



¿¿Preguntas?Preguntas?

la capa de transporte (pt. 1)cs.uns.edu.ar/~ags/rc/downloads/handouts/módulo 03 - la capa de... ·...

Documents