Slides TD IV - clases (9)

Vista previa del material en texto

TD4 2022TD4 2022
Agenda
▪ Servicios del nivel de transporte
▪ Multiplexación y demultiplexación
▪ Transporte no orientado a conexión: UDP
▪ Transferencia de datos confiable
▪ Transporte orientado a conexión: TCP
▪ Control de congestión
▪ Protocolos modernos: QUIC
2
TD4 2022TD4 2022 3
Servicios del
Nivel de Transporte
TD4 2022TD4 2022
Protocolos de transporte de Internet
▪TCP: Transmission Control Protocol
• Entrega confiable y en orden
• Control de congestión
• Control de flujo
• Establecimiento de conexión
▪UDP: User Datagram Protocol
• Entrega no confiable y fuera de orden
• “Best-effort” (extensión de IP)
▪Servicios no disponibles:
• Garantías de delay
• Garantías de ancho de banda
4
 
 
 
 
 
 
 
 
 
 
 
 
 
aplicación
transporte
red
enlace
física
canal lógico
aplicación
transporte
red
enlace
física
TD4 2022TD4 2022
Multiplexación/demultiplexación
proceso
socket
transporte
aplicación
física
enlace
red
P2P1
transporte
aplicación
física
enlace
red
P4
transporte
aplicación
física
enlace
red
P3
5
datos de distintos sockets; se 
agrega header de transporte 
(utilizado para demultiplexar 
luego)
multiplexación (emisor)
Entrega de segmentos recibidos al 
socket correcto a partir de los datos 
del header
demultiplexación (receptor)
TD4 2022TD4 2022
Resumen
▪ La multiplexación/demultiplexación se basa en los valores de 
los headers del datagrama y el segmento
▪ UDP: demultiplexación utilizando sólo el puerto destino
▪ TCP: demultiplexación utilizando la 4-upla conformada por las 
direcciones IP y los puertos origen y destino
6
TD4 2022TD4 2022
UDP: User Datagram Protocol
▪ Protocolo de transporte de 
Internet básico
▪ Servicio best effort: los 
segmentos pueden
• Extraviarse en la red
• Entregarse fuera de orden
▪ Sin establecimiento de 
conexión (agrega delay 
por RTT)
▪ Sencillo: sin estado tanto 
en emisor como en 
receptor
▪ Header más chico
▪ Sin control de congestión
▪ UDP puede ir tan “rápido” 
como quiera
▪ Puede funcionar ante la 
presencia de congestión
¿Por qué existe UDP?
▪ No orientado a conexión
• Sin handshaking entre emisor y 
receptor (connectionless)
• Cada segmento procesado 
independientemente de los 
otros 7
TD4 2022TD4 2022
UDP: User Datagram Protocol
▪ Usos de UDP:
▪ Aplicaciones de streaming (tolerantes a pérdidas y sensibles 
a la tasa de transferencia)
▪ DNS
▪ SNMP (protocolo para monitorear y administrar dispositivos)
▪ HTTP/3 (más detalle luego)
▪ En caso de necesitar transporte confiable sobre UDP (como 
HTTP/3):
▪ Agregar confiabilidad necesaria en la capa de aplicación
▪ Ídem control de congestión
8
TD4 2022TD4 2022
Header de UDP
puerto src puerto dst
32 bits
datos de la 
aplicación 
(payload)
Formato del segmento UDP
longitud checksum
longitud en bytes
del segmento
(incluyendo el header)
datos desde/hacia
el nivel de aplicación
9
TD4 2022TD4 2022
Checksum de UDP
transmitido: 5 6 11
Objetivo: detectar errores en los bits del segmento transmitido
1er número 2do número suma
checksum computado
en el receptor
checksum computado en el 
emisor (y enviado en el header)
recibido: 4 6 11
=
10
TD4 2022TD4 2022
Checksum de UDP
Emisor
▪ Interpreta el contenido del 
segmento como una secuencia 
de enteros de 16 bits (incluyendo 
header + direcciones IP)
▪ checksum: complemento a uno 
de la suma del contenido del 
segmento 
▪ El valor del checksum se coloca 
en el header del segmento
Receptor
▪ Calcula la suma de las palabras de 16 
bits del segmento recibido (incluido el 
checksum)
▪ Comprueba que el complemento a 
uno de este valor sea 0
• Si no es cero: error detectado!
• Si es cero: no se detectaron errores 
(...pero podría haber errores de todos 
modos?)
11
Objetivo: detectar errores en los bits del segmento transmitido
TD4 2022TD4 2022
Checksum: ejemplo
Ejemplo: suma (complemento a uno) de dos enteros de 16 bits
suma
checksum
Nota: al sumar números en complemento a uno, el bit de carry debe sumarse al resultado
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1carry
 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
12
TD4 2022TD4 2022
Ejercicio!
▪ UDP y TCP usan el complemento 1 para sus checksums. 
Supongamos que tenemos los siguientes tres bytes: 01010011, 
01100110, 01110100. 
• ¿Cuál es el checksum?
• ¿Por qué UDP toma el complemento a 1 de la suma? es 
decir, ¿por qué no usar simplemente la suma? 
• ¿Es posible que un error de 1 bit pase desapercibido? ¿Qué 
tal un error de 2 bits?
TD4 2022TD4 2022
Ejercicio!
▪ UDP y TCP usan el complemento 1 para sus checksums. 
Supongamos que tenemos los siguientes tres bytes: 01010011, 
01100110, 01110100. 
C1 = 1 1 0 1 0 0 0 1 
TD4 2022TD4 2022
Protección del checksum
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
 0 1 
 1 0 
Notar que los 
números cambiaron 
pero no se observan 
cambios en el 
checksum
15
Ejemplo: suma (complemento a uno) de dos enteros de 16 bits
suma
checksum
carry
TD4 2022TD4 2022
Resumen: UDP
▪ Protocolo básico
• Pueden perderse segmentos y ser entregados fuera de orden
• Servicio best effort: enviar y “esperar lo mejor”
▪ UDP tiene sus beneficios:
• No precisa setup inicial: evita penalización de RTT
• Puede funcionar cuando el servicio de la red está degradado
• Ayuda con la confiabilidad (checksum)
▪ Es posible agregar funcionalidad adicional sobre UDP en la capa 
de aplicación (e.g., HTTP/3)
TD4 2022TD4 2022 17
Protocolos confiables
TD4 2022TD4 2022
Transmisión confiable: conceptos
proceso
emisor
datos
proceso 
receptor
 canal confiable
aplicación
transporte
servicio confiable: abstracción
18
datos
TD4 2022TD4 2022
Transmisión confiable: conceptos
red
emisor del 
protocolo de 
transmisión 
confiable
19
proceso
emisor
datos
proceso 
receptor
 canal confiable
aplicación
transporte
servicio confiable: abstracción
proceso
emisor
proceso 
receptor
datos
 canal no confiable
servicio confiable: implementación
datos datos
transporte
receptor del 
protocolo de 
transmisión 
confiable
TD4 2022TD4 2022
Transmisión confiable: conceptos
La complejidad del protocolo depende 
fuertemente de las particularidades del 
canal no confiable subyacente (e.g. si 
corrompe, pierde y/o reordena datos)
20
emisor del 
protocolo de 
transmisión 
confiable
proceso
emisor
proceso 
receptor
 canal no confiable
servicio confiable: implementación
datos datos
receptor del 
protocolo de 
transmisión 
confiable
TD4 2022TD4 2022
Transmisión confiable: conceptos
Los interlocutores no conocen el estado 
del otro (e.g., el emisor no puede saber si 
un mensaje fue recibido)
▪ La única forma de conocer dicho 
estado es mediante el intercambio de 
mensajes (¡que puede fallar!)
21
emisor del 
protocolo de 
transmisión 
confiable
proceso
emisor
proceso 
receptor
 canal no confiable
servicio confiable: implementación
datos datos
receptor del 
protocolo de 
transmisión 
confiable
TD4 2022TD4 2022
API (abstracta) de un protocolo confiable
rdt_send()
udt_send() rdt_rcv()
deliver_data()
header header
rdt_send(): invocada 
desde la app para pasar 
datos a entregar al nivel de 
aplicación del receptor
udt_send(): invocada por 
rdt paratransmitir un 
paquete al receptor sobre el 
canal no confiable
rdt_rcv(): invocada 
cuando llega un paquete por 
el canal
deliver_data(): invocada 
por rdt para entregar datos a 
la capa de aplicación
comunicación bidireccional
datos
paquete
22
proceso
emisor
proceso 
receptor
 canal no confiable
datos datos
datosdatos
emisor del 
protocolo de 
transmisión 
confiable rdt
receptor del 
protocolo de 
transmisión 
confiable rdt
TD4 2022TD4 2022
API (abstracta) de un protocolo confiable
23
▪ rdt_send(data) crea un paquete que contiene los datos (mediante la 
acción make_pkt(data)) y los envía a la capa subyacente (utilizando la 
acción udt_send(packet)).
▪ rdt_rcv(packet) recibe un paquete del canal, remueve el encabezado 
mediante extract(packet,data) y lo pasa a la capa del nivel superior 
mediante la acción deliver_data(data).
TD4 2022TD4 2022
Diseño de un protocolo confiable
▪ Vamos a diseñar incrementalmente las características de un protocolo de 
transmisión confiable, rdt (Reliable Data Transfer)
▪ Motivación para entender la complejidad de protocolos como TCP
▪ Consideramos flujo unidireccional de datos (pero no así de información 
de control)
▪ Utilizaremos máquinas de estados finitos (FSMs) para especificar el 
protocolo:
24
estado
1
evento que causa
transición de estados
acciones tomadas al transicionar
el siguiente estado queda 
unívocamente determinado 
por el siguiente evento
estado
2evento
acciones
TD4 2022TD4 2022
rdt1.0: transmisión confiable sobre un canal confiable
▪ Comenzamos asumiendo que el canal subyacente es perfectamente 
confiable
• No introduce errores en los bits
• Tampoco pierde paquetes
packet = make_pkt(datos)
udt_send(packet)
rdt_send(datos)
extract(packet,datos)
deliver_data(datos)
rdt_rcv(packet)esperar
llamadareceptor
▪Tenemos una FSM para el emisor y otra para el receptor:
• El emisor envía datos al canal subyacente
• El receptor lee datos del canal
emisor
esperar 
llamada
25
TD4 2022TD4 2022
rdt2.0: transmisión sobre un canal con errores
▪ El canal subyacente puede corromper bits en los paquetes
• Se pueden detectar vía checksum 
▪ ¿Cómo podemos recuperarnos de los errores?
• Acknowledgements (ACKs): el receptor indica explícitamente 
que el paquete llegó bien
• Negative Acknowledgements (NAKs): el receptor indica 
explícitamente que el paquete llegó con errores
• El emisor retransmite el paquete al recibir un NAK
stop and wait
el emisor envía un paquete y luego espera la respuesta del receptor
26
TD4 2022TD4 2022
rdt2.0: especificación
esperar
ACK / NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
extract(rcvpkt,datos)
deliver_data(datos)
udt_send(ACK)
rdt_rcv(rcvpkt) && !corrupt(rcvpkt)
sndpkt = make_pkt(datos, checksum)
udt_send(sndpkt)
rdt_send(datos)
 
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ esperar
llamada receptor
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
27
Nota: el emisor no tiene forma de conocer el 
estado del receptor a menos que el mismo se 
comunique explícitamente
esperar 
llamada
emisor
TD4 2022TD4 2022
rdt2.0: ACKs/NAKs corruptos
Este protocolo falla si hay corrupción 
en ACKs/NAKs
▪El emisor no tiene forma de saber 
qué ocurrió en el receptor
▪No es posible retransmitir: podría 
generar datos duplicados
Manejo de duplicados:
▪El emisor retransmite el 
paquete actual ante 
corrupción de ACK/NAK
▪Agrega un número de 
secuencia a cada paquete
▪El receptor descarta paquetes 
duplicados valiéndose de este 
valor
28
stop and wait
el emisor envía un paquete y luego espera la respuesta del receptor
TD4 2022TD4 2022
rdt2.1: manejo de ACKs/NAKs corruptos
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
(corrupt(rcvpkt) || isNAK(rcvpkt))
29
emisor
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
(corrupt(rcvpkt) || isNAK(rcvpkt))
esperar
ACK / 
NAK
0
sndpkt = make_pkt(0, datos, checksum)
udt_send(sndpkt)
rdt_send(datos)
esperar
Llamada
1
rdt_rcv(rcvpkt) &&
!corrupt(rcvpkt) && isACK(rcvpkt) 
Λ
sndpkt = make_pkt(1, datos, checksum)
udt_send(sndpkt)
rdt_send(datos)
esperar
ACK / 
NAK
1
rdt_rcv(rcvpkt) &&
!corrupt(rcvpkt) && isACK(rcvpkt) 
Λ
esperar
Llamada 
0