Tema 3: Nivel de Transporte REDES DE COMPUTADORES Some material copyright 1996-2010 J.F Kurose and...
-
Upload
raimundo-onate -
Category
Documents
-
view
104 -
download
0
Transcript of Tema 3: Nivel de Transporte REDES DE COMPUTADORES Some material copyright 1996-2010 J.F Kurose and...
Tema 3: Nivel de Transporte
REDES DE COMPUTADORES
Some material copyright 1996-2010J.F Kurose and K.W. Ross, All Rights Reserved
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
Departamento deTecnología Electrónica
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-1
Tema 3: Nivel de TransporteObjetivos: Entender los
principios que hay detrás de los servicios del nivel de transporte: Multiplexión/demultiplexión Transferencia de
datos confiable Control de flujo
Conocer los protocolos de transporte usados en Internet: UDP: transporte no
orientado a la conexión TCP: transporte orientado
a la conexión
Transporte 3-2
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-3
Tema 3: Nivel de Transporte
Servicios del nivel de transporte proporciona comunicación
logica 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.
Las aplicaciones pueden escoger el protocolo de transporte que quieren usar, en función del tipo de servicio que necesiten En Internet: TCP y UDP
aplicación
transport.red
enlacefísica
aplicación
transport.red
enlacefísica
Comunicación lógica
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.
Transporte 3-5
origen
aplicacióntransporte
redenlacefísica
destino
aplicacióntransporte
redenlacefísica
redenlacefísica
router
Protocolo aplicación
Protocolo transporte
Protocolo red Protocolo red
Protocolo enlace
Protocolo físico
Protocolo enlace
Protocolo físico
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-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 Control de flujo Establecimiento de la
conexión UDP: Servicio de entrega
de datos no fiable y sin garantía de orden. Protocolo simple “sin
florituras” Servicios no disponibles:
Retardo garantizado Ancho de banda garantizado
Tanto TCP como UDP usan los servicios de IP protocolo que suministra un
servicio de mejor esfuerzo (“best-effort”).
aplicación
transport.red
enlacefísica red
enlacefísica
redenlacefísica
redenlacefísica
redenlacefísica
redenlacefísica
redenlacefísica
aplicación
transport.red
enlacefísica
Comunicación lógica
Transporte 3-8
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-9
Tema 3: Nivel de Transporte
Multiplexión/demultiplexión
aplicación
transporte
red
enlace
física
P1 aplicación
transporte
red
enlace
física
aplicación
transporte
red
enlace
física
P2P3 P4P1
host 1 host 2
Entregar en el socket correcto el contenido de los segmentos (T_PDU) recibidos, gracias a la info. de la cabecera (T_PCI).
host 3
= proceso= socket
Recolectar datos de múltiples sockets, crear los segmentos (T_PDU) añadiendo información de cabecera (T_PCI) que se usará luego al demultiplexar.
Demultiplexión al recibirMultiplexión al enviar
Transporte 3-10
Cómo funciona la demultiplexión El nivel de red recibe datagramas IP
(R_PDU) Cada R_PDU tiene una dirección IP
origen y una dirección IP destino en su cabecera (R_PCI).
Cada R_PDU encapsula en su interior un segmento (T_PDU)1.
El nivel de transporte recibe segmentos (T_PDU) Cada T_PDU tiene en su T_PCIun nº de puerto origen yun nº de puerto destino. Cada T_PDU encapsula datos del
usuario, el nivel de aplicación (T_UD). En el host destino las direcciones IP y
los números de puerto sirven para entregar la T_UD de la T_PDU al socket adecuado.
Nº puerto origen Nº puerto destino
32 bits
T_UD:Datos del nivelde aplicación
(mensaje)
Otros campos dela cabecera (T_PCI)
Formato de la T_PDUde TCP/UDP
Transporte 3-111 Cierto si no hay fragmentación
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-12
DatagramSocket serverSocket = new DatagramSocket(6428);
clienteIP: B
P2
cliente IP: A
P1P1P3
servidorIP: C
PO: 6428
PD: 9157
PO: 9157
PD: 6428
PO: 6428
PD: 5775
PO: 5775
PD: 6428
La IP origen y el Puerto Origen permitirán a P3 identificar al proceso origen (P1 o P2) y devolverle un mensaje.
PO = Nº de Puerto OrigenPD = Nº de Puerto Destino
Nº de puerto local. Obligatorio especificarlo si es un proceso servidor.
Transporte 3-13
Demultiplexión sin conexión (UDP)
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-14
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-15
Demultiplexión orientada a la conexión (TCP)
Demultiplexión en TCP:Servidor Web con varios procesos
P1
cliente IP: A
P1P2P4
servidorIP: C
PO: 9157
PD: 80PO: 9157
PD: 80
P5 P6 P3
IP-D: C
IP-O: A
IP-D: CIP-O: B
PO: 5775
PD: 80
IP-D: CIP-O: B
cliente IP: B
PO = Nº de Puerto OrigenPD = Nº de Puerto DestinoIP-O = Dir. IP OrigenIP-D = Dir. IP Destino
No es problema que dos procesos
cliente usen el mismo puerto
origen
No es problema que dos procesos
cliente usen la misma IP origen
Transporte 3-16
P4P1
cliente IP: A
P1P2
servidorIP: C
PO: 9157
PD: 80PO: 9157
PD: 80
P3
IP-D: C
IP-O: A
IP-D: CIP-O: B
PO: 5775
PD: 80
IP-D: CIP-O: B
cliente IP: B
PO = Nº de Puerto OrigenPD = Nº de Puerto DestinoIP-O = Dir. IP OrigenIP-D = Dir. IP Destino
En lugar de un proceso
servidor por cada socket, hay un “hilo”
por socket y un solo proceso.
Transporte 3-17
Demultiplexión en TCP:Servidor Web multihilo (threaded)
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-18
Tema 3: Nivel de Transporte
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-19
UDP: más…
A menudo usado por aplicaciones de streaming (multimedia) Tolerantes a
pérdidas Sensibles al ancho
de banda Otros usos de
UDP DNS SNMP
32 bits
longitud checksum
La cabecera (T_PCI) solo tiene
4 campos. La longitud es en bytes y es la
de la T_PDU completa, con
cabecera.
Nº puerto origen Nº puerto destino
Datos del nivelde aplicación
(mensaje)
Formato de la T_PDUde UDP
¿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 !
T_PCI
T_UD
Transporte 3-20
Checksum (suma de comprobación) UDP
El emisor: Trata la T_PDU como una
secuencia de enteros de 16 bits.
Simplificando un poco, podemos decir que suma todos los enteros de 16 bits que componen la T_PDU y luego le calcula el complemento a 1.
Coloca el valor calculado en el campo checksum de la cabecera (T_PCI).
El receptor: Calcula el checksum, otra vez,
de la misma forma que lo hizo el emisor, sobre la T_PDU recibida.
Comprueba si el checksum calculado es idéntico al valor del campo checksum de la T_PDU recibida. NO -> ¡Error detectado! SÍ -> No se detecta error
alguno, pero… ¿Puede que haya un error? Más sobre esto próximamente…
Objetivo: detectar “errores” (e.g., bits “cambiados”) en una T_PDU transmitida
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 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Acarreo
Suma (con acarreo)checksum
Transporte 3-22
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-23
Tema 3: Nivel de Transporte
¿Por qué es necesaria la T.F.? PDUs erróneas
En las transmisiones sobre los enlaces se producen interferencias que alteran los bits transmitidos. PDUs perdidas
Las colas de paquetes, cuando están saturadas, empiezan a descartar los paquetes entrantes. PDUs duplicadas
Determinados problemas en la comunicación provocan que se retransmitan PDUs que ya han sido recibidas.
¿Cómo se detectan estos problemas? PDUs erróneas
Usando mecanismos de comprobación de errores (incluidos en la PCI).
Algoritmos similares al del checksum.
Los algoritmos más complejos y fiables se utilizan en el nivel de enlace.
PDUs perdidas y duplicadasAñadiendo “algo” a la cabecera (PCI) de cada PDU que permita distinguirla del resto de PDUs enviadas.
¿Cómo se solucionan estos problemas? Retransmisiones
El transmisor vuelve a transmitir una copia exacta de la PDU que tuvo problemas.
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 !
Principios de la transferencia fiable
Transporte 3-24
Principios de la transferencia fiable
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-25
¿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)
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.
Nota
Principios de la transferencia fiable
Transporte 3-26
¿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.
La información de la PCI que sirve para identificar una determinada PDU de datos se llama número de
secuencia.
Nota
Principios de la transferencia fiable
Transporte 3-27
Principios de la transferencia fiable
Funcionamiento básico Tx: La entidad Tx de un
determinado nivel, construye una PDU de datos con UD y PCI y la transmite al Rx.
Ahora, el Tx espera durante un tiempo, conocido como time_out, a recibir una PDU de control del Rx que le indique
con un ACK que la PDU de datos llego bien al Rx.o Tx no hace nada más.
con un NACK, que la PDU de datos llegó con errores al Rx.o Tx retransmite la PDU.
Si expira el time_out antes de que llegue la PDU de control del Rx, entonceso Tx retransmite la PDU.
Funcionamiento básico Rx: Al recibir una PDU de datos
la entidad Rx de un determinado nivel:
Si la PDU de datos llegó correctamente, es obligatorio que el Rx le mande al TX una PDU de control de tipo ACK, avisándole.
Si la PDU de datos llegó con errores, es opcional que el Rx le mande al TX una PDU de control de tipo NACK, avisándole.
P: ¿Cuánto debe valer, como mínimo, el time_out?
P: ¿Entrega siempre el Rx al nivel superior los UD de una PDU de datos que llega correctamente?
Transporte 3-28
Ejemplo 1. Transmisor envía sólo una PDU con
UD y no envía la siguiente hasta tener éxito en la transmisión.
Receptor sólo envía PDU de control ACK.
Tx Rx
PDU 1
Tiempo
Sin errores
ACK 1PDU 2
ACK 2
PDU 3
ACK 3
PDU X
ACK X
dtransPDU
dtransack
PCI
Tx Rx
PDU 1
PDU 2
X
PDU 1
ACK 1
Time_out
Time_out
PDU 2
ACK 2
Con errores
PDU perdida
PDU errónea
Principios de la transferencia fiable
Transporte 3-29
Ejemplo 2.• Idem ejemplo 1.• Receptor también
envía PDU de control NACK.
• Sin errores. Mismo comportamiento
anterior
Tx Rx
PDU 1
tiempoPDU 2
XNACK 1
PDU 1
ACK 1
PDU 2
Time_out
ACK 2
Con errores
Principios de la transferencia fiable
Transporte 3-30
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. 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.
Principios de la transferencia fiable
Transporte 3-31
Eficiencia del protocolo parada y espera
Primer bit PDU enviado, t = 0
Tx Rx
RTT
Primer bit PDU recibidoÚltimo bit PDU recibido, enviar ACK
Recibido ACK, t = RTT + L / REnviar próxima PDU
U transmisor
= L / R
RTT + L / R
dtrans = L/R
Recuerda
Último bit PDU enviado, t = L / R
Transporte 3-32
El protocolo funciona, pero su eficiencia es mala Ejemplo: enlace de 1 Gbps, 30 ms de RTT, PDU
1KByte
ssb
pdukb
R
Ldtrans 8
/10
/89
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?
00027,0008,30
008,0
/
/
RLRTT
RLU transmisor
Eficiencia del protocolo parada y espera
Transporte 3-33
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 sirvan para distinguir todas las PDUs en tránsito.
Se requieren buffers en el Tx y, a veces, en Rx.
Parada y espera Pipeline
PDU PDU
ACK
NOTA: Profundizaremos en este concepto al abordar TCP Transporte 3-34
El “pipeline” mejora mucho la eficiencia
Envío bit 1 de 1ª PDU, t = 0
Tx Rx
RTT
Envío último bit de PDU, t = L / R
Llega primer bit de 1ª PDULlega último bit 1ª PDU, envío ACK
ACK recibido, envío siguiente PDU, la 4ª, t = RTT + L / R
Llega últimobit 2ª PDU, envío ACKLlega último 3ª PDU, envío ACK
U transmisor
= 0,024
30,008 = 0,0008
microseconds
3 * L / R
RTT + L / R =
Tener hasta 3 PDUs “en vuelo”
multiplica la eficiencia por un
factor de 3
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
El nivel de transporte tiene debajo el nivel de red, que le proporciona un servicio de transferencia no fiable (“unreliable”).
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
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.
Servicio de transferencia fiable
Transporte 3-38
Lado delemisor
(Tx)
Lado delReceptor
(Rx)
rdt_send(): llamado desde el nivel superior, (p.e., por la Aplic.) Nos pasa los datos que deberemos
suministrar al receptor del nivel superior.
udt_send(): llamado por rdt para enviar, por el canal no
fiable, una PDU.
rdt_rcv(): llamado desde el nivel inferior cuando tiene disponible una PDU que ha
llegado lado del receptor por el canal no fiable.
deliver_data(): llamado por rdt para pasar los datos al
nivel superior (lado del receptor).
Servicio de transferencia fiable: Empezando…
udt = Unreliable Data Transfer (Trasferencia de datos no fiable) Transporte 3-39
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 solo al Nivel de Transporte.
estado1
estado2
evento que causa cambio de estadoacciones tomadas al cambiar de estado
estado: estando en un cierto “estado” el
próximo estado depende
únicamente del próximo evento.
eventoacciones
Servicio de transferencia fiable: Empezando…
Transporte 3-40
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).Espera llamada desde arriba
packet = make_pkt(data)udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Espera llamada desde abajo
rdt_rcv(packet)
Emisor (Tx) Receptor (Rx)
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
rdt_send(data)
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Máquina de estados
del emisor(Tx)
Máquina de estados
del receptor (Rx)
rdt2.0: Maquina de estados finitos (FSM)
Espera ACK o NAK
Espera llamada desde abajo
Espera llamada desde arriba
Ambos, Tx y Rx, usan udt_send() para enviar sus
PDUs por el canal no fiable
implementado por el nivel
inferior.Ambos, Tx y Rx,
esperan el evento rdt_rcv() que les
entrega una PDU que llega desde el nivel inferior (no fiable).
Transporte 3-43
rdt_send(data)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
rdt2.0: Operación en escenario sin errores
Espera ACK o NAK
Espera llamada desde abajo
Espera llamada desde arriba
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
Transporte 3-44
rdt_send(data)
rdt2.0: Operación en escenario con errores
Espera llamada desde arriba
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Espera ACK o NAK
Espera llamada desde abajo
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
Transporte 3-45
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.
El emisor envía una PDU y espera la respuesta del receptor.
Parada y espera
Transporte 3-46
rdt2.1: Máquina de estados del Emisor.Soluciona el problema de los ACK/NAKs corruptos.
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for call 1 from
above
Wait for ACK or NAK 1
Transporte 3-47
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for 0 from below
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for 1 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt2.1: Máquina de estados del Receptor.Soluciona el problema de los ACK/NAKs corruptos.
Transporte 3-48
rdt2.1: Discusión
Emisor (Tx): Añade número de
secuencia a las PDUs Basta con usar dos
números de secuencia distintos (O y 1) ¿Por qué?
Debe comprobar si la PDU de control ACK/NAK está corrupta.
Se duplican los estados El estado “recuerda” si la
PDU “actual” tiene número de secuencia 0 o 1.
Receptor (Rx): Debe comprobar si la
PDU recibida es un duplicado. El estado indica si es
0 o 1 el número de secuencia esperado.
El Rx no puede saber si el último ACK/NAK que envió llego corrupto o no al TX.
Transporte 3-49
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-50
rdt2.2: Trozos de las máquinas de estados
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for ACK
0Trozo
máquina Tx
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)
Wait for 0 from below
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))
udt_send(sndpkt)
Trozo máquina
Rx
Transporte 3-51
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-52
stop_timerstop_timer
rdt3.0 Emisor (Tx)
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
Wait for
ACK0
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )
Wait for call 1 from
above
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)
udt_send(sndpkt)start_timer
timeout
udt_send(sndpkt)start_timer
timeout
rdt_rcv(rcvpkt)
Wait for call 0from
above
Wait for
ACK1
rdt_rcv(rcvpkt)
Diseñe la máquina de estados del receptor del protocolo
rdt3.0
Ejercicio
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
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-56
Tema 3: Nivel de Transporte
TCP: Visión general RFCs: 793, 1122, 1323, 2018, 2581
Servicio Full-Duplex: Por una conexión fluyen
datos bidireccionalmente.
MSS: Tamaño Máximo del Segmento (de los 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.
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
socketdoor
T C Psend buffer
T C Preceive buffer
socketdoor
segm en t
applicationwrites data
applicationreads data
Transporte 3-57
Estructura del segmento TCP (T_PDU)
Nº puerto Orig.Nº puerto dest.
32 bits
Datos del nivel de aplicación
(longitud variable)
Número de secuencia
Número de ACKVentana de Rx
Punt. Datos Urg.checksum
FSRPAULong.Cabe.
nousado
Opciones (long. variable)
URG: datos urgentes (no se suele usar)
ACK: indica que el nº de ACK es
válido
PSH: “empuja” datos ahora
(no se suele usar)
RST, SYN, FIN:Comandos para
establecer la conexión y terminarla
Nº de bytes que está dispuesto a aceptar el Rx
Cuentan los bytes de datos, no las PDUs
Internetchecksum
(como en UDP)
T_PCI
T_UD
Transporte 3-58
Longitud Cabecera (T_PCI) en palabras de 32 bits (4 bytes)
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: ¿Como trata el receptor los segmentos desordenados? R: La especificación de TCP lo deja a criterio del
implementador.Transporte 3-59
Nº de secuencia y de ACK en TCP(II)Entidad TCP Host A Entidad TCP Host B
42, 79, 10
79, 52, 13
52 ,92,0
Btx contiene “DIEZ BYTES”
tiempo
Escenario simple
- 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 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 .
Notas
Transporte 3-60
SEC, ACK, nºbytes UD
Btx contiene “TRECE BYTES ?”
Brx contiene “DIEZ BYTES”
Btx vacío
Brx contiene “TRECE BYTES ?”
Btx vacío
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 lo
calcularemos como la media de los valores de RTTmuestra más recientes.
Transporte 3-61
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
TCP estima el RTT para saber qué valor usar de time_out
Transporte 3-62
Ejemplo de estimación del RTTRTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
TCP estima el RTT para saber qué valor usar de time_out
Transporte 3-63
¿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:
Time_out = RTTestimado + 4*RTTdesv
RTTdesv = (1-)*RTTdesv + *|RTTmuestra-RTTestimado|(típicamente: = 0.25)
Así, el time_out podría calcularse como:
TCP estima el RTT para saber que valor usar de time_out
Transporte 3-64
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-65
Tema 3: Nivel de Transporte
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.
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-66
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 temporizadorLlega 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”
Arranca el temporizador solo si aún hay “en vuelo” datos pendientes de ACK.
Transporte 3-67
Emisor TCP (simplificado)SigNumSec = NumeroSecuenciaInicial
BaseEmision = NumeroSecuenciaInicialwhile ( true ) { switch( evento )
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)
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
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 */ iniciar el temporizador } } /* fin del bucle infinito */
Todos los bytes de datos con nº de secuencia menor a BaseEmision están reconocidos acumulativamente. Los de nº mayor o igual están pendientes de ser reconocidos.
El receptor nos envía acuse de recibo de todos los datos con nº de secuencia menores que y
SigNumSec apunta a datos “no enviados”.
Transporte 3-68
TCP: escenarios con retransmisiones (I)
Host A
100, 50,20
50,100,0
Escenario time_out
prematuro
Host B
92,50, 8
50,120,0
92, 50, 8
50,120,0
Host A
92, 50, 8
50,100,0perdido
EscenarioACK perdido
Host B
92, 50,8
50,100,0
tiempo
BaseEmision=120
tiempo
BaseEmision=100
Tim
e_o
ut
Sec=
92
Tim
e_o
ut
Sec=
92
BaseEmision= 100
Expira Expira
Transporte 3-69
BaseEmision=120
Host A
92, 50,8
50,100,0
Host B
100, 50,20
50,120,0
EscenarioACK
acumulativo
tiempo
perdido
TCP: escenarios con retransmisiones (II)
Tim
e_o
ut
Sec=
92
BaseEmision=120
No expira
Tim
e_o
ut
Sec=
92
El temporizador con la duración “recomendada” habría expirado antes de la llegada del ACK=120.El transmisor puede usar en ciertas 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-70
TCP: Generación del ACK [RFC 1122, RFC 2581]Evento en el Receptor TCP
Llegada de segmento en orden, con el nº de secuencia esperado. Todos los datos hasta el nº de secuencia esperado ya han sido reconocidos.
Llegada de segmento en orden, con el nº de secuencia esperado. Hay un segmento anterior pendiente de reconocer.
Llegada de segmento fuera de orden, con nº de secuencia mayor del esperado. Se detecta un “hueco” en los datos recibidos.
Llegada de un segmento que “rellena” total o parcialmente el “hueco” y que tiene el nº de secuencia esperado (“rellena” el “hueco” por su comienzo o límite inferior).
Acción del receptor TCP
ACK retardado. Esperar hasta un máximo de 500ms a que llegue el siguiente segmento en orden.Si no llegase, enviar ACK.
Enviar inmediatamente un ACK acumulativo que reconozca ambos segmentos ordenados.
Enviar inmediatamente un ACK duplicado, indicando el nº de secuencia del byte que se espera recibir.
Enviar inmediatamente un ACK para el segmento recibido o acumulativo dependiendo de si receptor almacena los UD de los segmentos fuera de orden.
Transporte 3-71
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 (3) 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.
TCP no usa NAKs, por lo que el receptor no puede avisar de que le falta un
segmento.
Nota
Transporte 3-72
Host A Host B
Reenviar 2º segmento
tiempo
Tim
e_o
ut
2º
segm
ento
No expira
TCP: Retransmisión rápida
El emisor al ver que, por tres veces, le llega un ACK 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.
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.
50,¿4?,0
ACK duplicado
ACK duplicado
ACK duplicado
Transporte 3-73
100, 50,20
92, 50, 8
¿1?, 50,30 ¿2?, 50,40 ¿3?, 50,50
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 */ iniciar el temporizador } 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*/ iniciar el temporizador } }
TCP: Retransmisión rápidaEste 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
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-75
Tema 3: Nivel de Transporte
Control de flujo en TCP El lado receptor de una conexión
TCP tiene un buffer de recepción donde se acumulan los datos que llegan desde el nivel inferior.
Servicio de ajuste de velocidades: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.
Puede que el proceso de aplicación sea muy lento leyendo del buffer de recepción TCP.
Conseguir que el emisor no desborde el buffer del receptor por
culpa de transmitir demasiados datos, demasiado rápido.
Control de flujo
Transporte 3-76
BufferRecepcion
VentanaRecepcion
Espacio libre en el
Buffer TCP
Datos en el Buffer TCP, esperando ser
leídos por la aplicación
Datos de IP
Hacia el proceso de aplicación
Va variando su tamaño
Tamaño fijo
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)
Transporte 3-77
BufferRecepcion
VentanaRecepcion
Espacio libre en el
Buffer TCP
Datos en el Buffer TCP, esperando ser
leídos por la aplicación
Datos de IP
Hacia el proceso de aplicación
Va variando su tamaño
Tamaño fijo
Esta diferencia indica lo que hay “ocupado”
Control de flujo en TCP (funcionamiento)
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-78
BufferRecepcion
VentanaRecepcion
Espacio libre en el
Buffer TCP
Datos en el Buffer TCP, esperando ser
leídos por la aplicación
Datos de IP
Hacia el proceso de aplicación
Tamaño fijo
Control de flujo en TCP (funcionamiento)
Va variando su tamaño
El valor del campo VentanaRecepcion de la T_PCI está relacionado con el valor del campo NºdeACK de la T_PCI.
Cuando el emisor recibe un segmento, observa el valor del campo NºdeACK y el valor del campo VentanaRecepcion para conocer el rango de números de secuencia correspondientes a los datos que está autorizado a tener “en vuelo”, pendientes de confirmación:
Transporte 3-79
Desde NºdeACK hasta (NºdeACK + VentanaRecepcion – 1)
Nº puerto Orig.Nº puerto Dest.
Datos del nivel de aplicación
(longitud variable)
Número de secuencia
Número de ACKVentana de Rx
Punt. Datos Urg.checksum
FSRPAULong.Cabe.
nousado
Opciones (long. variable)
T_P
CI
T_U
D
Estructura del segmento (T_PDU)
Control de flujo en TCP (funcionamiento)
3.1 Servicios del nivel de transporte
3.2 Multiplexión y demultiplexión
3.3 Transporte sin conexión: UDP
3.4 Principios de la transferencia fiable
3.5 Transporte orientado a la conexión: TCP Estructura del segmento TCP Transferencia de datos fiable Control de flujo Gestión de la conexión
Transporte 3-80
Tema 3: Nivel de Transporte
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ónSocket socketCliente = new Socket(“NombreHost”,NumPuerto);
servidor: Estaba “a la escucha” y es contactado por el clienteSocket socketConexion = socketAcogida.accept(); Transporte 3-81
Gestión de la conexión en TCP: Establecimiento
cliente
SYN, NumSec=nsi_cliente (no lleva ACK ni DATOS)
servidor
SYN, NumSec=nsi_servidor, ACK=nsi_cliente+1 (no lleva DATOS)
NumSec=nsi_cliente+1, ACK=nsi_servidor+1 (no suele llevar DATOS)
Proceso de acuerdo en tres fases
tiempotiempo
Gestión de la conexión en TCP: Establecimiento
Transporte 3-82
En el flujo de TCP_PDUs (segmentos) si un determinado flag está activo, se indica en el etiquetado, menos el del ACK que está implícito cuando el campo ACK tiene valor.
Nota
X.accept()
new socket
Conexión establecida
Servidor puede Enviar datos
Clientepuede Enviar datos
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 mísmas 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-83
Gestión de la conexión en TCP: Establecimiento
Transporte 3-84
Un segmento FIN es aquél que tiene activado el bit FIN, que a todos los efectos es considerado como el último byte del flujo de datos de la conexión TCP.
La entidad TCP que envía un segmento FIN ya no puede enviar más datos, pero puede seguir recibiéndolos.
esp
era
te
mpori
zada
cliente
FIN NS =X ACK= Y
servidor
NS = Y ACK=
X+1
NS= X+1, ACK = Y+1
FIN NS= Y ACK = X +1
socketCliente.close();
socketConexion.close();
Conexión cerrada
Cierre de la conexión TCP
Conexión cerrada
tiempotiempo
Gestión de la conexión en TCP: Cierre de la conexión
Tanto cliente como servidor pueden iniciar el cierre de la misma.
Nota
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).
Gestión de la conexión en TCP: Cierre de la conexión
Transporte 3-85
Transporte 3-86
Gestión de la conexión en TCP: Cierre de la conexión 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
CLOSING
LAST_ACK CLOSE_WAIT
ESTABLISHEDLISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1SYN_RCVD
SYN_SENT
CLOSED
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.
Transporte 3-88
Gestión de la conexión en TCP: Ciclo de vida
CLOSING
LAST_ACK CLOSE_WAIT
ESTABLISHEDLISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1SYN_RCVD
SYN_SENT
CLOSED
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.
Transporte 3-89
Gestión de la conexión en TCP: Ciclo de vida
CLOSING
LAST_ACK CLOSE_WAIT
ESTABLISHEDLISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1SYN_RCVD
SYN_SENT
CLOSED
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.
Gestión de la conexión en TCP: Ciclo de vida
En verde, podemos ver las transiciones del ciclo de vida típico de un cliente.
En rojo, aparece el ciclo de vida típico de un servidor.
Las transiciones de color negro son posibles pero no son tan habituales.
Transporte
CLOSING
LAST_ACK CLOSE_WAIT
ESTABLISHEDLISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1SYN_RCVD
SYN_SENT
CLOSED
3-90
Gestión de la conexión en TCP: Ciclo de vida
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”.
ESTABLISHED
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_SENT
CLOSED
Transporte 3-91
Gestión de la conexión en TCP: Ciclo de vida
Aquí podemos ver todas las combinaciones “evento/acción” de las transiciones del ciclo de vida típico del cliente.
ESTABLISHED FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_SENT
CLOSED
Transporte 3-92
Aplicación cliente inicia una conexión
Enviar segmento SYN
Se recibe segmento SYN-ACK
Enviar ACK del SYN
Transcurre 2 veces el tiempo MSL
No enviar nada
Se recibe ACK del FIN
No enviar nada
La aplicación indica que quiere cerrar la conexión
Enviar segmento FIN
Enviar ACK del FIN
Se recibe segmento FIN
NOTA: MSL (Maximum Segment Life), es el tiempo (estimado) de vida máximo de un segmento en la red.
Gestión de la conexión en TCP: Ciclo de vida
LAST_ACK CLOSE_WAIT
ESTABLISHEDLISTEN
SYN_RCVD
CLOSED
Transporte 3-93
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.
Gestión de la conexión en TCP: Ciclo de vida
Aquí podemos ver todas las combinaciones “evento/acción” de las transiciones del ciclo de vida típico del servidor.
CLOSED
Transporte 3-94
Aplicación servidora crea socket “de
acogida”
Se recibe segmento SYN
Enviar segmento ACK-SYN
Se recibe ACK del FIN
No enviar nada
Enviar ACK del FIN
Se recibe segmento FIN
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
SYN_RCVD
No enviar nada
Se recibe ACK del SYN
No enviar nada
La aplicación indica que quiere cerrar la
conexiónEnviar segmento FIN
Tema 3: Resumen
Hemos visto los principios que hay detrás de los servicios del Nivel de Transporte: Multiplexión y
demultiplexión. Transferencia de datos
fiable Control de flujo
Hemos estudiado los protocolos de internet proporcionan los servicios del nivel de transporte: UDP TCP
A continuación: Abandonamos
la “frontera” de la red (Niveles de aplicación y de transporte)
Entraremos en el “núcleo” de la red.
Transporte 3-95
Tema 3: PROBLEMAS
Transporte 3-96
Problema 1
Transporte 3-97
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?
Problema 2
Transporte 3-98
Observe las conexiones que han iniciado los clientes con el servidor Web y responda a lo siguiente:
P1
cliente IP: A
P1P2P4
Servidor WebIP: C
PO: 9157
PD: 80PO: 9157
PD: 80
P5 P6 P3
IP-D: C
IP-O: A
IP-D: CIP-O: B
PO: 5775
PD: 80
IP-D: CIP-O: B
cliente IP: B
PO = Nº de Puerto OrigenPD = Nº de Puerto DestinoIP-O = Dir. IP OrigenIP-D = Dir. IP Destino
Problema 2 (continuación)
Transporte 3-99
¿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?
Problema 3
Transporte 3-100
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.
Problema 4
Transporte 3-101
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
Transporte 3-102
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.
Problema 6
Transporte 3-103
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
Transporte 3-104
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.
Problema 7 (continuación)
Transporte 3-105
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.
Problema 8
Transporte 3-106
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
Transporte 3-107
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?
Problema 9 (continuación)
Transporte 3-108
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.
Problema 10
Transporte 3-109
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
Transporte 3-110
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
Transporte 3-111
¿Qué relación podemos establecer entre la variable BaseEmision del emisor TCP y la variable UltimoByteRecibido del receptor TCP?
Problema 13
Transporte 3-112
¿Qué relación podemos establecer entre la variable y del emisor TCP y la variable UltimoByteRecibido del receptor TCP?
Problema 14
Transporte 3-113
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
Transporte 3-114
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?