stringtranslate.com

Protocolo de datagramas de usuario

En redes informáticas , el Protocolo de datagramas de usuario ( UDP ) es uno de los protocolos de comunicación básicos 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, el UDP no requiere una comunicación previa para configurar 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 realiza un seguimiento de lo que ha enviado. [1] [2] UDP proporciona sumas de comprobació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 enlace 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 o protección duplicada. Si se necesitan funciones de corrección de errores en el 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.

El protocolo UDP es adecuado para aquellos casos en los que no es necesario comprobar ni corregir errores o estos se realizan en la aplicación; el protocolo UDP evita la sobrecarga que supone dicho procesamiento en la pila de protocolos . Las aplicaciones sensibles al tiempo suelen utilizar el protocolo UDP porque es preferible descartar paquetes que esperar a que se retrasen debido a la retransmisión , lo que 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 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 (a través de suma de comprobación ) del encabezado y la carga útil, [4] no proporciona 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 confiables . [5] 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 determinadas aplicaciones.

Puertos

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 como respuesta.

La Autoridad de Números Asignados de Internet (IANA) ha dividido los números de puerto en tres rangos. [6] 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 el permiso operativo del superusuario . Los números de puerto del 1024 al 49151 son los puertos registrados que se utilizan para los servicios registrados por 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 se pueden utilizar para cualquier propósito. También se pueden utilizar como puertos efímeros , que el software que se ejecuta en el host puede utilizar para crear dinámicamente puntos finales de comunicaciones según sea necesario. [6]

Estructura del datagrama UDP

Un datagrama UDP consta de un encabezado de datagrama seguido de una sección de datos (los datos de carga útil para la aplicación). El encabezado del datagrama UDP consta de 4 campos, cada uno de los cuales tiene 2 bytes (16 bits): [3]

El uso de los campos Checksum y Source Port es opcional en IPv4 (fondo violeta claro en la tabla). En IPv6, solo el campo Source Port es opcional. Si no se utilizan, estos campos deben configurarse a cero. [7]

Puerto de origen: 16 bits
Este campo identifica el puerto del remitente, cuando se utiliza, y se debe asumir 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. De manera similar al número de puerto de origen, si el cliente es el host de destino, el número de puerto probablemente será un número de puerto efímero y si el host de destino es el servidor, el número de puerto probablemente será un número de puerto conocido. [6]
Longitud: 16 bits
Este campo especifica la longitud en bytes 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, que impone el protocolo IPv4 subyacente, es de 65.507 bytes (65.535 bytes − encabezado UDP de 8 bytes − encabezado IP de 20 bytes ). [8]
Con los jumbogramas de 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 del encabezado UDP más los datos UDP es superior a 65.535. [9]
Suma de comprobación : 16 bits
El campo de suma de comprobación se puede utilizar para comprobar errores en el encabezado 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.

Cálculo de 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 pseudo encabezado 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. [7]

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. En cada adición, si se produce un acarreo (bit 17), haga girar ese bit de acarreo 17 y agréguelo al bit menos significativo del total acumulado. [11] Finalmente, la suma se complementa a uno para obtener el valor del campo de suma de comprobación UDP.

Si el cálculo de la suma de comprobación da como resultado el valor cero (los 16 bits son 0), se debe enviar como complemento de unos (todos 1), ya que una suma de comprobación de valor cero indica que no se ha calculado ninguna suma de comprobació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 del complemento de 1.

Las diferencias entre IPv4 e IPv6 están en el pseudo encabezado utilizado para calcular la suma de comprobación, y en que la suma de comprobación no es opcional en IPv6. [12] Bajo condiciones específicas, una aplicación UDP que utiliza IPv6 puede utilizar un modo de suma de comprobación cero UDP con un protocolo de túnel. [13]

Pseudo encabezado IPv4

Cuando UDP se ejecuta sobre IPv4, la suma de comprobación se calcula utilizando un pseudo encabezado que contiene parte de la misma información del encabezado IPv4 real . [7] : 2  El pseudo encabezado no es el encabezado IPv4 real utilizado para enviar un paquete IP, se utiliza solo para el cálculo de la suma de comprobación. 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 en el valor cero.

La suma de comprobación se calcula sobre los siguientes campos:

Dirección de origen: 32 bits
La dirección de origen del encabezado IPv4.
Dirección de destino: 32 bits
La dirección de destino del encabezado IPv4.
Ceros: 8 bits; Ceros == 0
Todos ceros.
Protocolo: 8 bits
El valor del protocolo para UDP: 17 (o 0x11 ).
Longitud UDP: 16 bits
La longitud del encabezado UDP y los datos (medida en octetos).

Pseudo encabezado IPv6

Como IPv6 tiene direcciones más grandes y un diseño de encabezado diferente, el método utilizado para calcular la suma de comprobación se modifica en consecuencia: [10] : §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 comprobación debe modificarse para su uso sobre IPv6, para incluir las direcciones IPv6 de 128 bits en lugar de las 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 suma de comprobación se calcula sobre los siguientes campos:

Dirección de origen: 128 bits
La dirección en el encabezado IPv6.
Dirección de destino: 128 bits
El destino final; si el paquete IPv6 no contiene un encabezado de enrutamiento, TCP utiliza la dirección de destino en el encabezado IPv6, de lo contrario, en el nodo de origen, utiliza la dirección en el último elemento del encabezado de enrutamiento y, en el nodo receptor, utiliza la dirección de destino en el encabezado IPv6.
Longitud UDP: 32 bits
La longitud del encabezado UDP y los datos (medida en octetos).
Ceros: 24 bits; Ceros == 0
Todos ceros.
Encabezado siguiente: 8 bits
El valor del protocolo de capa de transporte para UDP: 17 .

Fiabilidad y control de la congestión

Al carecer de confiabilidad, las aplicaciones UDP pueden experimentar pérdidas de paquetes, reordenamiento, errores o duplicaciones. Si se utiliza UDP, las aplicaciones de usuario final deben proporcionar cualquier protocolo de enlace necesario, como una 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. [6] 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 .

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 suelen utilizar UDP. En estas aplicaciones en particular, 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 causaría jitter si se perdieran paquetes, ya que TCP no proporciona datos posteriores a la aplicación mientras solicita un 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) [3] 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 ocasionales, por lo que solo se produce una ligera degradación en la calidad, en lugar de grandes demoras si se retransmiten los paquetes perdidos. Debido a que TCP y UDP se ejecutan sobre 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 ligeramente el rendimiento de las aplicaciones que usaban TCP, como los sistemas de puntos de venta , contabilidad y bases de datos (cuando TCP detecta la pérdida de paquetes, reducirá su uso de la velocidad de datos). [14]

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 basado en UDP. QUIC proporciona una conexión fiable y segura. HTTP/3 utiliza QUIC a diferencia de las versiones anteriores de HTTPS que utilizan 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 tener dos protocolos de enlace separados para TCP y TLS, lo que significa que el tiempo total para establecer una conexión se reduce. [15]

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 de manera bidireccional 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 establecen una conexión de extremo a extremo dedicada. La comunicación se logra transmitiendo información en una dirección desde el origen hasta el destino sin verificar la preparación o el estado del receptor.

Normas

Véase también

Referencias

  1. ^ Manual de ventas y servicios en red . 2003. ISBN 9781587050909.
  2. ^ Línea de comandos de Windows: El entrenador personal para Windows 8.1 Windows Server 2012 y Windows Server 2012 R2 . 2015. ISBN 9781627164139.
  3. ^ abc Kurose, JF; Ross, KW (2010). Redes informáticas: un enfoque descendente (5.ª ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
  4. ^ Clark, MP (2003). Redes de datos IP e Internet, 1.ª ed . West Sussex, Inglaterra: John Wiley & Sons Ltd.
  5. ^ [email protected] (15 de agosto de 2006). «Descripción general del protocolo UDP». Ipv6.com . Consultado el 17 de agosto de 2011 .{{cite web}}: CS1 maint: numeric names: authors list (link)
  6. ^ abcde Forouzan, BA (2000). TCP/IP: Protocol Suite, 1.ª ed . Nueva Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  7. ^ abcde J. Postel , ed. (28 de agosto de 1980). Protocolo de datagramas de usuario. IETF . doi : 10.17487/RFC0768 . STD 6. RFC 768. Estándar de Internet 6.
  8. ^ Stevens, W. Richard (1994). TCP/IP Illustrated: The protocols (TCP/IP ilustrado: los protocolos ). Vol. 1 (2.ª edición). Addison-Wesley. ISBN 978-0-20-163346-7.
  9. ^ D. Borman; S. Deering ; R. Hinden (agosto de 1999). Jumbogramas IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2675 . RFC 2675. Norma propuesta. Deja obsoleta la RFC 2147.
  10. ^ ab S. Deering ; R. Hinden (julio de 2017). Especificación del Protocolo de Internet, versión 6 (IPv6). IETF . doi : 10.17487/RFC8200 . STD 86. RFC 8200. Estándar de Internet 86. Obsoleto RFC 2460.
  11. ^ "Calcular la suma del complemento a uno de 16 bits". mathforum.org . John. 20 de marzo de 2002. Archivado desde el original ( correo electrónico ) el 17 de noviembre de 2020 . Consultado el 5 de noviembre de 2014 .
  12. ^ Especificación del Protocolo de Internet, versión 6 (IPv6). pág. 27-28. doi : 10.17487/RFC8200 . RFC 8200.
  13. ^ Especificación del Protocolo de Internet, versión 6 (IPv6). p. 23. doi : 10.17487/RFC8085 . RFC 8085.
  14. ^ "El impacto de UDP en las aplicaciones de datos". Networkperformancedaily.com. Archivado desde el original el 31 de julio de 2007. Consultado el 17 de agosto de 2011 .
  15. ^ "QUIC, un transporte de flujo multiplexado sobre UDP". chromium.org . Consultado el 17 de febrero de 2021 .

Enlaces externos