CAPA DE TRANSPORTE

La tarea de esta capa es proporcionar un transporte de datos confiable de la máquina de origen a la máquina de destino, independientemente de la red o redes físicas en uso.

☯ Transmission Control Protocol (TCP): es un protocolo de transporte

con todas las funciones orientado a la conexión fiable para las aplicaciones.

Incluye un gestor para el control de flujo.

Los ejemplos incluyen aplicaciones conocidas tales como el Protocolo de

transferencia de hipertexto (HTTP) el Protocolo de Transferencia de Archivos

(FTP) y el Simple Mail Transfer Protocol (SMTP).

☯ User Datagram Protocol (UDP): Un protocolo de transporte muy

simple que proporciona solo direccionamiento de capa de transporte.

Direccionamiento TCP / UDP: Puertos y Sockets

Los puertos conocidos son los comprendidos del 0 al 1023.

Los puertos registrados son aquellos del 1024 al 49151

Los puertos dinámicos y / o privados son los de 49152 a 65535

Sockets: Process Identification

<IP Address>:<Port Number>

41.199.222.3:80

41.199.222.3:8080

41.199.222.3:8800

41.199.222.3:9898

USER DATAGRAM PROTOCOL (UDP)

RFC 768, User Datagram Protocol , en el año 1980

Qué hace UDP?

La única tarea real para la transmisión usando UDP son:

1. Transferencia de datos de la capa superior: una aplicación envía datos al protocolo UDP.

2. Encapsulamiento del mensaje UDP: El mensaje de capa superior se encapsula en el campo de datos

de un mensaje UDP. Las cabeceras del mensaje UDP se rellenan, incluyendo el puerto de origen de la

aplicación que envía los datos y el puerto de destino del destinatario.

3. Transferir Mensaje a IP: Se pasa el mensaje UDP a la capa 3 para la transmisión.

Qué no hace UDP?

.

☯ UDP no establece conexiones antes de enviar datos. Simplemente empaqueta y envía.

☯ UDP no proporciona ninguna garantía de que sus mensajes llegarán.

☯ UDP no proporciona los reconocimientos que demuestran que se reciben los datos.

☯ UDP no detecta la pérdida de mensajes ni los retransmite.

☯ UDP no asegura que los datos se reciban en el mismo orden en que fueron enviados.

☯ UDP no proporciona ningún mecanismo para gestionar el flujo de datos entre los dispositivos, o

manejar la congestión.

Por qué algunas aplicaciones usan UDP?

El rendimiento es más importante que la fiabilidad

Intercambios de datos que son "cortos y relevantes"

Tráfico multicast

Aplicaciones que utilizan UDP y TCP

UDP Message Format

El encabezado UDP solo tiene 8 bytes de longitud;Field Name Size (bits) Description

Source Port 16 Número de puerto del proceso que originó el mensaje UDP en el

dispositivo de origen. Esto normalmente será un (cliente) Número de

puerto dinámico para una solicitud enviada por un cliente a un servidor, o

un número de puerto bien conocido / registrado (servidor) para una

respuesta enviada por un servidor a un cliente.

Destination Port 16 Número de puerto del proceso que es destinatario del mensaje en el

dispositivo de destino.

Esto suele ser un número de puerto bien conocido / registrado (servidor)

para una petición de un cliente, o un número de puerto dinámico

(cliente) para una respuesta del servidor.

Length 16 La longitud de todo el datagrama UDP, incluyendo tanto la cabecera y el

campo de datos.

Checksum 16 Suma de comprobación de 16 bits opcional calculado a lo largo de todo el

datagrama UDP. Si no se utiliza, se establece en un valor de todos unos.

Data Variable El mensaje de capa superior que se enviará.

TRANSMISSION CONTROL PROTOCOL (TCP)

Definido en el standard RFC 793 en septiembre de 1981. Actualizado en 1122, 3168, 6093, 6528

RFC Name Description

813 Window and Acknowledgment

Strategy in TCP

Discute el sistema de ventanas deslizantes de confirmación TCP, y describe

algunos problemas que pueden ocurrir con ella y métodos para corregirlas

879 The TCP Maximum Segment Size and

Related Topics

Discute el Tamaño máximo de segmento (MSS) que controla el tamaño de los

mensajes TCP, y relaciona este parámetro con el tamaño del datagrama IP

896 Congestion Control in IP/TCP

Internetworks

Habla sobre los problemas de congestión y cómo TCP se puede utilizar para

manejarlos.

1122 Requirements for Internet Hosts

Communication Layers

Describe detalles importantes de cómo se debe implementar TCP en hosts

1146 TCP Alternate Checksum Options Especifica un mecanismo alternativo de generación de suma de comprobación.

1323 TCP Extensions for High Performance Define extensiones TCP para enlaces de alta velocidad, y nuevas opciones de TCP

2018 TCP Selective Acknowledgment

Options

Una mejora de la funcionalidad básica de TCP que permite a los dispositivos TCP

especificar determinados segmentos específicos para la retransmisión.

5681 TCP Congestion Control Describe cuatro algoritmos utilizados para el control de la congestión en las redes

TCP

6298 Computing TCP's Retransmission Timer Trata los problemas relacionados con el ajuste de los timers de retransmisión de

TCP, que controla el tiempo que un dispositivo espera la confirmación de los

datos enviados antes de retransmitirlos

Características de TCP

☯ Con conexión.

☯ Bidireccional

☯Múltiple Conexión y dispositivo-identificado.

☯ Fiable

☯ Confirmación.

☯ Gestión del flujo de datos.

TCP Message Format

Field Name Size (bits) Description

Source Port 16 Número de puerto del proceso que originó el mensaje TCP

Destination Port 16 Número de puerto del proceso destinatario del mensaje

Sequence number 32 tiene una doble función:

Si el flag SYN es (1), entonces este es el número de secuencia inicial. El

número de secuencia del primer byte de datos real será entonces este

número de secuencia más 1.

Si el flag SYN es (0), entonces este es el número de secuencia acumulado

del primer byte de datos de este segmento de la sesión actual.

Acknowledgment

number

32 Si el flag ACK se establece entonces el valor de este campo es el siguiente

número de secuencia que el receptor está esperando. Esto confirma la

recepción de todos los bytes anteriores (si los hay). La primera ACK

enviado por cada extremo reconoce el número inicial de secuencia del

otro, pero no hay datos.

El encabezado TCP tiene una parte fija de 20 bytes de longitud y otra opcional que puede tener hasta 40 bytes.

Field Name Size (bits) Description

Data offset 4 Especifica el tamaño de la cabecera TCP en palabras de 32 bits. El

encabezado de tamaño mínimo es de 5 palabras y el máximo es de 15

palabras dando así el tamaño mínimo de 20 bytes y un máximo de 60

bytes. Este campo toma su nombre del hecho de que también es el

desplazamiento desde el inicio del segmento TCP a los datos reales.

Reserved 6 Para uso futuro. Se ajustan a 0.

Flags 6 URG: Campo Urgent Pointer, indica que ciertos datos son prioritarios.

ACK: acuse de recibo, campo ack es significativo

PSH: Función de PUSH, para enviar el buffer de recepción hacia la

aplicación

RST: aborta la conexión en respuesta a un error

SYN: iniciar conexión, sincronizar números de secuencia

FIN: No hay más datos de remitente

Window size 16 Es el tamaño de la ventana de recepción, que especifica el número de

bytes que el remitente de este segmento está dispuesto para recibir

Checksum 16 Control de errores del header y datos

Urgent pointer 16 Si el flag URG está establecido, este puntero indica la cantidad de los

datos en el segmento, contando desde el primer byte, es urgente.

Options 0 -320 En bloques de 32 bits. Ver RFC-793

TCP Establecimiento de conexión de proceso: El "Three-Way Handshake"

Control de Flujo

El mecanismo de acuse de recibo empleado está orientado al flujo de Bytes.

TCP utiliza una variación en el método de ventanas deslizantes. En lugar de usar un número de secuencia para dar acuse de recepción, se utiliza la cantidad de bytes transmitidos en el segmento.

Es acumulativo, de tal forma que el acuse de recibo de un número de secuencia X indica que todos

los octetos hasta, pero no incluyendo X, han sido recibidos.

Permite la detección fácil y directa de duplicados generados por retransmisiones. La numeración

de octetos dentro de un segmento es de la siguiente forma: el primer octeto de datos

inmediatamente tras la cabecera es el de menor número y los octetos siguientes son numerados

consecutivamente.

El espacio real de números de secuencia es finito y abarca desde el 0 hasta 232-1.

Números de secuencia inicial

Este protocolo no pone ninguna restricción sobre el hecho de reutilizar una y otra vez la mismaconexión.

Una conexión se define por el par de conectores. Cualquier nueva instancia de una conexión será referida como una “reencarnación” de la conexión.

"¿cómo identifica TCP los segmentos duplicados de encarnaciones previas de la conexión?"

Para evitar una confusión, se debe evitar que los segmentos de una encarnación de una conexión utilicen los números de secuencia que todavía posiblemente estén siendo utilizados en la red por otra conexión anterior.

Se utiliza un generador de números iniciales de secuencia (ISN, 'initial sequence number') que selecciona un nuevo ISN de 32 bits. El generador estará asociado a un reloj de 32 bits, cuyo bit menos significativo se incrementa aproximadamente cada 4 microsegundos.

Temporizador de retransmisión

RTO, Retransmittion Time Out (tiempo de espera de retransmisión)

La RFC 6298 determina la fórmula del cálculo del RTO.

Dos variables de estado, SRTT (smoothed round-trip time) y RTTVAR (round-trip time variation), y la granularidad

del reloj en G segundos.

Hasta se haya realizado una medición de tiempo RTT, el emisor debe establecer el RTO en 1 segundo. En la

versión anterior de esta RFC (2988) utiliza un RTO inicial de 3 segundos. Cuando se realiza la primera medición R

de RTT, se realizan los siguientes cómputos.

SRTT = R

RTTvar = R/2

RTO = SRTT + max ( G , K . RTTvar )

Cuando se realice una subsecuente medición R’de RTT:

SRTT’ = ( 1 – α ) SRTT + α R’

RTTvar’ = ( 1 – β ) RTTvar + β | SRTT – R’ |

Los valores sugeridos por la RFC son K = 4, α = 1/8 y β = 1/4.

Luego de actualizar los valores de SRTT y RTTvar, se recalcula el nuevo valor de RTO.

RTO = SRTT + max ( G , K . RTTvar )

Si RTO es menor de 1 segundo, entonces el valor debe redondearse a 1 segundo.

Algoritmo de Karn

Las mediciones de RTT no deben llevarse a cabo utilizando segmentos que fueron retransmitidos.

Pérdida de múltiples segmentos

Para habilitar SACK, debe ser negociado en el inicio de la conexión. Dentro del segmento SYN debe enviarse la

opción tipo-4 SACK Permitted.

Durante la conexión se enviará en los ACK la opción 5.

+--------+--------+

| Kind=5 | Length |

+--------+--------+--------+--------+

| Left Edge of 1st Block |

+--------+--------+--------+--------+

| Right Edge of 1st Block |

+--------+--------+--------+--------+

| |

/ . . . /

| |

+--------+--------+--------+--------+

| Left Edge of nth Block |

+--------+--------+--------+--------+

| Right Edge of nth Block |

+--------+--------+--------+--------+

2000 5000 6000 7000 80001000 3000 4000

Una opción SACK que especifica n bloques tendrá una longitud de 8 * n + 2 bytes, por lo que los 40 bytes disponibles para las opciones de TCP puede especificar un máximo de 4 bloques.

Terminación Normal de la Conexión

Control de Congestión

TCP utiliza una serie de mecanismos para lograr un alto rendimiento y evitar el colapso de la red por congestión.

1984, primera congestión

1994, Van Jacobson -> TAHOE

El sistema busca llegar a un estado de equilibrio basado en el principio de“conservación de los paquetes” en los enlaces, donde se establece que se envíaun paquete a la red cada vez que verifica que un paquete ha abandonado la red.

Se llega al estado de equilibrio por medio de pruebas que permiten inferir elancho de banda disponible.

Concepto

Variables del Control de Congestión

cwnd (congestion window), que controla del lado de la fuente la cantidad de

datos que se puede enviar sin haber recibido un ACK,

ssthresh (slow start threshold) que indica en qué fase de control de congestión

se encuentra el transmisor (slow start si es mayor que cwnd o congestion

avoidance si es menor; de ser iguales, se puede utilizar cualquiera de los dos

algoritmos). El valor inicial es 65536 bytes

smss (sender máximum segment size) es el tamaño máximo de segmento de la

conexión ó en caso de no anunciarse se toma el default de 536 bytes (RFC 879 )

sender Window = MIN (rwnd, cwnd)

Slow Start – Congestion Avoidance

El algoritmo comienza en la fase de crecimiento exponencial inicialmente con

un tamaño de ventana de congestión (CWND) de un MSS y lo aumenta en un

tamaño de segmento (MSS) para cada nuevo ACK recibido.

cwnd = cwnd + mss

Este comportamiento continúa hasta que el tamaño de la ventana decongestión (CWND) alcanza el tamaño de ssthresh o hasta que se produce unapérdida.

Cuando se produce una pérdida (timeout de un segmento enviado), se guardala mitad del valor de la CWND actual como nuevo umbral de inicio lento(ssthresh) y Slow Start comienza de nuevo desde su CWND inicial (1 MSS).

Una vez que el CWND alcanza el ssthresh, TCP finaliza el entra en modo CA, de

prevención de congestión, en cada nuevo ACK aumenta la CWND

cwnd = cwnd + mss * mss / cwnd

Esta fase continúa hasta que se alcanza la congestión nuevamente. Esto resulta

en un aumento lineal de la CWND.

Fast Retransmit

El algoritmo fast retransmit es utilizado para detectar y reparar pérdidas

basado en la recepción de ACK duplicados.

El algoritmo emplea la recepción de 3 ACK duplicados (4 ACKs idénticos)

para concluir que un segmento se ha perdido.

El transmisor envía el segmento que deduce se ha perdido sin esperar

que expire el timer de retransmisión.

El umbral ssthresh se fija a la mitad del valor de cwnd antes

de la pérdida y se arranca slow start con cwnd = 1 x MSS

Método Reno

Fast Recovery

Congestión severa: detectada por timeout de retransmisión.

o ssthresh a la mitad del valor de cwnd

o cwnd = 1 MSS

o Se aplica slow start

Congestión leve: detectada por fast retransmit (3 ack duplicados)

o ssthresh a la mitad del valor de cwnd

o cwnd = ssthresh

o Se aplica congestion avoidance

TCP Vegas

TCP Vegas controla su tamaño de ventana observando el RTT de los paquetes que ha enviado previamente.

Si el RTT observado se incrementa, TCP Vegas reconoce que la red comienza a congestionarse, y reduce el tamaño de la ventana.

Si el RTT disminuye, el host emisor determina que la red se alivia de la congestión, y aumenta el tamaño de la ventana de nuevo.

En fase de congestion avoidance, el tamaño de la ventana se actualiza como

Por default α=1 y β=3, debiendo ser siempre α ≤ β.