Version 03/03/2019

Computer Networks I

applicatio

n

transport

link

physical

network

1

CAPA DE TRANSPORTE

transporte

2

Contenidos

Conceptos generales

Entrega proceso a proceso

Sockets

Multiplexación y demultiplexación

Pushing & Pulling (empujar y recoger)

Control de Flujo

Control de Errores

Servicio no orientado a conexión y

orientado a conexión

Fiabilidad

UDP y TCP

3

Entrega proceso a proceso

Capa de Transporte:

Responsable de la entrega proceso a proceso

Los procesos se comunican usando el paradigma cliente-servidor

4

Cada proceso en el servidor escucha en un determinado puerto

El cliente define su propio puerto (puerto efímero) elegido al azar por el software para escuchar las respuestas

El servidor define su puerto entre un conjunto determinado llamado puertos bien conocidos

Números de puerto

5

Dirección IP y números de puerto

La dirección IP identifica al host

El puerto identifica a un proceso concreto en el host

Se usan 16 bits, con lo que los números varían entre 0 y 65535

6

Rangos IANA (Internet Assigned Number Authority)

Puertos bien conocidos: 0 - 1023 Asignados y controlados por IANA

Puertos registrados: 1024 to 49151 No asignados ni controlados por la IANA.

Sólo pueden ser registrados por IANA para evitar la duplicación.

Puertos dinámicos (o privados): 49152 - 65535 No controlados ni registrados por IANA

Se usan por cualquier proceso

Son efímeros.

IANA es un departamento de ICANN (Internet Corporation for Assigned Names and Numbers)

7

Puertos bien conocidos (I)

En Unix almacenados en un fichero llamado /etc/services

Ejemplo: servidor ftp

2 casos

Uno para cada protocolo de transporte

Puertos bien conocidos (II)

9

Sockets

Combinación de IP + puerto

Define un proceso de manera inequívoca

Los sockets se usan como abstracción básica para los programadores de red en la mayoría de los sistemas operativos

10

Multiplexación y demultiplexación

11

Control de flujo: Pushing & pulling

La entrega se puede producir de dos formas:

Push: Quien produce (productor) la entrega en el momento de generarla

No es solicitada por quien la recibe (consumidor)

El consumidor puede estar sobrecargado

Se necesita controlar el flujo

Pull: El productor la entrega cuando se la pide

No se necesita control de flujo

12

Control de flujo en la capa de transporte

Capa Aplicación (TX) Capa Transporte (TX): PUSH

Capa Transporte (TX) Capa Transporte (RX): PUSH

Capa Transporte (RX) Capa Aplicación (RX): PULL

13

La capa de red es no fiable

La fiabilidad se le exige a la capa de transporte. El control de errores es responsable de:

Detectar y descartar paquetes dañados

Realizar el seguimiento de los paquetes perdidos y descartados (reenvío si es necesario)

Evitar duplicidades

Almacén (buffer) para paquetes desordenados

Se implementa con:

Números de secuencia (en paquetes)

Confirmaciones y temporizadores

Control de errores

14

Protocolos no orientados a conexión (I)

El mensaje se divide en trozos (datagramas) por la capa de aplicación

Cada datagrama se trata como una unidad

Independiente del resto

Encapsulado como un paquete por la capa de transporte

Los paquetes se envían en orden

La recepción puede producirse fuera de orden

Problema porque no hay números de secuencia

Nadie controla el error

15

Protocolos no orientados a conexión (II)

16

Establecimiento previo de conexión lógica

Servicio extremo a extremo

Se puede implementar incluso sobre protocolos no orientados a conexión en la capa de red (por ejemplo IP)

Pueden implementar control de flujo y error

Protocolos orientados a conexión (I)

17

Protocolos orientados a conexión (II)

18

Protocolos en la capa de transporte en la pila TCP/IP

19

Protocolos confiables

20

Protocolos fiables (I)

Analicemos cómo proporcionar fiabilidad, desde el caso más sencillo hasta un caso real, aumentando la complejidad

Protocolo simple

Parada y espera

Vuelta atrás N (Go Back N, GBN)

21

Protocolos fiables (II)

22

Protocolo simple (I)

No orientado a conexión

Suponiendo condiciones ideales

No se necesita control de errores ni de flujo

No es un caso muy realista

23

Máquina de estados finitos (Finite State Machine, FSM)

Diagrama

de flujo

Protocolo simple (II)

24

Parada y espera (I)

Orientado a conexión

Control de flujo y error

Confirmación de cada paquete

Checksum (suma de comprobación) para comprobar la integridad

Secuencias numeradas

Necesita una ventana deslizante de tamaño 1

Temporizador

El emisor espera la confirmación del receptor antes de enviar un nuevo paquete

25

Parada y espera (II)

26

Máquina de Estados Finitos en Parada y espera

Parada y espera (III-a) con FSM

27

Parada y espera (III-b) con FSM

Emisor en estado preparado

Cuando llega una petición de la capa de aplicación, crea un paquete con el número de secuencia S, guarda una copia, lo envía, pone en marcha el temporizador y cambia al estado esperando

Emisor en estado esperando

Si llega un ACK correcto con el número esperado, S+1, se desplaza la ventana, finaliza el temporizador y cambia al estado preparado

Si llega un ACK corrupto o con un número no esperado, se descarta y sigue en el estado esperando

Si expira el temporizador, reenvía el paquete, se inicializa el temporizador y sigue en el estado esperando

28

Parada y espera (III-c) con FSM

Receptor, siempre en estado preparado

Si llega un paquete correcto con el número esperado R, se acepta y se entrega a la capa de aplicación, se actualiza la ventana receptora a R+1 y se envía ACK con dicho número R+1

Si llega un paquete correcto con un número no esperado (distinto de R), se descarta y se envía un ACK con el número esperado, R

Si llega un paquete corrupto, se descarta sin enviar ninguna confirmación ACK

29

Diagrama de Flujo

ACK anuncia el

nuevo paquete

que espera

Ejemplo de parada y espera

30

Esperar que un paquete se confirme antes de enviar otro conlleva una pobre eficiencia del canal

Para mejorar la eficiencia del canal, hay que enviar varios paquetes antes de que se confirmen, envío adelantado o pipelined

Flujo continuo de peticiones

Algunos pueden estar pendientes de confirmación

Los errores pueden obligar a volver atrás y retransmitir más de un paquete (de ahí el nombre “vuelta atrás N”)

Ventana deslizante

Más de un paquete pendiente (tamaño ventana >1)

Si se usan m bits para numerar los paquetes, habrá 2m-1 (números de secuencia). Ojo, 2 m-1, no 2 m

Vuelta atrás N, Go-Back-N (GBN)

31

Ventana deslizante (I)

Números de secuencia módulo 2m, con m bits

Tamaño de la ventana N = 2m -1

Mientras hay hueco dentro de la ventana, se pueden enviar nuevos paquetes

Una confirmación (ACK) provoca el deslizamiento de la ventana hacia la derecha

Sentido deslizamiento

32

Ventana deslizante con m=3 (II)

33

Ventana deslizante en GBN (I)

34

El tamaño de la ventana de recepción es 1

El receptor siempre está esperando la llegada de

un paquete específico

Cualquier paquete que no sea el esperado se

descarta y debe reenviarse

Cada vez que se recibe un paquete esperado, la

ventana se desplaza una posición, a la siguiente

A la izquierda de la ventana están los ya recibidos

y confirmados, mientras que a la derecha están los

paquetes que no pueden ser recibidos

Ventana deslizante en GBN (II)

35

Justificación del tamaño de la ventana deslizante (I)

Ejemplo para m=2, máximo tamaño ventana = 3

tamaño ventana emisor = 3 tamaño ventana emisor = 4

CORRECTO INCORRECTO

36

Todos los ACKs se pierden

El tamaño de la ventana debe ser menor (no igual) que 2m,

siendo m el número de bits. Sea, por ejemplo, m=2

Descarte correcto, tamaño máximo ventana emisor = 3, antes de

que expire el temporizador. En este caso se usa ventana tamaño 3

Se envía el paquete 0, el receptor lo recibe y espera el paquete 1

Se envía el paquete 1, el receptor lo recibe y espera el paquete 2

Se envía el paquete 2, el receptor lo recibe y espera el paquete 3

Expira el temporizador y se reenvían los paquetes 0, 1 y 2

Cuando el receptor recibe el paquete 0 la descarta correctamente

porque esperaba el paquete 3

Justificación del tamaño de la ventana deslizante (II)

37

Todos los ACKs se pierden

Aceptación errónea, tamaño máximo ventana emisor = 3, antes de

que expire el temporizador. En este caso se usa ventana emisor = 4

Se envía el paquete 0, el receptor lo recibe y espera el paquete 1

Se envía el paquete 1, el receptor lo recibe y espera el paquete 2

Se envía el paquete 2, el receptor lo recibe y espera el paquete 3

Se envía el paquete 3, el receptor lo recibe y espera el paquete 0

Expira el temporizador y se reenvían los paquetes 0, 1, 2 y 3

El receptor recibe el paquete 0 reenviado y lo acepta

erróneamente considerando que es el paquete 0 del siguiente ciclo

Justificación del tamaño de la ventana deslizante (III)

38

Emisor en estado preparado

Si llega una petición de la capa de aplicación, se crea un paquete con un número de secuencia Sn, se guarda una copia, se envía, se incrementa Sn y se pone en marcha el temporizador, y:

Si la ventana no está llena continúa en el estado preparado

Si la ventana sí está llena cambia al estado esperando

Si llega un ACK correcto con el número esperado de uno de los paquetes pendientes, se desplaza la ventana y, si todos los paquetes salientes quedan confirmados, se detiene el temporizador. Si no se confirman todos los paquetes, el temporizador se inicializa

Si llega un ACK corrupto o con un número no esperado, se descarta

Si expira el temporizador, se reenvían todos los paquetes y se inicializa el temporizador

Vuelta atrás N con FSM (I)

39

Emisor en estado esperando

Si llega un ACK correcto con el número esperado de uno de los paquetes pendientes, se desplaza la ventana, y:

Si se confirman todos los que estaban pendientes, se detiene el temporizador

Si quedan algunos por confirmar se reinicia el temporizador

En ambos casos cambia al estado preparado

Si llega un ACK corrupto o con un número no esperado, se descarta y sigue en el estado esperando

Si expira el temporizador, se reenvían de nuevo todos los paquetes, se inicializa el temporizador y sigue en el estado esperando

Vuelta atrás N con FSM (II)

40

Receptor, siempre en estado preparado.

Rn se inicializa a 0

Si llega un paquete correcto con el número Rn esperado, se acepta y se entrega a la capa de aplicación, se actualiza la ventana receptora a Rn+1 y se envía ACK con el número Rn+1

Si llega un paquete correcto con un número no esperado, se descarta y se envía un ACK con el número esperado Rn

Si llega un paquete corrupto, se descarta

Vuelta atrás N con FSM (III)

41

Vuelta atrás N con FSM (IV)

42

Tamaño ventana = 1

para el receptor m = 3

Tamaño ventana = 23 -1 = 7

para el emisor

Ejemplo de vuelta atrás N

Ejemplo con ACK

perdido

43

Explicación del ejemplo

Todos los paquetes enviados viajan correctamente, pero algún acuse

de recibo (ACK) se pierde, sin llegar a expirar el temporizador

Se envía el paquete 0 y se recibe ACK1

El emisor sabe que ha llegado el paquete 0 y pasa a enviar el paquete 1

Se envía el paquete 1 y no se recibe ACK2

El emisor no sabe si se ha perdido el paquete 1 o el ACK2

El receptor sí sabe que ha llegado el paquete 1, pero no sabe que se ha perdido

ACK2

Se envían los paquetes 2 y 3 y queda pendiente de confirmar el paquete 1

El emisor recibe ACK3 que confirma que se han recibido el paquete 2 e

indirectamente el paquete 1, quedando pendiente de confirmar el paquete 3

En el siguiente evento del emisor, se recibe ACK4 que confirma el paquete 3

No queda ningún paquete pendiente de confirmar

El emisor queda preparado para enviar más paquetes cuando lo solicite la capa de

aplicación

44

Otro ejemplo de vuelta atrás N

Ejemplo con

paquete

perdido

45

Todos los acuses de recibo viajan correctamente, pero algún paquete

se pierde

Se envía el paquete 0 y se recibe ACK1

El emisor sabe que ha llegado el paquete 0 y pasa a enviar los paquetes 1, 2 y 3

Se envían los paquetes 1, 2 y 3, pero el paquete 1 se pierde

El receptor recibe los paquetes 2 y 3 pero los descarta porque esperaba el paquete 1

Expira el temporizador y vuelven a reenviarse los paquetes 1, 2 y 3

Llega por primera vez a su destino el paquete 1 y se envía el ACK2

Cuando llega ACK2, después de haber enviado los paquetes 1, 2 y 3, el paquete 1

deja de estar pendiente de confirmación y se desliza la ventana una posición

Lo mismo ocurre cuando llega ACK3

Lo mismo ocurre cuando llega ACK4

Explicación del ejemplo