TRANSPORTE SIN CONECCIÓN: UDP

En esta sección, echaremos un vistazo a UDP, cómo funciona y qué hace.

Le recomendamos que consulte la Sección 2.1, que incluye una visión general del modelo de
servicio UDP, y la Sección 2.7.1, que trata sobre la programación de sockets con UDP. el
modelo de servicio UDP, y a la Sección 2.7.1, que discute la programación de sockets usando
UDP.

Para motivar nuestra discusión sobre UDP, supongamos que estás interesado en diseñar un
protocolo de transporte sencillo y sin complicaciones. ¿Cómo podría hacerlo?

En primer lugar, podría considerar el uso de un protocolo de transporte vacío. En particular, en

el lado

En particular, en el lado de envío, podría considerar tomar los mensajes del proceso de
aplicación y pasarlos directamente a la capa de red.

y pasarlos directamente a la capa de red; y en el lado receptor, podría

considerar tomar los mensajes que llegan de la capa de red y pasarlos

directamente al proceso de aplicación. Pero como hemos aprendido en la sección anterior,

tenemos que

¡tenemos que hacer algo más que nada! Como mínimo, la capa de transporte tiene que
proporcionar un servicio de multiplexación/desmultiplexación para pasar los datos entre la
capa de red y el proceso correcto de la aplicación.

capa de red y el proceso correcto a nivel de aplicación.

UDP, definido en [RFC 768], hace casi todo lo que puede hacer un protocolo de transporte

hacer. Aparte de la función de multiplexación/desmultiplexación y una ligera comprobación de

errores, no añade nada a IP.

de errores, no añade nada a IP. De hecho, si el desarrollador de la aplicación elige UDP

en lugar de TCP, entonces la aplicación está hablando casi directamente con IP. UDP toma

mensajes del proceso de la aplicación, adjunta los campos de número de puerto de origen y
destino

para el servicio de multiplexación/desmultiplexación, añade otros dos pequeños campos y

pasa el segmento resultante a la capa de red. La capa de red encapsula

el segmento de la capa de transporte en un datagrama IP y luego hace un intento de mejor

esfuerzo

para entregar el segmento al host receptor. Si el segmento llega al host receptor

Si el segmento llega al host receptor, UDP utiliza el número de puerto de destino para entregar
los datos del segmento al proceso de aplicación correcto. Ten en cuenta que con UDP no hay
un intercambio de información entre las entidades de la capa de transporte emisora y
receptora antes de enviar un segmento. Por esta razón,

se dice que UDP es sin conexión.

 Un control más fino a nivel de aplicación sobre qué datos se envían y cuándo. Bajo
UDP, tan pronto como un proceso de aplicación UDP, tan pronto como un proceso de
aplicación pasa datos a UDP, UDP empaquetará los datos dentro de un segmento UDP
e inmediatamente pasa el segmento a la capa de red. TCP, por otro lado, tiene un
mecanismo de control de la congestión que regula el TCP tiene un mecanismo de
control de la congestión que regula el remitente de la capa de transporte TCP cuando
uno o más enlaces entre los hosts de origen y destino se congestionan excesivamente.
TCP también continuará reenviando un segmento hasta que el destino acuse recibo del
segmento, independientemente del tiempo que tarde la entrega fiable. Dado que las
aplicaciones en tiempo real tiempo real suelen requerir una tasa de envío mínima, no
quieren retrasar demasiado la y pueden tolerar alguna pérdida de datos, el modelo de
servicio de TCP no se ajusta especialmente bien a las necesidades de estas
aplicaciones. Como se discute más adelante, estas aplicaciones pueden utilizar UDP e
implementar, como parte de la aplicación, cualquier funcionalidad adicional que se
necesite más allá de las características de UDP. funcionalidad adicional que se necesite
más allá del servicio de entrega de segmentos sin complicaciones de UDP.
 No se establece la conexión. Como veremos más adelante, TCP utiliza un apretón de
manos de tres vías antes de empezar a transferir datos. UDP se limita a transmitir sin
ningún tipo de preliminares formales. Así, UDP no introduce ningún retraso para
establecer una conexión. Esta es probablemente la razón principal por la que el DNS se
ejecuta a través de UDP en lugar de TCP: el DNS sería mucho más lento si se ejecutara
sobre TCP. HTTP utiliza TCP en lugar de UDP, ya que la fiabilidad es crítica para las
páginas web con texto. Sin embargo, como hemos comentado brevemente en el
apartado 2.2, el retraso en el establecimiento de la conexión TCP en HTTP contribuye
de forma importante a los retrasos asociados a la descarga de documentos web.
 No hay estado de conexión. TCP mantiene el estado de la conexión en los sistemas
finales. Este estado de la conexión incluye las memorias intermedias de recepción y
envío, los parámetros de control de congestión y los parámetros de números de
secuencia y acuse de recibo. Veremos en la sección 3.5 que esta información de estado
es necesaria para implementar el servicio de transferencia de datos fiable de TCP y
para proporcionar el control de la congestión. de datos de TCP y para proporcionar el
control de la congestión. UDP, por otro lado, no mantiene el estado de la conexión y
no hace un seguimiento de la misma. no mantiene el estado de la conexión y no
rastrea ninguno de estos parámetros. Por esta razón, un servidor dedicado a una
aplicación particular puede soportar normalmente muchos más clientes activos
cuando la aplicación se ejecuta sobre UDP en lugar de TCP.
 Pequeña sobrecarga de la cabecera del paquete. El segmento TCP tiene 20 bytes de
sobrecarga de cabecera en cada segmento, mientras que UDP sólo tiene 8 bytes de
sobrecarga.

En la figura 3.6 se enumeran las aplicaciones populares de Internet y los protocolos de

transporte que utilizan. utilizan. Como es de esperar, el correo electrónico, el acceso
remoto a terminales, la Web y la transferencia de archivos se ejecutan sobre TCP: todas
estas aplicaciones necesitan el servicio de transferencia de datos fiable de TCP. Sin
embargo, muchas aplicaciones importantes se ejecutan sobre UDP en lugar de TCP. UDP se
utiliza para RIP (ver Sección 4.6.1). Dado que las actualizaciones RIP se envían
periódicamente (normalmente cada cinco minutos), las actualizaciones perdidas serán
reemplazadas por otras más recientes, haciendo así más recientes, haciendo inútil la
actualización perdida y desfasada. UDP también se utiliza para transportar datos de
gestión de red (SNMP; ver Capítulo 9). En este caso se prefiere UDP a TCP, ya que las
aplicaciones de gestión de red Las aplicaciones de gestión de red deben ejecutarse a
menudo cuando la red está en un estado de tensión, precisamente cuando es difícil lograr
una transferencia de datos fiable y controlada por la congestión. Además, como hemos
mencionado antes, el DNS se ejecuta sobre UDP, evitando así los retrasos en el
establecimiento de la conexión de TCP.

Como se muestra en la figura 3.6, tanto UDP como TCP se utilizan hoy en día con
aplicaciones multimedia, como el teléfono por Internet, las videoconferencias en tiempo
real y el streaming de audio y vídeo almacenado. En el capítulo 7 analizaremos estas
aplicaciones con detenimiento. Sólo mencionaremos ahora que todas estas aplicaciones
pueden tolerar una pequeña cantidad de pérdida de paquetes, por lo que una
transferencia de datos fiable no es absolutamente crítica para el éxito de la aplicación.

Como se muestra en la figura 3.6, tanto UDP como TCP se utilizan hoy en día con
aplicaciones multimedia, como el teléfono por Internet, las videoconferencias en tiempo
real y el streaming de audio y vídeo almacenado. En el capítulo 7 analizaremos estas
aplicaciones con detenimiento. Sólo mencionaremos ahora que todas estas aplicaciones
pueden tolerar una pequeña cantidad de pérdida de paquetes, por lo que una
transferencia de datos fiable no es absolutamente crítica para el éxito de la aplicación.
Además, las aplicaciones en tiempo real, como el teléfono por Internet y las
videoconferencias, reaccionan muy mal al control de congestión de TCP. Por estas razones,
los desarrolladores de aplicaciones multimedia pueden optar por ejecutar sus aplicaciones
sobre UDP en lugar de TCP. Sin embargo, TCP se está utilizando cada vez más para el
transporte de streaming multimedia. Por ejemplo, [Sripanidkulchai 2004] descubrió que
casi el 75% de las transmisiones en directo y bajo demanda utilizaban TCP. Cuando las
tasas de pérdida de paquetes son bajas, y con algunas organizaciones que bloquean el
tráfico UDP por razones de seguridad (véase el capítulo 8), TCP se convierte en un
protocolo cada vez más atractivo para el transporte de medios de streaming.
Aunque hoy en día es habitual, la ejecución de aplicaciones multimedia sobre UDP es
controvertido. Como hemos mencionado anteriormente, UDP no tiene control de
congestión. Pero el control de la congestión es necesario para evitar que la red entre en un
estado de congestión en en el que se realiza muy poco trabajo útil. Si todo el mundo
empezara a transmitir vídeo de alta tasa de bits sin usar ningún control de congestión,
habría tanto desbordamiento de paquetes en los routers que muy pocos desbordamiento
de paquetes en los routers que muy pocos paquetes UDP atravesarían con éxito la ruta
ruta origen-destino. Además, las altas tasas de pérdida inducidas por los remitentes UDP
no controlados harían que los remitentes TCP (que, como veremos, sí disminuyen sus tasas
de envío ante la congestión) disminuyan drásticamente sus tasas.

Así, la falta de control de la congestión en UDP puede dar lugar a altas tasas de pérdida
entre un UDP y el receptor, y la saturación de las sesiones TCP, un problema
potencialmente grave [Floyd 1999]. Muchos investigadores han propuesto nuevos
mecanismos para obligar a todas las fuentes, incluidas las UDP, a realizar un control de
congestión adaptativo [Mahdavi 1997; Floyd 2000; Kohler 2006: RFC 4340].

Antes de hablar de la estructura de segmentos UDP, mencionamos que es posible que una
aplicación tenga una transferencia de datos fiable cuando utiliza UDP. Esto puede hacerse
si la fiabilidad se incorpora a la propia aplicación (por ejemplo, añadiendo mecanismos de
reconocimiento y retransmisión, como los que estudiaremos en la siguiente sección). Pero
esta es una tarea no trivial que mantendría al desarrollador de la aplicación ocupado
depurando durante mucho tiempo. Sin embargo, la construcción de la fiabilidad
directamente en la aplicación permite a la aplicación "tener su pastel y comerlo también".
Es decir, los procesos de la aplicación pueden comunicarse de forma fiable sin estar sujetos
a las restricciones de la tasa de transmisión impuestas por el mecanismo de control de
congestión de TCP.

3.3.1 ESTRUCTURA DEL SEGMENTO UDP

La estructura del segmento UDP, mostrada en la Figura 3.7, está definida en el 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. Para
una aplicación de streaming de audio, las muestras de audio llenan el campo de datos. La
cabecera UDP sólo tiene cuatro campos, cada uno de los cuales consta de dos bytes. Como
se ha comentado en la sección anterior, los números de puerto permiten al host de
destino pasar los datos de la aplicación al proceso correcto que se ejecuta en el sistema
final de destino (es decir, para realizar la función de demultiplexación). El campo especifica
el número de bytes del segmento UDP (cabecera más datos). Se necesita un valor de
longitud explícito en valor de longitud explícito es necesario ya que el tamaño del campo
de datos puede diferir de un segmento UDP a otro. La suma de comprobación es utilizada
por el host receptor para comprobar si errores se han introducido en el segmento. En
realidad, la suma de comprobación también se calcula sobre algunos de los campos de la
cabecera IP además del segmento UDP. Pero ignoramos este detalle para ver el bosque a
través de los árboles. Discutiremos el cálculo de la suma de comprobación más adelante.
Los principios básicos de la detección de errores se describen en la Sección 5.2. El campo
especifica la longitud del segmento UDP, incluyendo la cabecera, en bytes.

3.3.2 CHECKSUM
La suma de comprobación UDP sirve para detectar errores. Es decir, la suma de
comprobación se utiliza para determinar si los bits dentro del segmento UDP han sido
alterados (por ejemplo, por el ruido en los enlaces o mientras se almacena en un router)
mientras se mueve desde el origen hasta el destino. El UDP en el lado del remitente realiza
el complemento a 1s de la suma de todas las palabras de 16 bits en el segmento, con
cualquier desbordamiento encontrado durante la suma siendo envuelto. Este resultado se
pone en el campo de suma de comprobación del segmento UDP. En damos un ejemplo
sencillo del cálculo de la suma de comprobación. Puede encontrar detalles sobre detalles
sobre la implementación eficiente del cálculo en el RFC 1071 y el rendimiento sobre datos
reales en [Stone 1998; Stone 2000]. en [Stone 1998; Stone 2000]. Como ejemplo,
supongamos que tenemos las siguientes tres palabras de 16 bits: