Protocolo de datagramas de usuario
En las redes informáticas, el Protocolo de datagramas de usuario o UDP por sus siglas en inglés User Datagram Protocol es uno de los miembros principales del conjunto de protocolos de Internet. Con UDP, las aplicaciones informáticas pueden enviar mensajes, en este caso denominados datagramas, a otros hosts en una red de Protocolo de Internet (IP). No se requieren comunicaciones previas para establecer canales de comunicación o rutas de datos.
UDP utiliza un modelo de comunicación sin conexión simple con un mínimo de mecanismos de protocolo. UDP proporciona sumas de verificación para la integridad de los datos y números de puerto para abordar diferentes funciones en el origen y el destino del datagrama. No tiene diálogos de negociación y, por lo tanto, expone el programa del usuario a cualquier falta de confiabilidad de la red subyacente; no hay garantía de entrega, pedido o protección duplicada. Si se necesitan funciones de corrección de errores en el nivel de interfaz de red, una aplicación puede usar 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 fines en los que 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 que puede no ser una opción en un sistema en tiempo real.
El protocolo fue diseñado por David P. Reed en 1980 y definido formalmente en RFC 768.
Atributos
UDP es un protocolo de capa de transporte orientado a mensajes simple que está documentado en RFC 768. Aunque UDP proporciona verificación de integridad (mediante suma de verificación) del encabezado y la carga útil, no ofrece garantías para el protocolo de capa superior para la entrega de mensajes y la capa UDP no retiene ningún mensaje. estado de los mensajes UDP una vez enviados. Por esta razón, UDP a veces se conoce como Protocolo de datagramas no confiable. Si se desea confiabilidad en la transmisión, debe implementarse en la aplicación del usuario.
Una serie de atributos de UDP lo hacen especialmente adecuado para ciertas aplicaciones.
- Está orientado a transacciones, adecuado para protocolos simples de consulta y respuesta, como el Sistema de nombres de dominio o el Protocolo de tiempo de red.
- Proporciona datagramas, adecuados para modelar otros protocolos, como túneles IP o llamadas a procedimientos remotos y el sistema de archivos de red.
- Es simple, adecuado para arranque u otros fines sin una pila de protocolos completa, como DHCP y Trivial File Transfer Protocol.
- Es sin estado, adecuado para un gran número de clientes, como en aplicaciones de transmisión de medios como IPTV.
- La falta de demoras en la 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.
- Debido a que admite multidifusión, es adecuado para transmitir 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.
Puertos
Las aplicaciones pueden usar sockets de datagramas para establecer comunicaciones de host a host. 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 forma, UDP proporciona multiplexación de aplicaciones. Un puerto es una estructura de software que se identifica por 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 permisible si el proceso de envío no espera mensajes en respuesta.
La Autoridad de Números Asignados de Internet (IANA) ha dividido los números de puerto en tres rangos. Los números de puerto del 0 al 1023 se utilizan para servicios comunes y conocidos. En sistemas operativos similares a Unix, el uso de uno de estos puertos requiere permiso operativo de superusuario. Los números de puerto del 1024 al 49151 son los puertos registrados que se utilizan para los servicios registrados en la IANA. Los puertos del 49152 al 65535 son puertos dinámicos que no están oficialmente designados para ningún servicio específico y pueden usarse para cualquier propósito. Estos también se pueden usar como puertos efímeros, que el software que se ejecuta en el host puede usar para crear dinámicamente puntos finales de comunicaciones según sea necesario.
Estructura de datagrama UDP
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Puerto de origen | Puerto de destino | ||||||||||||||||||||||||||||||
| 4 | 32 | Longitud | Suma de verificación |
Un datagrama UDP consta de un encabezado de datagrama y una sección de datos. El encabezado del datagrama UDP consta de 4 campos, cada uno de los cuales tiene 2 bytes (16 bits). La sección de datos sigue al encabezado y son los datos de carga útil transportados por la aplicación.
El uso de los campos checksum y source port es opcional en IPv4 (fondo rosa en la tabla). En IPv6, solo el campo del puerto de origen es opcional.Número de puerto de origenEste campo identifica el puerto del remitente, cuando se usa, y se debe suponer que es el puerto al que responder si es necesario. Si no se usa, debe ser cero. Si el host de origen es el cliente, es probable que el número de puerto sea un número de 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.Número de puerto de destinoEste campo identifica el puerto del receptor y es obligatorio. Al igual que el número de puerto de origen, si el cliente es el host de destino, es probable que el número de puerto sea un número de puerto efímero y, si el host de destino es el servidor, es probable que el número de puerto sea un número de puerto conocido.LongitudEste campo especifica la longitud en bytes del encabezado UDP y los datos UDP. La longitud mínima es de 8 bytes, la longitud de la cabecera. 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).Usando jumbogramas IPv6 es posible tener datagramas UDP de tamaño superior a 65.535 bytes. RFC 2675 especifica que el campo de longitud se establece en cero si la longitud del encabezado UDP más los datos UDP es superior a 65 535.Suma de verificaciónEl campo de suma de verificación se puede utilizar para la verificación de errores del encabezado y los datos. Este campo es opcional en IPv4 y obligatorio en IPv6. El campo lleva todos ceros si no se usa.
Cálculo de la suma de comprobación
El método utilizado para calcular la suma de comprobación se define en RFC 768, y el cálculo eficiente se analiza en RFC 1071:
La suma de comprobación es el complemento a uno de 16 bits de la suma del complemento a uno de un pseudoencabezado de información del encabezado IP, el encabezado UDP y los datos, rellenado con cero octetos al final (si es necesario) para hacer un múltiplo de dos octetos.
En otras palabras, todas las palabras de 16 bits se suman utilizando la aritmética del complemento a uno. Sume los valores de 16 bits hacia arriba. En cada adición, si se produce un acarreo (bit 17), gire ese bit de acarreo 17 y agréguelo al bit menos significativo del total acumulado. Finalmente, la suma se complementa para producir el valor del campo de suma de comprobación UDP.
Si el cálculo de la suma de verificación da como resultado el valor cero (los 16 bits 0), debe enviarse como complemento de uno (todos los 1), ya que una suma de verificación de valor cero indica que no se ha calculado ninguna suma de verificación. 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 del complemento a 1.
Las diferencias entre IPv4 e IPv6 están en el pseudoencabezado que se usa para calcular la suma de verificación y que la suma de verificación no es opcional en IPv6.
Pseudoencabezado de IPv4
Cuando UDP se ejecuta sobre IPv4, la suma de comprobación se calcula mediante un "pseudoencabezado" que contiene parte de la misma información del encabezado IPv4 real. El pseudoencabezado no es el encabezado IPv4 real que se usa para enviar un paquete IP, se usa solo para el cálculo de la suma de verificación.
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Dirección IPv4 de origen | |||||||||||||||||||||||||||||||
| 4 | 32 | Dirección IPv4 de destino | |||||||||||||||||||||||||||||||
| 8 | 64 | ceros | Protocolo | Longitud UDP | |||||||||||||||||||||||||||||
| 12 | 96 | Puerto de origen | Puerto de destino | ||||||||||||||||||||||||||||||
| dieciséis | 128 | Longitud UDP | Suma de verificación | ||||||||||||||||||||||||||||||
| 20 | 160+ | Datos |
Las direcciones de origen y destino son las del encabezado IPv4. El protocolo es el de UDP (ver Lista de números de protocolo IP): 17 (0x11). El campo de longitud UDP es la longitud del encabezado y los datos UDP. Los datos de campo representan los datos transmitidos.
El cálculo de la suma de comprobación de UDP es opcional para IPv4. Si no se utiliza una suma de comprobación, debe establecerse en el valor cero.
Pseudoencabezado de IPv6
Cuando UDP se ejecuta sobre IPv6, la suma de verificación es obligatoria. El método utilizado para calcularlo se cambia como se documenta en RFC 2460:
Cualquier transporte u otro protocolo de capa superior que incluya las direcciones del encabezado IP en su cálculo de suma de verificación debe modificarse para su uso sobre IPv6 para incluir las direcciones IPv6 de 128 bits.
Al calcular la suma de verificación, nuevamente se usa un pseudoencabezado que imita el encabezado real de IPv6:
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Dirección IPv6 de origen | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | ||||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| dieciséis | 128 | Dirección IPv6 de destino | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| 24 | 192 | ||||||||||||||||||||||||||||||||
| 28 | 224 | ||||||||||||||||||||||||||||||||
| 32 | 256 | Longitud UDP | |||||||||||||||||||||||||||||||
| 36 | 288 | ceros | Siguiente encabezado = Protocolo | ||||||||||||||||||||||||||||||
| 40 | 320 | Puerto de origen | Puerto de destino | ||||||||||||||||||||||||||||||
| 44 | 352 | Longitud | Suma de verificación | ||||||||||||||||||||||||||||||
| 48 | 384+ | Datos |
La dirección de origen es la que está en el encabezado de IPv6. La dirección de destino es el destino final; si el paquete IPv6 no contiene un encabezado de enrutamiento, esa será la dirección de destino en el encabezado IPv6; de lo contrario, en el nodo de origen, será la dirección del último elemento de la cabecera de enrutamiento y, en el nodo de recepción, será la dirección de destino de la cabecera IPv6. El valor del campo Siguiente encabezado es el valor del protocolo para UDP: 17. El campo de longitud UDP es la longitud del encabezado y los datos UDP.
Confiabilidad y control de congestión
Al carecer de confiabilidad, las aplicaciones UDP pueden experimentar pérdida de paquetes, reordenación, errores o duplicación. Si usa UDP, las aplicaciones del usuario final deben proporcionar cualquier reconocimiento necesario, como una confirmación en tiempo real de que se recibió el mensaje. Las aplicaciones, como TFTP, pueden agregar mecanismos de confiabilidad rudimentarios en la capa de aplicación según sea necesario. Si una aplicación requiere un alto grado de confiabilidad, se puede usar en su lugar un protocolo como el Protocolo de control de transmisión.
La mayoría de las veces, las aplicaciones UDP no emplean mecanismos de confiabilidad e incluso pueden verse obstaculizadas por ellos. La transmisión de medios, los juegos multijugador en tiempo real y la voz sobre IP (VoIP) son ejemplos de aplicaciones que a menudo usan UDP. En estas aplicaciones particulares, la pérdida de paquetes no suele ser un problema fatal. En VoIP, por ejemplo, la latencia y el jitter son las principales preocupaciones. El uso de TCP provocaría fluctuaciones 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 faltantes.
Aplicaciones
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) y el Protocolo de configuración dinámica de host (DHCP).
El tráfico de voz y video generalmente se transmite mediante UDP. Los protocolos de transmisión de audio y video en tiempo real están diseñados para manejar paquetes perdidos ocasionalmente, por lo que solo se produce una ligera degradación en la calidad, en lugar de grandes retrasos si los paquetes perdidos se retransmiten. Debido a que tanto TCP como UDP se ejecutan en la misma red, a mediados de la década de 2000, algunas empresas descubrieron que el aumento del tráfico UDP de estas aplicaciones en tiempo real obstaculizaba levemente el rendimiento de las aplicaciones que utilizan TCP, como los sistemas de punto de venta, contabilidad y base de datos. (cuando TCP detecta la pérdida de paquetes, reducirá el uso de la tasa de datos).
Algunos sistemas VPN, como OpenVPN, pueden usar UDP y realizar una verificación de errores en el nivel de la aplicación mientras implementan conexiones confiables.
QUIC es un protocolo de transporte construido sobre UDP. QUIC proporciona una conexión fiable y segura. HTTP/3 usa QUIC a diferencia de las versiones anteriores de HTTPS que usan una combinación de TCP y TLS para garantizar la confiabilidad y la seguridad, respectivamente. Esto significa que HTTP/3 usa un solo protocolo de enlace para establecer una conexión, en lugar de tener dos protocolos de enlace separados para TCP y TLS, lo que significa que se reduce el tiempo total para establecer una conexión.
Comparación de UDP y TCP
El Protocolo de control de transmisión es un protocolo orientado a la conexión y requiere un protocolo de enlace para establecer comunicaciones de extremo a extremo. Una vez que se establece una conexión, los datos del usuario pueden enviarse bidireccionalmente a través de la conexión.
- Confiable: TCP administra el reconocimiento de mensajes, la retransmisión y los tiempos de espera. Se realizan varios intentos de entregar el mensaje. Si los datos se pierden en el camino, se volverán a enviar. En TCP, no faltan datos o, en caso de múltiples tiempos de espera, la conexión se interrumpe.
- Ordenado: si se envían dos mensajes a través de una conexión en secuencia, el primer mensaje llegará primero a la aplicación receptora. Cuando los segmentos de datos llegan en el orden incorrecto, TCP almacena en búfer los datos desordenados hasta que todos los datos se pueden reordenar correctamente y entregar a la aplicación.
- Peso pesado: TCP requiere tres paquetes para configurar una conexión de socket antes de que se puedan enviar datos de usuario. TCP maneja la confiabilidad y el control de congestión.
- Streaming: los datos se leen como un flujo de bytes, no se transmiten indicaciones distintivas a los límites del mensaje de señal (segmento).
El protocolo de datagramas de usuario es un protocolo sin conexión basado en mensajes más simple. Los protocolos sin conexión no establecen una conexión de extremo a extremo dedicada. La comunicación se logra mediante la transmisión de información en una dirección desde el origen hasta el destino sin verificar la preparación o el estado del receptor.
- No confiable: 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 reconocimiento, retransmisión o tiempo de espera.
- No ordenado: si se envían dos mensajes al mismo destinatario, no se puede garantizar el orden en que llegan.
- Ligero: no hay orden de mensajes, no hay conexiones de seguimiento, 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 generará un mensaje completo tal como se envió originalmente.
- Sin control de congestión: UDP en sí mismo no evita la congestión. Las medidas de control de congestión deben implementarse a nivel de aplicación o en la red.
- Difusiones: al no tener conexión, UDP puede transmitir: los paquetes enviados se pueden direccionar para que todos los dispositivos de la subred puedan recibirlos.
- Multidifusión: se admite un modo de operación de multidifusión mediante el cual un solo paquete de datagrama puede enrutarse automáticamente sin duplicación a un grupo de suscriptores.
Estándares
- RFC 768 - Protocolo de datagramas de usuario
- RFC 2460: especificación del protocolo de Internet, versión 6 (IPv6)
- RFC 2675: jumbogramas de IPv6
- RFC 4113 - Base de información de gestión para UDP
- RFC 8085: Pautas de uso de UDP