Nivel de Transporte: Introducción, UDP y TCP

Transcripción

TEMA 1: Introducción a las Redes de
Telecomunicaciones
Redes de Ordenadores
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
Clasificación de las Redes de Telecomunicaciones.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP.
Nivel de Transporte:
Introducción, UDP y TCP
1.1. ¿Qué es una Red de Telecomunicaciones?




Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transm
Receptor
DESTINO
Sistema Destino
2
Objetivos
‣
Conceptos y principios del nivel de transporte
Telecomunicaciones
>
>
>
>
‣
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
Multiplexación
Transporte fiable
Control de flujo
Control de congestion
Estudio del nivel de transporte en Internet
>
Protocolos TCP y UDP




FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
Funciones del nivel de transporte
‣
‣
Comunicación lógica
entre aplicaciones
Protocolo en los
extremos (end-to-end)
TEMA 1: Introducción Transporte
a las Redes de
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
>
>
‣
Red
Modelo Genérico.
Enlace
Red
Enlace
Red
segmentación
reensamblado
Enlace
Red
2 niveles de transporte en
Internet
>
>
TCP
UDP
Canal lógico




FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Enlace
Red
Enlace
Transporte
Red
Receptor
DESTINO
Enlace
Sistema Destino
2
Red y transporte
‣
Nivel de red
Comunicación lógica entre hosts
Nivel de transporte
Comunicación lógica entre procesos
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
‣
>
Modelo Genérico.
mejora y utiliza la comunicación entre hosts
App 1
App 1
 Es una Infraestructura.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
Transporte
Red
Red
FUENTE
Enlace
Sistema Origen
Transmisor
Sistemas de
Transmisión
Enlace
Transporte
Red
Receptor
Sistema Destino
Enlace
Red
Red
Enlace
Enlace
DESTINO
2
Transporte en Internet
‣
Entrega fiable y en
orden (TCP)
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
>
>
>
‣
Transporte
Modelo Genérico.
control de congestión
control de flujo
establecimiento de conexión
Red
Enlace
Red
Enlace
Red
Entrega no fiable, sin
garantias de orden
(UDP)
Enlace
Red




>
‣
best-effort igual que IP
En los dos casos
FUENTE
>
>
Transmisor
Sistemas de
Transmisión
retardo no garantizado
ancho de banda no garantizado
Sistema Origen
Receptor
Red
Enlace
Enlace
Transporte
DESTINO
Red
Sistema Destino
2
Enlace
Funciones TCP/UDP
‣
Función común
Multiplexación/demultiplexación de
aplicaciones
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
‣
Funciones sólo UDP
>
‣
Modelo Genérico.
Envio no orientado a conexión
Funciones sólo TCP




>
>
>
Manejo de conexiones
Transporte fiable de datos
Control de flujo y de congestión
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
Multiplexación y demultiplexación
‣
Un host con varias aplicaciones/programas/
procesos corriendo
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
>
El nivel de red envía los paquetes al nivel de red del ordenador destino
>
El nivel de transporte arbitra la comunicación entre diferentes aplicaciones
un nivel de red, un nivel de transporte, varias aplicaciones
>
Aplicación 1
Aplicación 2
Aplicación 3
Aplicación 4
Transporte
Red




Transporte
Emisor:
‣ recoger datos de distintas fuentes
‣ encapsular con información del
origen
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
Red
DESTINO
Sistema Destino
2
Receptor:
‣ entregar a la
aplicación (socket)
correcta
Multiplexación y demultiplexación
‣
El host recibe datagramas IP
Telecomunicaciones
>
>
>
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
Cada datagrama IP lleva una
dirección IP de origen y de destino
Cada datagrama IP lleva un
segmento del nivel de transporte
Cada segmento del niel de
transporte lleva un puerto origen y
destino (puerto: identificador de
proceso/aplicación)
Cabecera IP
...
puerto origen
puerto destino
cabecera de transporte
‣
El nivel de transporte usa
las direcciones IP y los
puertos para decidir a
quien entrega los datos




FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
Datos aplicación
DESTINO
Sistema Destino
2
Segmento del nivel
de transporte
Demultiplexación no orientada a conexión
Cuando UDP recibe un paquete...
‣ Se extraen de la cabecera
proceso 1
IP la dirección IP destino y
de la cabecera UDP el
puerto destino
80
sockets
‣ Se entregan los datos al
S1
socket identificado por la
tupla
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
proceso 2
6881
S2




(dirIP destino, puerto destino)
‣
Paquetes provenientes de
diferentes direcciónes origen y
puertos origen se entregan al
mismo socket
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
UDP
1234
S3
Demultiplexación no orientada a conexión
‣
Ejemplo
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
SP: source port
DP: destination port
Modelo Genérico.
P2
P1
P1
P3
SP: 6428
DP: 9157
SP: 6428
DP: 5775
client
IP: A
SP: 9157
DP: 6428




FUENTE
‣
SP: 5775
DP: 6428
server
IP: C
Transmisor
Sistemas de
Transmi
Receptor
Client
IP:B
DESTINO
La dirección origen y puerto origen permiten
responder al cliente
Sistema Origen
Sistema Destino
2
/
11
Demultiplexación orientada a conexión
‣
‣
Cuando TCP recibe un paquete puede pertenecer a
varias conexiones establecidas
Varios sockets con el mismo puerto...
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.
80
23421
CNX establecida
S4
TCP
S12y3
23421
CNX establecida
TCP




‣
proceso 3
proceso 2
proceso 1
S5
TCP
FUENTE
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Se entrega al socket identificado por la 4-tupla
Sistema Origen
Sistema Destino
(dirIP origen, puerto origen, dirIP destino, puerto destino)
2
‣
Ejemplo
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
P1
P4
P5
client
IP: A
1
SP: 9157
DP: 80
S-IP: A
D-IP:C
P2
P6




SP: source port
S-IP: source IP
D-IP: destination IP
Modelo Genérico.
SP: 5775
DP: 80
S-IP: B
D-IP:C
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
server
IP: C
Receptor
P1P3
SP: 9157
DP: 80
DESTINO
Sistema Destino
2
S-IP: B
D-IP:C
Client
IP:B
‣
Otro ejemplo
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
P1
P2
P4




client
IP: A
1
SP: source port
S-IP: source IP
D-IP: destination IP
Modelo Genérico.
SP: 9157
DP: 80
S-IP: A
D-IP:C
SP: 5775
DP: 80
S-IP: B
D-IP:C
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
server
IP: C
Receptor
P1P3
SP: 9157
DP: 80
DESTINO
Sistema Destino
2
S-IP: B
D-IP:C
Client
IP:B
UDP: User Datagram Protocol
‣
‣
UDP: User Datagram Protocol (RFC-768)
Proporciona un servicio de transporte para
aplicaciones sobre IP de tipo Best-Effort
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
>
>
>
>
‣
Modelo Genérico.
Sin garantizar la entrega
Sin garantizar el orden de entrega
Mucho menos con tiempo o con ancho de banda garantizado
Lo único que añade a IP es la multiplexación de aplicaciones y
detección de errores




No orientado a conexión
>
>
No hay establecimiento
Cada datagrama se trata independientemente (protocolo sin
estado)
FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
UDP
¿Por qué un protocolo como UDP?
‣ Es rapido: no hay establecimiento
aunque no garantice el retardo no añade retardos
innecesarios
‣ Es simple: no hay estado de conexión
ni en el emisor ni en el receptor
‣ Poco overhead
la cabecera UDP ocupa lo mínimo posible
‣ Es eficiente: no hay control de congestión
puede usar todo el ancho de banda que consigas
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
Modelo Genérico.




FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
UDP: detalles
32 bits
Formato del paquete
‣ puerto origen
‣ puerto destino
‣ longitud del segmento
UDP
Telecomunicaciones
>
‣
8 - 65535 bytes
checksum
sólo 8 bytes de
cabecera !
Cabecera IP
...
Modelo Genérico.
segmento UDP
 1.
 2.
 3.
 4.
 5.
puerto origen
longitud
Datos aplicación




FUENTE
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
puerto destino
checksum
DESTINO
Sistema Destino
2
UDP: checksum
‣
32 bits
Cálculo del checksum
Telecomunicaciones
>
>
 1.
 2.
 3.
 4.
 5.
dirección IP origen
dirección IP destino
Modelo Genérico.
Se trata el segmento como serie de
valores de 16 bits
Suma binaria
en complemento a 1
+ pseudo-cabecera con algunos
campos de la cabecera IP (para
proteger errores en las direcciones
y el protocolo)
0s
proto
puerto origen
longitud
longitud UDP
puerto destino
checksum
Datos aplicación
+
‣
segmento UDP




Detecta errores en todo el segmento UDP
(aunque no todos)
Si UDP detecta errores en un paquete
recibido no lo entrega
FUENTE
‣
Sistema Origen
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
UDP
En que se usa UDP ?
‣ Aplicaciones de streaming multimedia (audio/
video en tiempo real o audio/videoconferencia)
Telecomunicaciones
 1.
 2.
 3.
 4.
 5.
>
‣
Modelo Genérico.
tolerantes a las pérdidas y sensibles al ancho de banda
Mensajes de DNS
>
‣




SNMP (monitorización de red)
>
‣
bajo retardo y poco overhead
poco overhead y protocolo sencillo
Juegos en red
>
FUENTE
Sistema Origen
mínimo retardo posible
Transmisor
Sistemas de
Transmisión
Receptor
DESTINO
Sistema Destino
2
Transporte fiable
‣
¿Se puede conseguir un transporte fiable sobre
un nivel de datagramas de entrega no fiable?
t_envia(datos)
t_recibe(datos)
Nivel de
Transporte
r_envia(datos)
r_recibe(datos)
Nivel de Red
Entrega no garantizada
se pueden perder datos
Protocolo de transporte fiable
‣
Descripción con máquinas de estados finitos. Notación
Otro
estado
Un
estado
Una transición
Evento que causa la transición
Acciones que provoca la transición
‣
Ejemplo: protocolo de transporte sobre un nivel de red
fiable
Receptor r_recibe(p)
t_envia(datos)
Emisor
datos= extrae(p)
Espera
llamada
de app
10 octubre 2005
Espera
llegada
de datos
p= paquete(datos)
r_envia(p)
t_recibe(datos)
red fiable:
r_envia(p) siempre causa un r_recibe(p)
Transporte-2
4
/24
Errores de bit
)P
‣
nivel de red puede cambiar bits
(probabilidad de error)
Cambios necesarios en el protocolo de
transporte
>
>
>
Detección de errores
+ Uso de checksum
Comunicación de fallos al emisor
+ ACK (acknowledgement): avisar al emisor de los paquetes que
recibimos
+ NACK (negative acknowledgement): avisar al emisor de los
paquetes que no recibimos
Reenvío de paquetes
Protocolo de transporte fiable
‣
Para un canal con errores de bits
Emisor
t_envia(datos)
p= paquete(datos)
r_envia(p)
Espera
llamada
de app
r_recv(datos) == NACK
r_envia(p)
Espera
ACK o
NACK
Receptor
r_recv(datos) == ACK
nada
r_recibe(p) con error
r_envia(NACK)
‣
‣
Espera
llegada
de datos
r_recibe(p) sin error
datos= extrae(p)
t_recibe(datos)
r_envia(ACK)
Más conocido como Stop-and-Wait
¿Tiene algun problema este protocolo?
Problemas con stop-and-wait
‣
‣
‣
¿Qué pasa si hay un error en la transmisión del
ACK o NACK?
¿Qué pasa si el canal puede perder paquetes?
Soluciones complican el protocolo
>
>
>
‣
Detección de errores para ACK y NACK?
Checksums que permitan no solo detectar sino corregir errores?
Reenviar los datos si no entiendo el ACK/NACK ??
+ Nuevo problema: paquetes duplicados
Los protocolos más usados utilizan contra esto
numeros de secuencia del paquete
Protocolo con número de secuencia
‣
Cada paquete de datos lleva un numero de
secuencia 0 o 1
>
>
Si llega el que esperamos mandamos ACK y lo entregamos
Si llega el que no esperamos mandamos ACK pero no son datos
nuevos
r_recibe(datos)
sin error y seq 0
datos= extrae(p)
t_recibe(datos)
r_envia(ACK)
r_recibe(datos)
con error
r_recibe(datos)
con error
r_envia(NACK)
r_envia(NACK)
r_recibe(datos)
sin error y seq 1
r_envia(ACK)
Espera
paquete
0
Espera
paquete
1
r_recibe(datos)
sin error y seq 0
r_recibe(datos)
sin error y seq 1
datos= extrae(p)
t_recibe(datos)
r_envia(ACK)
r_envia(ACK)
‣
Estados del emisor
t_envia(datos)
p= paquete(datos,0)
r_envia(p)
r_recibe(datos)
con error o ack 1
r_envia(p)
Espera
datos
app 0
Espera
ACK 0
r_recibe(datos)
sin error y ack 0
r_recibe(datos)
sin error y ack 1
Espera
datos
app 1
Espera
ACK 1
r_recibe(datos)
con error o ack 0
r_envia(p)
t_envia(datos)
p= paquete(datos,1)
r_envia(p)
‣
Podemos eliminar los
NACKs
>
>
>
‣
En lugar de un ACK enviamos ACK
y la secuencia del siguiente paquete
que esperamos recibir
En lugar de un NACK enviamos
ACK y la secuencia del siguiente
paquete que esperamos recibir
El emisor sabe que tiene que
reenviar si recibe el ACK del
paquete que no espera
Problema pendiente:
¿Qué pasa si se pierde un
paquete?
s0
s1
s0
s0
ack1
ack0
ack0
ack1
Pérdidas de paquetes
‣
‣
Si se pierde un paquete el emisor se queda
bloqueado en un estado
Para romper el bloqueo usamos un
temporizador en el emisor
>
>
‣
Al enviar un paquete de datos ponemos en marcha un temporizador
Si transcurrido un tiempo, no se ha recibido ACK (TIMEOUT),
reenviamos el paquete
El receptor no se modifica
Protocolo con timeout
‣
Emisor con
retransmisión por
timeout
t_envia(datos)
p= paquete(datos,0)
r_envia(p)
inicia_temp()
timeout
Espera
datos
app 0
Espera
ACK 0
para_temp()
para_temp()
Espera
datos
app 1
Espera
ACK 1
r_envia(p)
inicia_temp()
t_envia(datos)
r_recibe(datos)
con error o ack 0
r_envia(p)
inicia_temp()
r_recibe(datos)
sin error y ack 0
r_recibe(datos)
sin error y ack 1
timeout
r_recibe(datos)
con error o ack 1
p= paquete(datos,1)
r_envia(p)
inicia_temp()
Ejemplos
Emisor
r_send(paq0)
r_recv(ack0)
r_send(paq1)
r_recv(ack1)
r_send(paq0)
Emisor
r_send(paq0)
Receptor
paq0
ack0
r_recv(ack0)
r_recv(paq0) r_send(paq1)
r_send(ack0)
Receptor
paq0
ack0
r_recv(paq0)
r_send(ack0)
paq1 perdido
paq1
ack1
paq0
ack0
r_recv(paq1)
r_send(ack1) timeout
r_send(paq1)
paq1
r_recv(paq0) r_recv(ack1)
r_send(ack0) r_send(paq0)
ack1
paq0
ack0
r_recv(paq1)
r_send(ack1)
r_recv(paq0)
r_send(ack0)
Operación normal
Pérdida de paquete
1
Ejemplos
Emisor
r_send(paq0)
r_recv(ack0)
r_send(paq1)
Emisor
Receptor
paq0
ack0
r_recv(ack0)
r_recv(paq0)
r_send(paq1)
r_send(ack0)
r_recv(paq1)
r_send(ack1)
perdido
r_recv(ack1)
r_send(paq0)
paq0
ack0
paq1
ack1
timeout
r_send(paq1)
ack1
paq0
r_recv(ack1)
r_recv(paq1) r_send(paq0)
r_send(ack1)
r_recv(ack1)
ack0
r_recv(paq0)
r_send(ack0)
Pérdida de ACK
r_recv(paq0)
r_send(ack0)
paq1
paq1
ack1
timeout
r_send(paq1)
r_send(paq0)
Receptor
paq1
paq0
ack1
r_recv(paq1)
r_send(ack1)
r_recv(paq1)
(detecto duplicado)
r_send(ack1)
ignorado
ack0
Timeout prematuro
1
Prestaciones
‣
‣
El protocolo anterior es fiable pero es muy poco
eficiente
Ejemplo:
Enlace de 1Gbps con un retardo de 15ms (4500Km),
paquetes de 1000 bytes
A que velocidad puedo enviar?
RoundTripTime
=30ms
tam
8000bits
v=
=
= 266Kbps
RoundTripTime
.03s
0.026% !! :-(
Protocolos más eficientes
‣
Para aumentar la eficiencia, se envían varios
paquetes mientras llega el ACK
Varios paquetes en la red por confirmar
>
>
>
Se usan más números de secuencia que 0 y 1
Emisor y receptor necesitarán buffer para varios paquetes
Varias políticas para reaccionar a los errores
Emisor
Receptor
+ Go-Back N
paq 0
+ Selective reject
paq 1
ack 0
paq 2
paq 3
Go back-N
‣
‣
‣
‣
‣
Se utiliza número de secuencia en el paquete
Se permite una ventana de N paquetes sin
confirmar
Cada ACK confirma todos los paquetes
anteriores (cumulative ACK)
Cada paquete inicia su propio timeout
Si caduca el timeout de un paquete se
retransmiten todos los siguientes
Go back-N
‣
Ventana deslizante
enviados
no ACKed
transmitidos
ACKed
se pueden
enviar
Ventana de N paquetes
Llega este ACK
no se pueden
enviar
Timeout del primer paquete
pueden enviarse
nuevos paquetes
La ventana se desliza hacia
mayores números de secuencia
Volvemos a enviar
Go back-N
Ventana de 4 paquetes
...
Emisor
paq 0
paq 1
paq 2
paq 3
paq 4
paq 5
timeout paq 2
paq 2
paq 3
paq 4
paq 5
Receptor
ack 0
ack 1
ack 1
ack 1
ack 1
ack 2
ack 3
ack 4
Selective Reject
‣
El receptor confirma (ACK) individualmente
cada paquete
>
Mantiene en buffer los paquetes recibidos a la espera de reconstruir
la secuencia y pasarlos al nivel de aplicación
Ventana
‣
Se reenvian los paquetes no confirmados por
timeout
>
‣
paquetes recibidos que no pueden
pasarse todavía al nivel de aplicacion
Timeout individual por cada paquete
Ventana de N paquetes que pueden enviarse
sin recibir ACK
Selective Reject
‣
Ventana deslizante del emisor
enviados
no ACKed
transmitidos
ACKed
‣
confirmados se pueden
ACKed
enviar
no se pueden
enviar
Ventana deslizante del receptor
esperados
confirmados
y entregados
recibidos y confirmados
en espera de poder entregarse
aceptables
no aceptables
fuera de la ventana
Selective reject
Ventana de 4 paquetes
Emisor
paq 0
paq 1
paq 2
paq 3
paq 4
paq 5
Receptor
ack 0
ack 1
ack 3
ack 4
ack 5
timeout
paq 2
ack 2
...
paq 5
El problema del selective reject
‣
‣
Número de secuencia
finito
Ejemplo
>
>
‣
‣
‣
seq= {0,1,2,3}
N=3
El receptor no puede
notar la diferencia entre
los dos escenarios
Y entrega datos
duplicados como buenos
Que relación debe haber
entre #secuencia y N?
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
paq duplicado
entregado !!!
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
paq correcto
entregado
TCP
‣
‣
Protocolo de transporte de Internet (RFC 793)
Transporte fiable
>
>
‣
Orientado a conexión
>
>
‣
Entrega garantizada
Entrega en orden
Stream bidireccional (como si fuera un fichero) entre los dos
extremos
No mantiene las fronteras de los mensajes
Con control de flujo y congestión
TCP
‣
Interfaz con el nivel de aplicación
>
>
>
Tras establecer una conexión proporciona un stream bidireccional entre sockets
Sin fronteras entre mensajes
2 buffers por conexión
+
+
Escribir en el socket pone los datos en buffer de envio
Buffer de recepción para esperar el read()
TCP
TCP
connexión
connexión
connexión
IP
connexión
connexión
IP
IP
IP
connexión
TCP
‣
Demultiplexación de datos que llegan a TCP:
>
Se identifica al socket destino por la tupla
( IP origen, puerto origen, IP destino, puerto destino )
>
‣
La tabla de tuplas (ip,puerto,ip,puerto) con sus sockets de un nivel TCP es la tabla
de conexiónes.
La conexión sólo existe en los extremos TCP
write(datos)
puertos A1 A2 A3
TCP
connexión
connexión
connexión
IPB, puertoB1, IPA, puertoA1 : cnx1
IPB, puertoB3, IPA, puertoA2 : cnx2
IPX, puertoP , IPA, puertoA3 : cnx3
host IPA
read(datos)
puertos B1
B3
Tabla de
conexiones
Paquete a IPB
puertoB3
TCP
connexión
connexión
IPA, puertoA1, IPB, puertoB1 : cnx1
IPA, puertoA2, IPB, puertoB3 : cnx2
...
recibido paquete
host IPB
TCP
‣
Los buffers aislan a TCP de las operaciónes del
usuario.
>
>
‣
Para realizar esto TCP necesitara un conjunto
de mensajes para comunicarse con el TCP del
otro lado
>
>
>
‣
TCP hará lo posible por enviar los datos cuando pueda
TCP colocara los datos en el buffer de recepción cuando lleguen
Mensajes de establecimiento y cierre de conexión
Mensajes de datos
Mensajes con ACKs
Veamos los mensajes del protocolo TCP
TCP
>
‣
20 hasta 60 bytes según las
opciones
Datos del nivel de
aplicación
Cabecera IP
...
20 bytes
obligatorios
‣
Segmento TCP
Cabecera de tamaño
variable
Cabecera TCP
‣
32 bits
puerto origen
puerto destino
numero secuencia
numero ack
HL nada flags ventena recep.
checksum
urgent data ptr
opciones
Datos aplicación
TCP
Contenido
‣ Datos de
multiplexación
>
>
Puerto origen
Puerto destino
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
opciones
Datos aplicación
TCP
Contenido
‣
Datos para transporte
fiable
>
Número de secuencia
>
Número de ACK
Checksum
Cabecera + datos de applicación +
algunos datos de IP (pseudo cabecera
como en UDP)
>
‣
En un mismo paquete
podemos mandar datos y
confirmar datos del
sentido contrario
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
opciones
Datos aplicación
TCP
Contenido
‣ FLAGs: diferentes tipos
de paquetes del
protocolo
>
>
>
>
>
>
URG
ACK
PSH
RST
SYN
FIN
urgente
acknowledgement
push
reset
syn
fin
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
opciones
Datos aplicación
TCP
Contenido
‣ Control de flujo
>
‣
‣
Datos urgentes
HL (header length)
>
>
‣
ventana de recepción
Tamaño de la cabecera (en
palabras de 4 bytes)
4 bits de de 5 a 15 palabras
de 20 a 60 bytes
Opciones extras
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
opciones
Datos aplicación
TCP
‣
‣
Permiten especificar operaciones y tipos de
paquetes que se han ido añadiendo
posteriormente al protocolo
Las opciones se colocan seguidas. 2 formatos
>
>
‣
opciones de 1 byte
opciones de varios bytes
tipo
tipo
longitud
variable
Opciones básicas
>
>
>
00000000
Fin-de-la-lista de opciones
No-operacion (para rellenar) 00000001
Maximum segment size
00000010 00000100
max seg size
Permite descubrir el tamaño máximo de segmento en una conexión
TCP: envío de datos
‣
‣
0
No hay separación de paquetes. Los bytes a enviar se
colocan en el buffer y forman una corriente de bytes
sin fronteras de paquetes
El número de secuencia y el numero de ACK hacen
referencia al byte concreto
17
51
Buffer
Datos de aplicacion a enviar al otro extremo... y no tienen fronteras de mensajes...
seq # =17
on a enviar al otro extremo... y n
o tienen fronteras de mensajes
Segmentos TCP
seq # =51
TCP: envío de datos
‣
Secuencia y ACK: campos de 32 bits
>
>
‣
El campo ACK
>
>
‣
4 Gb de datos para dar la vuelta
La secuencia no empieza de 0 sino que se genera al azar al principio
de cada conexión y para cada sentido
es valido si esta activado el flag ACK
indica la próxima secuencia que el receptor espera recibir
cumulative ACK: Go back N a nivel de byte
Si una conexión está transmitiendo en ambos
sentidos los ACKs de un sentido van en los
paquetes de datos del opuesto piggyback
Ejemplo
‣
Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22
Cliente
el usuario
pulsa la letra ‘c’
conexión establecida
seq=6 ack=16 datos=’c’
seq=16 ack=7 datos=’c’
el cliente del usuario
confirma la recepción
Servidor
seq=7 ack=17 nodatos
el servidor recibe la
letra ‘c’ y se la envia al
usuario para que
aparezca en pantalla
Ejemplo
‣
‣
Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22
Usando tcpdump para ver los paquetes
Tiempo
1124031783.543465
1124031783.544283
1124031783.544303
1124031783.652335
1124031783.653109
1124031783.653123
1124031783.798259
1124031783.798918
1124031783.798932
secuencia
10.1.1.253.48129 > 10.1.1.22.23:
10.1.1.22.23 > 10.1.1.253.48129:
10.1.1.253.48129 > 10.1.1.22.23:
10.1.1.253.48129 > 10.1.1.22.23:
10.1.1.22.23 > 10.1.1.253.48129:
10.1.1.253.48129 > 10.1.1.22.23:
10.1.1.253.48129 > 10.1.1.22.23:
10.1.1.22.23 > 10.1.1.253.48129:
10.1.1.253.48129 > 10.1.1.22.23:
Origen
{ ip, puerto }
Destino
{ ip, puerto }
P
P
.
P
P
.
P
P
.
ack
paquete
sin datos
6:7(1) ack 16 win 1460
16:17(1) ack 7 win 5792
ack 17 win 1460
7:8(1) ack 17 win 1460
17:18(1) ack 8 win 5792
ack 18 win 1460
8:10(2) ack 18 win 1460
18:20(2) ack 10 win 5792
ack 20 win 1460
Datos urgentes
‣
Si URG está activado.
>
El paquete lleva datos urgentes.
>
Canal de datos Out-of-band
El puntero urgente indica donde
acaban los datos urgentes
>
>
‣
Los datos normales se entregan
normalmente en el buffer para la
aplicación
Los datos urgentes se entregan aparte
No se usa mucho
En sockets los datos
urgentes hay que pedirlos
con setsockopt
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
opciones
Datos urgentes
Datos normales
TCP: transporte fiable
‣
TCP utiliza una ventana deslizante
>
>
‣
Los paquetes TCP llevan
>
>
>
‣
Número de secuencia: el primer byte enviado en el segmento
ACK: el próximo byte que espera recibir el receptor
Número de secuencia de los datos. Si no llevan datos, el campo número
de secuencia indica el proximo numero de secuencia que se enviará
Próximo número de secuencia que espera recibir su emisor. Es válido si
el byte ACK está activado
Los números de secuencia son independientes en ambos sentidos
Transmisiones simultáneas en los dos sentidos
Cada extremo funciona como un emisor y un
receptor independientes
TCP: emisor
‣
Eventos en el emisor
Llegan datos desde el
nivel de aplicacion
‣ crear segmento nuevo
‣ sec # el siguiente de la
stream
‣ iniciar temporizador si
no hay uno iniciado
timeout
‣ retransmitir el
segmento que causó el
timeout
‣ reiniciar timeout
recibido ACK
‣ Si confirme un
segmento nuevo
> actualizar ventana
EcumulativE ACK
> reiniciar timeout si
quedan segmentos
por confirmar
Ejemplos
Emisor
Emisor
sendbase=92
8bytes
Receptor
20bytes
sec=92 datos 8B
ack 100
sec
=92
sec
dat
os
=10
sec=92 datos 8B
ack 100
timeout
sendbase=92
8bytes
Receptor
timeout
sec
sendbase=120
sendbase=100
0 d
ato
s2
0B
=92
sendbase=100
8B
dat
os 8
0
2
1
k
B
ac
0
12
k
c
a
sendbase=120
pérdida de ACK
0
10
k
c
a
timeout prematuro
Ejemplos
Emisor
Emisor
sendbase=92
8bytes
20bytes
timeout
sendbase=120
timeout
cancelado
Receptor
sec
=92
sec
sendbase=92
8bytes
=10
dat
20bytes
os 8
sec
=92
sec
=10
ack 120
ACK acumulado
ack 100
sendbase=100
timeout datos
pendientes
dat
os
8B
0 d
ato
s2
0B
00
1
k
ac
20
1
k
ac
B
0 d
ato
s 20
B
Receptor
sec
=10
0 d
ato
s2
0B
reinicio timeout
TCP: varias retransmisiones
‣
El timeout se dobla
cada vez que caduca y
se envía de nuevo el
paquete
Exponential
backoff
Emisor
Receptor
TCP: receptor
‣
Eventos del receptor
>
Llega segmento en orden con el numero de secuencia esperado
No hay ACKs pendientes de enviar
Acción: Delayed ACK, espera hasta
500ms al siguiente paquete, si no llega
manda ACK
último ACK
enviado
último byte
recibido
>
Llega segmento en orden con el numero de secuencia esperado
Hay un delayed ACK pendiente
último ACK
enviado
último byte
recibido
Acción: envía inmediatamente ACK
(al ser acumulado confirma los dos)
TCP: receptor
‣
Eventos del receptor
>
Llega segmento fuera de orden generando hueco
último ACK
enviado
último byte
recibido
>
causando ACK duplicado
ACK #
Llega segmento rellenando hueco
último ACK
enviado
ACK #
>
Llega segmento ya reconocido
Acción: ignorar
TCP: Fast retransmit
‣
El timeout normalmente
es relativamente largo
>
>
‣
Si se pierde un paquete de datos
se genera hueco y se detendrá la
transmisión durante un timeout
Normalmente el emisor envía
varios paquetes seguidos
El receptor no puede
hacer un NACK pero
está generando ACKs
duplicados !!
Emisor
ack 100
ack 200
ack 200
ack 200
ack 200
ack 200
timeout
Receptor
TCP: Fast retransmit
‣
Fast retransmit
>
>
Si el emisor recibe 3 ACKs con el
mismo numero de ACK supondrá
que se ha perdido el paquete que
llevaba ese numero de secuencia
Reenvia el paquete
inmediatamente sin esperar a que
caduque el timeout
3 dup ACKs !!!
= fast retransmit
recibidos todos
timeout cancelado
Emisor
ack 100
ack 200
ack 200
ack 200
ack 200
ack 200
ack 700
Receptor
TCP: timeout
‣
¿Qué timeout se debe usar?
>
>
>
>
>
Suficiente para que el paquete llegue a su destino y el ACK vuelva.
A este tiempo se le denomina tiempo de ida y vuelta o
Round Trip Time (RTT)
El RTT depende de muchos factores
+ velocidad de la red
+ tiempos de respuesta del destino
RTT
+ tiempos de espera en routers
Muy variable, incl entre origen y destino fijos
timeout < RTT
retransmisiones innecesarias
timeout >> RTT
reacción lenta ante las pérdidas
TCP: timeout
‣
‣
Solución: estimar el RTT y
adaptar el timeout al valor
de RTT estimado
Estimando el RTT
>
Se toma una muestra SampleRTT por
cada vez que se envía un segmento
hasta que llega su correspondiente
ACK
+ Se ignora la muestra si el segmento
se retransmite
+
Se mide con delayed acks
(overestimation)
+
Sólo se puede medir una muestra a
la vez (1 solo timer)
y normalmente con precisión de
500ms
SampleRTT1
SampleRTT2
Descartado por
retransmisión
SampleRTT3
TCP: estimación RTT
‣
El valor medido SampleRTT varía
queremos un RTT estimado suave
>
Utilizamos el promedio de varias muestras
Exponential weighted moving average
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
>
>
La influencia de muestras pasadas decrece exponencialmente
Típicamente: α= 0.125
TCP: estimación de RTT
‣
Ejemplo
24 octubre 2005
Transporte-4
15
/17
TCP: estimación de RTT
‣
Eligiendo el timeout
>
EstimatedRTT mas un márgen de seguridad
+
+
A mayor variación de EstimatedRTT mayor debe ser el margen
de seguridad
Estimamos la variación de EstimatedRTT con
DevRTT = (1-β)*DevRTT +
β*|SampleRTT-EstimatedRTT|
(typically, β = 0.25)
‣
Se toma como timeout
TimeoutInterval = EstimatedRTT + 4*DevRTT
TCP: Control de flujo
‣
‣
El receptor de TCP tiene un buffer en el que TCP va
colocando los datos que llegan.
>
Estos datos se le entregan al nivel de aplicación al hacer un read() sobre el socket
>
La aplicación puede ser lenta al leer los datos. Qué pasa si los datos llegan y no hay
buffer?
>
Hace falta un mecanismo que ajuste la velocidad de los datos que llegan a la velocidad a
la que lee la aplicación
Este es el problema del control de flujo.
>
Es un problema general de los protocolos de comunicaciones
>
Normalmente se resuelve haciendo que el receptor sea capaz de enviar indicaciones al
emisor de que su buffer se esta llenando para que este reduzca la velocidad de envío
read()
buffer de recepción
‣
TCP informa al emisor de cuanto
buffer tiene libre en cada
paquete que le envía !!
>
>
>
Cabecera IP
...
puerto origen
puerto destino
numero secuencia
numero ack
checksum
urgent data ptr
Esa es la función del campo ventana de
recepción de la cabecera
En cada paquete el receptor anuncia cuantos
datos es capaz de recibir
Este valor se utiliza como máximo numero de
bytes que se pueden tener en la red sin recibir
ACK. Máximo de la ventana deslizante
ventana anunciada
buffer de recepción
opciones
Datos aplicación
Ejemplo
‣
De una transferencia de página web
1124207801.184011
1124207825.463815
1124207825.464062
1124207825.466289
1124207825.466784
1124207825.466915
1124207825.511610
1124207825.512278
1124207825.512382
1124207825.512503
1124207825.512626
1124207825.711709
1124207825.712371
1124207825.712474
1124207825.712595
1124207825.712723
1124207825.712842
1124207825.911783
‣
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
130.206.169.177.53611 > 130.206.166.105.80:
130.206.169.177.53611 > 130.206.166.105.80:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.169.177.53611 > 130.206.166.105.80:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.169.177.53611 > 130.206.166.105.80:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.166.105.80 > 130.206.169.177.53611:
130.206.169.177.53611 > 130.206.166.105.80:
.
P
.
P
.
P
.
.
.
.
P
.
.
.
.
.
P
.
ack 1 win 65535
1:39(38) ack 1 win 65535
ack 39 win 24616
1:291(290) ack 39 win 24616
291:1739(1448) ack 39 win 24616
1739:3187(1448) ack 39 win 24616
ack 3187 win 63422
3187:4635(1448) ack 39 win 24616
4635:6083(1448) ack 39 win 24616
6083:7531(1448) ack 39 win 24616
7531:8979(1448) ack 39 win 24616
ack 8979 win 57630
8979:10427(1448) ack 39 win 24616
10427:11875(1448) ack 39 win 24616
11875:13323(1448) ack 39 win 24616
13323:14771(1448) ack 39 win 24616
14771:16219(1448) ack 39 win 24616
ack 16219 win 50390
Conforme recibo datos se va llenando el buffer
‣
El campo para anunciar
ventana sólo tiene 16
bits
>
>
‣
Solo puede anunciar 65KBytes !!!
(el numero de secuencia direcciona
4GB)
Podían ser suficientes en los
primeros tiempos de TCP...
Consecuencias
>
>
no hay que preocuparse del
overlflow de numero de secuencia
si hay que preocuparse por las
velocidad de transferencia
RTT
La máxima velocidad
de transferencia es:
ventanamax
v=
RT T
En el ejemplo de 1Gbps y 30 ms
65535bytes
v=
≈ 17.5Mbps
30ms
Al menos llegamos al 17%
TCP: conexiones
‣
‣
‣
Hasta ahora hemos visto los mecanismos de
transporte fiable y control de flujo entre un emisor y
un receptor TCP.
TCP es orientado a conexión
Previamente comunicarse datos entre un emisor y un
receptor deben negociar un establecimiento de
conexión.
>
TCP inicializa sus variables para la conexión y crea los buffers
>
>
Esto se hace mediante los paquetes que utilizan los flags SYN, FIN y RST
Protocolo para establecer la conexión
>
Protocolo para liberar la conexión
TCP: establecimiento de conexión
‣
Mecanismo: Three way handshake
>
Lado cliente (socket que hace connect)
envía un paquete sin datos con el flag SYN
Establece el numero de secuencia inicial
>
Lado servidor (socket que hace accept)
responde con un paquete sin datos con ACK y SYN
>
Establece el numero de secuencia inicial
Lado cliente reconoce este paquete con un ACK
Este paquete ya puede llevar datos
>
Al recibir el ACK el servidor puede enviar ya datos
>
Los SYNs gastan un número de secuencia para poder
confirmarse con ACKs
SYN
ACK+SYN
ACK
Ejemplo
‣
Otra conexión web...
Los SYNs usan un número
de secuencia para poder ser
confirmados
IP ...177.53656 > ...105.80: S 3482203897:3482203897(0) win 65535
SYN
IP ...105.80 > ...177.53656: S 3356369201:3356369201(0) ack 3482203898 win 24616
IP ...177.53656 > ...105.80: . ack 3356369202 win 65535
ACK
SYN
+ACK
IP ...177.53656 > ...105.80: P 3482203898:3482204138(240) ack 3356369202 win 65535
IP ...105.80 > ...177.53656: . ack 3482204138 win 24616
IP ...105.80 > ...177.53656: P 3356369202:3356369502(300) ack 3482204138 win 24616
IP ...105.80 > ...177.53656: . 3356369502:3356370950(1448) ack 3482204138 win 24616
IP ...105.80 > ...177.53656: P 3356370950:3356372398(1448) ack 3482204138 win 24616
Aqui empieza la transferencia
Paquete 4
Cierre de la conexión
FIN
‣
Cualquiera de los dos
extremos puede
iniciarlo
>
>
>
Envia un paquete sin datos con
el flag FIN. Consume tambien
un numero de secuencia
El otro extremo, confirma
enviando un ACK e indica que
cierra tambien con otro FIN.
Este segundo FIN puede ir en
el mismo paquete o en otro.
El extremo original confirma
con un ACK
ACK+FIN
ACK
FIN
ACK
FIN
ACK
Cierre de la conexión
&LHUUHGH&RQH[LyQ
‣
Medio cierre
>
>
El cierre de cada sentido de la
conexión es en realidad
independiente
Un extremo puede cerrar la
conexión indicando que no enviara
mas datos pero puede seguir
recibiendo lo que le envian
FIN
ACK
datos
ACKs
FIN
ACK
close(s)
Ejemplo
‣
El final de una conexión web...
El servidor está enviando datos
El cliente decide cerrar y manda un FIN
...
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.169.177.53701 > 130.206.166.105.80:
IP 130.206.169.177.53701 > 130.206.166.105.80:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.169.177.53701 > 130.206.166.105.80:
P
P
.
F
.
F
.
80314174:80315622(1448) ack 4067364561 win 24616
80315622:80316551(929) ack 4067364561 win 24616
ack 80316551 win 65535
4067364561:4067364561(0) ack 80316551 win 65535
ack 4067364562 win 24616
80316551:80316551(0) ack 4067364562 win 24616
ack 80316552 win 65535
El servidor cierra su sentido
TCP: abortar una conexión
‣
Paquete Reset (RST)
>
>
>
>
>
Se envía cuando TCP recibe un paquete que
es inconsistente con su estado de la
conexión
recibir datos sin tener conexión abierta
Le dice al otro extremo que esa conexión
no existe y que destruya toda la
información de ese estado de conexión
También se usa para decir que no hay nadie
escuchando un puerto
También se puede usar por el nivel de
aplicación para cerrar una conexión de
forma rápida
El otro extremo no hace falta que conteste
nada
datos
RST
TCP: establecmimiento de conexión
‣
¿Qué pasa si se pierden paquetes del
establecimiento o del cierre?
>
>
‣
Retransmision de SYNs
>
‣
Tienen un número de secuencia así que se pueden retransmitir. Es como si
fueran un byte de datos.
Se utiliza retransmisión por timeout
Problema: al comenzar la conexión no ha habido tiempo de hacer
estimaciones del RTT.
La mayoría de las implementaciones utilizan un timeout inicial de 6
segundos. Si falla el timeout se pone a 24 segundos y se va doblando
Retransmision de FINs
>
Problema: el sistema operativo no puede deshacerse del estado de la
conexión inmediatamente. Tiene que mantenerlo un tiempo por si acaso
hacen falta retransmisiones
TCP estados
TCP Estados
del servidor
TCP Estados
del cliente
‣
Casos especiales: apertura simultánea
>
Si dos clientes inician simultaneamente una conexión entre ellos
>
Nótese que los dos tienen que usar puertos conocidos por el otro
Se usa muy poco
>
connect()
SYN
SYN
connect()
ACK+SYN
ACK+SYN
ACK
ACK
‣
Casos especiales: cierre simultáneo
>
>
Los dos extremos deciden cerrar a la vez
Los dos extremos deben esperar en TIME_WAIT para poder
retransmitir el FIN
close()
FIN
FIN
close()
ACK
TIME_WAIT
ACK
TIME_WAIT
¿Por qué se pierden los paquetes?
‣
Varias causas
>
Errores de transmisión.
Modifican bits aleatorios de los
paquetes. Los niveles que hacen
detección de errores se ven obligados
a descartar el paquete al no estar
seguros de entregarlo correctamente
>
Independiente del tráfico
Desbordamiento de buffer
Un router que debe reenviar un
paquete se encuentra con que todos
sus recursos de memoria (por
ejemplo en la cola de paquetes
esperando la salida están ocupados).
Debe descartar el paquete por falta
de recursos
Dependiente de la carga de la
red
Para R3
R1
R2
R3
R4
R1
R2
R3
R4
Congestión de red
¿Qué es?
‣ Demasiadas fuentes enviando demasiado trafico
para que la red pueda manejarlo
‣ No es lo mismo que el control de flujo
>
>
‣
Efectos:
>
>
‣
Relacionado con que el receptor pueda manejar el tráfico
La congestión puede darse aunque todos los receptores sean capaces de
aceptar el trafico que se está enviando
Pérdidas de paquetes (debido a desbordamiento de colas de routers)
Tiempos de espera elevados (debido a tiempos de espera en colas altos)
Es uno de los problemas más importantes de redes
Escenario 1
‣
‣
Dos emisores y dos receptores
Un router común (supongamos que con buffer infinito)
>
Nunca ocurren retransmisiones
>
Las dos fuentes envian a una media de λin
La capacidad del router es C
>
‣
Como se comporta el sistema??
Escenario 1
‣
Entrada y salida. Cuanto throughput obtenemos del sistema?
retardo
λout para cada λin aceptable (mitad de capacidad para cada uno)
!out
C/2
!in
‣
‣
‣
!in
C/2
C/2
Pero el retardo aumenta indefinidamente
Cada vez tiene más paquetes que procesar
Recursos infinitos no garantizan un buen funcionamiento
31 octubre 2005
Transporte-6
6
/18
Escenario 2
‣
Igual que el anterior pero ahora el router tiene
recursos finitos.
>
>
>
Los paquetes no esperan indefinidamente (retardo limitado)
Si se transmite a mucha velocidad algunos paquetes se perderan
y el nivel de transporte los retransmitirá
Tráfico
λ’in = λin + retransmisiones
Escenario 2
‣
λin = λout (goodput)
Envío perfecto (no hay retransmisiones hasta que alcancemos R/2)
> λout
!out
!out
Retransmisión implica λ’in
!out
‣
R/2
R/3
R/4
R/2
!'in
Perfecto
no retransmisiones
‣
R/2
!'in
Retransmisiones sólo
por desbordamiento
R/2
Retransmisiones por
timeout prematuro
Coste de la congestión
>
>
!'in
Más trabajo (retransmisiones) para el mismo resultado (goodput)
Retransmisiones innecesarias: capacidad perdida
Control de congestión
‣
Problema:
cuando la red está saturada por alta carga
proveniente de muchas fuentes
se pierden paquetes, se cursa menos tráfico útil y
aumenta el retardo de los paquetes que llegan a su
destino
Los protocolos de transporte reaccionan
aumentando las retransmisiones causando
más carga y más congestión
Dos enfoques para control de congestión
‣ Control de congestión extremo a extremo
>
>
>
>
No hay indicación explicita de la congestión
Los extremos estiman la congestión basandose en sus propias
observaciones de la red
+ Perdidas observadas
+ Retardo observado
Los extremos reacciónan a la congestión reduciendo la carga:
disminuyendo retransmisiones, tasa de envíos, aumentando
timeouts...
Esta es la filosofía que utiliza TCP
Dos enfoques para control de congestión
‣ Control de congestión asistido por la red
>
Los routers informan de la congestión a los extremos de la
comunicación
+ Modificando un bit para indicar congestión:
SNA, DECnet, TCP/IP ECN (RFC2481), ATM
+ Indicando la tasa máxima a la que puede enviar
ATM ABR
Control de congestión en Internet
‣Internet
‣
se basa en un nivel de red simple que
no asiste en la detección de la congestión
TCP utiliza control de congestión extremo a
extremo
>
Como inferimos que hay congestión en la red?
+ Perdidas?
+ Retardo?
>
Qué hacemos para evitarlo?
+ Reducir la tasa de envío? Cómo?
+
‣
Aumentar el timeout?
Si hay errores bajar la tasa de transferencia?
TCP: Control de congestión
‣
Usa control de congestión extremo a extremo
>
>
>
>
La ventana deslizante de transporte fiable tenia un limite máximo impuesto
por el control de flujo igual a la ventana anunciada por el receptor
Se utiliza otra ventana de congestión que limita los datos que se
pueden enviar a la red dependiendo de la percepción que tiene TCP de la
congestión
La ventana anunciada depende del receptor
La ventana de congestión se reduce ante la congestión limitando la tasa a la
que enviamos
CongWin
v=
RT T
Ventana = min { ventana anunciada, ventana de congestión }
confirmados
enviados
se pueden
enviar
no se pueden
enviar
TCP: Control de congestión
‣
¿Cómo percibe TCP la congestión?
>
Perdida de paquetes = congestión
+
+
‣
Ajustando la ventana de congestión
>
Congestion avoidance (evitación de congestion)
>
Slow start
Fast recovery
Timeout
>
>
‣
Evento de timeout
3 ACKs duplicados (Fast retransmit)
MSS: maximun segment size
>
>
Aun cuando TCP utiliza secuencias y ACKs por bytes individuales cuando tiene
mucho que enviar utiliza un máximo tamaño de segmento, que llamaremos
MSS
En la siguiente clase veremos como se elige el MSS
TCP: Congestion avoidance
‣
Tras detectar congestión TCP entra en una fase de
evitación de congestión (congestion avoidance)
>
Si la ventana de congestión tiene un valor de N MSS
>
En congestion avoidance se abre 1 MSS cada vez que enviamos con exito
toda la ventana
CongWin=4 MSS
La ventana sube linealmente
>
Buscando encontrar el punto de
equilibrio sin aumentar demasiado la
congestión
CongWin=5 MSS
Enviado
por RTT
tiempo
‣
Si en esta situación se produce una pérdida
>
>
De un sólo paquete, lo que provoca 3 ACKs duplicados. Se interpreta como
congestión ligera
La ventana se reduce inmediatamente a la mitad
A la vez que se hace fast retrasmit del paquete perdido
Esto se conoce como fast recovery (originalmente se reducía a 1MSS)
>
>
Buscando reducir notablemente la tasa
de transmisión y colaborar en que la
congestión no crezca
Si se siguen recibiendo ACKs la
ventana sigue creciendo linealmente
Enviado
por RTT
CongWin=8 MSS
CongWin=4 MSS
tiempo
‣
‣
Se puede ver que la tasa se va ajustando
alrededor del punto de congestión
>
si hay muchos errores la tasa baja y se tarda más en recuperarla
>
si hay pocos errores el crecimiento lineal es capaz de llegar mas a mas
velocidad
>
Este mecanismo se suele llamar AIMD
Additive Increase Multiplicative Decrease
Y cómo empieza la conexión??
>
Con CongWin = 1 MSS
Enviado
por RTT
1 pérdida
1 pérdida
1 pérdida
tiempo
TCP: Slow Start
‣
En el principio CongWin=1 MSS pero...
> Crecer linealmente es demasiado precavido,
no tenemos motivos para pensar que hay
congestión
> Se utiliza un enfoque más agresivo,
crecimiento exponencial
> Slow Start: cada vez que transmitimos una
ventana con éxito la ventana se dobla
CongWin
=1 MSS
CongWin
=2 MSS
CongWin
=4 MSS
CongWin
=8 MSS
tiempo
TCP: Slow Start
‣
El slow start se mantiene hasta que se produce una
pérdida (o bien se alcanza la ventan de control de
flujo) haciendo entrar en congestion avoidance
>
Si la perdida se detecta por ACKs duplicados...
+
‣
Fast retransmit + fast recovery
CongWin = CongWin/2
Y si se produce un timeout?
slow start
congestion avoidance
tiempo
TCP: pérdidas y congestión
‣
Pérdida detectada por ACK duplicados
>
>
‣
Congestión “ligera”: hay perdidas pero siguen llegando paquetes
Acciones:
+ Retransmitir el paquete perdido (Fast retransmit)
+ Bajar la ventana de congestion para reducir la tasa
+ Pasar a congestion avoidance (si no estabas)
Pérdida detectada por timeout
>
>
Congestión “grave”. Probablemente hemos perdido toda la ventana. Si el
timeout ha caducado llevamos un rato parados sin transmitir. Tasa =0
Acciones:
+ Poner la ventana de congestión a 1MSS
+ Pasar a slow start
+ Recordar a cuanto estaba la ventana de congestión al producirse el
error (poner la variable threshold=CongWin/2)
TCP: slow start
‣
Despues de una perdida por timeout
>
>
el slow start no espera a otra pérdida para entrar en congestion
avoidance.
Pasa a congestion avoidance en cuanto llega al humbral de la mitad
de la ventana de congestion al producirse el timeout
slow start
pérdidas y
timeout
congestion avoidance
tiempo
TCP: control de congestión
En resumen
‣ Cuando CongWin está por debajo de Threshold.
Slow start. La ventana crece exponencialmente
‣ Cuando CongWin está por encima de Threshold.
Congestion avoidance. La ventana crece
linealmente
‣ Cuando ocurre un triple ACK duplicado.
Threshold se pone a CongWin/2 y CongWin a
Threshold
‣ Cuando ocurre un timeout. Threshold se pone a
CongWin/2 y CongWin se pone a 1MSS
TCP: control de congestión
‣
Eventos en el emisor
Evento
Estado
Acción
Notas
Recibe ACK para
datos no
confirmados
Slow Start
(SS)
CongWin = CongWin + MSS,
If (CongWin > Threshold)
set state to “Congestion Avoidance”
CongWin se dobla por cada
RTT
Recibe ACK para
datos no
confirmados
Congestion
Avoidance
(CA)
CongWin = CongWin+MSS * (MSS/CongWin)
Additive increase, CongWin
aumenta 1 MSS por cada
RTT
Perdida
detectada por
triple ACK
duplicado
SS or CA
Threshold = CongWin/2,
CongWin = Threshold,
Set state to “Congestion Avoidance”
Fast recovery+multiplicative
decrease. CongWin nunca
baja a menos de 1MSS
Timeout
SS or CA
Threshold = CongWin/2,
CongWin = 1 MSS,
Set state to “Slow Start”
vuelve a slow start
ACK duplicado
SS or CA
Incrementar contador de ACKs duplicados
para ese segmento
CongWin y Threshold no
cambian
TCP: evolución de la conexión
‣
Ejemplo, una conexión TCP
muchas
perdidas
slo
w
slow
pérdida
sta
rt
n
o
i
t
s
ge
n
e
o
c
c
n
a
d
avoi
star
t
La ventana de control de
flujo impone el máximo
ion
t
s
e
cong ance
avoid
pérdida
TCP: eficiencia de la conexión
‣
‣
Sigue el límite de AdvertisedWindow/RTT
Esto es para una conexión que este siempre
enviando
>
>
‣
Tenga siempre datos en el buffer de emisión
La aplicación del receptor lea los datos suficientemente rápido
como para que el emisor siempre anuncie la ventana máxima
Cómo podemos transmitir a mayor velocidad?
>
>
>
Mejorando TCP para que permita ventanas mayores
Usando más de una conexión TCP??
UDP tiene control de flujo??
TCP: equidad (fairness)
‣
Equidad para TCP
>
Si N conexiones TCP comparten un enlace la capacidad del enlace R
debería repartirse entre todas por igual R/N
Cuello de botella
capacidad R
Más sobre equidad
‣
¿Qué pasa con UDP?
>
>
>
‣
Las aplicaciones multimedia suelen usar UDP para evitar el control
de congestión.
Envían a tasa constante y no quieren que esta se vea reducida
Son capaces de tolerar pérdidas
Sin embargo
>
>
>
Es dificil garantizar la equidad en ese ambiente TCP+UDP
El control de congestión de TCP es justo si compite con otros TCPs
Esto es un área de investigación activa
+ UDP que sea TCP friendly?
+ Envio de multimedia sobre TCP?
Más sobre equidad
‣
Las aplicaciones pueden abrir más de una
conexión TCP entre dos hosts
>
>
>
‣
Así podrían superar la limitación de la ventana de control de flujo de
65KB
Los navegadores web hacen esto
Parte de la mejora de transferencia de los sistemas P2P viene de
este efecto !!
Sin embargo
>
>
Esto también dificulta el problema de la equidad en TCP
Si en un enlace de capacidad R hay 9 conexiónes TCP
+ Puedo abrir una conexión y conseguir un reparto de R/10
+ O puedo abrir 11 y conseguir R/2 !!!
TCP: últimos detalles
‣
‣
Hemos estudiado el control de congestión y el
transporte fiable, cuando las aplicaciones envían
datos constantemente
Algunos problemas cuando las aplicaciones leen
y escriben de forma poco eficiente
>
>
Enviando pocos bytes, el algoritmo de Nagle
El problema de la ventana tonta (silly window sindrome)
TCP: algoritmo de Nagle
‣
‣
El problema de escribir
despacio
Aplicación de acceso remoto
>
>
‣
El usuario escribe a razon de una letra
cada muchos milisegundos. El servidor
hace echo de todo lo que le llega
El nivel TCP envía paquetes de 41 bytes
para enviar una letra
Demasiado overhead
sobre todo si no estamos en
una LAN
cliente
servidor
l
s
l
s
\n
\n
para enviar 6 bytes
hemos enviado a la
red 246 bytes
TCP: algoritmo de Nagle
‣
cliente
servidor
Algoritmo de Nagle
>
>
>
Si una conexión tiene datos
enviados sin confirmar no
puede enviar segmentos
pequeños (menores que MSS)
hasta que reciba el ACK de los
que envió
Los datos se van acumulando en
un paquete que se envía al llegar
el ACK
Algoritmo self-clocking en una
LAN no tiene efecto porque las
confirmaciones llegan muy
deprisa
‘l’
‘s’
‘‘
‘-’
‘l’
‘l’
‘l’
‘s -l’
‘\n’
‘s -l’
‘\n’
TCP: persist timer
‣
El problema de leer despacio
>
>
>
‣
Si la aplicación receptora lee muy despacio el buffer se puede llenar.
El receptor aununcia ventana 0
Cuando la ventana vuelve a aumentar el receptor debe anunciar
mayor ventana. Si no tiene datos que enviar lo hace en un paquete
simple de ACK
Que ocurre si este ACK se pierde?
+ El emisor no puede enviar mas datos porque la ventana esta a
cero
+ El receptor no sabe que su ACK se ha perdido
Para evitar esto TCP envía periódicamente
window probes con 1 byte de datos
>
Tambien usan exponential backoff (hasta 60s) pero nunca caducan
TCP: silly window
‣
Qué pasa si la aplicación lee
los datos muy despacio?
>
El emisor se ve forzado a enviar byte a
byte. A pesar de que la aplicación
tardara un tiempo en estar interesado
en ese byte !
win 500
win 0
1byte
win 1
‣
Soluciones
>
>
Delayed ACK : este es uno de los
motivos
No se anuncia ventana hasta que haya
un minimo tamaño en el buffer, 1MSS
win 0
1byte
win 1
win 0
TCP: detalles
‣
Para que sirve el flag PUSH ??
>
‣
Originalmente para indicar a TCP que debe entregar esos datos
inmediatamente a la aplicación. La aplicación emisora podía notificar a TCP
en que punto debía entregar.
Hoy en día las aplicaciones no tienen esa opción y TCP pone el flag PUSH
a 1 cuando vacía el buffer del emisor
Los sistemas derivados de BSD nunca retrasan la entrega de datos a las
aplicaciones
Si los dos extremos no envían nada. TCP envia
paquetes para mantener la conexión activa???
>
NO,
Hay una opción KEEPALIVE que hace enviar periódicamente paquetes para
confirmar que el otro extremo sigue ahí. Pero es objeto de gran polémica
Si tengo un telnet, pierdo la red y la recupero un tiempo después, por qué
debería perder la conexión?

Nivel de Transporte: Introducción, UDP y TCP

Transcripción

Documentos relacionados

Calibración de Access Points para Aplicaciones de Larga Distancia

Innovación