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

Transcripción

1 CAPA DE TRANSPORTE

2 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.

3 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.

4 Direccionamiento TCP / UDP: Puertos y Sockets

5 Los puertos conocidos son los comprendidos del 0 al Los puertos registrados son aquellos del 1024 al Los puertos dinámicos y / o privados son los de a 65535

6 Sockets: Process Identification <IP Address>:<Port Number> : : : :9898

7 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.

8 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.

9 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

10 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á.

11 TRANSMISSION CONTROL PROTOCOL (TCP) Definido en el standard RFC 793 en septiembre de Actualizado en 1122, 3168, 6093, 6528 RFC Name Description 813 Window and Acknowledgment Discute el sistema de ventanas deslizantes de confirmación TCP, y describe Strategy in TCP algunos problemas que pueden ocurrir con ella y métodos para corregirlas 879 The TCP Maximum Segment Size and Related Topics 896 Congestion Control in IP/TCP Internetworks 1122 Requirements for Internet Hosts Communication Layers 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 Habla sobre los problemas de congestión y cómo TCP se puede utilizar para manejarlos. 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 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 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

12 Características de TCP Con conexión. Bidireccional Múltiple Conexión y dispositivo-identificado. Fiable Confirmación. Gestión del flujo de datos.

13 TCP Message Format 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 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.

14 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 En bloques de 32 bits. Ver RFC-793

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

16 Control de Flujo 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. El mecanismo de acuse de recibo empleado está orientado al flujo de Bytes.

17 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

18 Números de secuencia inicial Este protocolo no pone ninguna restricción sobre el hecho de reutilizar una y otra vez la misma conexió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.

19 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.

20 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.

21 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.

22 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 Kind=5 Length Left Edge of 1st Block Right Edge of 1st Block /... / Left Edge of nth Block Right Edge of nth Block 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.

23 Terminación Normal de la Conexión

24 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

25 Concepto 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ía un 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 el ancho de banda disponible.

26 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 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 )

27 sender Window = MIN (rwnd, cwnd)

28 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

29

30 Este comportamiento continúa hasta que el tamaño de la ventana de congestión (CWND) alcanza el tamaño de ssthresh o hasta que se produce una pérdida. Cuando se produce una pérdida (timeout de un segmento enviado), se guarda la 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).

31 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.

32 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.

33 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

34 Método Reno

35 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

36

37 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.

38 En fase de congestion avoidance, el tamaño de la ventana se actualiza como Por default α=1 y β=3, debiendo ser siempre α β.

39

40