RC.G1.Tema3 Transporte PDF

Redes de Computadores
2018/2019
Departamento de
Tecnología Electrónica
Tema 3
La Capa de Transporte
Departamento de
Tema 3: La Capa de Transporte
Objetivos Contenido
• Entender los principios que hay 1. Servicios del nivel de
detrás de los servicios del nivel transporte
de transporte: 2. Multiplexión y demultiplexión
• Multiplexión/demultiplexión 3. Transporte sin conexión: UDP
• Transferencia de datos confiable
4. Principios de la transferencia
• Control de flujo fiable
• Conocer los protocolos de 5. Transporte orientado a la
transporte usados en Internet: conexión: TCP
• UDP: transporte no orientado a la • Estructura del segmento TCP
conexión • Transferencia de datos fiable
• TCP: transporte orientado a la • Control de flujo
conexión • Gestión de la conexión
Some material copyright 1996-2010

J.F Kurose and K.W. Ross, All Rights Reserved Transporte 1-3
Objetivos Contenido

Servicios del nivel de transporte
aplicación
transport.
red
• Proporciona comunicación lógica enlace
física
entre aplicaciones que se ejecutan
en hosts diferentes, ocultándoles
la complejidad de la red que une a
ambos host.
• Los protocolos de transporte se
ejecutan en los sistemas
terminales (hosts), no en los
routers. aplicación
• Las aplicaciones pueden escoger el transport.

red
protocolo de transporte que enlace
física
quieren usar, en función del tipo
de servicio que necesiten
• En Internet: TCP y UDP
Transporte 3-5
Servicios del nivel de transporte
• En el lado emisor (origen), el nivel de transporte acepta mensajes
(A_PDU) de las aplicaciones de red que recibe a través del T_SAP y con
ellas construye segmentos (T_PDU) que luego envía usando los servicios
del nivel de red.
• En el lado receptor (destino), el nivel de transporte recibe los segmentos
del nivel de red y pasa los datos de usuario que contienen (mensajes)
hacia el nivel de aplicación a través del T_SAP.
origen destino
Protocolo aplicación
aplicación aplicación
Protocolo transporte
transporte transporte
red Protocolo red
red
Protocolo red
red
enlace Protocolo enlace
enlace
Protocolo enlace
enlace
física Protocolo físico
física Protocolo físico
física
router Transporte 3-6

Nivel de Transporte frente a Nivel de Red
• Capa de red: proporciona un servicio de comunicación lógica

entre equipos terminales (hosts)
• Es un servicio similar al servicio de correo postal que permite enviar una
carta a una casa (domicilio).
• Capa de transporte: extiende el servicio de la capa de red para

proporcionar un servicio de comunicación lógica entre los
procesos de aplicación.
• Esto se conoce como multiplexión y demultiplexión de la capa de
transporte.
• Se consigue usando el servicio prestado por la capa de red, para, a partir
de él, construir un servicio “mejorado”.
Transporte 3-7
Protocolos de Transporte en Internet
aplicación
• TCP: Servicio de entrega de transport.
datos fiable y en orden red
enlace
• Control de flujo física
red
• Establecimiento de la conexión enlace
física
red
enlace
• UDP: Servicio de entrega de física
datos no fiable y sin garantía de
orden.
red
• Protocolo simple “sin florituras” enlace
física
• Servicios no disponibles: red
enlace
• Retardo garantizado física
red
• Ancho de banda garantizado enlace
aplicación
física
• Tanto TCP como UDP usan los red
enlace
transport.
red
servicios de IP física enlace
física
• Protocolo que suministra un
servicio de mejor esfuerzo
(“best-effort”).
Transporte 3-9
Objetivos Contenido

Multiplexión/demultiplexión
Multiplexión al enviar Demultiplexión al recibir
Recolectar datos de múltiples Entregar en el socket correcto el
sockets, crear los segmentos contenido de los segmentos
(T_PDU) añadiendo información (T_PDU) recibidos, gracias a la
de cabecera (T_PCI) que se usará información de la cabecera (T_PCI).
luego al demultiplexar.
= socket = proceso
aplicación P3 P1
P1 aplicación P2 P4 aplicación
transporte transporte transporte
red red red
enlace enlace enlace
física física física
host 1 host 2 host 3

Transporte 3-11
Cómo funciona la demultiplexión
32 bits
• El nivel de red recibe datagramas IP (R_PDU)
Nº puerto origen Nº puerto destino
• Cada R_PDU tiene una dirección IP origen y
una dirección IP destino en su cabecera
(R_PCI). Otros campos de
• Cada R_PDU encapsula en su interior un la cabecera (T_PCI)
segmento (T_PDU)1.
• El nivel de transporte recibe segmentos
(T_PDU) T_UD:
• Cada T_PDU tiene en su T_PCI Datos del nivel
un nº de puerto origen y de aplicación
un nº de puerto destino. (mensaje)
• Cada T_PDU encapsula datos del usuario, el
nivel de aplicación (T_UD).
• En el host destino las direcciones IP y los Formato de la T_PDU
números de puerto sirven para entregar la
T_UD de la T_PDU al socket adecuado. de TCP/UDP
1 Cierto si no hay fragmentación Transporte 3-12

Demultiplexión sin conexión (UDP)
• Al crear el socket UDP podemos proporcionar un número de
puerto local concreto o dejar que se use uno cualquiera que
esté libre:
DatagramSocket miSocket1 = new DatagramSocket(12534);
DatagramSocket miSocket2 = new DatagramSocket();
• Cuando el host origen prepara la T_IDU para enviarla por un
socket UDP, debe especificar (en la T_ICI):
(dirección IP destino, número de puerto destino)
• Cuando el protocolo UDP del host destino recibe la T_PDU:
• Comprueba el número de puerto destino en la cabecera (T_PCI).
• Dirige los datos de usuario (T_UD) de la T_PDU al socket UDP con ese
número de puerto.
• No se comprueba la dirección IP origen ni el nº de puerto
origen durante el proceso de demultiplexión (en UDP).
Transporte 3-13
Demultiplexión sin conexión (UDP)
Nº de puerto local. Obligatorio especificarlo si es un proceso servidor.
DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P1
P1
P3
PO: 6428 PO: 6428

PD: 9157 PD: 5775
PO: 9157 PO: 5775

cliente PD: 6428 PD: 6428 cliente
servidor
IP: A IP: C IP: B
La IP origen y el Puerto Origen permitirán a P3

identificar al proceso origen (P1 o P2) y devolverle PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
un mensaje.
Transporte 3-14
Demultiplexión orientada a la conexión (TCP)
• Una conexión TCP se identifica por una 4-tupla:
(Dir. IP local, Nº Puerto local, Dir. IP remota, Nº Puerto remoto)
• En el host destino se usan los 4 valores, (presentes en la
R_PCI y T_PCI) para hacer llegar los datos de usuario de la
T_PDU al socket TCP adecuado.
• Una aplicación servidora puede tener varias conexiones TCP
funcionando simultáneamente.
• Cada conexión se identifica por su propia 4-tupla.
• Un servidor web tiene una conexión TCP distinta para cada
cliente que se conecta.
• Con HTTP no persistente, cada petición del mismo cliente irá por una
conexión TCP diferente.
Transporte 3-15
Demultiplexión orientada a la conexión (TCP)
• Al crear el socket TCP…
• … en el servidor indicamos el número de puerto y se deja en modo escucha:
ServerSocket socketAcogida = new ServerSocket(6789);
• … en el cliente se proporciona el socket del servidor (IP/nombre, puerto) como
T_ICI y se establece la conexión con este (que debe estar en modo escucha).
Socket socketCliente = new Socket("hostnameservidor", 6789);
• en el servidor al recibir una solicitud de conexión por parte del cliente la acepta,
quedando esta identificada por socket cliente (IP cliente, puerto cliente) y socket
servidor (IP servidor, puerto servidor).
Socket socketConnection = welcomeSocket.accept();
• Cuando el protocolo TCP del host destino recibe la T_PDU comprueba
tanto el número de puerto origen como destino en la cabecera (T_PCI) así
como la dirección IP origen y destino recibida en la R_ICI y dirige los datos
de usuario (T_UD) de la T_PDU al proceso de aplicación correcto.
Transporte 3-16
Demultiplexión en TCP:
Servidor Web con varios procesos
P1 P4 P5 P6 P2 P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
PO: 9157 servidor PO: 9157 cliente

cliente
PD: 80 IP: C PD: 80 IP: B
IP: A
IP-O: A IP-O: B
IP-D: C IP-D: C No es problema que
dos procesos cliente
PO = Nº de Puerto Origen No es problema que usen la misma IP
PD = Nº de Puerto Destino dos procesos cliente origen
IP-O = Dir. IP Origen usen el mismo puerto
IP-D = Dir. IP Destino origen
Transporte 3-17
Demultiplexión en TCP:
Servidor Web multihilo (threaded)
P1 En lugar de un P4 P2 P1P3
proceso servidor
por cada socket, PO: 5775
hay un “hilo” por PD: 80
socket y un solo
proceso. IP-O: B
IP-D: C
PO: 9157 servidor PO: 9157

cliente cliente
PD: 80 IP: C PD: 80
IP: A IP: B
IP-O: A IP-O: B
IP-D: C IP-D: C
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen Transporte 3-18
IP-D = Dir. IP Destino
Objetivos Contenido

UDP: User Datagram Protocol [RFC 768]
• Es un protocolo de transporte de Internet muy simple, sin “florituras”.
• Ofrece un servicio de mejor esfuerzo, “best effort”, por lo que:
• Las T_PDU pueden “perderse” y no llegar a su destino.
• Si las T_PDU llegan desordenadas, los datos de usuario contenidos en
ellas se entregarían desordenados al Nivel de Aplicación.
• Sin conexión:
• No hay una fase acuerdo previa entre el emisor y el receptor UDP.
• Cada T_PDU se trata de forma independiente a las demás.
¿Por qué existe UDP?

• No hay un establecimiento de la conexión (que añadiría un retardo).
• Es simple de implementar: no hay que mantener el estado de la
conexión ni en el transmisor ni en el receptor.
• La cabecera (T_PCI) es más simple y pequeña.
Transporte 3-20
UDP: más… 32 bits
Nº puerto origen Nº puerto destino
T_PCI
• A menudo usado por longitud checksum
aplicaciones de
streaming multimedia T_UD
• Tolerantes a pérdidas Datos del nivel
• Sensibles al ancho de de aplicación
banda (mensaje)
• Otros usos de UDP
• DNS
• SNMP
• ¿Transferencia fiable Formato de la T_PDU
sobre UDP? Es posible si de UDP
añadimos fiabilidad a la
La cabecera (T_PCI) solo tiene 4 campos.
capa de aplicación La longitud es en bytes y es la de la T_PDU
• ¡ Recuperación de completa, con cabecera.
errores específica de la
aplicación !
Transporte 3-21
Checksum (suma de comprobación) UDP
Objetivo: detectar “errores” (e.g., bits “cambiados”) en una T_PDU transmitida.
El emisor: El receptor:
• Trata la T_PDU como una • Calcula el checksum, otra vez, de
secuencia de enteros de 16 bits. la misma forma que lo hizo el
• Simplificando un poco, podemos emisor, sobre la T_PDU recibida.
decir que suma todos los enteros • Comprueba si el checksum
de 16 bits que componen la calculado es idéntico al valor del
T_PDU y luego le calcula el campo checksum de la T_PDU
complemento a 1. recibida.
• Coloca el valor calculado en el • NO  ¡Error detectado!
campo checksum de la cabecera • SÍ  No se detecta error
(T_PCI). alguno, pero… ¿Puede que
haya un error? Más sobre esto
próximamente…
Transporte 3-22
Ejemplo de cálculo de checksum
Nota: al ir sumando los números de 16 bits que forman la

T_PDU, el acarreo que se vaya produciendo hay que volverlo a
sumar.
• Ejemplo de cómo sumar sólo dos enteros de 16 bit.
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
Acarreo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1
Suma (con acarreo) 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Transporte 3-23
Objetivos Contenido

Principios de la transferencia fiable
La T.F. es importante en capas de aplicación, transporte y enlace de datos.
¡Está en la lista de los 10 temas más importantes sobre redes!
¿Por qué es necesaria la T.F.? ¿Cómo se detectan estos problemas?

• PDUs erróneas • PDUs erróneas
En las transmisiones sobre los enlaces Usando mecanismos de comprobación
se producen interferencias que alteran de errores (incluidos en la PCI).
los bits transmitidos. • Algoritmos similares al del checksum.
• PDUs perdidas • Los algoritmos más complejos y fiables
se utilizan en el nivel de enlace.
Las colas de paquetes, cuando están • PDUs perdidas y duplicadas
saturadas, empiezan a descartar los
paquetes entrantes. Añadiendo “algo” a la cabecera (PCI) de
• PDUs duplicadas cada PDU que permita distinguirla del
resto de PDUs enviadas.
Determinados problemas en la
comunicación provocan que se
retransmitan PDUs que ya han sido ¿Cómo se solucionan estos problemas?
recibidas. Retransmisiones
El transmisor vuelve a transmitir una
copia exacta de la PDU que tuvo
problemas.
Transporte 3-25
Caso general de comunicación entre entidades pares de un mismo nivel:
• Al comunicarse con su entidad par, una entidad le envía a la otra una PDU formada
por cabecera (PCI) y, en general, datos de usuario (UD).
• Las cabeceras (PCI) contienen información de control del protocolo.
• En general, ambas entidades transmiten y reciben datos de usuario.
• Transferencia bidireccional de datos de usuario entre entidades pares.
Simplificación del caso general de comunicación entre entidades pares:

• Facilita la explicación de los principios de transferencia fiable.
• Supondremos una transferencia unidireccional de datos de usuario.
• A una de las entidades pares del nivel la llamaremos transmisor (Tx).
• A la otra entidad par la llamaremos receptor (Rx).
• El Tx transmite PDUs con PCI y UD (los UD vienen de su nivel superior).
• El Rx recibe PDUs con PCI y UD (los UD los pasará a su nivel superior).
• El Rx transmite PDUs que solo tendrán PCI (sin UD, solo info. de control).
• El Tx recibe PDUs que sólo tendrán PCI.
• Transferencia bidireccional de información de control del protocolo.
Transporte 3-26
¿Qué tipos de PDU se usan?
• PDU de datos
• Sólo las envía el Tx
• Contiene datos de usuario (UD)
• Contiene información de control del protocolo (en la PCI)
• PDU de control
• Sólo las envía el Rx
• No contiene datos de usuario (UD)
• Solo contiene información de control del protocolo (en la PCI)
Nota
Es un error pensar que el Tx no envía información de control porque solo envía PDUs de datos.
Las PDUs de datos también llevan información de control.
Transporte 3-27
¿Qué contiene la cabecera (PCI)?
• La PCI de una PDU de datos contiene información que permite:
• Que el Rx detecte si esa PDU de datos tiene errores.
• Identificar esa PDU de datos y distinguirla de otras PDU enviadas por el Tx.
• La PCI de una PDU de control contiene información que permite:
• Que el Tx detecte si esa PDU de control tiene errores.
• Que el Rx identifique una determinada PDU de datos, e informar que dicha
PDU de datos
• ha sido recibida correctamente por el Rx.
• ACK, acknowledgement, acuse de recibo.
• no ha sido recibida correctamente por el Rx.
• NAK, NACK, negative acknowledgement, acuse de recibo negativo.
Nota
La información de la PCI que sirve para identificar una
determinada PDU de datos se llama número de secuencia.
Transporte 3-28
Funcionamiento básico Tx: Funcionamiento básico Rx:
• La entidad Tx de un determinado • Al recibir una PDU de datos la
nivel, construye una PDU de datos entidad Rx de un determinado
con UD y PCI y la transmite al Rx. nivel:
• Ahora, el Tx espera durante un • Si la PDU de datos llegó
tiempo, conocido como time_out, correctamente, es obligatorio que
el Rx le mande al TX una PDU de
a recibir una PDU de control del control de tipo ACK, avisándole.
Rx que le indique
• Si la PDU de datos llegó con
• con un ACK que la PDU de datos errores, es opcional que el Rx le
llego bien al Rx. mande al TX una PDU de control
• Tx no hace nada más. de tipo NACK, avisándole.
• con un NACK, que la PDU de
datos llegó con errores al Rx.
• Tx retransmite la PDU. P: ¿Cuánto debe valer, como
• Si expira el time_out antes de que mínimo, el time_out?
llegue la PDU de control del Rx, P: ¿Entrega siempre el Rx al nivel
entonces superior los UD de una PDU de
• Tx retransmite la PDU. datos que llega correctamente?
Transporte 3-29
Ejemplo 1 PCI
• Transmisor envía sólo una PDU con UD y no envía
la siguiente hasta tener éxito en la transmisión.
dtransPDU
• Receptor sólo envía PDU de control ACK.
dtransack
Time_out
PDU perdida
Tiempo
Time_out
X
PDU errónea
Transporte 3-30
Tx Rx Tx Con errores Rx
Sin errores
Ejemplo 2
• Idem ejemplo 1.
• Receptor también envía PDU de control NACK. X
• Sin errores.
• Mismo comportamiento anterior
tiempo
Time_out
Tx Rx
Con errores
Transporte 3-31
• A este mecanismo de funcionamiento de un nivel para garantizar
la transferencia fiable se le conoce como Protocolo de parada y
espera
• Es poco eficiente
• El Tx se debe parar y esperar a recibir el ACK antes de poder enviar la
siguiente PDU.
• ¿Se puede medir la eficiencia?
• Para simplificar, vamos a suponer que
• Tx siempre tiene una PDU lista para transmitir,
• no se producen errores,
• cada PDU tiene L bytes de UD y 0 bytes de PCI, y
• dtransack = 0.
• Utilización del transmisor (o canal)
• Utransmisor = fracción de tiempo que el transmisor (o canal) está ocupado
transmitiendo bits de la PDU.
Transporte 3-32
Eficiencia del protocolo parada y espera
Recuerda
dtrans = L/R
Tx Rx
Primer bit PDU enviado, t = 0
Último bit PDU enviado, t = L / R
Primer bit PDU recibido

RTT Último bit PDU recibido, enviar ACK
Recibido ACK, t = RTT + L / R

Enviar próxima PDU
U L/R
transmisor =
RTT + L / R
Transporte 3-33
Eficiencia del protocolo parada y espera
• El protocolo funciona, pero su eficiencia es mala
• Ejemplo: enlace de 1 Gbps, 30 ms de RTT, PDU 1KByte
L/ R 0,008
U transmisor    0,00027
RTT  L / R 30,008
L 8kb / pdu
d trans   9
 8s
R 10 b / s
• 1 PDU de 1KByte cada 30,008 ms  33,3kByte/s tasa de
transferencia efectiva en un enlace de 1 Gbps
• ¡El Protocolo limita el uso de los recursos físicos!
• ¿Se puede mejorar?
Transporte 3-34
Protocolos con Pipeline
• Con Pipeline: El Tx puede tener múltiples PDUs en tránsito (“en
vuelo”) pendientes de ACK, mejorando mucho la eficiencia.
• Los números de secuencia utilizados en la PCI deben tener un rango
suficiente para que sirva para distinguir todas las PDUs en tránsito.
• Se requieren buffers en el Tx y, a veces, en Rx.
PDU PDU
ACK
Parada y espera Pipeline
NOTA: Profundizaremos en este concepto al abordar TCP

Transporte 3-35
El “pipeline” mejora mucho la eficiencia
Tx Rx
Envío bit 1 de 1ª PDU, t = 0
Envío último bit de PDU, t = L / R
Llega primer bit de 1ª PDU

RTT Llega último bit 1ª PDU, envío ACK
Llega último bit 2ª PDU, envío ACK
Llega último 3ª PDU, envío ACK
ACK recibido, envío siguiente PDU,
la 4ª, t = RTT + L / R
Tener hasta 3 PDUs “en
vuelo” multiplica la
eficiencia por un factor de 3
3*L/R 0,024
U = = = 0,0008 μs
transmisor 30,008
RTT + L / R
Transporte 3-36
Servicio de transferencia fiable
• ¿Cómo proporciona el nivel de transporte un servicio de
transferencia fiable al nivel de aplicación?
Transporte 3-37
• ¿Cómo proporciona el nivel de transporte un servicio de transferencia
fiable (“reliable”) al nivel de aplicación?
• El nivel de transporte tiene debajo el nivel de red, que le proporciona un
servicio de transferencia no fiable (“unreliable”).
Transporte 3-38
• El nivel de transporte debe implementar un protocolo de transferencia
fiable “reliable data transfer (rdt) protocol”.
• Las características concretas del canal no fiable condicionarán la

complejidad del protocolo rdt. Vamos a ir “experimentando” con distintos
tipos de canales no fiables. Transporte 3-39
Servicio de transferencia fiable: Empezando…
rdt_send(): llamado desde el nivel superior, deliver_data(): llamado por rdt para
(p.e., por la Aplic.). Nos pasa los datos que pasar los datos al nivel superior (lado
deberemos suministrar al receptor del nivel del receptor).
superior.
Lado del Lado del

emisor Receptor
(Tx) (Rx)
udt_send(): llamado por rdt para rdt_rcv(): llamado desde el nivel inferior
enviar, por el canal no fiable, una PDU. cuando tiene disponible una PDU que ha
llegado lado del receptor por el canal no fiable.
udt = Unreliable Data Transfer (Trasferencia de datos no fiable) Transporte 3-40

Servicio de transferencia fiable: Empezando…
• Implementaremos de forma incremental el lado emisor y el lado receptor
del protocolo rdt.
• Como antes, consideraremos, por simplicidad, transferencia de datos de
usuario unidireccional, de emisor a receptor (de Tx a Rx).
• ¡OJO! La información de control fluye en ambas direcciones.
• Usaremos máquinas de estados finitos (FSM) para especificar el emisor y el
receptor.
• El protocolo rdt realmente es aplicable a cualquier nivel que deba
proporcionar fiabilidad, y no sólo al Nivel de Transporte.
evento que causa cambio de estado

acciones tomadas al cambiar de estado
estado: estando en un
estado estado
cierto “estado” el
1 evento 2
próximo estado
depende únicamente acciones
del próximo evento.
Transporte 3-41
rdt 1.0: transferencia fiable sobre canal fiable
• Es el caso más sencillo. No es algo real.
• El canal del nivel inferior es perfectamente fiable.
• No hay errores de bit (bits alterados).
• No hay pérdida de PDUs.
• Hay una FSM para el emisor y otra para el receptor.
• Emisor envía PDUs por el canal subyacente (al nivel inferior).
• El receptor recibe PDUs del canal subyacente (del nivel inferior).
Emisor (Tx) Receptor (Rx)

SOLICITUD DEL NIVEL SUPERIOR INDICACIÓN DEL NIVEL INFERIOR
Espera rdt_send(data) Espera rdt_rcv(packet)

llamada llamada
desde packet = make_pkt(data) desde extract (packet,data)
arriba udt_send(packet) abajo deliver_data(data)
SOLICITUD HACIA EL NIVEL INFERIOR INDICACIÓN HACIA EL NIVEL SUPERIOR
Transporte 3-42
Nota: En las máquinas de estados a las PDUs las llama paquetes (“packets”).
rdt 2.0: Canal con errores de bit
• El canal subyacente puede alterar los bits de un paquete
• Necesitaremos un checksum para detectar errores de bit
• Usaremos algunos de los principios vistos anteriormente para
conseguir una transferencia de datos fiable:
• acknowledgements (ACKs): el receptor explícitamente le dice al
emisor que el paquete se recibió correctamente.
• negative acknowledgements (NAKs): el receptor explícitamente le
dice al emisor que el paquete tenía errores, por lo que quiere
que se lo retransmitan.
• Nuevos mecanismos en rdt 2.0 (mejorando rdt 1.0):
• Detección de errores
• El receptor proporciona “realimentación” al emisor con PDUs de
control (ACK, NAK).
Transporte 3-43
rdt2.0: Máquina de estados finitos (FSM)
rdt_send(data) Máquina de
sndpkt = make_pkt(data, checksum) estados
udt_send(sndpkt)
rdt_rcv(rcvpkt) && del receptor (Rx)
Espera isNAK(rcvpkt)
llamada Espera ACK rdt_rcv(rcvpkt) &&
desde o NAK udt_send(sndpkt) corrupt(rcvpkt)
arriba
udt_send(NAK)
Ambos, Tx y Rx, usan
rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send() para Espera
L enviar sus PDUs por llamada
Máquina de el canal no fiable desde
implementado por el abajo
estados nivel inferior.
del emisor rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
(Tx)
extract(rcvpkt,data)
Ambos, Tx y Rx, esperan el evento deliver_data(data)
rdt_rcv() que les entrega una PDU que udt_send(ACK)
llega desde el nivel inferior (no fiable).
Transporte 3-44
rdt2.0: Operación en escenario sin errores
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Espera rdt_rcv(rcvpkt) &&
llamada
ACK o udt_send(sndpkt) corrupt(rcvpkt)
desde
NAK
arriba
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt) Espera

L llamada
desde
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
Transporte 3-45
rdt2.0: Operación en escenario con errores
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Espera rdt_rcv(rcvpkt) &&
llamada
ACK o udt_send(sndpkt) corrupt(rcvpkt)
desde
NAK
arriba
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt) Espera

L llamada
desde
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
Transporte 3-46
rdt 2.0 tiene un fallo grave…
¿Qué ocurre si una PDU de control (ACK o NAK) se corrompe
(tiene bits erróneos)?
• ¡El Tx no sabe si ha recibido un ACK o un NAK, pues la PDU tiene errores!
• ¡El Tx no sabe cómo llegó la PDU de datos al Rx!
• No es válido, simplemente, retransmitir la última PDU pues… ¡El Rx podría
recibirla dos veces y no darse cuenta de que es la misma PDU!
Para evitar PDUs duplicadas:
• El Tx retransmite la PDU de datos si la PDU de control recibida (ACK o NAK)
está corrupta (tiene errores).
• El Tx añade un número de secuencia en la PCI de cada PDU.
• El Rx es capaz de detectar PDUs duplicadas, gracias al número de
secuencia, por lo que las descarta y no pasa sus datos al nivel superior.
Parada y espera
El emisor envía una PDU y espera la respuesta del receptor.
Transporte 3-47
rdt2.1: Máquina de estados del EMISOR con el problema de los
ACK/NAKs corruptos solucionado.
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from
NAK 1 above
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) || rdt_send(data)
isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt) udt_send(sndpkt)
Transporte 3-48
rdt2.1: Máquina de estados del RECEPTOR con el problema de
los ACK/NAKs corruptos solucionado.
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
Transporte 3-49
rdt2.1: Discusión
Emisor (Tx) Receptor (Rx)

• Añade número de secuencia • Debe comprobar si la PDU
a las PDUs recibida es un duplicado.
• Basta con usar dos números • El estado indica si es 0 ó 1 el
número de secuencia
de secuencia distintos (O y esperado.
1) ¿Por qué?
• El Rx no puede saber si el
• Debe comprobar si la PDU último ACK/NAK que envió
de control ACK/NAK está llegó corrupto o no al Tx.
corrupta.
• Se duplican los estados
• El estado “recuerda” si la PDU
“actual” tiene número de
secuencia 0 ó 1.
Transporte 3-50
rdt2.2: un protocolo sin NAKs
• La misma funcionalidad que el rdt2.1, usando solo
ACKs.
• En lugar de enviar un NAK, el Rx reenviará el ACK de la
última PDU que recibió correctamente.
• Con esta estrategia, el Rx debe incluir explícitamente en la
PCI de todas las PDUs de control ACK el número de
secuencia de la PDU de datos de la que se quiere dar acuse
de recibo positivo.
• El Tx, al recibir un ACK duplicado (ya recibido) realiza
la misma acción que al recibir un NAK: retransmitir la
PDU actual (que aún no ha sido reconocida).
Transporte 3-51
rdt2.2: Trozos de las máquinas de estados
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
Trozo
máquina Tx rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for Trozo
0 from
udt_send(sndpkt) below
máquina Rx

&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
Transporte 3-52
rdt3.0: canal con errores y pérdidas
Nuevo escenario:
• El canal no fiable proporcionado por el nivel inferior puede, además de
corromper las PDUs, perderlas por completo (PDUs de datos y de control).
• El checksum, números de secuencia, ACKs, y retransmisiones son de
gran ayuda, pero no bastan.
Nuevo enfoque:
• El Tx espera un tiempo “razonable” (time_out) a que llegue el ACK.
• Si en ese tiempo no ha llegado el ACK de una PDU de datos, el Tx la
retransmite.
• Si la PDU de datos (o de control) no se ha perdido, sino que solo se ha
retrasado:
• La retransmisión originará un duplicado, pero gracias a los números de secuencia eso
no es problema.
• Como antes, el Rx debe incluir en la PCI del ACK el número de secuencia de
la PDU de datos que se está reconociendo.
• Requiere el uso de temporizadores para detectar si expira el time_out.
Transporte 3-53
rdt3.0 Emisor (Tx)
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer L
L Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Ejercicio
Transporte 3-54
Diseñe la máquina de estados del receptor del protocolo rdt3.0.
rdt3.0 en acción en diversas situaciones
Transporte 3-55
rdt3.0 en acción en diversas situaciones
Transporte 3-56
Objetivos Contenido

TCP: Visión general RFCs: 793, 1122, 1323, 2018, 2581
• Punto a punto:
• Un emisor, un receptor (no multidifusión)
• Flujo de bytes, fiable y ordenado:
• Sin “frontera” entre los mensajes (A_PDUs)
• Usa “pipeline”:
• El control de flujo de TCP fija el tamaño de la ventana (máx. nº datos “en vuelo”)
• Buffers de Btx y Brx
application application
writes data reads data
socket socket
socket
door socket
door
TCP TCP
send buffer receive buffer
segment
• Servicio Full-Duplex:
• Por una conexión fluyen datos bidireccionalmente.
• MSS: Tamaño Máximo del Segmento (de las UD).
• Orientado a conexión:
• Acuerdo previo al envío de datos. El emisor toma la iniciativa enviando un mensaje de
control, que el receptor debe estar esperando.
• Control de flujo:
• El emisor no debe desbordar al receptor.
Transporte 3-58
Estructura del segmento TCP (T_PDU)
ACK: indica que el nº
de ACK es válido 32 bits
URG: datos urgentes
Nº puerto Orig. Nº puerto dest. Cuentan los
(no se suele usar) bytes de
Número de secuencia datos, no las
Longitud Cabecera
Número de ACK PDUs
(T_PCI) en palabras de 32
Long. no
bits (4 bytes) Cabe. usado
UAP R S F Ventana de Rx
T_PCI
checksum Punt. Datos Urg.
PSH: “empuja” datos ahora
(no se suele usar) Nº de bytes
Opciones (long. variable) que está
dispuesto a
RST, SYN, FIN: aceptar el
Comandos para Rx
establecer la conexión y Datos del nivel de
terminarla aplicación
(longitud variable) T_UD
Internet
checksum
(como en UDP) Transporte 3-59
Nº de secuencia y de ACK en TCP(I)
Nº de secuencia:
• Es el número asignado, dentro del flujo de bytes, al primer byte de los
datos del segmento TCP que se envía a la otra entidad par.
• El valor inicial de este campo lo decide de manera aleatoria cada entidad
par al iniciar la conexión.
• Se va incrementado a medida que se envían segmentos que contienen UD.
Nº de ACK:
• Sirve para indicar el nº de secuencia del byte que se espera recibir a
continuación por parte de la otra entidad par.
• Todos los bytes anteriores los da por reconocidos (ACK acumulativo).
P: ¿Cómo trata el receptor los segmentos desordenados?

• R: La especificación de TCP lo deja a criterio del implementador.
Transporte 3-60
Nº de secuencia y de ACK en TCP(II)
Escenario simple
Entidad TCP Host A #sec actual en A = 42 #sec actual en B = 79 Entidad TCP Host B
Btx contiene “DIEZ BYTES” Btx vacío
Btx vacío
42+10 Brx contiene “DIEZ BYTES”

Btx contiene “TRECE BYTES”
79+13
Brx contiene “TRECE BYTES” No lleva
datos
Notas
• El gráfico muestra intercambio de TCP_PDUs (segmentos). El buffer de transmisión (Btx) tiempo
contiene las UD solicitadas por el nivel de aplicación a través del T_SAP. El bufffer de
recepción (Brx) se vaciará cuando a través del T_SAP lo solicite el nivel de aplicación
• TCP envía el ACK “superpuesto” en su PDU de datos (“piggybacking”), como aparece en los Transporte
dos primeros segmentos que ambos host han enviado. 3-61
TCP estima el RTT para saber qué valor
usar de time_out
¿Qué valor debe usar TCP como time_out?
• Debe ser algo mayor que el RTT
• Pero el RTT cambia a lo largo del tiempo…
• Un valor muy pequeño produce un time_out prematuro y retransmisiones
innecesarias.
• Un valor demasiado grande hace que se reaccione muy tarde ante la
pérdida de un segmento.
¿Cómo estimar el RTT?
• RTTmuestra es el tiempo (real) medido desde que se transmite un
segmento hasta que llega el ACK.
• ignorando retransmisiones…
• RTTmuestra puede ser muy variable… Queremos una estimación del RTT
más “suave” (menos “cambiante”).
• RTTestimado se calcula como la media de los valores de RTTmuestra más recientes.
Transporte 3-62
usar de time_out
RTTestimado = (1-)* RTTestimado +  * RTTmuestreado
• Media móvil exponencialmente ponderada.

• La influencia de una muestra anterior sobre el nuevo valor estimado
decrece de una forma exponencialmente rápida.
• Se suele usar, típicamente:  = 0.125
Transporte 3-63
usar de time_out (ejemplo)
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
250
RTT (milliseconds)
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
SampleRTT Estimated RTT

Transporte 3-64
TCP estima el RTT para saber que valor
usar de time_out
¿Cómo fijamos el time_out a partir del RTT?
• Time_out = RTTestimado + un “margen de seguridad”
• Mucha desviación en RTTestimado  usar un margen mayor
• Una primera estimación de cuánto se desvía RTTmuestra del valor
RTTestimado sería:
RTTdesv = (1-)*RTTdesv + * |RTTmuestra-RTTestimado|

(típicamente:  = 0.25)
Así, el time_out podría calcularse como:

Time_out = RTTestimado + 4*RTTdesv
Transporte 3-65
Objetivos Contenido

TCP: Transferencia de datos fiable
• TCP crea un servicio de transferencia de datos fiable encima del
servicio de transferencia no fiable que le proporciona IP.
• TCP usa la técnica del “pipeline”, manteniendo varios
segmentos “en vuelo”.
• TCP usa ACKs acumulativos, que reconocen un dato y todos los
anteriores.
• TCP usa, por simplicidad, un único temporizador para todas las
T_PDUs de una conexión (lo asocia a los datos más antiguos).
• TCP debe retransmitir los datos cuando:
• Se produce un time_out
• Llega un ACK duplicado
• Inicialmente consideraremos un emisor TCP simplificado:
• Ignora ACKs duplicados
• Sin control de flujo
Transporte 3-67
Eventos que trata el emisor TCP (simplificado)
Llegan datos de la aplicación (nivel superior):
• Crea un segmento con un nº de secuencia adecuado y se lo pasa al nivel
inferior (IP).
• El nº de secuencia del segmento es el nº de secuencia, dentro del flujo de
bytes, del primer byte de datos del segmento.
• Arranca el temporizador, si no estaba ya corriendo (estaría en marcha si
había datos anteriores sin reconocer).
• El temporizador se programa para expirar al cabo de Time_out segundos.
Expira el temporizador (time_out):
• Retransmite el segmento que ha provocado el time_out.
• Rearranca el temporizador.
Llega un ACK…
• …correspondiente a datos de los cuales no se había recibido aún un ACK:
• Actualiza el indicador que apunta a los “datos más antiguos pendientes de ACK”
y detiene el temporizador.
• Arranca el temporizador solo si aún hay “en vuelo” datos pendientes de ACK.
Transporte 3-68
Emisor TCP (simplificado)
SigNumSec = NumeroSecuenciaInicial Todos los bytes de datos con nº de secuencia menor
BaseEmision = NumeroSecuenciaInicial a BaseEmision están reconocidos acumulativamente.
while ( true ) { Los de nº mayor o igual están pendientes de ser
switch( evento ) reconocidos.
evento: datos recibidos de la aplicación /* Llegan datos de la capa superior*/

crear segmento TCP con datos y número de secuencia SigNumSec
if ( el temporizador está parado )
iniciar el temporizador
pasar el segmento a IP /* La capa inferior, no fiable, hará llegar el segmento al Rx */
SigNumSec = SigNumSec + longitud(datos)
SigNumSec apunta a datos “no enviados”.
evento: el temporizador expira /* Se ha producido un time_out */
retransmitir el segmento pendiente de ACK con menor número de secuencia
iniciar el temporizador El receptor nos envía acuse de recibo
de todos los datos con nº de
evento: recibido ACK con campo nº de ACK valiendo y secuencia menores que y
if ( y > BaseEmision ) { /* Si están reconociendo datos no reconocidos anteriormente */
BaseEmision = y /* Actualizar indicador datos reconocidos/pendientes de ACK */
detener el temporizador
if ( SigNumSec > BaseEmision ) /* Si hay datos “en vuelo” pendientes de ACK */
}
} /* fin del bucle infinito */ Transporte 3-69
TCP: escenarios con retransmisiones (I)
Host A Host B Host A Host B
Time_out Sec=92
Time_out Sec=92
perdido
Expira Expira
BaseEmision=100
BaseEmision=120
BaseEmision tiempo BaseEmision=120 tiempo

= 100
Escenario
Escenario time_out
ACK perdido prematuro
Llegan duplicados pero TCP sólo sube uno al nivel de Aplicación.
Transporte 3-70
TCP: escenarios con retransmisiones (II)
Time_out Sec=92 Host A Host B
Time_out Sec=92
perdido
BaseEmision=120
Reconoce el primer
segmento y el segundo
El temporizador con la duración

“recomendada” habría expirado antes de Escenario
la llegada del ACK=120. ACK tiempo
No expira
El transmisor puede usar en ciertas acumulativo
ocasiones un time_out que dure más de
lo recomendado lo cual hace que sea fácil
que se produzcan ACKs acumulativos.
Transporte 3-71
TCP: Generación del ACK [RFC 1122, RFC 2581]
Evento en el Receptor TCP Acción del receptor TCP
Llegada de segmento en orden, con el nº ACK retardado. Esperar hasta un
de secuencia esperado. Todos los datos máximo de 500ms a que llegue el
hasta el nº de secuencia esperado ya han siguiente segmento en orden.
sido reconocidos. Si no llegase, enviar ACK.
Llegada de segmento en orden, con el nº Enviar inmediatamente un ACK

de secuencia esperado. Hay un segmento acumulativo que reconozca ambos
anterior pendiente de reconocer. segmentos ordenados.
Llegada de segmento fuera de orden, con Enviar inmediatamente un ACK

nº de secuencia mayor del esperado. Se duplicado, indicando el nº de
detecta un “hueco” en los datos recibidos. secuencia del byte que se espera
recibir.
Llegada de un segmento que “rellena” Enviar inmediatamente un ACK para

total o parcialmente el “hueco” y que tiene el segmento recibido o acumulativo
el nº de secuencia esperado (“rellena” el dependiendo de si receptor almacena
“hueco” por su comienzo o límite inferior). los UD de los segmentos fuera de
orden.
Transporte 3-72
TCP: Retransmisión rápida
• El time_out tiene una duración relativamente larga:
• Pasa mucho tiempo hasta que se retransmite un segmento perdido.
• Detectar segmentos perdidos gracias a los ACKs duplicados.
• El emisor a menudo envía muchos segmentos seguidos, muy
“pegados”.
• Si se pierde un segmento, muy probablemente lleguen muchos ACKs
duplicados.
• Si el emisor recibe tres ACKs duplicados para los mismos datos,
supone que se ha perdido el segmento cuyos datos siguen a los
datos que están siendo reconocidos:
• Retransmisión rápida: reenviar ese segmento que se supone perdido
aunque su temporizador aún no ha expirado.
Nota
TCP no usa NAKs, por lo que el receptor no puede avisar de que le falta un segmento.
Transporte 3-73
Host A Host B La llegada de estos tres
segmentos fuera de orden ha
hecho que el receptor envíe
inmediatamente un ACK
duplicado para cada uno de
ellos, reconociendo los datos
del primer segmento.
El emisor al ver que, por tres

veces, le llega un ACK
Time_out 2º segmento
duplicado de los datos del

primer segmento, supone que
el segundo segmento se ha
perdido y lo reenvía rápido,
antes de que expire su
temporizador.
tiempo
No expira
Transporte 3-74
Este es el evento de recepción de ACK en el emisor TCP simplificado.
evento: recibido ACK con campo nº de ACK valiendo y

if ( y > BaseEmision ) { /* Si están reconociendo datos no reconocidos anteriormente */
BaseEmision = y /* Actualizar indicador datos reconocidos/pendientes de ACK */
detener el temporizador
if ( SigNumSec > BaseEmision ) /* Si hay datos “en vuelo” pendientes de ACK */
}
else { /* Se trata de un ACK duplicado de un segmento ya reconocido */
incrementar el contador de ACKs duplicados de y
if (contador de ACKs duplicados de y = 3 ) {
retransmitir segmento cuyo número de secuencia es y /* retransmisión rápida*/
}
}
Le hemos añadido la parte del “else” para que el emisor TCP simplificado no sea tan
“simple” y sepa reaccionar ante tres ACKs duplicados, llevando a cabo la retransmisión
rápida del segmento no reconocido.
Transporte 3-75
Objetivos Contenido

Control de flujo en TCP Control de flujo
Conseguir que el emisor no
• El lado receptor de una conexión TCP tiene un desborde el buffer del
buffer de recepción donde se acumulan los receptor por culpa de
datos que llegan desde el nivel inferior. transmitir demasiados datos,
demasiado rápido.
VentanaRecepcion Va variando su tamaño
Espacio libre Datos en el Buffer TCP, Hacia el

Datos
en el Buffer esperando ser leídos por proceso de
de IP
TCP la aplicación aplicación
Puede que el proceso de

Tamaño fijo BufferRecepcion aplicación sea muy lento
leyendo del buffer de
• Servicio de ajuste de velocidades: recepción TCP.
Hace que la tasa de transmisión del otro extremo se ajuste al ritmo al que la
aplicación receptora “consume” los datos que llegan.
Transporte 3-77
Control de flujo en TCP (funcionamiento)

Datos
de IP
Tamaño fijo BufferRecepcion
• Supondremos que el receptor TCP descarta los segmentos que recibe

desordenados, por lo que esos no ocupan espacio en el buffer de Rx.
• Espacio libre en el buffer de recepción:
VentanaRecepcion = BufferRecepcion – (UltimoByteRecibido – UltimoByteLeido)
Esta diferencia indica lo que hay “ocupado”

Transporte 3-78

Datos
de IP
Tamaño fijo BufferRecepcion
• El receptor informa al emisor del espacio libre en el buffer gracias al

campo VentanaRecepcion presente en la cabecera (T_PCI) de los
segmentos (T_PDU) que envía.
• El emisor limita el número de datos “en vuelo” pendientes de ACK de
forma que quepan en la VentanaRecepcion.
• Esto garantiza que el BufferRecepcion nunca se desborda.
Transporte 3-79
Nº puerto Orig. Nº puerto Dest.
• El valor del campo
VentanaRecepcion de la Número de secuencia
T_PCI está relacionado con
el valor del campo Número de ACK
T_PCI
NºdeACK de la T_PCI. Long. no
Cabe. usado
UAP R S F Ventana de Rx
• Cuando el emisor recibe un checksum Punt. Datos Urg.
segmento, observa el valor
del campo NºdeACK y el
valor del campo Opciones (long. variable)
VentanaRecepcion para
conocer el rango de Datos del nivel de
T_UD
números de secuencia
correspondientes a los aplicación
datos que está autorizado (longitud variable)
a tener “en vuelo”,
pendientes de
confirmación: Estructura del segmento
(T_PDU)
Desde NºdeACK hasta (NºdeACK + VentanaRecepcion – 1)
Transporte 3-80
Objetivos Contenido

Gestión de la conexión en TCP: Establecimiento
Recuerde: El cliente y el servidor TCP establecen la conexión antes de
intercambiar segmentos que transporten datos de usuario.
Durante la fase de establecimiento de la conexión, ambos deben inicializar las
variables de TCP:
• Números de secuencia a usar.
• Buffers de transmisión y recepción (ambos en cliente y servidor).
• Información de control de flujo (ej: VentanaRecepcion).
• etc.
• Cliente: Es el que toma la iniciativa de establecer la conexión

Socket socketCliente = new Socket(“NombreHost”,NumPuerto);
• Servidor: Estaba “a la escucha” y es contactado por el cliente

ServerSocket socketAcogida = new ServerSocket(NumPuerto);
while(true){
Socket socketConexion = socketAcogida.accept();
Transporte 3-82
Cliente Proceso de acuerdo en tres fases Servidor
new socket
X.accept()
Servidor
puede
Enviar
datos
Conexión
establecida
Cliente
puede
Enviar
Nota
datos
En el flujo de TCP_PDUs (segmentos) si un determinado flag está
tiempo activo, se indica en el etiquetado, menos el del ACK que está tiempo
implícito cuando el campo ACK tiene valor. Transporte 3-83
Proceso de acuerdo en tres fases:
Paso 1: El host cliente inicializa todas las variables de TCP (buffers, número de
secuencia inicial, etc.) y envía al servidor un segmento SYN que:
• No transporta datos.
• Especifica el Nº de secuencia inicial (nsi_cliente).
• Lleva el bit SYN activado, que a todos los efectos es considerado como el
primer byte del flujo de datos de la conexión TCP.
Paso 2: El host servidor, al recibir el segmento SYN, inicializa los buffers y variables
TCP y responde al cliente enviándole un segmento SYN-ACK, que:
• Tiene las mismas características del segmento SYN del cliente pero lo que
especifica es el número de secuencia inicial del servidor (nsi_servidor).
• Sirve, además, para reconocer (ACK) que se ha recibido el segmento SYN del
cliente.
Paso 3: El cliente recibe el segmento SYN-ACK del servidor y le responde
enviándole un segmento ACK, que:
• Sirve para reconocer la llegada del SYN-ACK del servidor.
• Puede contener datos de usuario, aunque no es lo habitual.
Transporte 3-84
Gestión de la conexión en TCP: Cierre de la conexión
Cierre de la conexión TCP
cliente servidor
socketCliente.close();
• Un segmento FIN es aquél que

tiene activado el bit FIN, que a
todos los efectos es considerado socketConexion.close();
como el último byte del flujo de
datos de la conexión TCP.
espera temporizada
• La entidad TCP que envía un
segmento FIN ya no puede
enviar más datos, pero puede Conexión cerrada
seguir recibiéndolos.
Nota
Tanto cliente como servidor
pueden iniciar el cierre de la
misma.
Conexión cerrada
Transporte
tiempo tiempo 3-85
Paso 1: La aplicación cliente decide cerrar la conexión haciendo
socketCliente.close(); lo cual provoca que la entidad TCP envíe
un segmento FIN al servidor.
Paso 2: La entidad TCP del servidor recibe el segmento FIN y responde con un
ACK al cliente.
Paso 3: La aplicación servidora, cuando lo estime oportuno, cerrará la
conexión haciendo socketConexion.close(); lo cual provocará que
la entidad TCP envíe un segmento FIN al cliente.
Paso 4: El cliente recibe el segmento FIN y responde con un ACK.
• El cliente entra durante un tiempo en un estado de espera durante el cual, si le
llega un FIN del servidor, responde con un ACK.
• Al acabar el tiempo de espera, el cliente TCP dará por cerrada la conexión
(liberando buffers y demás recursos asociados a ella).
Paso 5: El servidor TCP recibe el ACK correspondiente a su FIN y da por cerrada
la conexión TCP (liberando buffers y demás recursos).
Transporte 3-86
• Los pasos anteriores, con alguna modificación menor, son los
mismos que se seguirían para cerrar la conexión si:
• Es la aplicación servidora la que toma la iniciativa a la hora de cerrar y
ejecuta en primer lugar un socketConexion.close();
• Ambas aplicaciones, la cliente y la servidora, deciden,
simultáneamente, cerrar la conexión y ejecutan, a la vez,
socketCliente.close(); y socketConexion.close();
• Las conexiones se deben cerrar de forma abrupta e
inmediata cuando se recibe un segmento RST (con el bit RST
activado). El envío de un segmento de RESET (“reinicio”) se
produce solo en casos especiales y no es la forma normal de
provocar el cierre de una conexión.
Transporte 3-87
Gestión de la conexión en TCP: Ciclo de vida
• Ciclo de vida de una conexión TCP: Es la secuencia de estados por los
que pasa una conexión TCP.
• La siguiente máquina de estados muestra los 11 estados posibles y
las diferentes transiciones que pueden darse, de un estado a otro.
CLOSED LAST_ACK CLOSE_WAIT
SYN_SENT TIME_WAIT
LISTEN ESTABLISHED CLOSING
SYN_RCVD FIN_WAIT_1 FIN_WAIT_2
Transporte 3-88
• El estado CLOSED es realmente un estado “ficticio”. La conexión está
en ese estado antes de crearse y después de haberse cerrado por
completo. En el estado CLOSED, la conexión aún no existe o ya ha
dejado de existir.
• CLOSED es el estado inicial y final de una conexión.
SYN_SENT TIME_WAIT
Transporte 3-89
• Cuando la conexión está en el estado ESTABLISHED las entidades TCP
pueden intercambiar segmentos con datos.
• Por tanto, el objetivo del cliente y del servidor es pasar de CLOSED a
ESTABLISHED, enviar y recibir datos y volver de nuevo al estado
CLOSED.
SYN_SENT TIME_WAIT
Transporte 3-90
• En verde podemos ver las transiciones del ciclo de vida típico de un
cliente.
• En azul aparece el ciclo de vida típico de un servidor.
• Las transiciones de color negro son posibles pero no son tan
habituales.
SYN_SENT TIME_WAIT
Transporte 3-91
• La primera transición del ciclo de vida típico del cliente es la que va
del estado CLOSED al estado SYN_SENT.
• Se da cuando se produce el evento “Aplicación cliente inicia una
conexión”.
• Lleva asociada la acción “Enviar segmento SYN”.
CLOSED
SYN_SENT TIME_WAIT
ESTABLISHED
FIN_WAIT_1 FIN_WAIT_2
Transporte 3-92
Aquí podemos ver todas las combinaciones “evento/acción” de las
transiciones del ciclo de vida típico del cliente.
Aplicación cliente inicia una conexión Transcurre 2 veces el tiempo MSL

Enviar segmento SYN No enviar nada
CLOSED
SYN_SENT TIME_WAIT
Se recibe segmento SYN-ACK Se recibe segmento FIN

Enviar ACK del SYN Enviar ACK del FIN
ESTABLISHED FIN_WAIT_2
La aplicación indica que quiere Se recibe ACK del FIN

cerrar la conexión FIN_WAIT_1
No enviar nada
Enviar segmento FIN
Transporte 3-93
NOTA: MSL (Maximum Segment Life), es el tiempo (estimado) de vida máximo de un segmento en la red.
• La primera transición del ciclo de vida típico del servidor es la que va
del estado CLOSED al estado LISTEN.
• Se produce da cuando la aplicación servidora crea un socket “de
acogida” que se queda esperando los intentos de conexión de los
posibles clientes.
• No hay acción asociada a esta primera transición.
LISTEN ESTABLISHED
SYN_RCVD
Transporte 3-94
Aquí podemos ver todas las combinaciones “evento/acción” de las
transiciones del ciclo de vida típico del servidor.
Aplicación servidora crea

socket “de acogida” Se recibe ACK del FIN
No enviar nada CLOSED No enviar nada
LISTEN LAST_ACK
Se recibe segmento SYN La aplicación indica que

quiere cerrar la conexión
Enviar segmento ACK-SYN
Enviar segmento FIN
SYN_RCVD CLOSE_WAIT
Se recibe ACK del SYN Se recibe segmento FIN

ESTABLISHED
No enviar nada Enviar ACK del FIN
Transporte 3-95
Objetivos Contenido

Tema 3: Resumen
• Hemos visto los principios que A continuación:

hay detrás de los servicios del
Nivel de Transporte: • Abandonamos la “frontera” de
la red (Niveles de aplicación y
• Multiplexión y demultiplexión de transporte)
• Transferencia de datos fiable
• Entraremos en el “núcleo” de
• Control de flujo la red.
• Hemos estudiado los protocolos
de internet proporcionan los
servicios del nivel de transporte:
• UDP
• TCP
Transporte 3-97
Departamento de
Redes de Computadores
EJERCICIOS
Problema 1
• Suponga que el cliente A inicia una conexión TCP con un
servidor web de nombre S. Más o menos simultáneamente,
el cliente B también inicia una conexión TCP con S.
• Indique posibles números de puerto origen y destino para:
• Los segmentos enviados de A a S
• Los segmentos enviados de B a S
• Los segmentos enviados de S a A
• Los segmentos enviados de S a B
• Si A y B están en host diferentes, ¿podría el número de
puerto origen de los segmentos que van de A a S ser el
mismo que el de los segmentos que van de B a S?
• ¿Y si los procesos clientes A y B están en el mismo host?
Transporte – Problemas 3 - 1
Problema 2
Observe las conexiones que han iniciado los clientes con el servidor Web y
responda a lo siguiente:
P1 P4 P5 P6 P2 P1P3
PO: 5775
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino PD: 80
IP-O = Dir. IP Origen IP-O: B
IP-D = Dir. IP Destino IP-D: C
PO: 9157 Servidor Web PO: 9157

cliente cliente
PD: 80 PD: 80
IP: A IP: C IP: B
IP-O: A IP-O: B
IP-D: C IP-D: C
a) ¿Cuáles son los valores de los puertos de origen y de destino en los

segmentos que fluyen desde el servidor de vuelta a los procesos cliente?
b) ¿Cuáles son las direcciones IP (origen y destino) de los datagramas de la
capa de red (R_PDU) que transportan a esos segmentos de la capa de
transporte?
Problema 3
UDP y TCP usan como “checksum” el complemento a 1 de la
suma. Suponga que los datos a los que hay que calcular el
checksum son las tres palabras siguientes:
• 1110000001010010
• 1101010100101111
• 0010101110101111
a) Calcule el complemento a 1 de la suma.
b) El receptor suma las tres palabras junto con el checksum
recibido. Si el resultado de la suma, en binario, contiene
algún cero, el receptor se da cuenta de que hubo algún
error en un bit ¿Es eso correcto?
c) ¿Se detecta cualquier error que solo afecte a un bit?
d) Proponga un ejemplo concreto de error no detectable.
Problema 4
Hemos visto que los protocolos con “pipeline” mejoran la

eficiencia frente a protocolos de “parada y espera”.
Suponga un Tx y un Rx un enlace de 1Gbps, 30ms de RTT, con
PDUs de 1500 bytes y con tamaños de cabecera cero (es decir
un tamaño totalmente despreciables frente a los otros
tamaños).
¿Cuántas PDUs de datos tiene que tener “en vuelo” el Tx para
que la tasa de utilización del canal sea del 95%?
Problema 5
Una aplicación puede preferir a UDP como protocolo de

transporte en lugar de TCP, para así tener un mayor grado de
control sobre qué datos se envían en la T_PDU y en qué
instante.
a) Explique por qué UDP ofrece a la aplicación mayor control
sobre qué datos se envían en la T_PDU.
b) Explique por qué UDP ofrece a la aplicación mayor control
sobre el instante en que se envía una T_PDU.
Problema 6
Suponga que un protocolo aplicación cliente desea enviar sólo
una PDU de 1000 bytes usando el servicio de transporte fiable
de Internet a una aplicación servidora que le responde con
100 bytes.
Realice un diagrama con el flujo de TCP_PDUs que se
intercambirán etiquetando cada una de ellas con los flags
activos, el valor del campo número de secuencia, el valor del
campo número de ACK y el nº de bytes de TCP_UD que
transporta. Para cada TCP_PDU intercambiada debe indicar el
tamaño en bytes de la misma. Suponga que TCP no tiene
opciones, el número de secuencia inicial (NSI) del cliente es
1000 y el del servidor 3000.
Problema 7
Se va a transferir de A a B un archivo de gran tamaño (L bytes) por una
conexión TCP en la cual el MSS ha quedado establecido en 536 bytes.
Considerando que el MSS es el tamaño máximo de los datos de usuario
transportados dentro de cualquier segmento de la conexión TCP. En el
segmento SYN, usando las opciones de la cabecera TCP, cada entidad TCP
informa a la otra del MSS que desea usar. Se usará el menor de los dos.
a) Calcule el valor máximo que podrá tener L si no queremos que los
números de secuencia usados en la conexión empiecen a repetirse.
b) Calcule el tiempo que tardaría en transmitirse un fichero de la
longitud L que ha calculado anteriormente, suponiendo que:
1) A y B están conectados por un enlace de 155Mbps
2) Cada segmento TCP se encapsula en un único datagrama IP y este en una única
trama, lo cual añade un total de 66 bytes de cabeceras a los datos del nivel de
aplicación.
3) Se puede enviar al ritmo máximo, sin peligro de desbordar al receptor, por lo
que no tendremos en cuenta el control de flujo.
Problema 8
Suponga que un protocolo aplicación cliente desea enviar sólo
una PDU de 100 bytes usando el servicio de transporte fiable
de Internet a una aplicación servidora que le responde con
1000 bytes.
Realice un diagrama con el flujo de TCP_PDUs que se
intercambirán etiquetando cada una de ellas con los flags
activos, el valor del campo número de secuencia, el valor del
campo número de ACK y el nº de bytes de TCP_UD que
transporta. Para cada TCP_PDU intercambiada debe indicar el
tamaño en bytes de la misma. Suponga que TCP no tiene
opciones, el número de secuencia inicial (NSI) del cliente es 0,
el del servidor 0 y el MSS 536.
Problema 9
Los hosts A y B se están comunicando a través de una conexión TCP. El
host B ha recibido de A todos los bytes hasta el byte 126 y A ha recibido
sus ACK.
Suponga que A envía ahora a B dos segmentos seguidos, el primero de 70
bytes de datos y el otro de 50.
El Nº de secuencia del primer segmento es 127, el Nº de puerto origen es
el 302 y el Nº de puerto destino el 80.
Suponga que B envía un reconocimiento cada vez que le llega un
segmento de A.
a) ¿Qué Nº de secuencia, Nº de puerto origen y Nº de puerto destino
tiene el segundo segmento que envió A?
b) Si el primer segmento llega a B antes que el segundo ¿cuál es el Nº de
reconocimiento, Nº de puerto origen y Nº de puerto destino del ACK
que enviará B por él?
Problema 9 (continuación)
c) Si la capa de red desordena los dos segmentos de A, de forma que

el segundo llega en primer lugar a B ¿cuál será el Nº de
reconocimiento del ACK que enviará B nada más recibirlo?
d) Suponga que los dos segmentos de A a B llegan en orden, y que a
los dos ACKs que envía B les ocurre.
• El primero se pierde y no llega a A.
• El segundo llega después de que en A se haya producido el time_out del
primer segmento.
e) Dibuje un diagrama temporal con los dos segmentos que envió A,
los dos ACKs de B y añada el resto de segmentos que se van a
enviar debido a retransmisiones y nuevos ACKs. Suponga que no
se perderán más segmentos. Indique tamaño de los datos, Nº de
secuencia y Nº de reconocimiento.
Problema 10
Los hosts A y B se están comunicando a través de una conexión
TCP. Ambos están unidos directamente por un enlace de
100Mbps. A está transfiriendo a B un archivo de gran tamaño a
través de la conexión TCP.
La capa de aplicación del host A es capaz de enviar datos a su
socket TCP a un ritmo de 120Mbps.
La capa de aplicación del host B va sacando los datos del buffer
de recepción TCP a un ritmo que no supera los 60Mbps.
Describa el efecto del control de flujo de TCP sobre el ritmo al
que la capa de aplicación de A envía datos a su socket TCP.
Problema 11
Hemos visto que TCP necesita estimar el valor del RTT para saber lo
que debe quedarse esperando un ACK.
Para estimar el RTT se basa en valores RTTmuestra que son el tiempo
transcurrido entre el envío de un segmento y la llegada de su ACK.
Sin embargo, TCP no usa el valor de RTTmuestra asociado a
segmentos que han sido retransmitidos.
¿Por qué no usa TCP como RTTmuestra el tiempo transcurrido entre
la retransmisión de un segmento y la llegada de su ACK?
Problema 12
¿Qué relación podemos establecer entre la variable

BaseEmision del emisor TCP y la variable
UltimoByteRecibido del receptor TCP?
Problema 13
¿Qué relación podemos establecer entre la variable y

del emisor TCP y la variable UltimoByteRecibido del
receptor TCP?
Problema 14
TCP deduce que un segmento se ha perdido cuando recibe,
por tres veces, un ACK que reconoce datos ya reconocidos.
Al recibir tres ACKs duplicados de un segmento, TCP hace una
retransmisión rápida de ese segmento que supone perdido,
sin esperar a que expire el temporizador.
¿Por qué TCP no hace la retransmisión rápida en cuanto llega
el primer ACK duplicado y espera al tercero?
Problema 15
El host A está enviando al host B un gran archivo a través de una
conexión TCP.
La entidad TCP del host B tiene un buffer de recepción grande, donde
puede caber el archivo completo mientras que el buffer de transmisión
de la entidad TCP de A sólo tiene capacidad para un porcentaje del
mismo.
En la conexión TCP no se está perdiendo ningún segmento, por lo que los
ACKs llegan siempre a tiempo y nunca expiran los temporizadores.
El ancho de banda del enlace que conecta a A con Internet es de R bps.
La capa de aplicación de A es capaz de enviar datos a su socket TCP a un
ritmo de S bps, que es 10 veces R, sin embargo algo le impide alcanzar el
ritmo S.
¿Está impidiendo el control de flujo que la capa de aplicación envíe datos
a su socket TCP a un ritmo S, o es otro el motivo?

RC.G1.Tema3 Transporte PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

RC.G1.Tema3 Transporte PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Redes de Computadores

Some material copyright 1996-2010

Some material copyright 1996-2010

• Las aplicaciones pueden escoger el transport.

router Transporte 3-6

• Capa de red: proporciona un servicio de comunicación lógica

• Capa de transporte: extiende el servicio de la capa de red para

Some material copyright 1996-2010

transporte transporte transporte

red red red

enlace enlace enlace

física física física

host 1 host 2 host 3

1 Cierto si no hay fragmentación Transporte 3-12

DatagramSocket serverSocket = new DatagramSocket(6428);

PO: 6428 PO: 6428

PO: 9157 PO: 5775

La IP origen y el Puerto Origen permitirán a P3

PO: 9157 servidor PO: 9157 cliente

PO: 9157 servidor PO: 9157

Some material copyright 1996-2010

¿Por qué existe UDP?

Nota: al ir sumando los números de 16 bits que forman la

Suma (con acarreo) 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

Some material copyright 1996-2010

¿Por qué es necesaria la T.F.? ¿Cómo se detectan estos problemas?

Simplificación del caso general de comunicación entre entidades pares:

Primer bit PDU recibido

Recibido ACK, t = RTT + L / R

Parada y espera Pipeline

NOTA: Profundizaremos en este concepto al abordar TCP

Llega primer bit de 1ª PDU

• Las características concretas del canal no fiable condicionarán la

Lado del Lado del

udt = Unreliable Data Transfer (Trasferencia de datos no fiable) Transporte 3-40

evento que causa cambio de estado

Emisor (Tx) Receptor (Rx)

Espera rdt_send(data) Espera rdt_rcv(packet)

SOLICITUD HACIA EL NIVEL INFERIOR INDICACIÓN HACIA EL NIVEL SUPERIOR

rdt_rcv(rcvpkt) && isACK(rcvpkt) Espera

rdt_rcv(rcvpkt) && isACK(rcvpkt) Espera

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Emisor (Tx) Receptor (Rx)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Some material copyright 1996-2010

P: ¿Cómo trata el receptor los segmentos desordenados?

42+10 Brx contiene “DIEZ BYTES”

RTTestimado = (1-)* RTTestimado +  * RTTmuestreado

• Media móvil exponencialmente ponderada.

SampleRTT Estimated RTT

RTTdesv = (1-)*RTTdesv + * |RTTmuestra-RTTestimado|

Así, el time_out podría calcularse como:

Some material copyright 1996-2010

evento: datos recibidos de la aplicación /* Llegan datos de la capa superior*/

Host A Host B Host A Host B

BaseEmision tiempo BaseEmision=120 tiempo

El temporizador con la duración

Llegada de segmento en orden, con el nº Enviar inmediatamente un ACK

Llegada de segmento fuera de orden, con Enviar inmediatamente un ACK

Llegada de un segmento que “rellena” Enviar inmediatamente un ACK para

El emisor al ver que, por tres

duplicado de los datos del

evento: recibido ACK con campo nº de ACK valiendo y

RTTdesv = (1-)RTTdesv +  |RTTmuestra-RTTestimado|