Slides TD IV - clases (12)

Vista previa del material en texto

TD4 2022TD4 2022
Agenda
▪ Servicios del nivel de transporte
▪ Multiplexación y demultiplexación
▪ Transporte no orientado a conexión: UDP
▪ Transferencia de datos confiable
▪ Transporte orientado a conexión: TCP
▪ Control de congestión
▪ Protocolos modernos: QUIC
2
TD4 2022TD4 2022 3
El protocolo TCP
TD4 2022TD4 2022
TCP: vista general [RFCs: 793,1122, 2018, 5681, 7323]
▪ ACKs acumulativos
▪ Pipelining
• La ventana de emisión se 
define mediante el control de 
flujo y el control de congestión 
▪ Orientado a conexión
• Se inicializa estado en los 
interlocutores mediante un 
proceso de handshaking 
(intercambio de mensajes de 
control)
▪ Control de flujo
• Permite que el emisor no sature 
al receptor
▪ Punto a punto
• Un emisor y un receptor 
por conexión
▪ Flujo (stream) de bytes 
confiable y en orden
• Sin límites de mensajes
▪ Canal full-duplex
• Flujo de datos bidireccional 
en la misma conexión
4
TD4 2022TD4 2022
Estructura del segmento TCP
puerto src puerto dst
32 bits
sin 
uso ventana rec. cantidad de bytes que el 
receptor está dispuesto 
a aceptar
nro. de secuencia
cuenta cantidad de bytes 
enviados por el stream de 
datos
datos de la aplicación
(longitud variable)
datos enviados al 
socket TCP por la 
aplicación 
A
nro. de ACK
ACK: nro. de secuencia del 
próximo byte esperado
flag A: indica ACK
opciones (longitud variable)
opciones de TCP
head
len
longitud del header
checksumMismo que en UDP
(Internet checksum)
flags RST, SYN, FIN:
manejo de conexión
FSR
URG pointer
PUC E
flags C, E:
notificación de congestión
5
TD4 2022TD4 2022
Números de secuencia y ACKs
Número de secuencia
• Índice en el stream de bytes 
del primer byte en el payload
enviados, 
con ACK
enviados, 
sin ACK
aún no 
enviados
no utilizables
tamaño de ventana, N
espacio de números de secuencia 
puerto src puerto dst
#SEQ
#ACK
checksum
rwnd
URG pointer
segmento del emisor
Número de ACK
• Número de secuencia del 
siguiente byte esperado por 
el otro interlocutor
• ACK acumulativo
El manejo de segmentos fuera de orden 
queda a cargo de la implementación
6
N
puerto src puerto dst
#SEQ
#ACK
checksum
rwnd
URG pointer
segmento del receptor
A
TD4 2022TD4 2022
Números de secuencia y ACKs
El host envía un 
ACK de la ‘C’ 
recibida
El host envía un ACK de 
‘C’ y manda de vuelta el 
caracter
Ejemplo: telnet
Host BHost A
El usuario tipea ‘C’ #SEQ=42, #ACK=79,
payload = ‘C’
#SEQ=79, #ACK=43,
payload = ‘C’
#SEQ=43, 
#ACK=80
7
TD4 2022TD4 2022
Timeout y RTT en TCP
¿Cómo definir el timeout en TCP?
▪ Debe ser mayor que el RTT… pero el 
RTT es variable
▪De ser muy corto, ocurrirían 
retransmisiones innecesarias por 
timeouts prematuros
▪De ser muy largo, habría una 
reacción pobre ante la pérdida de 
segmentos
¿Cómo estimar el RTT?
▪SampleRTT: tiempo transcurrido 
entre la transmisión de un 
segmento y la recepción de su 
ACK (ignorando retransmisiones)
▪SampleRTT es dinámico
• Para lograr una estimación 
“suave”, se promedian varias 
mediciones recientes
8
TD4 2022TD4 2022
Timeout y RTT en TCP
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
▪ Ante una nueva muestra de SampleRTT, TCP estima el RTT a través de una media 
móvil ponderada exponencial (EWMA)
▪ El peso de las muestras decrece a velocidad exponencial
▪ El parámetro α representa la influencia de las muestras recientes en la estimación 
(valor típico: α = 0.125)
RT
T 
[m
s]
SampleRTT
EstimatedRTT
tiempo [s] 9
TD4 2022TD4 2022
Timeout y RTT en TCP
▪ El timeout (RTO) se calcula como el RTT estimado más un “margen de seguridad”: el 
desvío entre el RTT estimado y la muestra
• Cuando hay grandes fluctuaciones en el muestreo, queremos un margen mayor
RTT estimado margen de seguridad
RTO = EstimatedRTT + 4*DevRTT
DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|
(típicamente, β = 0.25)
▪DevRTT: media móvil ponderada exponencial del desvío de SampleRTT respecto de 
EstimatedRTT: 
10
TD4 2022TD4 2022
Emisor TCP (simplificado)
Evento: recepción de datos de la 
aplicación
▪ Generar segmento con #SEQ 
(índice en el stream de bytes del 
primer byte en el payload)
▪ Disparar timer (si no está 
corriendo) 
• Este timer mide el tiempo del 
segmento más antiguo sin ACK
• Expira cuando se consume el RTO
Evento: expiración de timer
▪ Retransmitir segmento que 
causó el timeout
▪ Reiniciar timer
 
Evento: ACK recibido
▪ Si el ACK reconoce segmentos 
enviados anteriormente:
• Actualizar el puntero de bytes 
reconocidos (con ACK)
• Reiniciar timer si aún hay 
segmentos sin ACK
11
TD4 2022TD4 2022
Receptor TCP: generación de ACKs [RFC 5681]
 Evento
Arribo de segmento en orden 
con #SEQ esperado; los bytes 
hasta #SEQ están ACKeados
Arribo de segmento en orden 
con #SEQ esperado; otro 
segmento tiene ACK pendiente
Arribo de segmento fuera de 
orden con #SEQ mayor al 
esperado (gap)
Arribo de segmento que cubre 
parcial o totalmente un gap
 Acción
Delayed ACK: esperar hasta 500 ms 
para el siguiente segmento; si no 
llega, enviar ACK
Envío inmediato de ACK 
acumulativo que contemple ambos 
segmentos
Envío inmediato de ACK duplicado 
indicando #SEQ del siguiente byte 
esperado
Envío inmediato de ACK (siempre y 
cuando el segmento comience en la 
parte inferior del gap)
12
TD4 2022TD4 2022
Retransmisiones
Caso 1:
ACK extraviado
Host BHost A
#SEQ=92,
8 bytes de datos
#SEQ=92,
8 bytes de datos
#ACK=100
X
#ACK=100
tim
eo
ut
Caso 2:
timeout prematuro
Host BHost A
tim
eo
ut
#ACK=100
#ACK=120
#unACKed=100
#unACKed=120
#unACKed=120
#SEQ=92,
8 bytes de datos
#SEQ=100,
20 bytes de datos
#ACK=120
envío de ACK 
acumulativo, 
#ACK=120
13
#unACKed=92
#SEQ=92,
8 bytes de datos
TD4 2022TD4 2022
Retransmisiones
Caso 3:
El ACK acumulativo cubre la 
pérdida del ACK anterior
Host BHost A
#SEQ=92,
8 bytes de datos
#SEQ=120, 
15 bytes de datos
#SEQ=100,
20 bytes de datos
X
#ACK=120
#ACK=100
14
TD4 2022TD4 2022
TCP Fast Retransmit
Host BHost A
tim
eo
ut
#ACK=
100
#ACK
=100
#ACK
=100
#ACK
=100
X
#SEQ=92, 8 bytes de datos
#SEQ=100, 20 bytes de datos
#SEQ=100,
20 bytes de datos
La recepción de tres ACKs 
duplicados indica tres 
segmentos recibidos luego de 
un segmento faltante: es 
probable que esto se deba a una 
pérdida, por lo que activa una 
retransmisión de inmediato
Si el emisor recibe tres ACKs extra 
para los mismos datos, se reenvía 
el segmento sin ACK con el #SEQ 
más bajo
▪ Probablemente se haya perdido, por 
lo que no se espera al RTO
TCP Fast Retransmit
15
TD4 2022TD4 2022
Control de flujo en TCP: motivación
proceso
buffers del 
socket TCP
código
de TCP
código 
de IP
stack de protocolos 
del receptor
Si la capa de red 
entrega datos más 
rápido que la velocidad 
de procesamiento de la 
capa de aplicación, se 
produce una saturación
capa de red 
entregando payload 
de datagramas IP a 
los buffers del 
socket TCP
paquetes 
del emisor
app extrayendo datos 
de los buffers de TCP
16
TD4 2022TD4 2022
Control de flujo en TCP: motivación
mecanismo mediante el cual el 
receptor controla al emisor de modo 
tal que no sature los buffers 
transmitiendo demasiado rápido
control de flujo
17
rwnd
cantidad de bytes 
que el receptor está 
dispuesto a aceptar
app extrayendo datos 
de los buffers de TCP
stack de protocolos 
del receptor
paquetes 
del emisor
código 
de IP
código
de TCP
proceso
buffers del 
socket TCP
TD4 2022TD4 2022
Control de flujo en TCP
▪El receptor anuncia espacio 
disponible en los buffers en el 
campo rwnd del header TCP
• El tamaño del buffer (RcvBuffer) 
puede definirse vía opciones del 
socket (suele ser 4096 bytes por 
defecto)
• Muchos SOs auto-ajustan el 
RcvBuffer
▪El emistor limita la cantidad de datos 
sin ACK (“en vuelo”) de acuerdo al 
valor recibido de rwnd
▪ Garantiza que el buffer del receptor 
no se saturará
datos bufferados
espacio 
disponible
rwnd
RcvBuffer
payloads de segmentos TCP
al proceso de aplicación
Buffering deTCP
18
Demo: https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/flow-control/index.html
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/flow-control/index.html
TD4 2022TD4 2022
Establecimiento de conexión
Antes de intercambiar datos, los interlocutores TCP establecen la conexión 
mediante un handshake:
▪ Acuerdo mutuo de establecer la conexión
▪ Acuerdo de parámetros (e.g., #SEQs iniciales; buffers)
estado: ESTABLISHED
variables:
#SEQ cliente-servidor
 servidor-cliente
rcvBuffer
 
 
aplicación
red
estado: ESTABLISHED
variables:
#SEQ cliente-servidor
 servidor-cliente
rcvBuffer
 
aplicación
red
Socket clientSocket =
new Socket("hostname", 80);
Socket connectionSocket = 
listenSocket.accept();
19
TD4 2022TD4 2022
Acuerdo de establecimiento de conexión
 ¿Podemos garantizar el 
funcionamiento de este protocolo 
en la red?
▪ Delays variables
▪ Retransmisiones de mensajes 
por pérdidas
▪ Reordenamiento
Consideremos un handshake simple en dos pasos:
elegir x req_conn(x)
ESTABLISHED
ESTABLISHED
acc_conn(x)
20
TD4 2022TD4 2022
Escenarios del handshake en dos pasos
fin
elegir x
req_conn(x)
ESTABLISHED
ESTABLISHED
acc_conn(x)
data(x+1)
ACK(x+1)
21
TD4 2022TD4 2022
Escenarios del handshake en dos pasos
ESTABLISHED
retransmisión de
req_conn(x)
req_conn(x)
el cliente 
finaliza
el servidor
“descarta” x
elegir x
req_conn(x)
ESTABLISHED
ESTABLISHED
acc_conn(x)
acc_conn(x)conexión semi-abierta
no hay cliente
22
TD4 2022TD4 2022
Escenarios del handshake en dos pasos
el cliente
finaliza
ESTABLISHED
elegir x
req_conn(x)
ESTABLISHED
acc_conn(x)
data(x+1)
el servidor 
“descarta” x
datos duplicados
retransmisión
de req_conn(x)
ESTABLISHED
req_conn(x)
data(x+1)
retransmisión
de data(x+1)
TD4 2022TD4 2022
TCP: handshake en 3 pasos
SYN=1, #SEQ=x
elegir #SEQ inicial x
enviar segmento 
TCP SYN
ESTABLISHED
SYN=1, #SEQ=y
ACK=1, #ACK=x+1
elegir #SEQ inicial 
crear buffers y
enviar segmento 
TCP SYN+ACK
ACK=1, #ACK=y+1
crear buffers
enviar ACK al servidor
(este segmento puede 
contener datos del cliente)
SYN_SENT
ESTABLISHED
SYN_RCVD
Estado del cliente
CLOSED
Estado del servidor
LISTEN
clientSocket = socket(AF_INET, SOCK_STREAM)
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
connectionSocket, addr = serverSocket.accept()
clientSocket.connect((serverName,serverPort))
24
TD4 2022TD4 2022
Cierre de conexión TCP
▪ Tanto el cliente como el servidor cierran su parte de la conexión 
cuando no tienen más datos por enviar
• En particular, envían un segmento TCP con el flag FIN 
prendido
▪ El interlocutor responde a dicho FIN con un ACK
• Al recibir un FIN, el ACK puede combinarse con el propio FIN
▪ El protocolo soporta intercambio simultáneo de FINs
26