1
Protocolo de Datagrama de Usuario
User Data Protocol (UDP)
2
Protocolo no orientado a conexión
Mensajes no numerados
No fiable
Muy sencillo => mínima sobrecarga
Sin control de flujo ni de error
Excepto para la suma de comprobación (checksum). Los paquetes erróneos se descartan
Sin control de congestión
El control de flujo o de error lo podría proporcionar la capa de aplicación si fuera necesario
Características generales
3
Puertos bien conocidos usados con UDP
4
Cabecera de tamaño fijo de 8 bytes
Usada principalmente para especificación de puertos
Chequeo de comprobación (checksum)
Longitud total, incluyendo la propia cabecera, 16 bits, 64 KB
Datagrama de usuario
5
Colas en UDP
En el cliente puede haber hasta dos colas (entrada y salida) que
se destruyen al terminar el proceso. En la salida, UDP extrae
mensajes uno a uno, añade cabacera y los entrega a la capa de
red. En la entrada, si existe la cola se entrega al cliente, y en
caso contrario se descarta
En el servidor, las colas están abiertas mientras se ejecuta el
proceso. Si llega un mensaje y existe la cola, se pone al final
de la misma. En caso contrario se descarta
6
Protocolo de Control de Transmisión
Transmission Control Protocol (TCP)
7
TCP es un protocolo orientado a conexión que crea
una conexión virtual entre dos extremos para enviar
datos. Además, TCP usa mecanismos de control de
flujo y error en la capa de transporte.
Servicios TCP
Flujos
Segmentos
Conexión TCP
Control de flujo
Control de error
Aspectos a estudiar en este apartado:
Características generales
8
Servicios TCP
Comunicación Full Duplex
- Los datos circulan en ambos sentidos al mismo tiempo
Orientado a conexión
– Se establece una comunicación previa entre ellos
– Se intercambian datos (en ambas direcciones)
– Se cierra la conexión
Conexión virtual (no física)
– Segmento TCP encapsulado en un datagrama IP
– Cada segmento puede usar una ruta distinta
– En caso de perderse o corromperse, se reenvía
Fiable, confirmación de que los datos han llegado bien y
en orden, usando confirmaciones, reenvíos, checksum, etc…
9
Puertos bien conocidos usados por TCP
10
Transmisión de flujos
Permite al proceso emisor enviar datos como si fuese un
flujo de bytes, y permite al proceso receptor obtener los
datos a partir de dicho flujo de bytes
11
Envío y recepción de buffers
Las velocidades de emisor y receptor pueden ser
distintas. Se necesitan buffers para almacenamiento.
12
Segmentos TCP
En realidad, IP manda los datos en paquetes y no en flujo
de bytes. TCP agrupa un número de bytes en un paquete
llamado segmento, que se encapsula en un datagrama IP
13
TCP numera todos los bytes de datos que se
transfieren en cada conexión.
La numeración empieza en un número aleatorio
No existe campo número de segmento.
Hay “número de secuencia” y “número de
confirmación” (referidos ambos al byte).
Después de numerar los bytes, TCP asigna un
número de secuencia a cada segmento que
envía, que coincide con el número del primer
byte.
Conexión TCP: Numeración
14
Suponer una conexión TCP para transferir un fichero de
5000 bytes. El primer byte tiene el número 10.001. Obtener los
“números de secuencia” para cada segmento si los datos se
envían en 5 segmentos de 1000 bytes cada uno.
Ejemplo
El valor del campo “número de secuencia” de un
segmento define el número del primer byte de
datos contenido en dicho segmento
15
El valor del campo de confirmación de un
segmento define el número del siguiente byte que
espera recibir el receptor del segmento.
El número de confirmación es acumulativo: el
receptor del segmento pone el número del último
byte recibido correctamente, le suma 1 y envía
dicha suma como número de confirmación.
Ejemplo, si usa 5643 como número de
confirmación, significa que el último byte recibido
fue el 5642 (no que haya recibido 5642 bytes,
porque el primero no tiene por qué ser 1).
Número de confirmación (ACK)
16
Formato segmento TCP
17
Descripción de flags en el
Campo de Control
18
Algunas consideraciones
sobre el segmento TCP
La longitud de la cabecera, HLEN, se expresa en palabras de 32 bits
(4 bytes). Como la cabecera oscila entre 20 bytes y 60 bytes,
5<=HLEN<=15.
El tamaño de la ventana, cuyo máximo valor es 65535, es el tamaño
que debe tener en bytes la ventana en el receptor, también llamada
ventana de recepción rwnd y la fija el receptor. El emisor debe acatar
esta orden del receptor.
Opciones: hasta 40 bytes adicionales para la cabecera TCP.
Puntero urgente: si el flag correspondiente está activado,
este campo de 16 bits se usa cuando hay datos urgentes.
Se suma número de secuencia y puntero para obtener
el número del último byte urgente y principio de datos no
urgentes (normales).
19
Conexión TCP: establecimiento de
conexión con la negociación en tres pasos
Se establece una conexión virtual
(lógica) entre origen y destino en tres
fases:
• Establecimiento
• Transferencia de datos
• Cierre
20
Conexión TCP: establecimiento de cone-
xión con la negociación en tres pasos (I)
1.- El cliente emite una petición de apertura activa enviando un
segmento de control, SYN, con número de secuencia 8000, con el fin
de iniciar el establecimiento de una comunicación con un servidor
determinado que está preparado. No puede llevar datos, aunque
consume un número de secuencia.
2.- El servidor responde con el envío de un segmento de control,
SYN+ACK, con número de secuencia 15000, y el número de
confirmación 8001, que confirma la correcta recepción del segmento
de control 8000. No puede llevar datos, pero consume número de sec.
3.- El cliente envía un segmento de control, ACK, confirmando la
recepción del mensaje SYN+ACK numerado como 15000. El número
de secuencia es el siguiente al del mensaje anterior (8001). Este
mensaje no tiene número si no lleva datos (como es el caso).
Conexión TCP: establecimiento de cone-
xión con la negociación en tres pasos (II)
22
Un segmento SYN no puede llevar datos, pero
consume número de secuencia
Un segmento SYN + ACK no puede llevar
datos, pero consume número de secuencia
Un segmento ACK (después de recibir
SYN+ACK), si no lleva datos (que podría
llevar), no consume número de secuencia
Conexión TCP: establecimiento de cone-
xión con la negociación en tres pasos (III)
Establecimiento de la conexión:
Ataque por SYN masivo (DoS)
24
Conexión TCP:
transferencia de datos (I)
El cliente envía desde el byte 8001 hasta el 9000, y espera
recibir del servidor el byte 15001. El cliente envía desde el
byte 9001 hasta el 10000, y sigue esperando recibir del
servidor el byte 15001. El flag P está activo para pedir
respuesta inmediata.
El servidor confirma que ha recibido correctamente hasta
el byte 10000 enviando ACK 10001, y envía al cliente
desde el byte 15001 hasta el 17000.
El cliente confirma que ha recibido correctamente el byte
17000 y envía desde el byte 10001
Conexión TCP:
transferencia de datos (II)
26
+1
Conexión TCP: cierre de la conexión
con la negociación en tres pasos (I)
1.- El cliente envía un segmento de control, FIN+ACK, con número
de secuencia x, y número de confirmación y (ha recibido hasta y-1)
con el fin de finalizar una comunicación. No lleva datos, aunque
podría llevarlos.
2.- El servidor responde con el envío de un segmento de control,
FIN+ACK, con número de secuencia y, y el número de
confirmación x+1, que confirma la correcta recepción del
segmento de control x. No lleva datos, aunque podría llevarlos.
3.- El cliente envía un segmento de control, ACK, confirmando la
recepción del mensaje FIN+ACK numerado como y+1 (ha recibido
hasta y), y con número de secuencia x+1, el mismo que envió al
principio del cierre aumentado en 1. No puede llevar datos y no
consume número de secuencia.
Conexión TCP: cierre de la conexión
con la negociación en tres pasos (II)
28
El segmento FIN consume un número de
secuencia si no lleva datos, que podría llevar
El segmento FIN + ACK consume un número de
secuencia si no lleva datos, que podría llevar
El segmento ACK del cliente se incrementa en 1,
no puede lleva datos y no consume número de
secuencia
Conexión TCP: cierre de la conexión
con la negociación en tres pasos (III)
29
Conexión TCP: fin de la conexión con la
negociación en 4 pasos: semicierre (I)
30
Un extremo puede dejar de enviar datos,
pero seguir recibiendo: semicierre
En la Figura ocurre con el cliente.
Aunque no envía datos, sí envía ACKs
El cliente envía un segmento FIN y el servidor
lo acepta con un ACK (no ACK+FIN).
El servidor sigue mandando datos y finalmente,
cuando el servidor termina, envía un segmento
con ACK+FIN que es confirmado por el cliente
Conexión TCP: fin de la conexión con la
negociación en 4 pasos: semicierre (II)
31
Funcionamiento normal (I)
32
Funcionamiento normal (II)
1.- El cliente envía el número de segmento 1201 correspondiente al
bloque de bytes 1201 a 1400 ambos incluídos. Además, espera
recibir el byte 4001, con lo que confirma haber recibido
correctamente hasta el byte 4000.
2.- El servidor responde confirmando que ha recibido el byte 1400,
enviando 1401 como número de confirmación, y envía el bloque de
bytes de 4001 a 5000 ambos incluídos, indicando en su campo
número de segmento el valor 4001.
3.- Pasados 500 ms y esperando por si llegan más segmentos, se
dispara un temporizador. El cliente, que no tiene datos que enviar,
confirma la correcta recepción del byte 5000 enviando un mensaje
ACK con el campo de confirmación puesto a 5001.
33
Funcionamiento normal (III)
4.- El servidor envía el número de segmento 5001 correspondiente al
bloque de bytes 5001 a 6000 ambos incluídos. Además, sigue esperando
recibir el byte 4001. El último byte correcto que recibió fue el 4000. El
cliente no ha enviado más bytes con números superiores a 4000, por eso no
los ha recibido.
5.- El servidor envía el número de segmento 6001 correspondiente al
bloque de bytes 6001 a 7000 ambos incluídos y sigue esperando recibir el
byte 4001.
6.- Aunque no ha llegado a expirar el temporizador cuando llega el bloque
de bytes 6001-7000, el cliente confirma la correcta recepción del bloque
6001 - 7000 en cuanto lo recibe, e indirectamente del bloque 5001 - 6000,
enviando un ACK con número de confirmación 7001, sin añadir nuevos
datos.
34
Segmento perdido (I)
Suponer comunicación unidireccional
35
Segmento perdido (II)
1.- El emisor envía el número de segmento 501 correspondiente al
bloque de bytes 501 a 600 ambos incluídos. Además, espera recibir
el byte x (confirmada la correcta recepción hasta el byte x-1). Se
recibe correctamente en el receptor y se almacena en el buffer.
2.- El emisor envía el número de segmento 601 correspondiente al
bloque de bytes 601 a 700, ambos incluídos. Además, sigue
esperando recibir el byte x. Se recibe correctamente en el receptor y
se almacena en el buffer a continuación del anterior.
3.- El receptor confirma la correcta recepción hasta el byte 700 e
indirectamente también el bloque anterior (501-600) enviando un
mensaje de ACK sin datos con el campo de confirmación a 701.
36
Segmento perdido (III)
4.- El emisor envía el número de segmento 701 correspondiente al
bloque de bytes 701 a 800 ambos incluídos. Este segmento se pierde
y no llega al receptor. Poco después, el emisor envía el número de
segmento 801 correspondiente al bloque de bytes 801 a 900 ambos
incluídos, que sí llega al receptor.
5.- El receptor confirma la correcta recepción hasta el byte 700,
igual que en el punto anterior y almacena en el buffer el bloque de
bytes 801 a 900, dejando un hueco para el bloque perdido 701-800.
6.- Cuando el emisor recibe una confirmación que no corresponde al
último byte que envió y expira el temporizador (timeout), vuelve a
enviar el segmento del que todavía no tiene constancia de que haya
llegado.
37
Segmento perdido (IV)
7.- El emisor envía el número de segmento 701 correspondiente
al bloque de bytes 701 a 800 ambos incluídos. Esta vez no se
pierde y sí llega al servidor.
8.- Por un lado, el receptor confirma la correcta llegada del
último byte del que tiene constancia, el 900, enviando un ACK
con número de confirmación 901.
9.- Coloca el segmento con los bytes 701 a 800 perdido y
reenviado en el hueco que le había reservado en el buffer, de
manera que queda subsanada la pérdida del segmento con
bytes 701 a 800.