En las redes de computadoras , el Protocolo de datagramas de usuario ( UDP ) es uno de los protocolos de comunicación principales del conjunto de protocolos de Internet que se utiliza 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 configurar canales de comunicación o rutas de datos.
UDP utiliza un modelo de comunicación simple sin conexión 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 destino del datagrama. No tiene diálogos de intercambio 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 contra duplicados. Si se necesitan funciones de corrección de errores a nivel de interfaz de red, una aplicación puede utilizar en su lugar 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 urgentes suelen utilizar UDP porque es preferible descartar paquetes que esperar paquetes retrasados debido a la retransmisión , lo que puede no ser una opción en un sistema en tiempo real . [1]
El protocolo fue diseñado por David P. Reed en 1980 y definido formalmente en RFC 768.
UDP es un protocolo de capa de transporte simple orientado a mensajes que está documentado en RFC 768. Aunque UDP proporciona verificación de integridad (mediante suma de verificación ) del encabezado y la carga útil, [2] no brinda garantías al protocolo de capa superior para la entrega de mensajes y el UDP La capa no retiene 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 confiables . [3] Si se desea confiabilidad de transmisión, se debe implementar en la aplicación del usuario.
Varios atributos de UDP lo hacen especialmente adecuado para determinadas aplicaciones.
Las aplicaciones pueden utilizar 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 manera, 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 permitido 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. [4] Los números de puerto del 0 al 1023 se utilizan para servicios comunes y conocidos. En sistemas operativos tipo 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 utilizados para los servicios registrados en la 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 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. [4]
Un datagrama UDP consta de un encabezado de datagrama seguido de una sección de datos (los datos de carga útil de la aplicación). El encabezado del datagrama UDP consta de 4 campos, cada uno de los cuales tiene 2 bytes (16 bits): [1]
El uso de los campos de suma de comprobación y puerto de origen es opcional en IPv4 (fondo rosa en la tabla). En IPv6 sólo el campo del puerto de origen es opcional.
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 unos de 16 bits de la suma en complemento a unos 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 formar un múltiplo de dos octetos. [8]
En otras palabras, todas las palabras de 16 bits se suman utilizando la aritmética en complemento a uno. Sume los valores de 16 bits. En cada suma, si se produce una transferencia (bit 17), mueva ese bit de transferencia 17 y agréguelo al bit menos significativo del total acumulado. [9] Finalmente, la suma se complementa a unos para obtener 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 unos (todos los 1), ya que una suma de verificación de valor cero indica que no se ha calculado ninguna suma de verificación. [8] En este caso, no se requiere ningún procesamiento específico en el receptor, porque todos los ceros y todos los unos son iguales a cero en la aritmética en complemento a 1.
Las diferencias entre IPv4 e IPv6 están en el pseudo encabezado utilizado para calcular la suma de verificación, y que la suma de verificación no es opcional en IPv6. [10] En condiciones específicas, una aplicación UDP que utiliza IPv6 puede utilizar un modo de suma de verificación cero UDP con un protocolo de túnel. [11]
Cuando UDP se ejecuta sobre IPv4, la suma de comprobación se calcula utilizando un pseudoencabezado que contiene parte de la misma información del encabezado IPv4 real . [8] : 2 El pseudo encabezado no es el encabezado IPv4 real utilizado para enviar un paquete IP; se utiliza únicamente para el cálculo de la suma de comprobación.
Las direcciones de origen y destino son las que figuran en el 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 del campo representan los datos transmitidos.
El cálculo de la suma de comprobación UDP es opcional para IPv4. Si no se utiliza una suma de comprobación, se debe establecer el valor cero.
Como IPv6 tiene direcciones más grandes y un diseño de encabezado diferente, el método utilizado para calcular la suma de verificación cambia en consecuencia: [7] : §8.1
Cualquier protocolo de 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 en IPv6, para incluir direcciones IPv6 de 128 bits en lugar de direcciones IPv4 de 32 bits.
Al calcular la suma de comprobación, nuevamente se utiliza un pseudo encabezado que imita el encabezado IPv6 real :
La dirección de origen es la que está en el encabezado 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 en el último elemento del encabezado de enrutamiento y, en el nodo receptor, será la dirección de destino en el encabezado de 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.
Al carecer de confiabilidad, las aplicaciones UDP pueden experimentar pérdida de paquetes, reordenamiento, errores o duplicaciones. Si se utiliza UDP, las aplicaciones del usuario final deben proporcionar cualquier protocolo de enlace necesario, como la confirmación en tiempo real de que se ha recibido el mensaje. Las aplicaciones, como TFTP , pueden agregar mecanismos de confiabilidad rudimentarios a la capa de aplicación según sea necesario. [4] Si una aplicación requiere un alto grado de confiabilidad, se puede utilizar en su lugar un protocolo como el Protocolo de control de transmisión .
En la mayoría de los casos, 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 suelen utilizar UDP. En estas aplicaciones particulares, la pérdida de paquetes no suele ser un problema fatal. En VoIP, por ejemplo, la latencia y la fluctuación son las principales preocupaciones. El uso de TCP provocaría inestabilidad si se perdiera algún paquete, ya que TCP no proporciona datos posteriores a la aplicación mientras solicita un reenvío de los datos faltantes.
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) [1] 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 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 TCP y UDP se ejecutan en la misma red, a mediados de la década de 2000, algunas empresas descubrieron que un aumento en el tráfico UDP de estas aplicaciones en tiempo real obstaculizaba levemente el rendimiento de las aplicaciones que usaban TCP, como punto de venta , contabilidad y base de datos. sistemas (cuando TCP detecta la pérdida de paquetes, reducirá su uso de velocidad de datos). [13]
Algunos sistemas VPN , como OpenVPN, pueden usar UDP y realizar comprobaciones de errores a nivel de aplicación mientras implementan conexiones confiables.
QUIC es un protocolo de transporte construido sobre UDP. QUIC proporciona una conexión confiable y segura. HTTP/3 usa QUIC a diferencia de versiones anteriores de HTTPS que usan una combinación de TCP y TLS para garantizar confiabilidad y seguridad respectivamente. Esto significa que HTTP/3 utiliza un único protocolo de enlace para configurar 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. [14]
El Protocolo de control de transmisión es un protocolo orientado a la conexión y requiere un protocolo de enlace para configurar las comunicaciones de un extremo a otro. Una vez configurada una conexión, los datos del usuario pueden enviarse bidireccionalmente a través de la conexión.
El protocolo de datagramas de usuario es un protocolo sin conexión basado en mensajes más simple . Los protocolos sin conexión no configuran una conexión dedicada de un extremo a otro. La comunicación se logra transmitiendo información en una dirección desde el origen al destino sin verificar la preparación o el estado del receptor.
{{cite web}}: CS1 maint: numeric names: authors list (link)