Comunicación de Datos y

Redes
Profesor : Karen Kiefer Hernández
mkiefer@ubiobio.cl

Diapositivas basadas en texto “Computer Networks: A System Approach” por Larry Peterson y Bruce Davie.
Morgan Kaufmann, 2013
Objetivos capa de transporte

 Servicios capa de  Transporte orientado a la conexión;

Transporte TCP
 Estructura de segmento TCP
 Multiplexión y demultiplexión
 Transferencia confiable de datos
 Transporte sin conexión: UDP
 Control de flujo
 Principios de transferencia confiable de datos
 Gestión de una conexión
 Rdt 1.0
 Principio de control de congestión
 Rdt 2.0
 Control de congestión TCP
Protocolos y servicios de transporte

 Proveer comunicación lógica entre

procesos aplicación corriendo en
diferentes hosts
 Los protocolos de transporte corren en
sistemas terminales (computadores, no
equipos internos como routers)
 Lado Fuente: divide el mensaje de la
aplicación en segmentos, y los pasa a la
capa de red.
 Lado Receptor: re-ensambla los
segmentos del mensaje , y lo pasa a la
capa aplicación
 Hay más de un protocolo de transporte
disponible para las aplicaciones
 Internet: TCP y UDP
Capa de Transporte vs capa de Red
 Capa de red: encargada
de la comunicación
lógica entre hosts
 Capa transporte:
encargada de la
comunicación lógica
entre procesos
 Descansa en, mejora
los servicios de la capa
de red
Analogía:
12 niños envían cartas a otros 12 niños.
Ana y Pedro recopilan las cartas en cada
hogar y las envían por correo. También
distribuyen las cartas que llegan.
 procesos = niños
 Mensajes aplicación = cartas en sobres
 hosts = casas
 Protocolo de transporte = Ana y Pedro
 Protocolo capa red = Servicio de
correos
Protocolos de la capa de transporte en
Internet
 Entrega confiable y en orden (TCP)
 Tiene: control de congestión
 Control de flujo
 Establecimiento de conexión
 Entrega no confiable, tal vez
desordenada: (UDP)
 Básicamente el mismo servicio que
“mejor esfuerzo (“besteffort”) IP
 Qué servicios no se ofrecen:
 Garantías de retardo
 Garantías de ancho de banda

(Básicamente porque no son posibles de

ofrecer basándose en los servicios de IP)
 Capa de transporte

 Servicios capa de transporte

 Transporte orientado a la conexión;
 Multiplexión y TCP
Demultiplexión  Estructura de segmento TCP
 Transferencia confiable de datos
 Transporte sin conexión: UDP
 Control de flujo
 Principios de transferencia confiable de datos
 Gestión de una conexión
 Rdt 1.0
 Principio de control de congestión
 Rdt 2.0
 Control de congestión TCP
Multiplexión /Demultiplexión
¿Cómo trabaja la demultiplexión?

 El host recibe paquetes IP

 Cada paquete tiene dirección IP fuente y
dirección IP destino
 Cada paquete lleva 1 segmento de la capa
Transporte
 Cada segmento tiene números de puerto
fuente y destino
(recordar: hay números de puerto conocidos
para aplicaciones específicas)
 El host usa direcciones IP y números de
puertos para conducir un segmento al
socket apropiado
Demultiplexión sin conexión (UDP)
Demultiplexión sin conexión (UDP)
Demultiplexión orientada a la conexión
 Sockets TCP queda definido
por 4-tupla:
 Dirección IP Origen
 Número de puerto Origen
 Dirección IP Destino
 Número de puerto Destino
 Host Receptor usa los cuatro
valores para dirigir los
segmentos al socket
apropiado.
 Un Host servidor puede soportar
muchos sockets TCP simultáneos:
 Cada socket es identificado por su
propia 4-tupla
 Servidores Web tiene sockets
diferentes por cada cliente
conectado
 HTTP no-persistente tendrá
diferentes sockets por cada
requerimiento
Demultiplexión orientada a la conexión
Demultiplexión orientada a la conexión
 Capa de transporte

 Servicios capa de transporte

 Multiplexión y Demultiplexión  Transporte orientado a la conexión;
TCP
 Transporte sin conexión:  Estructura de segmento TCP

UDP  Transferencia confiable de datos

 Control de flujo
 Principios de transferencia confiable de datos
 Gestión de una conexión
 Rdt 1.0
 Principio de control de congestión
 Rdt 2.0
 Control de congestión TCP
UDP: User datagrama Protocol (RFC 768)

 Protocolo Internet de transporte “sin

adicionales”
 Servicio de “mejor esfuerzo”, un
segmento UDP puede ser:
 Perdido
 Entregado a la aplicación fuera de
orden

 Sin conexión:
 No hay handshaking (apretón de
manos) entre servidor y receptor UDP
 Cada segmento UDP es manejado en
forma independiente de los otros
UDP: más
 A menudo es usado para flujos (streaming)
multimedia en aplicaciones que requieren:
 Tolerancia a pérdida
 Sensibilidad a la tasa
 Otros usos de UDP
 DNS
 SNMP (Simple red Management Protocol)
 Transferencia confiable sobre UDP: agrega
confiabilidad en la capa Aplicación
 Recuperación de errores específicos según la
aplicación!
 Checksum UDP (suma de chequeo)
Objetivo: detectar “errores” (e.g., bits cambiados) en
segmentos transmitidos

Fuente/emisor: Receptor:
• Trata el contenido de cada  Calcula el checksum del segmento recibido
segmento como una secuencia  Chequea si el valor calculado corresponde al
valor de checksum recibido en el campo:
de enteros de 16 bits
 NO corresponde – error detectado
• Checksum: suma del contenido
 SI - no hay error detectado.
del segmento y luego tomamos
el complemento 1.
• El origen pone el valor del
checksum en el campo
checksum del datagrama UDP
Ejemplo Checksum en Internet
 Cuando sumamos números, la reserva del bit más significativo debe ser sumada al resultado
 Tomar el complemento 1 no es más que invertir los bits
 Capa de transporte

 Servicios capa de transporte

 Multiplexión y Demultiplexión  Transporte orientado a la conexión;
TCP
 Transporte sin conexión: UDP
 Estructura de segmento TCP
 Principios de  Transferencia confiable de datos

transferencia confiable de
 Control de flujo

 Gestión de una conexión

datos  Principio de control de congestión
 Rdt 1.0
 Control de congestión TCP
 Rdt 2.0
Principios de trasferencia confiable de
datos
Principios de trasferencia confiable de
datos: aspectos previos
Principios de trasferencia confiable de datos:
aspectos previos
• Desarrollaremos incrementalmente los lados Fuente y Receptor del
protocolo de transferencia confiable (rdt)
• Consideraremos sólo transferencias de datos unidireccionales
• Pero la información de control fluye en ambas direcciones!
• Usaremos máquina de estados finitos (MEF) para especificar la
fuente y el receptor
Rdt1.0: transferencia confiable sobre
canal confiable
 Canal subyacente es perfectamente confiable
 no hay errores de bit
 no hay pérdida de paquetes
 MEF separada por Fuente y Receptor:
 Fuente envía datos vía en canal inferior
 Receptor lee datos desde el canal inferior
Rdt1.0: transferencia confiable sobre
canal confiable
rdt2.0: canal con errores de bits

 Canal de transmisión puede cambiar bits de un paquete

 Se usa checksum para detectar errores de bits
 Pregunta: ¿Como Recuperarse de errores?

¿Como los seres humanos nos recuperamos de “errores” durante una

conversación?
 rdt2.0: canal con errores de bits
 Canal de transmisión puede cambiar bits de un paquete
 Se usa checksum para detectar errores de bits
 Pegunta: ¿Como recuperarnos de errores? :
 Reconocimientos o acuses de recibo (ACKs): receptor explícitamente le dice al emisor
que paquete fue recibido OK
 Reconocimiento negativo (NAKs): receptor explícitamente le dice al emisor que
paquete tiene errores
 Emisor retransmite paquete al recibir un NAK
 Nuevo mecanismo en rdt2.0 (mejora de rdt1.0):
 Detección de errores
 Realimentación del receptor: msjs de control (ACK,NAK) rcpt->emisor
rdt2.0: Especificación de la MEF
rdt 2.0: escenario sin errores
rdt 2.0: escenario con errores
rdt 2.0 Tiene una falla fatal

 ¿Qué pasa si se corrompe el Manejo de Duplicados:

ACK/NAK?
 Fuente agrega números de
 Fuente no sabe qué pasó en el secuencia a cada paquete.
receptor
 Fuente retrasmite el paquete
 No puede sólo retrasmitir: actual si ACK/NAK llega mal
generaría un posible duplicado
 El receptor descarta (no entrega
hacia arriba) los paquetes
duplicados
Rdt 2.1: Fuente, manejo de de ACK/NAK
errados
Rdt 2.1: Receptor, manejo de ACK/NAKs
errados
Rdt 2.1: Discusión
Fuente:
• Agrega # secuencia al paquete
• 2 #’s (0,1) de secuencia
• Debe chequear si el ACK/NAK
recibido esta corrupto
• El doble del numero de estados
• Estado debe “recordar” si paquete
“actual” tiene # de secuencia 0 ó 1
Receptor:
• Debe chequear si el paquete
recibido es duplicado
• Estado indica si el numero de
secuencia esperado es 0 o 1
• Nota: el receptor no puede saber si
su ultimo ACK/NAK fue recibido OK
por la fuente
Rdt 2.2: un protocolo libre de NAK

 La misma funcionalidad que rdt2.1, usando solo ACKs

 En lugar de NAK, el receptor envía ACK por el ultimo
 paquete recibido OK
 Receptor debe explícitamente incluir # de secuencia del paquete siendo
confirmado con el ACK
 ACK duplicados en la fuente resulta en la misma acción que NAK: retrasmitir
paquete actual
Rdt 2.2: Fragmentos de la fuente y
receptor
Hasta aquí

 Si el canal es ideal, el mecanismo es simple( rdt 1.0)

 Si hay errores, pero no se pierden datos, usar ACK y NAK (rdt 2.0)
 Si los ACK o NAK también pueden venir con errores, el emisor reenvía el
paquete, entonces debemos usar número de secuencia para eliminar
duplicados (rdt 2.1)
 Se pueden evitar NAK, enviando ACK duplicados en lugar de NAK, entonces
debemos usar numero de secuencia para detectar ACK duplicados (rdt 2.2)
Rdt 3.0: canales con errores y pérdidas
Suposición nueva:
• canal subyacente también puede
perder paquetes (de datos o ACKs)
• checksum, # de secuencias, ACKs, y
retransmisiones ayudan pero no son
suficientes
Estrategia:
• transmisor espera un tiempo
“razonable” por el ACK
• Retransmitir si no se recibe ACK en
este tiempo
• Si el paquete (o ACK) esta retardado
(no perdido):
• La retransmision sera un duplicado,
pero el uso de #’s de secuencia ya
maneja esto
• Receptor debe especificar el # de
secuencia del paquete siendo
confirmado en el ACK Se requiere un
temporizador de cuenta regresiva
Rdt 3.0 Fuente
Rtd 3.0 en acción
Rdt 3.0 en acción
Desempeño de rdt 3.0
Rdt 3.0 operación parar y esperar
Protocolos con Pipeline
Pipeline: incremento de la utilización
Protocolos con Pipeline: revisión
Go-Back_N: Fuente
GBN: MEF extendida de la Fuente
GBN:MEF extendida del receptor
GBN en acción
Repetición Selectiva

 Receptor envía acuse de recibo individuales de todos los paquetes recibidos

 Almacena paquetes en buffer, según necesidad para su entrega en orden a la capa
superior
 Transmisor solo re-envia los paquetes sin ACK recibido
 Transmisor usa un timer por cada paquete sin ACK
 Ventana del Transmisor
 N # de secuencia consecutivos
 Nuevamente limita los #s de secuencia de paquetes enviados sin ACK
Repetición Selectiva; ventanas de la
fuente y receptor
Repetición Selectiva
Repetición Selectiva
Dilema de la repetición Selectiva
La clave para evitar este problema es impedir que se
pueda producir el escenario en la figura (B).
Supongamos que la ventana de recepción del
receptor es [m, m+w-1], por lo tanto ha recibido y
enviado ACK del paquete m-1 y los w-1 paquetes
previos a éste.
Si ninguno de estos ACK han sido recibidos por el
emisor, entonces ACK con valores [m-w,m-1] pueden
estar en tránsito. En este caso la ventana del
transmisor será [m-w,m-1]. r
Así, el límite inferior de la ventana del emisor es m-
w,y el mayor número de secuencia de la ventana del
receptor será m+w-1.r
Para que no haya traslape, debemos tener un espacio
de números de secuencia
tan grande como para acomodar 2w números de
secuencia, luego k >= 2w.
 Capa de transporte

Servicios capa de transporte


 Transporte orientado
Multiplexión y Demultiplexión

a la conexión: TCP
 Transporte sin conexión: UDP
 Estructura de segmento TCP
 Principios de transferencia confiable de datos
 Transferencia confiable de datos
 Control de flujo
 Gestión de una conexión
 Principio de control de congestión
 Control de congestión TCP
TCP: Generalidades (RFCs:793,1122,1323,2018,2581)
Estructura de un segmento TCP
# de sec. Y ACKs en TCP
# de sec. Y ACK en TCP
Round Trip Time y Timeout en TCP
Round Trip Time y Timeout en TCP
Ejemplo de estimación de RTT:
Round Trip Time y Timeout en TCP
 Capa de transporte

 Servicios capa de transporte  Transporte orientado a la

 Multiplexión y Demultiplexión conexión: TCP
 Transporte sin conexión: UDP  Estructura de segmento TCP
Principios de transferencia confiable de datos
 Transferencia


confiable de datos
 Control de flujo
 Gestión de una conexión
 Principio de control de congestión
 Control de congestión TCP
Transferencia confiable de datos en TCP
Eventos del transmisor en TCP
TCP: escenarios de retransmisión
TCP: escenarios de retransmisión
Retransmisiones Rápidas
Retransmisión rápida TCP
 Capa de transporte

 Servicios capa de transporte  Transporte orientado a la

 Multiplexión y Demultiplexión conexión: TCP
 Transporte sin conexión: UDP  Estructura de segmento TCP
 Transferencia confiable de datos
 Principios de transferencia confiable de datos
 Control de flujo
 Gestión de una
conexión
 Principio de control de congestión
 Control de congestión TCP
TCP control de flujo
TCP control de flujo
Gestión de una conexión
Saludo de manos de 3 vías TCP
Saludos de mano de 3 vías: MEF
Cerrando conexión TCP
Cerrando conexión TCP
 Capa de transporte próxima clase

 Servicios capa de transporte  Transporte orientado a la conexión:

TCP
 Multiplexión y Demultiplexión
 Estructura de segmento TCP
 Transporte sin conexión: UDP
 Transferencia confiable de datos
 Principios de transferencia confiable de datos
 Control de flujo
 Gestión de una conexión

 Control de congestión
TCP
Control de Congestion
Estrategias para control de congestión
Control de congestión en TCP
Control de congestión TCP; incremento
aditivo decrecimiento multiplicativo (AIMD)
Partida lenta en TCP
TCP: detectando y reaccionando a una
perdida
Refinamiento
Otros