Protocolo de datagramas de usuario

En redes informáticas , el Protocolo de Datagramas de Usuario ( UDP ) es uno de los protocolos de comunicación principales del conjunto de protocolos de Internet, utilizado para enviar mensajes (transportados como datagramas en paquetes ) a otros hosts en una red de Protocolo de Internet (IP). Dentro de una red IP, UDP no requiere comunicación previa para establecer canales de comunicación o rutas de datos.

UDP es un protocolo sin conexión , lo que significa que los mensajes se envían sin negociar una conexión y que UDP no mantiene un registro de lo que ha enviado. ^{[ 1 ] [ 2 ]} UDP proporciona sumas de verificación para la integridad de los datos y números de puerto para direccionar diferentes funciones en el origen y el destino del datagrama. No tiene diálogos de establecimiento de conexión y, por lo tanto, expone el programa del usuario a cualquier falta de fiabilidad de la red subyacente; no hay garantía de entrega, orden ni protección contra duplicados. Si se necesitan mecanismos de corrección de errores a nivel de interfaz de red, una aplicación puede utilizar el Protocolo de Control de Transmisión (TCP) o el Protocolo de Transmisión de Control de Flujo (SCTP), que están diseñados para este propósito.

UDP es adecuado para propósitos donde la verificación y corrección de errores no son necesarias o se realizan en la aplicación; UDP evita la sobrecarga de dicho procesamiento en la pila de protocolos . Las aplicaciones sensibles al tiempo a menudo usan UDP porque descartar paquetes es preferible a esperar paquetes retrasados ​​debido a la retransmisión , lo cual puede no ser una opción en un sistema en tiempo real . ^{[ 3 ]}

El protocolo fue diseñado por David P. Reed en 1980 y definido formalmente en el RFC 768 . 

UDP es un protocolo de capa de transporte simple orientado a mensajes, documentado en la RFC 768. Si bien UDP proporciona verificación de integridad (mediante suma de comprobación ) de la cabecera y la carga útil, ^{[ 4 ]} no ofrece garantías al protocolo de capa superior para la entrega de mensajes, y la capa UDP no conserva ningún estado de los mensajes UDP una vez enviados. Por esta razón, a veces se hace referencia a UDP como Protocolo de Datagramas No Confiable . ^{[ 5 ]} Si se desea confiabilidad en la transmisión, esta debe implementarse en la aplicación del usuario. 

Varias características del protocolo UDP lo hacen especialmente adecuado para ciertas aplicaciones.

• Está orientado a transacciones y es adecuado para protocolos sencillos de consulta-respuesta como el Sistema de Nombres de Dominio o el Protocolo de Tiempo de Red .
• Proporciona datagramas adecuados para modelar otros protocolos como la tunelización IP o la llamada a procedimiento remoto y el sistema de archivos de red .
• Es sencillo , adecuado para el arranque o para otros fines sin una pila de protocolos completa , como DHCP y el Protocolo de Transferencia de Archivos Trivial .
• Es un protocolo sin estado , adecuado para un número muy elevado de clientes, como en aplicaciones de transmisión de contenido multimedia como IPTV .
• La ausencia de retrasos por retransmisión lo hace adecuado para aplicaciones en tiempo real como Voz sobre IP , juegos en línea y muchos protocolos que utilizan el Protocolo de Transmisión en Tiempo Real (RTP ).
• Debido a que admite multidifusión , es adecuado para la difusión de información, como en muchos tipos de descubrimiento de servicios e información compartida, como el Protocolo de Tiempo de Precisión y el Protocolo de Información de Enrutamiento .

Las aplicaciones pueden usar sockets de datagramas para establecer comunicaciones entre hosts. Una aplicación vincula un socket a su punto final de transmisión de datos, que es una combinación de una dirección IP y un puerto . De esta manera, UDP proporciona multiplexación de aplicaciones . Un puerto es una estructura de software que se identifica mediante el número de puerto , un valor entero de 16 bits, que permite números de puerto entre 0 y 65535. El puerto 0 está reservado, pero es un valor de puerto de origen permitido si el proceso emisor no espera mensajes como respuesta.

La Autoridad de Números Asignados de Internet (IANA) ha dividido los números de puerto en tres rangos. ^{[ 6 ]} Los puertos del 0 al 1023 se utilizan para servicios comunes y conocidos. En sistemas operativos tipo Unix , el uso de uno de estos puertos requiere permisos de superusuario . Los puertos del 1024 al 49151 son los puertos registrados utilizados para los servicios registrados en IANA. Los puertos del 49152 al 65535 son puertos dinámicos que no están designados oficialmente para ningún servicio específico y pueden utilizarse para cualquier propósito. Estos también pueden utilizarse como puertos efímeros , que el software que se ejecuta en el host puede utilizar para crear dinámicamente puntos finales de comunicación según sea necesario. ^{[ 6 ]}

Un datagrama UDP consta de una cabecera de datagrama seguida de una sección de datos (los datos de carga útil para la aplicación). La cabecera de datagrama UDP consta de 4 campos, cada uno de los cuales es de 2 bytes (16 bits): ^{[ 3 ]}

El uso de los campos Suma de verificación y Puerto de origen es opcional en IPv4 (fondo morado claro en la tabla). En IPv6, solo el campo Puerto de origen es opcional. Si no se utilizan, estos campos deben establecerse en cero. ^{[ 7 ]}

Puerto de origen : 16 bits

Este campo identifica el puerto del remitente, cuando se utiliza, y debe asumirse que es el puerto al que se debe responder si es necesario. Si el host de origen es el cliente, es probable que el número de puerto sea un puerto efímero. Si el host de origen es el servidor, es probable que el número de puerto sea un número de puerto conocido entre 0 y 1023. ^{[ 6 ]}

Puerto de destino : 16 bits

Este campo identifica el puerto del receptor y es obligatorio. Al igual que con el número de puerto de origen, si el cliente es el host de destino, el número de puerto probablemente será un puerto efímero; si el host de destino es el servidor, el número de puerto probablemente será un puerto conocido. ^{[ 6 ]}

Longitud : 16 bits

Este campo especifica la longitud del datagrama UDP (los campos de encabezado y el campo de datos) en octetos . La longitud mínima es de 8 bytes, la longitud del encabezado. El tamaño del campo establece un límite teórico de 65 535 bytes (encabezado de 8 bytes + 65 527 bytes de datos) para un datagrama UDP. Sin embargo, el límite real para la longitud de los datos, impuesto por el protocolo IPv4 subyacente, es de 65 507 bytes (65 535 bytes − encabezado UDP de 8 bytes − encabezado IP de 20 bytes ). ^{[ 8 ]}

Mediante jumgramas IPv6 es posible tener datagramas UDP de tamaño superior a 65.535 bytes. El campo de longitud se establece en cero si la longitud de la cabecera UDP más los datos UDP es superior a 65.535. ^{[ 9 ]}

Suma de verificación : 16 bits

El campo de suma de verificación puede utilizarse para comprobar errores en la cabecera y los datos. Este campo es opcional en IPv4 y obligatorio en la mayoría de los casos en IPv6. ^{[ 10 ]}

Datos : Variable

La carga útil del paquete UDP.

El método utilizado para calcular la suma de verificación se define en el RFC 768 , y el cálculo eficiente se analiza en el RFC 1071 :  

La suma de verificación es el complemento a uno de 16 bits de la suma del complemento a uno de una pseudoencabezado de información del encabezado IP, el encabezado UDP y los datos, rellenado con octetos cero al final (si es necesario) para que sea un múltiplo de dos octetos. ^{[ 7 ]}

En otras palabras, todas las palabras de 16 bits se suman utilizando aritmética de complemento a uno. Se suman los valores de 16 bits. En cada suma, si se produce un acarreo (bit 17), se reorganiza ese bit y se suma al bit menos significativo del total acumulado. ^{[ 11 ]} Finalmente, la suma se complementa a uno para obtener el valor del campo de suma de verificación UDP.

Si el cálculo de la suma de verificación da como resultado el valor cero (los 16 bits son 0), debe enviarse como complemento a uno (todos unos), ya que una suma de verificación de valor cero indica que no se ha calculado ninguna suma de verificación. ^{[ 7 ]} En este caso, no se requiere ningún procesamiento específico en el receptor, porque todos los 0 y todos los 1 son iguales a cero en la aritmética de complemento a uno.

Las diferencias entre IPv4 e IPv6 radican en el pseudo encabezado utilizado para calcular la suma de verificación, y en que la suma de verificación no es opcional en IPv6. ^{[ 12 ]} Bajo ciertas condiciones, una aplicación UDP que utiliza IPv6 puede usar un modo UDP de suma de verificación cero con un protocolo de túnel. ^{[ 13 ]}

Debido a su falta de fiabilidad, las aplicaciones UDP pueden experimentar pérdida de paquetes, reordenamiento, errores o duplicación. Si se utiliza UDP, las aplicaciones del usuario final deben proporcionar el protocolo de enlace necesario, como la confirmación en tiempo real de la recepción del mensaje. Algunas aplicaciones (por ejemplo, TFTP) pueden incorporar mecanismos de fiabilidad rudimentarios en la capa de aplicación según sea necesario. ^{[ 6 ]} Para aplicaciones que requieren un alto grado de fiabilidad, se puede utilizar un protocolo alternativo como el Protocolo de Control de Transmisión (TCP) .

Por lo general, las aplicaciones UDP no emplean mecanismos de confiabilidad e incluso pueden verse afectadas por ellos. La transmisión de contenido multimedia , los juegos multijugador en tiempo real y la voz sobre IP (VoIP) son aplicaciones típicas que utilizan UDP. En estas aplicaciones, la pérdida de paquetes no suele ser un problema grave. En VoIP, por ejemplo, la latencia y la fluctuación son las principales preocupaciones. El uso de TCP provocaría fluctuación si se perdiera algún paquete, ya que TCP no proporciona datos posteriores a la aplicación mientras solicita el reenvío de los datos perdidos.

Numerosas aplicaciones clave de Internet utilizan UDP, entre ellas: el Sistema de Nombres de Dominio (DNS), el Protocolo Simple de Administración de Red (SNMP), el Protocolo de Información de Enrutamiento (RIP) ^{[ 3 ]} y el Protocolo de Configuración Dinámica de Host (DHCP).

El tráfico de voz y vídeo generalmente se transmite mediante UDP. Los protocolos de transmisión de audio y vídeo en tiempo real están diseñados para gestionar la pérdida ocasional de paquetes, por lo que solo se produce una ligera degradación de la calidad, en comparación con los grandes retrasos que se producirían si se retransmitieran los paquetes perdidos. Dado que tanto TCP como UDP se ejecutan sobre la misma red, a mediados de la década de 2000 algunas empresas descubrieron que un aumento del tráfico UDP procedente de estas aplicaciones en tiempo real perjudicaba ligeramente el rendimiento de las aplicaciones que utilizaban TCP, como los sistemas de punto de venta , contabilidad y bases de datos (cuando TCP detecta la pérdida de paquetes, reduce su velocidad de transmisión de datos). ^{[ 14 ]}

Algunos sistemas VPN , como OpenVPN , admiten el funcionamiento sobre UDP y proporcionan comprobación de errores en la capa de aplicación, así como mecanismos para mejorar la fiabilidad de la transmisión. WireGuard utiliza UDP y realiza comprobación de errores, pero no ofrece ninguna garantía de fiabilidad; esta se delega a los protocolos de capa superior dentro del túnel o a las aplicaciones finales.

QUIC es un protocolo de transporte basado en UDP. QUIC proporciona una conexión fiable y segura. HTTP/3 utiliza QUIC, a diferencia de las versiones anteriores de HTTPS , que emplean una combinación de TCP y TLS para garantizar la fiabilidad y la seguridad, respectivamente. Esto significa que HTTP/3 utiliza un único protocolo de enlace para establecer una conexión, en lugar de dos protocolos de enlace separados para TCP y TLS, lo que reduce el tiempo total necesario para establecer la conexión. ^{[ 15 ]}

El Protocolo de Control de Transmisión (TCP) es un protocolo orientado a la conexión y requiere un intercambio de claves para establecer comunicaciones de extremo a extremo. Una vez establecida la conexión, los datos del usuario pueden enviarse bidireccionalmente a través de ella.

• Confiable : TCP gestiona la confirmación de recepción, la retransmisión y los tiempos de espera de los mensajes. Se realizan múltiples intentos para entregar el mensaje. Si se pierden datos durante el proceso, se reenvían. En TCP, no hay pérdida de datos o, en caso de múltiples tiempos de espera, se interrumpe la conexión.
• Ordenado : Si se envían dos mensajes en secuencia a través de una conexión, el primer mensaje llegará primero a la aplicación receptora. Cuando los segmentos de datos llegan en un orden incorrecto, TCP almacena en búfer los datos desordenados hasta que todos los datos puedan reordenarse correctamente y entregarse a la aplicación.
• Con un protocolo pesado , TCP requiere tres paquetes para establecer una conexión de socket antes de que se puedan enviar datos de usuario. TCP gestiona la fiabilidad y el control de la congestión .
• Transmisión continua : Los datos se leen como una secuencia de bytes ; no se transmiten indicaciones distintivas para señalar los límites de los mensajes (segmentos).

El Protocolo de Datagramas de Usuario (UDP) es un protocolo sin conexión basado en mensajes, más sencillo . Los protocolos sin conexión no establecen una conexión dedicada de extremo a extremo. La comunicación se logra transmitiendo información en una sola dirección, desde el origen hasta el destino, sin verificar la disponibilidad ni el estado del receptor.

• Poco fiable : cuando se envía un mensaje UDP, no se puede saber si llegará a su destino; podría perderse en el camino. No existe el concepto de acuse de recibo, retransmisión ni tiempo de espera.
• Sin orden específico : si se envían dos mensajes al mismo destinatario, no se puede garantizar el orden en que lleguen.
• Ligero : no hay ordenación de mensajes, ni seguimiento de conexiones, etc. Es una capa de transporte muy simple diseñada sobre IP.
• Datagramas : Los paquetes se envían individualmente y se verifica su integridad al llegar. Los paquetes tienen límites definidos que se respetan al recibirlos; una operación de lectura en el socket del receptor devolverá el mensaje completo tal como se envió originalmente.
• Sin control de congestión : el protocolo UDP por sí solo no evita la congestión. Las medidas de control de congestión deben implementarse a nivel de aplicación o en la red.
• Difusión : al no tener conexión, UDP puede realizar transmisiones; los paquetes enviados pueden dirigirse para que los reciban todos los dispositivos de la subred.
• Multidifusión : se admite un modo de funcionamiento de multidifusión mediante el cual un único paquete de datagramas puede enrutarse automáticamente sin duplicación a un grupo de suscriptores.

• RFC 9868 – Protocolo de datagramas de usuario 
• RFC 2460 – Especificación del Protocolo de Internet, versión 6 (IPv6) 
• RFC 2675 – Jumbogramas IPv6 
• RFC 4113 – Base de información de gestión para UDP 
• RFC 8085 – Directrices de uso de UDP 

• Asignaciones de puertos de IANA
• El problema del escaneo UDP (PDF)
• Desglose de la trama UDP. Archivado el 22 de enero de 2009 en la Wayback Machine.
• UDP en MSDN Magazine Sockets y WCF