Académique Documents
Professionnel Documents
Culture Documents
Transporte 3-2
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-3
Servicios del nivel de transporte
proporciona comunicación logica aplicación
transport.
entre aplicaciones que se red
enlace
ejecutan en hosts diferentes, física
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.
Las aplicaciones pueden escoger aplicación
Transporte 3-4
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-5
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).
Transporte 3-6
Nivel de Transporte frente a
Nivel de Red
Analogía del servicio de correo postal “mejorado”:
Dos casas con 10 niños en cada una, los cuales se envian
semanalmente cartas entre ellos.
procesos = niños
Mensajes de aplicación = cartas en sobres
Sistema finales = casas
Protocolo de nivel de transporte = Ana (en una casa) y
Benito (en la otra) se encargan de recoger las cartas de
sus hermanos, enviarlas en la oficina de correos, estar
pendientes del correo entrante y de repartirlo cuando
llega, directamente a sus hermanos.
Protocolo de nivel de red = servicio de correo postal
Transporte 3-7
Protocolos de Transporte en Internet
TCP: Servicio de entrega de
datos fiable y en orden aplicación
transport.
Control de flujo red
enlace
Establecimiento de la conexión física
red
enlace
UDP: Servicio de entrega de
red
física
enlace
física
datos no fiable y sin garantía
de orden. red
enlace
Protocolo simple “sin florituras” física red
enlace
Servicios no disponibles: red
física
Retardo garantizado
enlace
aplicación
física red transport.
enlace
Ancho de banda garantizado física
red
enlace
física
Tanto TCP como UDP usan los
servicios de IP
protocolo que suministra un
servicio de mejor esfuerzo
(“best-effort”). Transporte 3-8
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-9
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 info. de la cabecera (T_PCI).
usará luego al demultiplexar.
= socket = proceso
aplicación P3 P1
P1 aplicación P2 P4 aplicación
P2 P1
P1
P3
Transporte 3-14
Demultiplexión orientada a la
conexión (TCP) … en el servidor al recibir una
solicitud de conexión por parte
Al crear el socket TCP… del cliente la acepta, quedando
esta identificada por socket
… en el servidor indicamos el número cliente (IP cliente, puerto
de puerto y se deja en modo cliente) y socket servidor (IP
escucha: servidor, puerto servidor).
ServerSocket socketAcogida = new Socket socketConnection =
ServerSocket(6789); welcomeSocket.accept();
… en el cliente se proporciona el Cuando el protocolo TCP del host
socket del servidor (IP/nombre, destino recibe la T_PDU
puerto) como T_ICI y se establece comprueba tanto el número de
la conexión con este (que debe puerto origen como destino en la
estar en modo escucha). cabecera (T_PCI) así como la
Socket socketCliente = new dirección IP origen y destino
Socket("hostnameservidor", 6789); 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-15
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 = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen
IP-D = Dir. IP Destino Transporte 3-17
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-18
UDP: User Datagram Protocol [RFC 768]
Es un protocolo de transporte de
Internet muy simple, sin “florituras”. ¿Por qué existe UDP?
Ofrece un servicio de mejor esfuerzo, No hay un
“best effort”, por lo que: establecimiento de la
Las T_PDU pueden “perderse” y no conexión (que añadiría
llegar a su destino. un retardo).
Si las T_PDU llegan desordenadas, Es simple de
los datos de usuario contenidos en implementar: no hay
ellas se entregarían desordenados al que mantener el
Nivel de Aplicación. estado de la conexión
ni en el transmisor ni
sin conexión:
en el receptor.
No hay una fase acuerdo previa
La cabecera (T_PCI)
entre el emisor y el receptor UDP.
es más simple y
Cada T_PDU se trata de forma pequeña.
independiente a las demás.
Transporte 3-19
UDP: más… 32 bits
Nº puerto origen Nº puerto destino
T_PCI checksum
longitud
A menudo usado
por aplicaciones de
streaming T_UD
multimedia Datos del nivel
La cabecera de aplicación
Tolerantes a (T_PCI) solo tiene
(mensaje)
pérdidas 4 campos.
La longitud es en
Sensibles al ancho bytes y es la de la
T_PDU completa,
de banda con cabecera.
Otros usos de UDP Formato de la T_PDU
DNS de UDP
SNMP
¿Transferencia fiable sobre UDP? Es posible si
añadimos fiabilidad a la capa de aplicación
¡ Recuperación de errores específica de la aplicación !
Transporte 3-20
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 la misma forma que lo hizo el
bits. emisor, sobre la T_PDU recibida.
Simplificando un poco, Comprueba si el checksum
podemos decir que suma calculado es idéntico al valor del
todos los enteros de 16 bits campo checksum de la T_PDU
que componen la T_PDU y recibida.
luego le calcula el NO -> ¡Error detectado!
complemento a 1. SÍ -> No se detecta error
Coloca el valor calculado en el alguno, pero… ¿Puede que haya
campo checksum de la un error? Más sobre esto
cabecera (T_PCI). próximamente…
Transporte 3-21
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: sumar solo 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
Transporte 3-22
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-23
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 tópicos más importantes sobre redes !
Transporte 3-25
Principios de la transferencia fiable
¿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-26
Principios de la transferencia fiable
¿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-27
Principios de la transferencia fiable
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 entidad Rx de un determinado
datos con UD y PCI y la nivel:
transmite al Rx. Si la PDU de datos llegó
Ahora, el Tx espera durante un correctamente, es
tiempo, conocido como time_out, obligatorio que el Rx le
a recibir una PDU de control del mande al TX una PDU de
Rx que le indique control de tipo ACK,
con un ACK que la PDU de avisándole.
datos llego bien al Rx. Si la PDU de datos llegó
o Tx no hace nada más. con errores, es opcional
con un NACK, que la PDU de
que el Rx le mande al TX
datos llegó con errores al una PDU de control de tipo
Rx. NACK, avisándole.
o Tx retransmite la PDU.
P: ¿Cuánto debe valer, como
Si expira el time_out antes
de que llegue la PDU de mínimo, el time_out?
control del Rx, entonces P: ¿Entrega siempre el Rx al nivel
o Tx retransmite la PDU.
superior los UD de una PDU de
datos que llega correctamente?
Transporte 3-28
Principios de la transferencia fiable
Ejemplo 1. PCI
Time_out
PDU perdida
Tiempo
X
Time_out
PDU errónea
Tx Rx Tx Con errores Rx
Sin errores Transporte 3-29
Principios de la transferencia fiable
Ejemplo 2.
• Idem ejemplo 1.
X
• Receptor también envía
PDU de control NACK.
tiempo
• Sin errores.
Mismo comportamiento Time_out
anterior
Tx Rx
Con errores
Transporte 3-30
Principios de la transferencia fiable
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.
dtrans = L/R
Tx Rx
Primer bit PDU enviado, t = 0
Último bit PDU enviado, t = L / R
U L/R
=
transmisor
RTT + L / R
Transporte 3-32
Eficiencia del protocolo parada y espera
L 8kb / pdu
dtrans 9
8s
R 10 b / s
L/ R 0,008
U transmisor 0,00027
RTT L / R 30,008
PDU PDU
ACK
U 3*L/R 0,024
= = = 0,0008
transmisor 30,008
RTT + L / R microsecon
ds
Transporte 3-35
Servicio de transferencia fiable
¿Cómo proporciona el nivel de transporte un servicio de
transferencia fiable al nivel de aplicación?
Transporte 3-36
Servicio de transferencia fiable
¿Cómo proporciona el nivel de transporte un servicio de
transferencia fiable (“reliable”) al nivel de aplicación?
Transporte 3-37
Servicio de transferencia fiable
El nivel de transporte debe implementar un protocolo de
transferencia fiable “reliable data transfer (rdt) protocol”.
Nota: En las máquinas de estados a las PDUs las llama paquetes (“packets”).
Transporte 3-41
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-42
rdt2.0: Maquina de estados finitos (FSM)
Máquina de
rdt_send(data) estados
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
del receptor
rdt_rcv(rcvpkt) && (Rx)
Espera isNAK(rcvpkt)
Espera rdt_rcv(rcvpkt) &&
llamada
ACK o udt_send(sndpkt) corrupt(rcvpkt)
desde
NAK
arriba
udt_send(NAK)
Ambos, Tx y Rx,
rdt_rcv(rcvpkt) && isACK(rcvpkt) usan udt_send() Espera
L para enviar sus llamada
Máquina de PDUs por el canal desde
no fiable
estados
abajo
implementado por
del emisor el nivel inferior. rdt_rcv(rcvpkt) &&
(Tx) Ambos, Tx y Rx, notcorrupt(rcvpkt)
esperan el evento extract(rcvpkt,data)
rdt_rcv() que les deliver_data(data)
entrega una PDU que udt_send(ACK)
llega desde el nivel
inferior (no fiable).
Transporte 3-43
rdt2.0: Operación en escenario sin errores
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Espera isNAK(rcvpkt)
Espera rdt_rcv(rcvpkt) &&
llamada
ACK o udt_send(sndpkt) corrupt(rcvpkt)
desde
NAK
arriba
udt_send(NAK)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Transporte 3-44
rdt2.0: Operación en escenario con errores
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Espera isNAK(rcvpkt)
Espera rdt_rcv(rcvpkt) &&
llamada
ACK o udt_send(sndpkt) corrupt(rcvpkt)
desde
NAK
arriba
udt_send(NAK)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Transporte 3-45
rdt 2.0 Tiene un fallo grave…
¿Qué ocurre si una PDU de Para evitar PDUs duplicadas:
control (ACK o NAK) se El Tx retransmite la PDU de
corrompe (tiene bits datos si la PDU de control
recibida (ACK o NAK) está
erróneos)?
corrupta (tiene errores).
¡ El Tx no sabe si ha recibido
El Tx añade un número de
un ACK o un NAK, pues la PDU
secuencia en la PCI de cada PDU.
tiene errores !
El Rx es capaz de detectar PDUs
¡ El Tx no sabe cómo llegó la
duplicadas, gracias al número de
PDU de datos al Rx !
secuencia, por lo que las
No es válido, simplemente, descarta y no pasa sus datos al
retransmitir la última PDU nivel superior.
pues… ¡ El Rx podría recibirla
dos veces y no darse cuenta Parada y espera
de que es la misma PDU ! El emisor envía una PDU y espera
la respuesta del receptor.
Transporte 3-46
rdt2.1: Máquina de estados del Emisor.
Soluciona el problema de los ACK/NAKs corruptos.
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-47
rdt2.1: Máquina de estados del Receptor.
Soluciona el problema de los ACK/NAKs corruptos.
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
Transporte 3-48
rdt2.1: Discusión
Transporte 3-50
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
udt_send(sndpkt)
0 from
below
máquina Rx
Transporte 3-53
rdt3.0 en acción en diversas situaciones
Transporte 3-54
rdt3.0 en acción en diversas situaciones
Transporte 3-55
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-56
TCP: Visión general RFCs: 793, 1122, 1323, 2018, 2581
Transporte 3-59
Nº de secuencia y de ACK en TCP(II)
Escenario simple
Entidad TCP Host A Entidad TCP Host B
Btx contiene “DIEZ BYTES” Btx vacío
Btx vacío
Notas
- El gráfico muestra intercambio de TCP_PDUs (segmentos). El buffer de
transmisión (Btx) contiene los UD solicitados por el nivel de aplicación a través del
tiempo
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 dos primeros segmentos que ambos host han enviado .
Transporte 3-60
TCP estima el RTT para saber
qué valor usar de time_out
¿Qué valor debe usar TCP ¿Cómo estimar el RTT?
como time_out? RTTmuestra es el tiempo (real)
Debe ser algo mayor que el medido desde que se transmite
RTT un segmento hasta que llega el
ACK.
Pero el RTT cambia a lo
largo del tiempo… ignorando retransmisiones…
Un valor muy pequeño RTTmuestra puede ser muy
produce un time_out variable… Queremos una
prematuro y estimación del RTT más “suave”
retransmisiones (menos “cambiante”).
innecesarias. RTTestimado lo
Un valor demasiado grande calcularemos como la media
hace que se reaccione muy de los valores de
tarde ante la pérdida de un RTTmuestra más recientes.
segmento.
Transporte 3-61
TCP estima el RTT para saber
qué valor usar de time_out
Transporte 3-62
TCP estima el RTT para saber
qué valor usar de time_out
Ejemplo de estimación del RTT
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)
Transporte 3-63
TCP estima el RTT para saber
que valor usar de time_out
¿Como 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:
Transporte 3-64
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-65
TCP: Transferencia de datos fiable
TCP crea un servicio de TCP debe retransmitir
transferencia de datos fiable los datos cuando:
encima del servicio de Se produce un time_out
transferencia no fiable que le Llega un ACK duplicado
proporciona IP. Inicialmente
TCP usa la técnica del consideraremos un
“pipeline”, manteniendo varios emisor TCP
segmentos “en vuelo”. simplificado:
TCP usa ACKs acumulativos, que Ignora ACKs duplicados
reconocen un dato y todos los Sin control de flujo
anteriores.
TCP usa, por simplicidad, un
único temporizador para todas
las T_PDUs de una conexión.
Transporte 3-66
Eventos que trata el emisor TCP (simplificado):
Time_out Sec=92
Time_out Sec=92
perdido
Expira Expira
BaseEmision=100
BaseEmision=120
Time_out Sec=92
perdido
BaseEmision=120
El temporizador con la duración tiempo
“recomendada” habría expirado
antes de la llegada del ACK=120. Escenario
El transmisor puede usar en ACK
ciertas ocasiones un time_out No expira
acumulativo
que dure más de lo recomendado
lo cual hace que sea fácil que se
produzcan ACKs acumulativos.
Transporte 3-70
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.
Transporte 3-73
TCP: Retransmisión rápida
Este es el evento de recepción de ACK
en el emisor TCP simplificado.
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-74
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-75
Control de flujo en TCP Control de flujo
Conseguir que el emisor
El lado receptor de una conexión TCP
no desborde el buffer
tiene un buffer de recepción donde se
del receptor por culpa de
acumulan los datos que llegan desde el
transmitir demasiados
nivel inferior.
datos, demasiado rápido.
VentanaRecepcion Va variando su tamaño
Transporte 3-78
Control de flujo en TCP (funcionamiento)
Nº puerto Orig. Nº puerto Dest.
El valor del campo
VentanaRecepcion de la Número de secuencia
T_PCI está relacionado con Número de ACK
T_PCI
el valor del campo NºdeACK Long. no
UA P R S F Ventana de Rx
Cabe. usado
de la T_PCI. checksum Punt. Datos Urg.
Cuando el emisor recibe un
segmento, observa el valor Opciones (long. variable)
del campo NºdeACK y el
T_UD
valor del campo Datos del nivel de
VentanaRecepcion para aplicación
conocer el rango de números (longitud variable)
de secuencia
correspondientes a los datos Estructura del
que está autorizado a tener
“en vuelo”, pendientes de
segmento (T_PDU)
confirmación:
Desde NºdeACK hasta (NºdeACK + VentanaRecepcion – 1)
Transporte 3-79
Tema 3: Nivel de Transporte
3.1 Servicios del nivel de 3.5 Transporte orientado a la
transporte conexión: TCP
3.2 Multiplexión y Estructura del segmento TCP
demultiplexión Transferencia de datos fiable
Control de flujo
3.3 Transporte sin
Gestión de la conexión
conexión: UDP
3.4 Principios de la
transferencia fiable
Transporte 3-80
Gestión de la conexión en TCP: Establecimiento
Transporte 3-81
Gestión de la conexión en TCP: Establecimiento
new socket
X.accept()
Servidor
puede
Enviar
datos
Conexión
establecida
Cliente
puede
Enviar
datos Nota
tiempo En el flujo de de TCP_PDUs (segmentos) si un determinado tiempo
flag está activo, se indica en el etiquetado, menos el del ACK
que está implícito cuando el campo ACK tiene valor. Transporte 3-82
Gestión de la conexión en TCP: Establecimiento
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.
temporizada
tiempo tiempo
Transporte 3-84
Gestión de la conexión en TCP: Cierre de la conexión
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).
SYN_SENT TIME_WAIT
Transporte 3-87
Gestión de la conexión en TCP: Ciclo de vida
SYN_SENT TIME_WAIT
Transporte 3-88
Gestión de la conexión en TCP: Ciclo de vida
SYN_SENT TIME_WAIT
Transporte 3-89
Gestión de la conexión en TCP: Ciclo de vida
SYN_SENT TIME_WAIT
Transporte 3-90
Gestión de la conexión en TCP: Ciclo de vida
CLOSED
SYN_SENT TIME_WAIT
ESTABLISHED
FIN_WAIT_1 FIN_WAIT_2
Transporte 3-91
Gestión de la conexión en TCP: Ciclo de vida
SYN_SENT TIME_WAIT
ESTABLISHED FIN_WAIT_2
NOTA: MSL (Maximum Segment Life), es el tiempo (estimado) de vida máximo de un segmento en la red. Transporte 3-92
Gestión de la conexión en TCP: Ciclo de vida
LISTEN ESTABLISHED
SYN_RCVD
Transporte 3-93
Gestión de la conexión en TCP: Ciclo de vida
LISTEN LAST_ACK
SYN_RCVD CLOSE_WAIT
Transporte 3-94
Tema 3: Resumen
Hemos visto los principios que
hay detrás de los servicios del
Nivel de Transporte:
Multiplexión y demultiplexión.
A continuación:
Transferencia de datos fiable
Abandonamos la
Control de flujo
“frontera” de la
Hemos estudiado los protocolos red (Niveles de
de internet proporcionan los aplicación y de
servicios del nivel de transporte: transporte)
UDP Entraremos en
TCP el “núcleo” de la
red.
Transporte 3-95
Tema 3:
PROBLEMAS
Transporte 3-96
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 3-97
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
PD: 80
IP-O: B
IP-D: C
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen
IP-D = Dir. IP Destino Transporte 3-98
Problema 2 (continuación)
¿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?
¿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?
Transporte 3-99
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
Calcule el complemento a 1 de la suma.
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?
¿Se detecta cualquier error que solo afecte a un bit?
Proponga un ejemplo concreto de error no detectable.
Transporte 3-100
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%?
Transporte 3-101
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.
Explique por qué UDP ofrece a la aplicación mayor
control sobre qué datos se envían en la T_PDU.
Explique por qué UDP ofrece a la aplicación mayor
control sobre el instante en que se envía una T_PDU.
Transporte 3-102
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.
Transporte 3-103
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.
NOTA: 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.
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.
Transporte 3-104
Problema 7 (continuación)
Calcule el tiempo que tardaría en transmitirse un
fichero de la longitud L que ha calculado anteriormente,
suponiendo que:
A y B están conectados por un enlace de 155Mbps
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.
Se puede enviar al ritmo máximo, sin peligro de
desbordar al receptor, por lo que no tendremos en
cuenta el control de flujo.
Transporte 3-105
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.
Transporte 3-106
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.
¿Qué Nº de secuencia, Nº de puerto origen y Nº de
puerto destino tiene el segundo segmento que envió A?
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?
Transporte 3-107
Problema 9 (continuación)
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?
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.
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. Transporte 3-108
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.
Transporte 3-109
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?
Transporte 3-110
Problema 12
¿Qué relación podemos establecer entre la variable
BaseEmision del emisor TCP y la variable
UltimoByteRecibido del receptor TCP?
Transporte 3-111
Problema 13
¿Qué relación podemos establecer entre la variable y
del emisor TCP y la variable UltimoByteRecibido del
receptor TCP?
Transporte 3-112
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?
Transporte 3-113
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 solo 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?
Transporte 3-114