Formato de una trama TCP y UDP

Formato de una trama TCP y UDP

Ervin Wilfredo Meza Mairena

Jueves 14 de mayo del 2015

1 Formato de trama para protocolo UDP.

La estructura de los segmentos UDP, está definida en el documento RFC 768. Los datos de la aplicación ocupan el campo de datos del segmento UDP. Por ejemplo, para DNS el campo de datos contiene un mensaje de consulta o un mensaje de respuesta. En el caso de una aplicación de flujo de audio, las muestras del audio llenaran el campo de datos. La cabecera UDP solo tiene cuatro campos, y cada uno de ellos tiene una longitud de dos bytes. Los números de puerto permiten al host de destino pasar los datos de la aplicación al proceso apropiado que está ejecutándose en el sistema terminal de destino. El host receptor utiliza la suma de comprobación para detectar si se han introducido errores en el segmento. En realidad, la suma de comprobación también se calcula para unos pocos campos de la cabecera IP, además de para el segmento UDP. El campo longitud específica la longitud del segmento UDP en bytes, incluyendo las cabeceras.

N° de puerto de origen	N° de puerto de origen
Longitud	Suma de comprobación
Datos de la aplicación (mensaje).

32 bits.

2¿Este formato de trama contiene algún numero de secuencia?

UDP no mantiene información del estado de la conexión y no controla parámetros relativos al número de secuencia o de reconocimiento. Pero en recompensa de esto un servidor dedicado a una aplicación concreta suele poder soportar más clientes activos cuando la aplicación se ejecuta sobre UDP.

3 Formato de trama para protocolo TCP.

El segmento TCP consta de campos de cabecera y un campo de datos. El campo de datos contiene un fragmento de los datos de aplicación, el MSS limita el tamaño máximo del campo de datos de un segmento. Sin embargo, las aplicaciones interactivas suelen transmitir fragmentos de datos que son más pequeños que el MSS; por ejemplo, en las aplicaciones de inicio de sesión remoto como Telnet, el campo de datos del segmento TCP solo tiene un byte. Puesto que habitualmente la cabecera de TCP tiene 20 bytes, los segmentos enviados mediante Telnet solo pueden tener una longitud de 21 bytes. La cabecera incluye los números de puerto de origen y de destino. La cabecera también incluye un campo de suma de comprobación. La cabecera de un segmento TCP contiene los siguientes campos:

El campo número de secuencia de 32 bits y el campo número de reconocimiento también de 32 bits son utilizados por el emisor y el receptor de TCP para implementar un servicio de transferencia de datos fiable.

El campo ventana de recepción de 16 bits se utiliza para el control de flujo.

El campo de longitud de cabecera de 4 bits especifica la longitud de la cabecera TCP en palabras de 32 bits. La cabecera TCP puede tener una longitud variable a causa del campo opciones de TCP.

El campo opciones es opcional y de longitud variable. Se utiliza cuando un emisor y un receptor negocian el tamaño máximo de segmento (MSS) o como un factor de escala de la ventana en redes de alta velocidad.

El campo indicador tiene 6 bits. El bit ACK se utiliza para indicar que el valor transportado en el campo de reconocimiento es válido; es decir, el segmento contiene un reconocimiento para un segmento que ha sido recibido correctamente. Los bits RST, SYN y FIN se utilizan para el establecimiento y cierre de conexiones, la activación del bit PSH indica que el receptor deberá pasar los datos a la capa superior de forma inmediata. Por último, el bit URG se utiliza para indicar que hay datos en este segmento que la entidad de la capa superior del lado emisor ha marcado como “urgentes”. La posición de este último byte de estos datos urgentes se indica mediante el campo puntero de datos urgentes de 16 bits. TCP tiene que informar a la entidad de la capa superior del lado receptor si existen datos urgentes y pasarle un puntero a la posición donde finalizan los datos urgentes.

32 bits.

Numero de puerto de origen					Numero de puerto de destino
Numero de secuencia
Numero de reconocimiento
Long Cabec.	No usado	URG	ACK	PSH	RST	SYN	FIN	Ventana de recepción
Suma de comprobación internet					Puntero de datos Urgente
Opciones
Datos

4¿Qué nombre reciben las estrategias que utiliza TCP para el control de flujo?

TCP es un protocolo de ventana deslizante. Este mecanismo surge como mejora del usado por protocolos con reconocimientos positivos de tipo Stop&Wait. Estos protocolos obligan al emisor a retrasar la emisión de cada nuevo paquete hasta que se recibe el ACK del anterior, desaprovechando así, la posible capacidad de comunicación bidireccional de la red. Los protocolos de ventana deslizante aprovechan mejor el ancho de banda al permitir transmitir un número determinado de paquetes antes de que llegue el ACK correspondiente. La ventana se coloca sobre la secuencia de octetos que configuran el flujo de datos proveniente de la aplicación e indica qué paquetes pueden ser transmitidos.

Secuencia de segmentos ventana

SEG N-3 SEG N-2 SEG N-1 SEG N SEG N+1 SEG N+2 SEG N+3 SEG N+4

El número de paquetes no reconocidos es como máximo, en cada momento, igual al tamaño de la ventana. Si el protocolo está bien “sintonizado”, mantendrá el enlace completamente saturado.

El valor óptimo para optimizar el ancho de banda disponible (BW) es:

Ventana = RTT * BW

TCP utiliza un mecanismo de ventana deslizante especial que le sirve tanto para conseguir una transmisión eficiente (el emisor puede enviar múltiples segmentos sin esperar su reconocimiento) como para proporcionar control de flujo permitiendo al receptor restringir el número de octetos que puede recibir en cada momento. El receptor envía, junto con cada reconocimiento, el tamaño de ventana que puede aceptar en ese momento, es decir, el rango de números de secuencia aceptables a partir del último segmento recibido correctamente. Este tamaño puede variar a lo largo de la conexión (incluso llegando a valer 0). El emisor aplica continuamente la ventana recibida para determinar qué paquetes puede enviar.

5¿Cómo determina TCP cuál es el valor del temporizador asociado a la recepción de cada mensaje?

El tratamiento de la temporización y la retransmisión es fundamental en TCP, tanto en entornos como el móvil en los que las pérdidas son frecuentes, como en redes fijas en las cuales la congestión puede dar lugar a pérdidas de paquetes o retardos importantes.

Para llevar a cabo este tratamiento se han establecido las siguientes estrategias:

1. Algoritmo de retransmisión adaptativo [Ste94, Jac88]

El ajuste del temporizador de retransmisión, RTO (Retransmission Time Out), es especialmente crítico en TCP, al actuar tanto en redes locales, en enlaces punto a punto o en una red tan cambiante como Internet. Debe asegurarse un mecanismo que funcione correctamente en entornos tan diferentes como en los que opera TCP. RTO debe ser suficientemente pequeño como para responder rápidamente a las pérdidas, pero no tanto como para forzar la retransmisión de datos que han sufrido un pico de retardo en la red sin haber llegado a perderse, como sería el caso de congestión.

Para adaptarse a los retardos variables característicos de un entorno como Internet, TCP usa un algoritmo de retransmisión adaptativo que monitoriza el retardo en cada conexión y ajusta el valor de RTO de acuerdo con ese valor. La especificación del protocolo sugiere tomar muestras del tiempo de ida y vuelta, RTT (Round Trip Time), calculado como la diferencia de tiempo entre la emisión de un segmento y la recepción de su reconocimiento. Con esta información, TCP puede ajustar dinámicamente una variable que identifique el tiempo medio de ida y vuelta, de la siguiente forma:

RTT= α ∗ RTTanterior + (1-α) ∗ RTTnuevo

2-4

Finalmente el tiempo de retransmisión, se ajusta a:

RTO= β ∗ RTT

Los valores recomendados de α y β son 0.9 y 2 respectivamente, para el caso de redes fijas.

Dado que estos valores han sido hallados experimentalmente, no se asegura el buen funcionamiento del algoritmo en circunstancias muy particulares.

Esta estrategia, no obstante, no se adapta a fluctuaciones importantes en RTT provocando retransmisiones innecesarias. Se hace necesario introducir una estimación, también, de la varianza del tiempo de ida y vuelta, por lo tanto:

RTO= a + 4 ∗ d

a: RTT medio

d: estimador de la desviación media de RTT

Cada vez que se obtiene una nueva muestra del tiempo de ida y vuelta, m, los estimadores se actualizan así:

Err=m - a

a= a + g ∗ Err

d=d + h ∗ (Err - d)

Los valores recomendados para g y h son 0.125 y 0.25 respectivamente, también obtenidos experimentalmente.

b) Algoritmo de Karn [KaP87]

Cuando se recibe un reconocimiento de un segmento que ha sido objeto de retransmisión, es imposible determinar si éste corresponde al primer segmento transmitido o a su posterior retransmisión. El algoritmo de Karn evita esta ambigüedad.

Este algoritmo establece que el cálculo del RTT estimado para determinar RTO debe hacerse ignorando las muestras correspondientes a segmentos retransmitidos.

c) Marca Temporal o Timestamp

Existe una solución alternativa para la medida exacta de RTT que hace desaparecer la ambigüedad, de forma que hace innecesaria la aplicación del algoritmo de Karn. Esta solución se basa en aprovechar el ancho de banda para mandar la información de tiempo en cada segmento. De esta forma puede realizarse una medida por cada segmento enviado independientemente de si se trata de un segmento retransmitido o no, obteniendo así más medidas. Esta solución, si bien es adecuada para redes de alta velocidad en las que el ancho de banda no es un recurso escaso, no lo es para transmisiones sobre el canal móvil en las que el ancho de banda es un recurso que debe gestionarse y utilizarse de forma eficiente.