0
Protocolo UDP
UDP (user datagram protocol o protocolo de datagrama de usuario) trabaja en la capa
de transporte. Esta capa define una comunicación entre procesos de dos
computadoras, denominadas cliente y servidor. Mientras que la capa de enlace
permite la comunicación entre dos dispositivos físicos interconectados y la capa de
red hace lo propio entre dos dispositivos distantes (entre redes), esta capa permite
que dos aplicaciones interactúen como si estuvieran formando parte del mismo
dispositivo físico, cuando en realidad están distantes.
Un switch se encarga de procesar y reenviar tramas Ethernet en una red LAN. Un
router enruta paquetes para que viajen entre redes. Finalmente, los clientes y
servidores crean una conexión lógica en la capa de transporte.
Otros protocolos de esta capa serán abordados en otras lecturas.
Paradigma cliente-servidor
En el modelo cliente-servidor, dos computadoras interactúan: un server o servidor
ejecuta un proceso de forma continua, mientras que los clientes se conectan desde
cualquier ubicación alcanzable a través de un protocolo de red (IP en general). El
modelo permite que múltiples clientes puedan conectarse en forma simultánea para
utilizar un servicio ofrecido por el servidor. Estos servicios son provistos por la capa de
aplicación. Algunos ejemplos son: servicio de acceso remoto (SSH), servicio de
transferencia de archivos (FTP) y servicio para sitios web (WWW).
Puertos
En este momento, puede surgir la duda: ¿cómo se identifica el proceso al que quiere
acceder el cliente? ¿Cómo es posible que múltiples usuarios accedan al mismo
proceso?
Tanto el proceso que corre en el servidor como el que se crea en el cliente para poder
acceder al servicio ofrecido por el servidor, se identifican con un número que ocupa
16 bits. Esto da lugar a números entre 0 y 65535. Para que un cliente y un servidor se
comuniquen entre sí e intercambien mensajes, es necesario conocer no solo las
direcciones IP de cliente y destino, y la IP del servidor, sino que será también
necesario conocer el puerto que usa la aplicación del servidor y el puerto que usa la
aplicación del cliente.
1
Para evitar averiguar qué puerto utiliza cada aplicación, se han definido entre 1 y
1023 los “puertos bien conocidos”. Es decir, las aplicaciones más utilizadas ya tienen
un número de puerto asignado, por lo que los clientes lo conocen de antemano. Estos
números son controlados por ICANN.
En el caso del número de puerto que usan los clientes, estos son asignados por el
sistema operativo siendo su número mayor a 49152. Los números entre 1024 y 49151
no son asignados ni controlados por ICANN, pero pueden ser registrados para evitar
duplicaciones.
Figura 1: Algunos puertos “bien conocidos”
Fuente: Forouzan, 2013, p. 737.
En la figura anterior, se observan algunos puertos “well known”. Es interesante notar
que un mismo número de puertos puede ser utilizado por diferentes protocolos de la
capa de transporte (UDP/TCP/SCTP). Las celdas en gris significan que la aplicación no
admite ese protocolo de la capa de transporte. Por ejemplo, SMTP no admite
protocolo UDP.
Protocolo UDP
El protocolo UDP ofrece un tipo de servicio a la capa de aplicación: es no orientado a
la conexión, y no confiable. Estas características son similares al protocolo IP por lo
que no le agrega valor agregado y solamente cumple su función para hacer posible la
comunicación proceso a proceso.
2
¿Para qué fue diseñado un protocolo así? Para ciertas situaciones, resulta ventajoso
que el protocolo sea simple y veloz. Por ejemplo, para enviar mensajes cortos o
información en tiempo real, ya que pierde sentido si debe ser retransmitida. En
cualquier caso, las tareas relacionadas con un eventual control de flujo o detección de
pérdida de paquetes, por ejemplo, deberán ser realizadas por la capa superior
(aplicación).
Te invito a ver el siguiente video para conocer más sobre UDP:
Video 1: UDP
Fuente: Mastering IT (30 de mayo de 2019). Protocolo UDP vs. TCP - La MEJOR
explicación en toda la red [Archivo de video]. Recuperado de:
[Link]
Encabezado del datagrama
El encabezado de los datagramas UDP es muy simple. Se identifica a los puertos de
origen y destino (16 bits cada campo), la longitud total (otros 16 bits) y finalmente
una suma de verificación (16 bits).
Figura 2: Encabezado UDP
Fuente: Forouzan, 2013, p. 738.
Checksum
El cálculo del checksum es diferente al realizado en el encabezado IP. Este último
realiza una suma de verificación que abarca todo el encabezado IP (incluyendo su
propio campo checksum que es puesto en cero para hacer posible dicho cálculo). En
el caso de UDP, la suma de verificación cubre tres áreas:
● El encabezado UDP.
● El área de datos de UDP.
● Un pseudoencabezado.
¿Qué es y por qué se incluye este pseudoencabezado en el checksum?
3
En la capa de transporte, es necesario identificar tanto direcciones IP como puertos.
Si se corrompen ciertos valores del encabezado IP y esta información no está
disponible en el checksum UDP, el paquete IP pudo haber sido entregado a un host de
destino diferente al que se suponía (por ejemplo, un cambio en el campo IP de
destino del paquete IP) y UDP no detectaría problema alguno.
Los campos que se incluyen en el pseudoencabezado se observan en la Figura 3.
Están incluidas las direcciones IP de origen y de destino como así también el campo
“protocolo”. Esto último para poder identificar si en el encabezado IP estaba indicado
que en la capa de transporte se utilizó UDP en el transmisor.
Figura 3: Checksum UDP
Fuente: Forouzan, 2013, p. 739.
El checksum en UDP es opcional y puede suprimirse en el caso de que la aplicación
considere que es beneficioso no utilizar tiempo de CPU para este cálculo. En el caso
de que el checksum no se calcule, el campo debe ser rellenado con ceros. En el caso
de que sí se calcule y su resultado sea 0, se invierten todos los bits a 1.
Funcionamiento
Los servicios que provee UDP son: comunicación proceso a proceso, sin conexión, sin
control de flujo ni congestión y sin control de errores (solo se detectan con checksum,
pero nada se hace).
“Sin conexión”: cuando una aplicación utiliza UDP para enviar sus mensajes, estos
serán enviados al receptor sin mediar intercambio alguno previo para que tanto
transmisor como receptor puedan tomar conocimiento de la situación.
4
“Sin control de flujo”: si la velocidad con la que el transmisor envía sus datagramas es
mayor a la velocidad con la que el receptor puede procesarlas, este último se saturará
y UDP nada hará al respecto.
Algo similar puede ocurrir cuando existe congestión en la red. UDP no podrá
detectarlo.
UDP solo realiza un checksum para detectar errores y descartar tramas, pero puede
haber otro tipo de errores como por ejemplo datagramas duplicados o perdidos en la
red. Estos inconvenientes no son detectados por UDP y junto a los anteriores deben
ser solucionados por la capa de aplicación.
Manejo de mensajes
UDP implementa queues (colas) asociadas a los procesos que son abiertos por el
sistema operativo tanto en el receptor como en el transmisor. Las colas están
asociadas a los puertos de origen y destino.
En la cola de salida del transmisor, son colocados todos los mensajes que se envían o
reciben.
Además, UDP “multiplexa” y “demultiplexa”, ya que muchos servicios pueden
requerir el uso del protocolo en el mismo dispositivo.
Continúa estudiando sobre UDP en el Capítulo 10 del libro Transmisión de datos y
redes de computadores (2003) de López Soler, Díaz Verdejo y García Teodoro.
UDP-Lite
UDP-Lite (lightweight user datagram protocol o protocolo de datagrama de usuario
ligero) es un protocolo basado en UDP que permite que un datagrama que ha sufrido
cierta cantidad de daño en su área de datos sea considerado como válido en lugar de
ser descartado por el error en el checksum.
Para lograr su objetivo, la cantidad de datos que cubre el checksum es variable. Por lo
tanto, la aplicación puede decidir cuánta información estará cubierta.
5
Este protocolo fue diseñado para ser utilizado por aplicaciones multimedia en donde
es preferible recibir parte de la información a recibir nada. Pensemos en llamadas
telefónicas que usan voz sobre IP o streaming de video. Recibir información
incompleta reduce la calidad de la llamada o el video, pero no recibir nada es aún
peor.
Referencias
Forouzan, B. A. (2013). Data communications and networking. Estados Unidos:
McGraw-Hill.
Tanenbaum, W. (2012). Redes de computadoras. México: Pearson.
