Tema 3 - Departamento de Tecnología Electrónica

REDES DE COMPUTADORES
Tema 3: Nivel de Transporte
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
Departamento de
Tecnología Electrónica
Some material copyright 1996-2010
J.F Kurose and K.W. Ross, All Rights Reserved
Transporte
3-1
Tema 3: Nivel de Transporte
Objetivos:
 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
Tema 3: Nivel de Transporte
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
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
enlace
física
aplicación
transport.
red
enlace
física
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
aplicación
transporte
red
enlace
física
destino
Protocolo aplicación
Protocolo transporte
Protocolo red
Protocolo enlace
Protocolo físico
red
enlace
física
router
Protocolo red
Protocolo enlace
Protocolo físico
aplicación
transporte
red
enlace
física
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).

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
enlace
física
red
enlace
física
red
enlace
física
red
enlace
física
red
enlace
física
red
enlace
física
red
enlace
física
aplicación
transport.
red
enlace
física
Transporte
3-8
Tema 3: Nivel de Transporte
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
Multiplexión/demultiplexión
Multiplexión al enviar
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 recibir
Entregar en el socket correcto el
contenido de los segmentos
(T_PDU) recibidos, gracias a la
info. de la cabecera (T_PCI).
= socket
aplicación
transporte
red
P3
P1
P1
aplicación
transporte
P2
= proceso
P4
aplicación
transporte
red
red
enlace
enlace
enlace
física
física
física
host 1
host 2
host 3
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_PCI
un nº de puerto origen y
un 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.
32 bits
Nº puerto origen
Nº puerto destino
Otros campos de
la cabecera (T_PCI)
T_UD:
Datos del nivel
de aplicación
(mensaje)
Formato de la T_PDU
de TCP/UDP
1 Cierto si no hay fragmentación
Transporte
3-11
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:

 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.
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:

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
Demultiplexión sin conexión (UDP)
Nº de puerto local. Obligatorio especificarlo si es un proceso servidor.
DatagramSocket serverSocket = new DatagramSocket(6428);
P2
P1
P1
P3
PO: 6428
PO: 6428
PD: 9157
PD: 5775
PO: 9157
cliente
IP: A
PD: 6428
PO: 5775
servidor
IP: C
La IP origen y el Puerto Origen permitirán a
P3 identificar al proceso origen (P1 o P2) y
devolverle un mensaje.
PD: 6428
cliente
IP: B
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
Transporte
3-13
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
Demultiplexión orientada a la
 … en el servidor al recibir una
conexión (TCP)
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).
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);
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 en TCP:
Servidor Web con varios procesos
P1
P4
P5
P2
P6
P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
cliente
IP: A
PO: 9157
PD: 80
IP-O: A
servidor
IP: C
PD: 80
IP-O: B
IP-D: C
IP-D: C
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen
IP-D = Dir. IP Destino
PO: 9157
No es problema que
dos procesos cliente
usen el mismo
puerto origen
cliente
IP: B
No es problema
que dos procesos
cliente usen la
misma IP origen
Transporte
3-16
Demultiplexión en TCP:
Servidor Web multihilo (threaded)
P1
cliente
IP: A
En lugar de un
proceso servidor
por cada socket,
hay un “hilo” por
socket y un solo
proceso.
PO: 9157
PD: 80
IP-O: A
IP-D: C
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen
IP-D = Dir. IP Destino
P4
P2
P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
servidor
IP: C
PO: 9157
PD: 80
IP-O: B
IP-D: C
cliente
IP: B
Transporte
3-17
Tema 3: Nivel de Transporte
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
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.
¿Por qué existe UDP?


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.

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
T_PCI
T_UD
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
longitud
Nº puerto destino
checksum
Datos del nivel
de aplicación
(mensaje)
Formato de la T_PDU
de 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 !
Transporte
3-20
Checksum (suma de comprobación) UDP
Objetivo: detectar “errores” (e.g., bits “cambiados”)
en una T_PDU transmitida
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…
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
Suma (con acarreo)
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Transporte
3-22
Tema 3: Nivel de Transporte
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
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 !
 ¿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 duplicadas
Añ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.
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
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:


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, entonces
o 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
Principios de la transferencia fiable
PCI
 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.

Time_out
dtransPDU
dtransack
PDU perdida
Tiempo
Time_out
Tx
Sin errores
Rx
X
Tx Con errores Rx
PDU errónea
Transporte
3-29
Principios de la transferencia fiable
 Ejemplo 2.
• Idem ejemplo 1.
X
• Receptor también envía
PDU de control NACK.
• Sin errores.
 Mismo comportamiento
tiempo
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.
 ¿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.

Transporte
3-31
Eficiencia del protocolo parada y espera
Recuerda
dtrans = L/R
Rx
Tx
Primer bit PDU enviado, t = 0
Último bit PDU enviado, t = L / R
Primer bit PDU recibido
Último bit PDU recibido, enviar ACK
RTT
Recibido ACK, t = RTT + L / R
Enviar próxima PDU
U
transmisor
=
L/R
RTT + L / R
Transporte
3-32
Eficiencia del protocolo parada y espera


El protocolo funciona, pero su eficiencia es mala
Ejemplo: enlace de 1 Gbps, 30 ms de RTT, PDU 1KByte
L 8kb / pdu
dtrans  
 8s
9
R 10 b / s
U transmisor 



L/ R
0,008

 0,00027
RTT  L / R 30,008
1 PDU de 1KByte cada 30,008 ms -> 33,3kByte/s tasa de transferencia
efectiva en un enlace de 1 Gbps
¡El Protocolo limita el uso de los recursos físicos!
¿Se puede mejorar?
Transporte
3-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.
PDU
PDU
ACK
Parada y espera
NOTA: Profundizaremos en este concepto al abordar TCP
Pipeline
Transporte
3-34
El “pipeline” mejora mucho la eficiencia
Tx
Rx
Envío bit 1 de 1ª PDU, t = 0
Envío último bit de PDU, t = L / R
Llega primer bit de 1ª PDU
Llega último bit 1ª PDU, envío ACK
Llega últimobit 2ª PDU, envío ACK
Llega último 3ª PDU, envío ACK
RTT
ACK recibido, envío siguiente
PDU, la 4ª, t = RTT + L / R
U
transmisor
Tener hasta 3 PDUs
“en vuelo” multiplica
la eficiencia por un
factor de 3
=
3*L/R
RTT + L / R
=
0,024
30,008
= 0,0008
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?
El nivel de transporte tiene debajo el nivel de red, que le
proporciona un servicio de transferencia no fiable (“unreliable”).
Transporte
3-37
Servicio de transferencia fiable


El nivel de transporte debe implementar un protocolo de
transferencia fiable “reliable data transfer (rdt) protocol”.
Las características concretas del canal no fiable condicionarán la
complejidad del protocolo rdt. Vamos a ir “experimentando” con
distintos tipos de canales no fiables.
Transporte
3-38
Servicio de transferencia fiable: Empezando…
rdt_send(): llamado desde el nivel
superior, (p.e., por la Aplic.) Nos pasa
los datos que deberemos suministrar al
receptor del nivel superior.
Lado del
emisor
(Tx)
udt_send(): llamado por rdt
para enviar, por el canal no
fiable, una PDU.
udt = Unreliable Data Transfer
(Trasferencia de datos no fiable)
deliver_data(): llamado por
rdt para pasar los datos al nivel
superior (lado del receptor).
Lado del
Receptor
(Rx)
rdt_rcv(): llamado desde el nivel
inferior cuando tiene disponible
una PDU que ha llegado lado del
receptor por el canal no fiable.
Transporte
3-39
Servicio de transferencia fiable: Empezando…




Implementaremos de forma incremental el lado emisor y el lado
receptor del protocolo rdt.
Como antes, consideraremos, por simplicidad, transferencia de
datos de usuario unidireccional, de emisor a receptor (de Tx a Rx).
 ¡ OJO ! La información de control fluye en ambas direcciones
Usaremos máquinas de estados finitos (FSM) para especificar el
emisor y el receptor.
El protocolo rdt realmente es aplicable a cualquier nivel que deba
proporcionar fiabilidad, y no solo al Nivel de Transporte.
evento que causa cambio de estado
acciones tomadas al cambiar de estado
estado: estando en un
cierto “estado” el
próximo estado
depende únicamente
del próximo evento.
estado
1
evento
acciones
estado
2
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
rdt_send(data)
packet = make_pkt(data)
udt_send(packet)
Emisor (Tx)
Espera
llamada
desde
abajo
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
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
rdt2.0: Maquina de estados finitos (FSM)
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Espera
Espera
ACK o
NAK
llamada
desde
arriba
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Máquina de
estados
del emisor
(Tx)
Máquina de
estados
del receptor
(Rx)
L
Ambos, Tx y Rx,
esperan el evento
rdt_rcv() que les
entrega una PDU que
llega desde el nivel
inferior (no fiable).
Ambos, Tx y Rx,
usan udt_send()
para enviar sus
PDUs por el canal
no fiable
implementado por
el nivel inferior.
Espera
llamada
desde
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
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) &&
isNAK(rcvpkt)
Espera
Espera
ACK o
NAK
llamada
desde
arriba
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
Espera
llamada
desde
abajo
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) &&
isNAK(rcvpkt)
Espera
Espera
ACK o
NAK
llamada
desde
arriba
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
Espera
llamada
desde
abajo
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
control (ACK o NAK) se
corrompe (tiene bits
erróneos)?



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 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
Parada y espera
dos veces y no darse cuenta
El emisor envía una PDU y espera
de que es la misma PDU !
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
isNAK(rcvpkt) )
ACK or
call 0 from
udt_send(sndpkt)
NAK 0
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
L
Wait for
ACK or
NAK 1
Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
Transporte
3-47
rdt2.1: Máquina de estados del Receptor.
Soluciona el problema de los ACK/NAKs corruptos.
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Wait for
0 from
below
Wait for
1 from
below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
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
su 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
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for
Wait for
isACK(rcvpkt,1) )
ACK
call 0 from
0
udt_send(sndpkt)
above
Trozo
máquina Tx
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
Wait for
0 from
below
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
Trozo
máquina Rx
L
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
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
rdt3.0 Emisor (Tx)
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait
for
ACK0
Wait for
call 0from
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
timeout
udt_send(sndpkt)
start_timer
L
Wait
for
ACK1
Wait for
call 1 from
above
rdt_rcv(rcvpkt)
L
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
Ejercicio
Diseñe la máquina de estados del
receptor del protocolo rdt3.0
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
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
TCP: Visión general

Punto a punto:
RFCs: 793, 1122, 1323, 2018, 2581

 Por una conexión fluyen
datos bidireccionalmente.
 Un emisor, un receptor (no
multidifusión)


Flujo de bytes, fiable y
ordenado:

MSS: Tamaño Máximo del
 Sin “frontera” entre los
mensajes (A_PDUs)

Orientado a conexión:
Usa “pipeline”:
socket
door
Buffers de Btx y Brx
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
Segmento (de los UD).
 Acuerdo previo al envío de
datos. El emisor toma la
iniciativa enviando un
mensaje de control, que el
receptor debe estar
esperando.
 El control de flujo de TCP
fija el tamaño de la ventana
(máx. nº datos “en vuelo”)

Servicio Full-Duplex:

Control de flujo:
 El emisor no debe
socket desbordar al receptor.
door
segment
Transporte
3-57
Estructura del segmento TCP (T_PDU)
ACK: indica que el
nº de ACK es válido
URG: datos urgentes
(no se suele usar)
Longitud Cabecera
(T_PCI) en palabras
de 32 bits (4 bytes)
PSH: “empuja” datos
ahora
(no se suele usar)
RST, SYN, FIN:
Comandos para
establecer la
conexión y
terminarla
Internet
checksum
(como en UDP)
32 bits
Nº puerto Orig. Nº puerto dest.
Número de secuencia
Número de ACK
Long. no
UA P R S F
Cabe. usado
checksum
Ventana de Rx
Punt. Datos Urg.
Opciones (long. variable)
Datos del nivel de
aplicación
(longitud variable)
Cuentan los
bytes de
datos, no
las PDUs
T_PCI
Nº de
bytes que
está
dispuesto
a aceptar
el Rx
T_UD
Transporte
3-58
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)
Escenario simple
Entidad TCP Host A
Btx contiene
“DIEZ BYTES”
Entidad TCP Host B
Btx vacío
Btx vacío
Brx contiene “DIEZ BYTES”
Btx contiene “TRECE BYTES ?”
Brx contiene “TRECE
BYTES ?”
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
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 .
tiempo
Transporte
3-60
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
TCP estima el RTT para saber
qué valor usar de time_out
RTTestimado = (1-)* RTTestimado +  * RTTmuestreado



Media móvil exponencialmente ponderada .
La influencia de una muestra anterior sobre el nuevo valor
estimado decrece de una forma exponencialmente rápida.
Se suele usar, típicamente:  = 0.125
Transporte
3-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
RTT (milliseconds)
300
250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
Estimated RTT
Transporte
3-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:
|RTTmuestra-RTTestimado|
RTTdesv = (1-)*RTTdesv + *
(típicamente:  = 0.25)
Así, el time_out podría calcularse como:
Time_out = RTTestimado + 4*RTTdesv
Transporte
3-64
Tema 3: Nivel de Transporte
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
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 temporizador
Llega un ACK…
 …correspondiente a datos de los
cuales no se había recibido aún
un ACK:
 Actualiza el indicador que
apunta a los “datos más
antiguos pendientes de ACK”
y detiene el temporizador.
 Arranca el temporizador solo
si aún hay “en vuelo” datos
pendientes de ACK.
Transporte
3-67
Emisor TCP (simplificado)
SigNumSec = NumeroSecuenciaInicial
BaseEmision = NumeroSecuenciaInicial
while ( true ) {
switch( evento )
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.
evento: datos recibidos de la aplicación
/* Llegan datos de la capa superior*/
crear segmento TCP con datos y número de secuencia SigNumSec
if ( el temporizador está parado )
iniciar el temporizador
pasar el segmento a IP
/* La capa inferior, no fiable, hará llegar el segmento al Rx */
SigNumSec = SigNumSec + longitud(datos)
SigNumSec apunta a datos “no enviados”.
evento: el temporizador expira
/* Se ha producido un time_out */
retransmitir el segmento pendiente de ACK con menor número de secuencia
iniciar el temporizador
El receptor nos envía acuse de
recibo de todos los datos con nº
de secuencia menores que y
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 */
Transporte 3-68
TCP: escenarios con retransmisiones (I)
Host A
Host B
Host B
Time_out Sec=92
Time_out Sec=92
Host A
perdido
Expira
BaseEmision=100
Expira
BaseEmision=120
BaseEmision
= 100
tiempo
Escenario
ACK perdido
BaseEmision=120
Escenario
time_out
prematuro
tiempo
Transporte
3-69
TCP: escenarios con retransmisiones (II)
BaseEmision=120
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.
No expira
Time_out Sec=92
Time_out Sec=92
Host A
Host B
perdido
tiempo
Escenario
ACK
acumulativo
Transporte
3-70
TCP: Generación del ACK
Evento en el Receptor TCP
[RFC 1122, RFC 2581]
Acción del 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.
ACK retardado. Esperar hasta un
máximo de 500ms a que llegue el
siguiente segmento en orden.
Si no llegase, enviar ACK.
Llegada de segmento en orden, con el nº
de secuencia esperado. Hay un segmento
anterior pendiente de reconocer.
Enviar inmediatamente un ACK
acumulativo que reconozca ambos
segmentos ordenados.
Llegada de segmento fuera de orden, con
nº de secuencia mayor del esperado. Se
detecta un “hueco” en los datos recibidos.
Enviar inmediatamente un ACK
duplicado, indicando el nº de
secuencia del byte que se espera
recibir.
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).
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.
Nota
TCP no usa NAKs, por lo que
el receptor no puede avisar
de que le falta un segmento.
Transporte
3-72
TCP: Retransmisión rápida
Time_out 2º segmento
Host A
No expira
Host B
La llegada de estos tres
segmentos fuera de orden
ha hecho que el receptor
envíe inmediatamente un
ACK duplicado para cada
uno de ellos, reconociendo
los datos del primer
segmento.
El emisor al ver que, por
tres veces, le llega un ACK
duplicado de los datos del
primer segmento, supone
que el segundo segmento se
ha perdido y lo reenvía
rápido, antes de que expire
su temporizador.
tiempo
Transporte
3-73
TCP: Retransmisión rápida
Este es el evento de recepción de ACK
en el emisor TCP simplificado.
evento: recibido ACK con campo nº de ACK valiendo y
if ( y > BaseEmision ) { /* Si están reconociendo datos no reconocidos anteriormente */
BaseEmision = y /* Actualizar indicador datos reconocidos/pendientes de ACK */
detener el temporizador
if ( SigNumSec > BaseEmision ) /* Si hay datos “en vuelo” pendientes de ACK */
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
}
}
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
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
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.
VentanaRecepcion
Datos
de IP
Espacio
libre en el
Buffer TCP
Control de flujo
Conseguir que el emisor
no desborde el buffer
del receptor por culpa de
transmitir demasiados
datos, demasiado rápido.
Va variando su tamaño
Hacia el
proceso de
aplicación
Datos en el Buffer TCP,
esperando ser leídos
por la aplicación

Tamaño fijo

BufferRecepcion
Puede que el proceso de
aplicación sea muy lento
leyendo del buffer de
recepción TCP.
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.
Transporte
3-76
Control de flujo en TCP (funcionamiento)
VentanaRecepcion
Datos
de IP
Espacio
libre en el
Buffer TCP
Tamaño fijo


Va variando su tamaño
Datos en el Buffer TCP,
esperando ser leídos
por la aplicación
Hacia el
proceso de
aplicación
BufferRecepcion
Supondremos que el receptor TCP descarta los segmentos que recibe
desordenados, por lo que esos no ocupan espacio en el buffer de Rx.
Espacio libre en el buffer de recepción:
VentanaRecepcion = BufferRecepcion – (UltimoByteRecibido – UltimoByteLeido)
Esta diferencia indica lo
que hay “ocupado”
Transporte
3-77
Control de flujo en TCP (funcionamiento)
VentanaRecepcion
Datos
de IP
Espacio
libre en el
Buffer TCP
Tamaño fijo



Va variando su tamaño
Datos en el Buffer TCP,
esperando ser leídos
por la aplicación
Hacia el
proceso de
aplicación
BufferRecepcion
El receptor informa al emisor del espacio libre en el buffer gracias al
campo VentanaRecepcion presente en la cabecera (T_PCI) de los
segmentos (T_PDU) que envía.
El emisor limita el número de datos “en vuelo” pendientes de ACK de
forma que quepan en la VentanaRecepcion
Esto garantiza que el BufferRecepcion nunca se desborda.
Transporte
3-78
Control de flujo en TCP (funcionamiento)
Número de secuencia
Número de ACK
Long. no
UA P R S F
Cabe. usado
checksum
Ventana de Rx
Punt. Datos Urg.
T_PCI

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:
Opciones (long. variable)
T_UD

Nº puerto Orig. Nº puerto Dest.
Datos del nivel de
aplicación
(longitud variable)
Estructura del
segmento (T_PDU)
Desde NºdeACK hasta (NºdeACK + VentanaRecepcion – 1)
Transporte
3-79
Tema 3: Nivel de Transporte
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
Gestión de la conexión en TCP: Establecimiento
Recuerde: El cliente y el servidor TCP establecen la conexión antes
de intercambiar segmentos que transporten datos de usuario.


Durante la fase de establecimiento de la conexión, ambos deben
inicializar las variables de TCP:
 Números de secuencia a usar.
 Buffers de transmisión y recepción (ambos en cliente y servidor).
 Información de control de flujo (ej: VentanaRecepcion).
 Etc.
cliente: Es el que toma la iniciativa de establecer la conexión
Socket socketCliente = new Socket(“NombreHost”,NumPuerto);

servidor: Estaba “a la escucha” y es contactado por el cliente
Socket socketConexion = socketAcogida.accept();
Transporte
3-81
Gestión de la conexión en TCP: Establecimiento
cliente
Proceso de acuerdo en tres fases
servidor
new socket
X.accept()
Servidor
puede
Enviar
datos
Conexión
establecida
Cliente
puede
Enviar
datos
tiempo
Nota
En el flujo de 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.
tiempo
Transporte
3-82
Gestión de la conexión en TCP: Establecimiento
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: Cierre de la conexión
Cierre de la conexión TCP
servidor
cliente
socketCliente.close();

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.
socketConexion.close();
espera
temporizada

Conexión cerrada
tiempo
Conexión cerrada
Nota
Tanto cliente como servidor
pueden iniciar el cierre de la
misma.
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).
Paso 5: El servidor TCP recibe el ACK correspondiente a su FIN y da
por cerrada la conexión TCP (liberando buffers y demás recursos).
Transporte
3-85
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-86
Gestión de la conexión en TCP: Ciclo de vida


Ciclo de vida de una conexión TCP: Es la secuencia de
estados por los que pasa una conexión TCP.
La siguiente máquina de estados muestra los 11 estados
posibles y las diferentes transiciones que pueden darse,
de un estado a otro.
CLOSED
LAST_ACK
SYN_SENT
LISTEN
SYN_RCVD
CLOSE_WAIT
TIME_WAIT
ESTABLISHED
FIN_WAIT_1
CLOSING
FIN_WAIT_2
Transporte
3-87
Gestión de la conexión en TCP: Ciclo de vida


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.
CLOSED
LAST_ACK
SYN_SENT
LISTEN
SYN_RCVD
CLOSE_WAIT
TIME_WAIT
ESTABLISHED
FIN_WAIT_1
CLOSING
FIN_WAIT_2
Transporte
3-88
Gestión de la conexión en TCP: Ciclo de vida


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.
CLOSED
LAST_ACK
SYN_SENT
LISTEN
SYN_RCVD
CLOSE_WAIT
TIME_WAIT
ESTABLISHED
FIN_WAIT_1
CLOSING
FIN_WAIT_2
Transporte
3-89
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.
CLOSED
LAST_ACK
SYN_SENT
LISTEN
SYN_RCVD
CLOSE_WAIT
TIME_WAIT
ESTABLISHED
FIN_WAIT_1
CLOSING
FIN_WAIT_2
Transporte
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”.
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
 Aquí
podemos ver todas las combinaciones
“evento/acción” de las transiciones del
ciclo de vida típico del cliente.
Aplicación cliente inicia una conexión
Enviar segmento SYN
Transcurre 2 veces el tiempo MSL
CLOSED
SYN_SENT
No enviar nada
TIME_WAIT
Se recibe segmento SYN-ACK
Se recibe segmento FIN
Enviar ACK del SYN
Enviar ACK del FIN
ESTABLISHED
La aplicación indica que
quiere cerrar la conexión
Enviar segmento FIN
FIN_WAIT_2
FIN_WAIT_1
Se recibe ACK del FIN
No enviar nada
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



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.
CLOSED
LISTEN
LAST_ACK
CLOSE_WAIT
ESTABLISHED
SYN_RCVD
Transporte
3-93
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.
Aplicación servidora crea
socket “de acogida”
Se recibe ACK del FIN
CLOSED
No enviar nada
No enviar nada
LISTEN
LAST_ACK
Se recibe segmento SYN
Enviar segmento ACK-SYN
La aplicación indica que
quiere cerrar la conexión
SYN_RCVD
Se recibe ACK del SYN
No enviar nada
Enviar segmento FIN
CLOSE_WAIT
ESTABLISHED
Se recibe segmento FIN
Enviar ACK del FIN
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.
 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




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
P2
P6
P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
cliente
IP: A
PO: 9157
PD: 80
IP-O: A
IP-D: C
PO = Nº de Puerto Origen
PD = Nº de Puerto Destino
IP-O = Dir. IP Origen
IP-D = Dir. IP Destino
Servidor Web
IP: C
PO: 9157
PD: 80
IP-O: B
IP-D: C
cliente
IP: B
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