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.