Protocolo de datagramas de usuario

UDP (Protocolo de datagramas de usuario)
Familia: Familia de protocolos de Internet
Área de operación: Transmisión
de datos sin conexión a través de Internet
UDP en la pila de protocolos TCP / IP :
solicitud DNS DHCP ...
transporte UDP
Internet IP ( IPv4 , IPv6 )
Acceso a la red Ethernet
Bus simbólico
Anillo simbólico 		FDDI ...
Estándares: RFC 768 ( 1980 )

El Protocolo de datagramas de usuario , o UDP para abreviar , es un protocolo de red mínimo y sin conexión que pertenece a la capa de transporte de la familia de protocolos de Internet . UDP permite que las aplicaciones envíen datagramas en redes informáticas basadas en IP .

El desarrollo de UDP comenzó en 1977 cuando se requería un protocolo más simple para la transmisión de voz que el anterior TCP orientado a la conexión . Se requería un protocolo que solo fuera responsable de direccionar sin asegurar la transmisión de datos, ya que esto daría lugar a retrasos en la transmisión de voz.

funcionalidad

UDP usa puertos para permitir el envío de datos al programa correcto en la computadora de destino. Para ello, cada datagrama contiene el número de puerto del servicio que va a recibir los datos. Esta extensión de la transmisión de host a host del Protocolo de Internet a la transmisión de proceso a proceso se conoce como multiplexación y demultiplexación de aplicaciones.

Además, UDP ofrece la posibilidad de una verificación de integridad mediante el envío de una suma de verificación . Esto significa que los datagramas transmitidos incorrectamente se pueden reconocer y descartar.

propiedades

UDP es un protocolo de transmisión sin conexión , no confiable y no seguro , así como desprotegido . Esto significa que no hay garantía de que llegue un paquete que se envió una vez , que los paquetes llegarán en el mismo orden en que fueron enviados o que un paquete solo llegará al destinatario una vez. Tampoco hay garantía de que los datos lleguen sin adulterar o inaccesibles a terceros. Por lo tanto, una aplicación que utiliza UDP debe ser insensible a los paquetes perdidos y sin clasificar o proporcionar las medidas correctivas adecuadas y, si es necesario, las medidas de seguridad en sí.

Dado que no es necesario establecer una conexión antes del inicio de la transferencia, uno o ambos socios pueden comenzar a intercambiar datos más rápidamente. Esto es particularmente importante en aplicaciones en las que solo es necesario intercambiar pequeñas cantidades de datos. Los protocolos simples de preguntas y respuestas, como DNS (el sistema de nombres de dominio ), utilizan principalmente UDP para la resolución de nombres con el fin de mantener baja la carga de la red y, por lo tanto, aumentar el rendimiento de los datos. Un protocolo de enlace de tres vías como con TCP (el Protocolo de control de transmisión ) para establecer la conexión generaría una sobrecarga innecesaria en este caso .

Además, la transmisión no segura también ofrece la ventaja de que las fluctuaciones de retardo de transmisión son bajas: si se pierde un paquete durante una conexión TCP, se vuelve a solicitar automáticamente. Esto lleva tiempo y, por lo tanto, el tiempo de transmisión puede fluctuar, lo que es malo para las aplicaciones multimedia. Con VoIP z. B. habría caídas repentinas, o los búferes de reproducción tendrían que agrandarse. En el caso de los servicios de comunicación sin conexión, por otro lado, los paquetes perdidos no detienen la transmisión completa, sino que solo reducen la calidad.

En teoría, el tamaño máximo de un datagrama UDP es 65 535 bytes, ya que el campo de longitud del encabezado UDP tiene 16 bits y el número más grande que se puede representar con 16 bits es 65 535 (= 2 16 -1). Sin embargo, estos grandes segmentos se transmiten fragmentados por IP. En la práctica, la longitud máxima posible de un datagrama UDP está sujeta a restricciones adicionales .

IP elimina paquetes en caso de errores de transmisión o sobrecarga. Por tanto, pueden faltar datagramas. UDP no ofrece ningún mecanismo de detección o corrección para esto, como TCP. En el caso de varias rutas posibles al destino, IP puede elegir nuevas rutas si es necesario. Esto significa que, en casos excepcionales, es posible que los datos enviados más tarde superen a los enviados antes. Además, un paquete de datos que se ha enviado una vez puede llegar al destinatario varias veces.

Datagrama UDP

Además de los datos de usuario a transmitir, también se envía otra información, que siempre está al comienzo de un mensaje UDP, en el llamado encabezado . El encabezado UDP consta de cuatro campos de datos, cada uno de los cuales tiene un tamaño de 16 bits :

un poco 0 15 dieciséis 31
Puerto de origen Puerto de destino
largo Suma de comprobación
Datos
Formato de encabezado de datagrama UDP
Puerto de origen
especifica el número de puerto del proceso de envío. Esta información es necesaria para que el destinatario pueda responder al paquete. Dado que UDP no tiene conexión, el puerto de origen es opcional y se puede establecer en el valor "0" (en el caso de que no se esperen paquetes de respuesta y solo se envíen paquetes al destinatario).
Puerto de destino
especifica qué proceso debe recibir el paquete.
Längenfeld
especifica la longitud del datagrama, que consta de los datos y el encabezado, en octetos . El valor más pequeño posible es de 8 octetos (o bytes). El campo de longitud define un límite superior teórico de 2 16 −1 = 65 535 bytes (encabezado de 8 bytes + 65 527 bytes de datos de usuario). La longitud realmente disponible de los datos del usuario se debe al protocolo IP subyacente, sin embargo, a 65.507 bytes (65.535 - encabezado UDP de 8 bytes - encabezado IP de 20 bytes) cuando se usa IPv4 y 65.487 bytes (65.535 - encabezado UDP de 8 bytes - 40 bytes) Encabezado IPv6)) cuando se utiliza IPv6 .
Campo de suma de comprobación
También se puede enviar una suma de comprobación de 16 bits . La suma de comprobación se forma utilizando el llamado pseudo encabezado , el encabezado UDP y los datos. La suma de control es opcional, pero casi siempre se usa en la práctica, si no, se establece en "0".
Campo de datos
contiene la carga útil real, también conocida como carga útil . El campo es opcional y teóricamente puede estar completamente ausente, lo que en realidad nunca ocurre en la práctica. El campo de datos siempre consta de un número par de octetos. Los octetos que quedan libres al final se rellenan con ceros.

Pseudo encabezados

El Protocolo de Internet (IP) se proporciona para la transmisión del paquete UDP . Frente al paquete UDP, este protocolo coloca otro encabezado en el que se ubican los datos requeridos por IP:

Para generar la suma de comprobación UDP, partes de este encabezado IP se transfieren a un llamado "pseudo encabezado". Solo se utiliza para generar la suma de comprobación y no se transmite.

IPv4

Con IPv4, el pseudo encabezado tiene un tamaño de 12 octetos (96 bits) y está compuesto por la dirección IP de origen (32 bits), la dirección IP de destino (32 bits), el campo en blanco de 8 bits y el ID de protocolo de 8 bits. (UDP tiene ID 17 ) y la longitud del datagrama UDP (16 bits):

un poco 0 32 64 72 80 96
Dirección IP origen Dirección IP de destino 00000000 ID de protocolo Longitud del datagrama UDP
Pseudo encabezado IPv4

IPv6

En IPv6 , el pseudo encabezado tiene un tamaño de 40 octetos (320 bits). Está compuesto de la siguiente manera:

un poco 0 128 256 288 312 320
Dirección IP origen Dirección IP de destino Longitud del paquete de la capa superior 0
(24 bits) 		Siguiente encabezado
Pseudo encabezado IPv6

Cálculo de la suma de comprobación

La suma de comprobación del remitente se calcula utilizando el siguiente algoritmo:

  1. Establezca el campo de suma de comprobación en el encabezado UDP en 0000 0000 0000 0000.
  2. Genere un número de 32 bits sin signo para la suma de comprobación, inicialícelo con ceros.
  3. Combine bytes directamente vecinos del paquete UDP en bloques de 16 bits. Si el último bloque tiene menos de 16 bits, llénelo con ceros desde el final hasta que tenga 16 bits.
  4. Guarde el resultado de agregar todos los bloques de 16 bits con acarreo en la suma de comprobación.
  5. Combine bytes directamente adyacentes del pseudo encabezado en bloques de 16 bits.
  6. Guarde el resultado de agregar estos bloques de 16 bits y la suma de comprobación anterior con acarreo en la suma de comprobación.
  7. Combine los bytes vecinos directamente de la suma de control en dos bloques de 16 bits, agréguelos y guarde el resultado con acarreo en la suma de control hasta que no haya más acarreo en la suma.
  8. Los 16 bits más significativos de la suma de comprobación de 32 bits son ahora ceros. Los bits menos significativos son la suma de comprobación real; guárdelo como un número de 16 bits sin firmar.
  9. Si este número de 16 bits no es todos unos, entonces almacene su complemento a uno en el encabezado UDP (tanto 1111 1111 1111 1111 como su complemento a uno, 0000 0000 0000 0000, simbolizan el número 0). En IPv4 UDP, 0000 0000 0000 0000 también se utiliza para indicar que no se ha calculado ninguna suma de comprobación. Los paquetes IPv6 UDP con la suma de comprobación 0000 0000 0000 0000 no son válidos ( RFC 6935 ).

El destinatario comprueba primero si el campo de suma de comprobación del paquete recibido solo consta de ceros. Si es así, puede evaluar el paquete como recibido correctamente, ya que no hay suma de comprobación. De lo contrario, aplica el algoritmo descrito anteriormente al paquete recibido y el pseudo encabezado asociado, omite el último paso y agrega la suma de verificación autocalculada a la suma de verificación recibida en el campo de suma de verificación, que corresponde a una resta debido a la representación del complemento a uno. . Si el receptor recibe 0 como resultado de la suma (o resta), evalúa los datos recibidos como los mismos que los datos enviados.

UDP-Lite

El Protocolo de datagramas de usuario ligero (UDP-Lite) de acuerdo con RFC 3828 es una variación de UDP, especialmente para la transmisión de datos donde es importante un retardo bajo, pero se pueden tolerar errores más pequeños. Este es el caso, por ejemplo, de las transmisiones de audio y vídeo en directo , que a menudo utilizan UDP como protocolo de transporte. Si un bit de un paquete de datos UDP está defectuoso, todos los datos del paquete, i. H. hasta varios miles de bits, descartados. Si, por el contrario, se utilizara el paquete con el bit defectuoso, el error sería inaudible o invisible , según el códec . El uso de UDP-Lite debería suprimir la verificación de ciertas partes de los paquetes de datos por parte de las capas inferiores, de manera efectiva solo para los paquetes UDP-Lite. A nivel de Ethernet , esto afecta la verificación CRC de los paquetes.

UDP-Lite es compatible con UDP, pero interpreta el campo de longitud como la longitud sobre la que se calcula la suma de comprobación ( cobertura de la suma de comprobación ). Un paquete UDP normal siempre corresponde a las especificaciones de UDP-Lite. Por el contrario, este no es necesariamente el caso, ya que UDP-Lite define un mayor grado de libertad. La longitud de un paquete UDP o UDP-Lite se puede calcular utilizando la información de la capa de protocolo de Internet ; la longitud de IP es la suma del tamaño del encabezado IP y el tamaño del paquete UDP. Si el encabezado IP en UDP-Lite es más largo que en el campo de longitud del encabezado UDP (-Lite), el paquete contiene datos adicionales sin verificar. Por ejemplo, un campo de longitud de ocho significa que la suma de comprobación solo se calcula utilizando el encabezado. Con el valor cero, la suma de control se calcula sobre todo el paquete. Los valores 1,…, 7 no están permitidos, i. H. el encabezado UDP-Lite siempre se incluye en la suma de comprobación. La limitación del tamaño máximo de paquete de UDP (65 535 bytes) ya no es aplicable. En este caso, la suma de comprobación puede calcularse sobre todo el paquete o, como máximo, sobre los primeros 65.535 bytes.

Especificaciones

  • Protocolo de datagramas de usuario RFC 768
  • RFC 3828 El protocolo ligero de datagramas de usuario (UDP-Lite)

Ver también

enlaces web

Evidencia individual

  1. ^ RFC 5405 - Directrices de uso de Unicast UDP.
  2. ↑ RFC 768 - Protocolo de datagramas de usuario. (Inglés, PDF: tools.ietf.org ).