Interpretación TCP-IP Volumen 1: Notas de lectura del protocolo_11
A continuación se muestra el formato de datagrama UDP encapsulado en un único datagrama IP:
UTP no proporciona confiabilidad: envía los datos pasados por la aplicación a la capa IP, pero no Se garantiza que estos datos llegarán a su destino.
Las aplicaciones deben ser conscientes de la longitud de los datagramas IP. Si se excede la MTU (Unidad de transmisión máxima) de la red, el datagrama IP debe fragmentarse. Si cada red, desde el origen hasta el destino, requiere fragmentación, entonces no solo la primera red a la que se conecta el host de envío necesita fragmentación.
La estructura del encabezado es la siguiente:
El número de puerto indica el proceso de envío y el proceso de recepción. Debido a que la capa IP ha asignado datagramas IP a TCP o UDP (según el valor del campo de protocolo en el encabezado IP), TCP ve el número de puerto TCP y UDP ve el número de puerto UDP.
El campo de longitud UDP se refiere a la longitud (en bytes) del encabezado UDP y de los datos UDP. El valor mínimo para este campo es 8 bytes (también es aceptable enviar un datagrama UDP de 0 bytes). Esta longitud UDP es redundante; la longitud del datagrama IP se refiere a la longitud completa del datagrama, por lo que la longitud del datagrama UDP es igual a la longitud del datagrama IP menos la longitud del encabezado IP.
La suma de comprobación UDP cubre el encabezado UDP y los datos UDP. Tenga en cuenta que la suma de verificación del encabezado IP solo incluye el encabezado IP ---- y no ningún dato en el datagrama IP.
Tanto UDP como TCP tienen sumas de verificación al principio, que cubren sus encabezados y datos. La suma de comprobación UDP es opcional, mientras que la suma de comprobación TCP es obligatoria.
Aunque el cálculo básico de la suma de verificación UDP es similar al cálculo de la suma de verificación del encabezado IP que presentamos en la Sección 3 (la suma recíproca binaria de palabras de 16 bits), existen algunas diferencias entre ellos. . En primer lugar, los datagramas UDP pueden tener un número impar de bytes, pero el algoritmo de suma de comprobación suma palabras de 16 bits. La solución es agregar bytes de relleno 0 al final si es necesario; esto solo se usa para cálculos de suma de verificación (es decir, los bytes de relleno que se pueden agregar no se transmiten).
Si el remitente no calcula una suma de verificación y el receptor detecta un error en la suma de verificación, el datagrama UDP se descarta silenciosamente. No se genera ningún mensaje de error (esto también se hace cuando la capa IP detecta un error en la suma de comprobación inicial de IP).
Una suma de comprobación UDP es una suma de comprobación de un extremo a otro. Lo calcula el remitente y luego lo verifica el receptor. Su propósito es detectar cualquier cambio en los encabezados y datos UDP que ocurren entre el remitente y el receptor.
La capa de red física suele limitar la longitud máxima de cada trama de datos enviada. Cuando la capa IP recibe un datagrama IP para enviar, determina a qué interfaz local (ruta) enviar los datos y consulta esa interfaz para obtener su MTU. Puede producirse fragmentación en el host de envío original o en los enrutadores intermedios.
Después de fragmentar el datagrama IP, solo se reensamblará cuando llegue al destino (el reensamblaje aquí es diferente de otros protocolos de red, que requieren el reensamblaje en la siguiente parada en lugar del reensamblaje del destino final). . El reensamblaje lo realiza la capa IP en el destino para que el proceso de fragmentación y reensamblaje sea transparente para la capa de transporte (TCP y UDP). Un datagrama que ha sido fragmentado puede volver a fragmentarse y los datos contenidos en el encabezado IP proporcionan información suficiente para la fragmentación y el reensamblaje.
El campo de identificación contiene un valor único para cada datagrama IP enviado por el remitente. A medida que el datagrama se fragmenta, este valor se copia en cada fragmento. Un bit en el campo de banderas significa "más fragmentos".
Cada fragmento que compone el datagrama, excepto el último datagrama, tiene el bit 1 establecido. El campo de desplazamiento del fragmento se refiere a la posición de desplazamiento del fragmento desde el comienzo del datagrama original. Además, cuando se fragmenta un datagrama, el valor de longitud total de cada fragmento se cambia al valor de longitud de ese fragmento.
Finalmente, hay un bit en el campo de banderas llamado bit "sin fragmentación". Si este bit se establece en 1, IP no fragmentará el datagrama. En su lugar, descarta el datagrama y envía un mensaje de error ICMP ("Se requiere fragmentación, pero no se establece ningún bit de fragmentación") a la fuente.
Cuando se fragmenta un datagrama IP, cada fragmento se convierte en un paquete con su propio encabezado IP y es independiente de otros paquetes en el enrutamiento. Por lo tanto, estos fragmentos del datagrama pueden llegar desordenados al destino, pero hay suficiente información en el encabezado IP para permitir que el extremo receptor ensamble estos fragmentos de datagrama correctamente.
Hay un problema con la fragmentación de IP: perder un fragmento de datos requiere retransmitir el datagrama completo.
La razón es que la capa IP no tiene un mecanismo de retransmisión de tiempo de espera: los tiempos de espera y las retransmisiones son responsabilidad de las capas superiores. Cuando se pierde un fragmento de un segmento TCP, un tiempo de espera de TCP retransmite todo el segmento TCP, lo que equivale a un datagrama IP. No hay forma de retransmitir fragmentos de datagramas desde dentro del datagrama.
El uso de UDP puede conducir fácilmente a la fragmentación de IP. El siguiente es un ejemplo de fragmentación UDP:
Otra situación en la que verá un error de ICMP inalcanzable es cuando el enrutador recibe un datagrama que necesita ser fragmentado y el indicador No fragmentar (DF). Un programa puede utilizar este error si necesita determinar la MTU mínima en la ruta a un destino ----, lo que se denomina mecanismo de descubrimiento de MTU de ruta.
El formato del mensaje de error ICMP inalcanzable en este caso es el siguiente:
Si el enrutador no proporciona este nuevo formato de mensaje de error ICMP, la MTU del siguiente salto es 0.
Teóricamente, la longitud máxima de un datagrama IP es de 65.535 bytes, que está limitada por el campo de longitud total de 16 bits del encabezado IP. Excluyendo el encabezado IP de 20 bytes y el encabezado UDP de 8 bytes, la longitud máxima de los datos de usuario en un datagrama UDP es 65507 bytes. Sin embargo, la mayoría de las implementaciones proporcionan una longitud inferior a este valor máximo.
Existen dos limitaciones:
1. Las aplicaciones pueden estar limitadas por las interfaces de sus programas. La API de socket proporciona una función a la que una aplicación puede llamar para establecer la longitud de los buffers de recepción y envío. Para los sockets UDP, esta longitud está directamente relacionada con la longitud máxima del datagrama UDP que la aplicación puede leer y escribir.
2. La segunda limitación proviene de la implementación del kernel de TCP/IP. Puede haber alguna característica de implementación (o error) que haga que la longitud del datagrama IP sea inferior a 65535 bytes.
También podemos utilizar UDP para evitar errores de "supresión de fuente" de ICMP. Este error ocurre cuando un sistema (enrutador o host) acepta datagramas más rápido de lo que puede procesarlos.
Este mensaje de error ocurre cuando los datos que se transmiten a través de Ethernet necesitan pasar por un enlace SLIP. Dado que un enlace SLIP es aproximadamente una milésima parte más rápido que Ethernet, puede agotar fácilmente su caché.
En este ejemplo, la aplicación no recibió la señal de error de supresión de origen o la recibió pero la ignoró. Como resultado, las implementaciones BSD normalmente ignoran los mensajes de supresión de origen recibidos si se utiliza el protocolo UDP. Esto se debe en parte a que el proceso que provocó la supresión de la fuente puede haber finalizado cuando recibe el mensaje de error de supresión de la fuente.
El hecho de que no se manejen los errores de supresión de origen ICMP sugiere que UDP es un protocolo poco confiable que solo controla el control de flujo de un extremo a otro. A menos que exista algún mecanismo de reconocimiento integrado en la aplicación, el remitente no tiene idea de si el receptor ha recibido los datos.
El cliente envía un datagrama UDP. El encabezado IP contiene la dirección IP de origen y la dirección IP de destino, y el encabezado UDP contiene el número de puerto UDP de origen y el número de puerto UDP de destino.
Cuando una aplicación recibe un datagrama UDP, el sistema operativo debe decirle quién envió la información, es decir, la dirección IP de origen y el número de puerto.
Esta característica permite que los servidores UDP interactivos manejen múltiples clientes. Cada cliente que envía una solicitud recibe una respuesta.
Algunas aplicaciones necesitan conocer el destinatario del datagrama, es decir, la dirección de destino. Esto requiere que el sistema operativo proporcione a la aplicación la dirección IP de destino del datagrama UDP recibido.
La mayoría de los servidores UDP son servidores interactivos, con un único proceso de servidor que maneja todas las solicitudes de los clientes en un único puerto UDP.
Normalmente, cada puerto UDP utilizado por un programa está asociado a una cola de entrada de tamaño limitado. Esto significa que las solicitudes de diferentes clientes ingresarán automáticamente a la cola UDP si llegan aproximadamente al mismo tiempo. Los datagramas UDP entrantes se entregan a la aplicación en el orden en que fueron recibidos.
Por lo tanto, el desbordamiento de la cola que conduce a la pérdida de datagramas UDP es inevitable. La aplicación no sabe cuándo se desborda su cola de entrada, por lo que sólo puede permitir que UDP elimine el exceso de datagramas. Al mismo tiempo, no habrá ningún mensaje informándole al cliente que su datagrama ha sido descartado.
La mayoría de los servidores UDP crean direcciones IP locales comodín para los puntos finales UDP. Esto significa que si un datagrama UFP entrante está destinado a un puerto de servidor, cualquier interfaz local puede recibir el datagrama.
La mayoría de los sistemas permiten que los puntos finales UDP limiten las direcciones remotas.
Los siguientes son los tres tipos de enlaces de direcciones que puede crear el propio servidor UDP:
En todos los casos, lport se refiere al número de puerto del nombre del servidor y localIP debe ser la de la dirección IP de la interfaz local. El orden de estas tres filas en la tabla es el orden utilizado por el módulo UDP al decidir qué punto final usar para recibir un datagrama. Las direcciones más seguras (primera línea) coinciden primero y las direcciones menos seguras (direcciones IP con dos asteriscos en la última línea) coinciden en último lugar.
Si un datagrama UDP llega a una dirección IP de destino que es una dirección de difusión o multidifusión, y hay varios puntos finales en esa dirección IP y número de puerto de destino, se transmitirá una copia del datagrama a cada uno de ellos. punto final (la dirección IP local del punto final puede contener un asterisco, que coincide con cualquier dirección IP de destino). Sin embargo, si un datagrama UDP llega a una dirección de unidifusión, solo se transmite un datagrama a uno de los puntos finales. La elección de qué punto final transmitir datos depende de cada implementación diferente del sistema.
UDP es un protocolo sencillo. El servicio que quiere brindar al proceso del usuario está por encima de la capa IP, que incluye un número de puerto y una suma de verificación opcional, que usamos para verificar la suma de verificación y comprender cuánto tiempo está fragmentado el UDP.
Cuando un sistema recibe datagramas IP más rápido de lo que puede procesarlos, el sistema puede enviar un mensaje de error de supresión de fuente ICMP. Estos errores de ICMP pueden ocurrir fácilmente cuando se utiliza UDP.