¿En qué se diferencia el protocolo tcp de udp? ¿Cuál es la diferencia entre TCP y UDP, en términos simples? Protocolo ARP. Solicitud

UDP (Protocolo de datagramas de usuario) es protocolo de transporte para la transmisión de datos a través de redes IP sin establecer una conexión. Él es uno de los más protocolos simples capa de transporte del modelo OSI. Su ID de IP es 0x11.

UDP se usa comúnmente en aplicaciones como transmisión de video y juegos de computadora, donde la pérdida de paquetes es aceptable y volver a intentar una solicitud es difícil o no está justificado, o en aplicaciones de desafío-respuesta (como consultas DNS) donde crear una conexión requiere más recursos que reenviar. De hecho Funciones UDP se reducen a operaciones de multiplexación y demultiplexación, así como a una simple comprobación de errores en los datos. Así, cuando se utiliza U DP, la aplicación se comunica casi directamente con el protocolo de capa de red IP.

UDP recibe mensajes de la capa de aplicación, agrega campos de puerto de origen y destino para que el receptor los demultiplexe, así como otros dos campos especiales, y pasa el segmento resultante a la capa de red. La capa de red envuelve el segmento en un datagrama y lo reenvía "si es posible" al host de destino. Si este último recibe correctamente el segmento, UDP reenvía los datos del segmento utilizando el campo de número de puerto de destino. el proceso correcto. Por lo tanto, se dice que UDP realiza transferencias de datos sin conexión.

Un ejemplo de protocolo de capa de aplicación que utiliza servicios de protocolo UDP es DNS. Cuando una aplicación DNS genera una consulta, crea un mensaje DNS y lo pasa al protocolo UDP.

Comparación de protocolos UDP y TCP.

Si una aplicación requiere confirmación de la entrega del mensaje, utiliza el protocolo tcp. TCP divide el mensaje en fragmentos tamaño más pequeño, llamados segmentos. Estos segmentos se numeran secuencialmente y se pasan al protocolo IP, que luego ensambla los paquetes. TCP realiza un seguimiento de la cantidad de segmentos enviados a un host en particular por una aplicación en particular. Si el remitente no recibe la confirmación dentro de cierto periodo Al mismo tiempo, TCP considera estos segmentos como perdidos y los reenvía. Sólo se reenvía la parte perdida del mensaje, no el mensaje completo.

El protocolo TCP en el nodo receptor es responsable de volver a ensamblar los segmentos del mensaje y transmitirlos a la aplicación adecuada.

FTP y HTTP son ejemplos de aplicaciones que utilizan TCP para entregar datos.

Protocolo UDP realiza entrega de datos no garantizada y no solicita confirmación al destinatario. El protocolo UDP es más preferible para la transmisión transmisión de audio, comunicaciones de vídeo y voz basadas en el Protocolo de Internet (VoIP). Confirmar la entrega solo ralentizará el proceso de transferencia de datos y no se recomienda volver a realizar la entrega. Un ejemplo del uso del protocolo UDP es la radio por Internet.

protocolo ARP. Solicitud.

ARP(Inglés) Protocolo de resolución de direcciones- protocolo de determinación de dirección) - utilizado en redes informáticas protocolo nivel bajo, diseñado para determinar la dirección de la capa de enlace a partir de una dirección de capa de red conocida. Este protocolo se ha generalizado más debido a la ubicuidad de las redes IP construidas sobre Ethernet, ya que en casi el 100% de los casos se utiliza ARP con esta combinación. La descripción del protocolo se publicó en noviembre de 1982 en RFC 826. ARP fue diseñado para el caso de transmitir paquetes IP a través de un segmento Ethernet. Al mismo tiempo, el principio general propuesto para ARP puede haberse utilizado para otros tipos de redes.

Existen los siguientes tipos de mensajes ARP: solicitud ARP y respuesta ARP. El sistema de envío utiliza una solicitud ARP para solicitar dirección física sistema receptor. La respuesta (la dirección física del host de destino) viene en forma de respuesta ARP.

Antes de transmitir un paquete de capa de red a través de un segmento Ethernet, pila de red comprueba el caché ARP para ver si ya está registrado en él información necesaria sobre el nodo receptor. Si no existe dicha entrada en la caché ARP, se realiza una solicitud de transmisión ARP. Esta consulta de dispositivos en la red tiene el siguiente significado: “¿Alguien sabe la dirección física del dispositivo que tiene la siguiente dirección IP?” Cuando el destinatario con esta dirección IP reciba este paquete, tendrá que responder: “Sí, esta es mi dirección IP. Mi dirección física es:…” Luego, el remitente actualizará su caché ARP y podrá transmitir la información al destinatario.

Las entradas de la caché ARP pueden ser estáticas o dinámicas. El ejemplo anterior describe una entrada de caché dinámica. También puede crear entradas estáticas en la tabla ARP.

ARP se desarrolló originalmente no sólo para el protocolo IP, sino que ahora se utiliza principalmente para asignar direcciones IP y MAC.

Principio de funcionamiento

El nodo que necesita asignar la dirección IP a dirección local, genera una solicitud ARP, la inserta en una trama de protocolo de capa de enlace, indicando en ella una dirección IP conocida y transmite la solicitud.

Todos los hosts de la red local reciben una solicitud ARP y comparan la dirección IP allí especificada con la suya.

Si coinciden, el nodo genera una respuesta ARP, en la que indica su dirección IP y su dirección local y la envía ya dirigida, ya que en la solicitud ARP el remitente indica su dirección local.

Me gusta mucho toda la serie de artículos y además siempre quise probarme como traductor. Tal vez, desarrolladores experimentados El artículo parecerá demasiado obvio, pero me parece que será útil en cualquier caso.

Hola, mi nombre es Glenn Fiedler y le doy la bienvenida al primer artículo de mi libro en línea, Programación de redes para desarrolladores de juegos.

En este artículo comenzaremos con lo más aspectos basicos programación de red- recibir y transmitir datos a través de la red. Recibir y transmitir datos es la principal y más parte simple de toda la gama de tareas que realizan los programadores de redes, pero a menudo es difícil determinar qué camino es mejor tomar. Presta suficiente atención a esta parte: si tienes un malentendido, ¡puede tener consecuencias nefastas para tu juego multijugador más adelante!

Probablemente ya haya oído algo sobre los sockets y quizás sepa que vienen en dos tipos principales: TCP y UDP. Lo primero que debes decidir al desarrollar un juego multijugador es qué tipo de sockets usar: ¿TCP, UDP o ambos?

La elección del tipo de socket depende completamente del género del juego que estés desarrollando. EN este ciclo artículos, asumiré que estás escribiendo un juego de acción, como Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress, etc.

Ahora analizaremos más de cerca las propiedades de cada tipo de enchufe (teniendo en cuenta que estamos desarrollando un juego de estilo acción) y profundizaremos un poco más en los detalles de cómo funciona Internet. Después de una revisión detallada opción correcta¡será obvio!

TCP significa "protocolo de control de transmisión" e IP significa "protocolo de Internet". Juntos sustentan casi todo lo que usted hace en línea, desde la navegación web hasta IRC y las comunicaciones por correo electrónico, todo funcionando en TCP/IP.

Si alguna vez ha utilizado sockets TCP, debe saber que TCP es un protocolo que utiliza el principio de una conexión confiable. Esto significa que establece una conexión entre dos computadoras y luego envía datos entre ellas, tal como escribiría información en un archivo en una computadora y la leería del mismo archivo en otra.

En este caso, la conexión se considera confiable y consistente, es decir, se garantiza que toda la información que envía llegará al destinatario en el mismo orden en que fue enviada. También conexión TCP Puede considerarse un flujo continuo de datos: el propio protocolo se encarga de dividir los datos en paquetes y enviarlos a través de la red.

Una vez más: todo es tan sencillo como escribir o leer un archivo de forma normal. ¡Elemental, Watson!

Pero esta facilidad de uso es completamente diferente de lo que realmente sucede "bajo el capó", en un nivel inferior: el nivel del protocolo IP.

En este nivel no existe el concepto de conexión; en cambio, paquetes individuales transmitido de una computadora a otra. Puedes pensar en este proceso como pasar una nota de una persona a otra en una habitación llena de gente: al final la nota llega a la persona adecuada, pero al mismo tiempo pasa por muchas manos.

Sin embargo, no hay garantía de que la nota llegue al destinatario. El remitente simplemente envía una nota con la esperanza de que llegue, pero ni siquiera sabe si el mensaje ha llegado o no, hasta que el destinatario decide responder.
Naturalmente, en realidad todo es un poco más complicado, ya que el ordenador emisor no conoce la secuencia exacta de ordenadores de la red a través de los cuales se debe transmitir el paquete para que llegue lo más rápido posible. A veces, IP transmite múltiples copias del mismo paquete, que pueden tomar caminos diferentes para llegar al destino y es probable que lleguen en momentos diferentes.

¿Qué pasa si queremos transferir información entre computadoras no en un estilo de lectura/escritura de archivos, sino enviando y recibiendo paquetes individuales directamente?

Bueno, podemos hacer esto usando UDP. UDP significa "protocolo de datagramas de usuario" y se ejecuta sobre IP (como TCP), pero en lugar de agregar una gran cantidad de funciones, es solo un pequeño complemento a IP.

Usando UDP, podemos enviar un paquete a una dirección IP específica (por ejemplo, 112.140.20.10) y a un puerto (por ejemplo, 52423), y se transmitirá de computadora a computadora hasta que llegue a su destino (o se pierda en el camino). forma).

Al mismo tiempo, en el lado del receptor simplemente nos sentamos y esperamos, escuchando puerto específico(52423 en nuestro caso), y cuando llega un paquete de alguien (recordemos que no se utilizan conexiones), recibimos una notificación sobre esto con la dirección y puerto de la computadora que envía, el tamaño del paquete, y luego podemos lea los datos de este paquete.

El protocolo UDP no garantiza la entrega de datos. En la práctica, la mayoría de los paquetes, por supuesto, llegan, pero siempre hay una pérdida de alrededor del 1-5% y, a veces, hay períodos de tiempo en los que los paquetes no llegan (recuerde que entre el remitente y el destinatario puede haber haber miles de computadoras, en cualquiera de las cuales puede fallar o averiarse).

Además, UDP no garantiza el orden en que se entregan los paquetes. Puede enviar cinco paquetes en orden (1, 2, 3, 4, 5), pero es posible que lleguen en un orden completamente diferente (por ejemplo, 3, 1, 2, 5, 4). Nuevamente, en la práctica, lo más probable es que lleguen llegar V en el orden correcto en la mayoría de los casos, ¡pero no puedes confiar en ello!

Finalmente, aunque UDP no aporta mucho a IP, sí garantiza una cosa. Si reenvía un paquete, llegará completo o no llegará en absoluto. Por lo tanto, si envía un paquete de 256 bytes a otra computadora, esta no puede recibir solo los primeros 100 bytes del paquete; debe recibir los 256 bytes. Esto es realmente lo único que garantiza el protocolo UDP: todo lo demás recae sobre sus hombros.

Entonces debemos decidir si usar TCP o Conectores UDP? Echemos un vistazo a sus propiedades:

• Utiliza el principio de conexión.
• Garantiza la entrega y el tiempo de entrega.
• Divide automáticamente la información en paquetes.
• Garantiza que los datos no se envíen con demasiada intensidad (control del flujo de datos)
• Fácil de usar, como escribir/leer desde un archivo

UDP:

• No utiliza el principio de conexión; deberá implementarlo manualmente
• No garantiza la entrega y el orden de entrega de los paquetes: ¡pueden llegar en el orden incorrecto, con duplicados o no llegar en absoluto!
• Debe dividir manualmente los datos en paquetes y enviarlos.
• Debe tener cuidado de no enviar datos con demasiada intensidad.
• Si se pierde un paquete, debe rastrearlo de alguna manera y, si es necesario, reenviarlo

Con tal lista, la solución parece obvia: TCP implementa todas las funciones que necesitamos y es más fácil de usar, mientras que usar UDP promete hemorroides al escribir todo manualmente, desde cero. Entonces usamos TCP, ¿verdad?

Pero no.

Usar TCP es probablemente el peor error que puedes cometer al desarrollar un juego multijugador. Para entender por qué, veamos qué hace que TCP sea tan fácil de usar.

Cómo funciona TCP

Tanto TCP como UDP funcionan sobre IP, pero en realidad son completamente diferentes. UDP se comporta de manera muy similar a IP, mientras que TCP abstrae al usuario de todos los problemas de paquetes, haciendo que la interacción con él sea similar a leer/escribir en un archivo.

Entonces, ¿cómo lo hace?

En primer lugar, TCP utiliza una abstracción de flujo de datos: simplemente puede escribir bytes de datos en ese flujo y TCP se asegurará de que llegue a su destino. Debido a que IP transmite datos en paquetes y TCP se ejecuta sobre IP, TCP debe dividir el flujo de entrada del usuario en paquetes individuales. Entonces, dentro de TCP, cierta lógica recopila datos en una cola y, cuando hay suficientes, forma un paquete y lo envía al destino.

Este comportamiento podría suponer un problema para nuestro juego multijugador si necesitamos transferir paquetes muy pequeños. Puede suceder que TCP decida no transmitir nuestros datos hasta que haya acumulado lo suficiente como para formar un paquete de cierto tamaño (digamos, más de cien bytes). Y este es un gran problema, porque es necesario transferir datos desde el cliente (pulsaciones de teclas del reproductor) al servidor lo más rápido posible, y si hay retrasos debido al almacenamiento en búfer de datos por parte del protocolo, entonces para el reproductor en el lado del cliente. el juego no será el más agradable. En este caso, la actualización de los objetos del juego se producirá con retraso y en raras ocasiones, mientras que necesitamos actualizar los objetos a tiempo y con frecuencia.

TCP tiene una opción para solucionar este problema: "TCP_NODELAY". Le dice al protocolo que no espere a que los datos se acumulen en la cola de envío, sino que los envíe inmediatamente.

Desafortunadamente, incluso con esta opción instalada, TCP tiene muchos problemas cuando se usa en juegos de red.

La raíz de todos los problemas radica en la forma en que TCP maneja los paquetes perdidos o desordenados, creando la ilusión de una conexión confiable y consistente.

Cómo TCP garantiza la confiabilidad de la conexión

En transmisión TCP divide el flujo de datos en paquetes individuales, los envía a través de la red utilizando el protocolo IP no confiable y luego los reconstruye desde la computadora receptora paquetes recibidos flujo original.

¿Pero qué pasa si uno de los paquetes no llega? ¿O si los paquetes llegan desordenados o duplicados?

Sin profundizar demasiado en los detalles de cómo funciona TCP (y este es un tema realmente muy complejo; puede leerlo en TCP/IP ilustrado), el proceso se ve así: TCP envía un paquete, determina que el paquete no llegó y reenvía el mismo paquete al destinatario. Los paquetes duplicados se eliminan por parte del destinatario y los paquetes que llegan desordenados se reordenan para que todo esté como debe ser: de manera confiable y en orden.

El problema es que cuando TCP “sincroniza” el flujo de datos de esta manera, si se pierde un paquete, la transmisión se detiene hasta que el paquete perdido se reenvía (y se recibe en el destino). Si llegan nuevos datos mientras espera, se pondrán en cola y no podrá leerlos hasta que llegue el paquete perdido. ¿Cuánto tiempo se tarda en reenviar un paquete? Se necesita al menos el tiempo de ida y vuelta del paquete (cuando TCP determina qué paquete reenviar), más el tiempo para volver a entregar el paquete perdido. Entonces, si el ping entre computadoras es de 125 ms, retransmisión El paquete tardará aproximadamente un quinto de segundo y, en el peor de los casos, hasta medio segundo (imagínese si de repente también se pierde el paquete recién enviado). ¡Veseluja!

Por qué nunca deberías usar TCP para juegos multijugador

El problema con el uso de TCP en juegos en línea es que, a diferencia de los navegadores, correo electrónico y otras aplicaciones, los juegos dependen de la interacción en tiempo real. Para muchos aspectos del juego, como las teclas presionadas por el usuario y la posición de los jugadores en el juego, no importa lo que sucedió hace un segundo, sino solo el estado más actual. mundo del juego.

Veamos un ejemplo sencillo de un juego multijugador, como un juego de disparos en 3D. parte de la red El juego está estructurado de manera muy simple: en cada iteración del ciclo del juego, el cliente envía al servidor una descripción de todas las acciones del jugador (teclas presionadas, posición del mouse, etc.), y en cada iteración el servidor procesa estos datos, actualiza el modelo. del mundo del juego y envía las posiciones actuales de los objetos al mundo del cliente para que dibuje un nuevo marco para el jugador.

Entonces, en nuestro juego, si un paquete se pierde mientras se transmite a través de la red, el juego se detiene y espera hasta que el paquete se vuelva a entregar. En el lado del cliente, los objetos del juego se congelan y en el servidor, los jugadores tampoco pueden moverse ni disparar porque el servidor no puede aceptar nuevos paquetes. Cuando finalmente llega el paquete perdido, contiene información obsoleta que ya no es relevante. Además, después de esto, también llegan todos aquellos paquetes que se han acumulado en la cola durante el tiempo de espera, y todos deben procesarse en una iteración del bucle. ¡Completa confusión!

Desafortunadamente, no hay manera de cambiar este comportamiento de TCP, y no es necesario hacerlo, ya que ese es el significado de TCP. Esta es una necesidad para que la transmisión de datos a través de Internet sea un flujo de datos confiable y consistente.
Pero no necesitamos un flujo de datos confiable y consistente.

Necesitamos que los datos lleguen del cliente al servidor lo más rápido posible y no queremos esperar a que se reenvíen.
Es por eso que nunca debes usar TCP para juegos multijugador.

¡Pero espera! ¿Por qué no puedo utilizar UDP y TCP juntos?

Para los datos del juego en tiempo real, como los clics de los usuarios y el estado del mundo del juego, solo son importantes los datos más actuales, pero para otros tipos de datos, como los conjuntos de comandos enviados de una computadora a otra, la confiabilidad y coherencia del canal. puede ser muy importante.

Por supuesto, es tentador utilizar UDP para la entrada del usuario y datos del estado mundial, y TCP para los datos cuya entrega se debe garantizar. Quizás incluso estés pensando que podrías crear múltiples “hilos” de comandos, por ejemplo, uno para cargar niveles y otro para comandos de IA. Estás pensando: "No necesito equipos de IA esperando en fila si se pierde el paquete de datos para cargar un nivel, ¡porque no tienen ninguna relación!". En este caso, tiene razón y puede decidir crear un socket TCP para cada flujo de comando.

A primera vista, esto gran idea. Pero el problema es que, dado que TCP y UDP se ejecutan sobre IP, los paquetes de ambos protocolos se afectarán entre sí, ya en el nivel de IP. Cómo se manifestará exactamente este efecto es una cuestión muy compleja y está relacionada con los mecanismos de confiabilidad en TCP. Pero, en cualquier caso, tenga en cuenta que el uso de TCP suele provocar una mayor pérdida de paquetes UDP. Si quieres saber más sobre esto, puedes leer

protocolo UDP

Protocolo de datagramas de usuario (UDP) es un protocolo simple, sin conexión y orientado a datagramas que proporciona un servicio de transporte rápido, pero no necesariamente confiable. Admite interacciones de uno a muchos y, por lo tanto, se utiliza a menudo para la transmisión de datagramas de difusión y multidifusión.

El Protocolo de Internet (IP) es el protocolo principal de Internet. El Protocolo de control de transmisión (TCP) y UDP son protocolos de capa de transporte creados sobre un protocolo subyacente.

TCP/IP es un conjunto de protocolos, también llamado Conjunto de Protocolos de Internet, que consta de cuatro capas. Recuerde que TCP/IP no es sólo un protocolo, sino una familia o conjunto de protocolos que consta de otros protocolos de nivel inferior como IP, TCP y UDP. UDP se encuentra en la capa de transporte encima de IP (protocolo de capa de red). La capa de transporte proporciona comunicación entre redes a través de puertas de enlace. Utiliza direcciones IP para enviar paquetes de datos a través de Internet u otra red utilizando una variedad de controladores de dispositivos.

Antes de comenzar a aprender cómo funciona UDP, veamos cierta terminología básica que necesita conocer bien. A continuación definiremos brevemente los principales términos asociados a UDP:

Paquetes

En las comunicaciones de datos, un paquete es una secuencia de dígitos binarios que representan datos y señales de control que se transmiten y conmutan a través del host. Dentro del paquete, esta información se encuentra de acuerdo con un formato especial.

Datagramas

Un datagrama es un paquete de datos único e independiente que transporta suficiente información para viajar desde el origen al destino, por lo que no se requiere tráfico adicional entre el origen, el destino y la red de transporte.

MTU (máximo Unidad de transmisión)

MTU caracteriza capa de enlace y corresponde al número máximo de bytes que se pueden transmitir en un paquete. En otras palabras, la MTU es el paquete más grande que puede transportar un entorno de red determinado. Por ejemplo, Ethernet tiene una MTU fija de 1500 bytes. En UDP, si el tamaño del datagrama es mayor que la MTU, el protocolo IP realiza la fragmentación dividiendo el datagrama en partes más pequeñas (fragmentos) de modo que cada fragmento sea menor que la MTU.

Puertos

Para hacer coincidir los datos entrantes con un proceso específico que se ejecuta en una computadora, UDP utiliza puertos. UDP reenvía el paquete a la ubicación adecuada utilizando el número de puerto especificado en el encabezado UDP del datagrama. Los puertos están representados por números de 16 bits y por lo tanto toman valores que van de 0 a 65.535. Los puertos, que también se denominan puntos finales de conexión lógica, se dividen en tres categorías:

Puertos conocidos: de 0 a 1023

Puertos registrados: de 1024 a 49151

Puertos dinámicos/privados: 49152 a 65535

Tenga en cuenta que los puertos UDP pueden recibir más de un mensaje a la vez. En algunos casos, los servicios TCP y UDP pueden utilizar los mismos números de puerto, como 7 (Echo) o 23 (Telnet).

UDP utiliza los siguientes puertos conocidos:

La lista de puertos UDP y TCP la mantiene la IANA (Autoridad de Números Asignados de Internet).

direcciones IP

Un datagrama IP consta de direcciones IP de origen y destino de 32 bits. La dirección IP de destino especifica el punto final del datagrama UDP y la dirección IP de origen se utiliza para obtener información sobre quién envió el mensaje. En el destino, los paquetes se filtran y aquellos cuyas direcciones de origen no están incluidas en el conjunto válido de direcciones se descartan sin notificar al remitente.

Una dirección IP de unidifusión identifica de forma única un host en una red, mientras que una dirección IP de multidifusión identifica grupo específico direcciones en la red. Las direcciones IP de transmisión son recibidas y procesadas por todos los hosts de una red local o de una subred específica.

TTL

El valor de tiempo de vida o TTL (tiempo de vida) le permite establecer un límite superior en la cantidad de enrutadores a través de los cuales puede pasar un datagrama. El valor TTL evita que los paquetes lleguen bucles sin fin. Lo inicializa el remitente y lo disminuye en uno cada enrutador que procesa el datagrama. Cuando el valor TTL llega a cero, el datagrama se descarta.

correo grupal

La multidifusión es un método abierto basado en estándares para distribuir información idéntica a múltiples usuarios simultáneamente. La multidifusión es la característica principal del protocolo UDP; no es posible para el protocolo TCP. La multidifusión permite la interacción de uno a muchos, por ejemplo haciendo posibles usos como el envío de noticias y correo a múltiples destinatarios, radio por Internet o programas de demostración en tiempo real. El envío en grupo no carga la red tanto como transmisión, ya que los datos se envían a varios usuarios a la vez:

Cómo funciona UDP

Cuando una aplicación basada en UDP envía datos a otro host de la red, UDP les agrega un encabezado de ocho bits que contiene los números de puerto de origen y destino, la longitud total de los datos y una suma de verificación. IP agrega su encabezado encima del datagrama UDP, formando un datagrama IP:

La figura anterior indica que la longitud total del encabezado UDP es de ocho bytes. Teóricamente tamaño máximo Un datagrama IP tiene 65.535 bytes. Con 20 bytes de encabezado IP y 8 bytes de encabezado UDP, la longitud de los datos del usuario puede ser de hasta 65 507 bytes. Sin embargo, la mayoría de los programas funcionan con tamaños de datos más pequeños. Por lo tanto, para la mayoría de las aplicaciones, la longitud predeterminada es de aproximadamente 8192 bytes, ya que esta es la cantidad de datos que la red lee y escribe. sistema de archivos(NFS). Puede configurar los tamaños de los buffers de entrada y salida.

La suma de comprobación es necesaria para comprobar si los datos se entregaron correctamente a su destino o si estaban dañados. Cubre tanto el encabezado UDP como los datos. Se utiliza un byte de relleno si el número total de octetos del datagrama es impar. Si la suma de verificación recibida es cero, el destinatario informa un error suma de control y descarta el datagrama. Aunque una suma de comprobación es una característica opcional, siempre se recomienda incluirla.

En el siguiente paso, la capa IP agrega 20 bytes de encabezado, que incluye el TTL, las direcciones IP de origen y destino, y otra información. Esta acción se llama encapsulación de IP.

Como se mencionó anteriormente, el tamaño máximo de paquete es 65.507 bytes. Si el paquete es más grande que el predeterminado Tamaño de MTU, luego la capa IP divide el paquete en segmentos. Estos segmentos se denominan fragmentos y el proceso de dividir los datos en segmentos se llama fragmentación. El encabezado IP contiene toda la información del fragmento.

Cuando la aplicación emisora ​​"arroja" un datagrama a la red, se enruta a la dirección IP de destino especificada en el encabezado IP. Al pasar por un enrutador, el valor del tiempo de vida (TTL) en el encabezado IP se reduce en uno.

Cuando un datagrama llega a un destino y puerto determinados, la capa IP verifica su encabezado para ver si el datagrama está fragmentado. Si es así, el datagrama se ensambla de acuerdo con la información del encabezado. Finalmente, la capa de aplicación recupera los datos filtrados eliminando el encabezado.

Desventajas de UDP

En comparación con TCP, UDP tiene las siguientes desventajas:

Sin señales de reconocimiento. Antes de enviar un paquete UDP, el lado emisor no intercambia señales de protocolo de enlace con el lado receptor. Por lo tanto, el remitente no tiene forma de saber si el datagrama ha llegado al sistema de destino. Como resultado, UDP no puede garantizar que los datos realmente se entreguen al destino (por ejemplo, si el sistema o la red final no funciona).

Por el contrario, TCP está orientado a la conexión y permite la comunicación entre hosts conectados a la red mediante paquetes. TCP utiliza apretones de manos para verificar que los datos se hayan transportado correctamente.

Usando sesiones. La naturaleza orientada a la conexión de TCP está respaldada por sesiones entre hosts. TCP utiliza un identificador de sesión para realizar un seguimiento de las conexiones entre dos hosts. UDP no admite sesiones debido a su naturaleza sin conexión.

Fiabilidad. UDP no garantiza que solo se entregará una copia de los datos al destinatario. para enviar sistema final gran cantidad de datos, UDP los divide en partes pequeñas. UDP no garantiza que estas piezas se entregarán a su destino en el mismo orden en que fueron creadas en origen. Por el contrario, TCP utiliza números de puerto junto con números de serie y confirmaciones enviadas periódicamente para garantizar la entrega ordenada de los datos.

Seguridad. TCP es más seguro que UDP. En muchas organizaciones, los firewalls y enrutadores no permiten el paso de paquetes UDP. Esto se debe a que los piratas informáticos pueden aprovechar los puertos UDP sin realizar conexiones explícitas.

control de flujo. UDP no tiene control de flujo y, como resultado, una aplicación UDP mal diseñada puede consumir una parte importante del ancho de banda de la red.

Beneficios de la UDP

Comparado con TCP, UDP tiene las siguientes ventajas:

No se ha establecido ninguna conexión. UDP es un protocolo sin conexión, por lo que elimina la sobrecarga asociada al establecimiento de conexiones. Dado que UDP no utiliza apretones de manos, también se evitan retrasos en la conexión. Esta es la razón por la que DNS favorece UDP sobre TCP: DNS sería mucho más lento si se ejecutara sobre TCP.

Velocidad. UDP es más rápido que TCP. Por este motivo, muchas aplicaciones prefieren UDP a TCP. Las mismas características que hacen que TCP sea más robusto (como las señales de protocolo de enlace) también lo ralentizan.

Diversidad topológica. UDP admite comunicaciones uno a uno y uno a muchos, mientras que TCP solo admite comunicaciones uno a uno.

Gastos generales. Trabajar con TCP significa una mayor sobrecarga; la sobrecarga impuesta por UDP es significativamente menor. TCP utiliza muchos más recursos en comparación con UDP Sistema operativo, y como consecuencia, en entornos donde los servidores atienden a muchos clientes simultáneamente, UDP se usa ampliamente.

Tamaño del encabezado. Para cada paquete, el encabezado UDP tiene solo ocho bytes de longitud, mientras que TCP tiene encabezados de 20 bytes y, por lo tanto, UDP consume menos ancho de banda de la red.

Protocolo de datagramas de usuario (UDP)(Protocolo de datagramas de usuario) es un protocolo estándar TCP/IP definido en RFC 768, "Protocolo de datagramas de usuario (UDP)". Se utiliza UDP en lugar de TCP para transportar datos de forma rápida y poco confiable entre hosts TCP/IP.

protocolo UDP proporciona un servicio sin conexión, por lo que UDP no garantiza la entrega ni las comprobaciones de secuencia de ningún datagrama. Anfitrión que necesita comunicación confiable debe utilizar el protocolo TCP o un programa que supervise la secuencia de datagramas y confirme la recepción de cada paquete.

Las aplicaciones urgentes suelen utilizar UDP (datos de vídeo) porque es preferible descartar paquetes en lugar de esperar paquetes retrasados, lo que puede no ser posible en sistemas en tiempo real. Además, la pérdida de uno o más fotogramas al transmitir datos de vídeo a través de UDP no es tan crítica como al transmitir archivos binarios, donde la pérdida de un paquete puede provocar la corrupción de todo el archivo. Otra ventaja del protocolo UDP es que la longitud del encabezado UDP es de 4 bytes, mientras que el protocolo TCP tiene 20 bytes.

Los mensajes UDP se encapsulan y transmiten en datagramas IP.

encabezado UDP

La figura muestra los campos presentes en el encabezado UDP.

• Puerto del remitente: este campo especifica el número de puerto del remitente. Se supone que este valor especifica el puerto al que se enviará una respuesta si es necesario. De lo contrario, el valor debería ser 0. Si el host de origen es un cliente, lo más probable es que el número de puerto sea efímero. Si la fuente es un servidor, entonces su puerto será uno de los "conocidos".
• Puerto del destinatario: este campo es obligatorio y contiene el puerto del destinatario. De manera similar al puerto de origen, si el cliente es el host del destinatario, entonces el número de puerto es efímero; de lo contrario (el servidor es el destinatario) es un "puerto conocido".
• La longitud del datagrama es un campo que especifica la longitud de todo el datagrama (encabezado y datos) en bytes. La longitud mínima es igual a la longitud del encabezado: 8 bytes. Teóricamente, el tamaño máximo de campo es 65535 bytes para un datagrama UDP (8 bytes para encabezado y 65527 para datos). El límite real de longitud de datos cuando se utiliza IPv4 es 65507 (además de los 8 bytes por encabezado UDP, se requieren otros 20 bytes por encabezado IP).
• Suma de comprobación: el campo de suma de comprobación se utiliza para comprobar si hay errores en el encabezado y los datos. Si el transmisor no genera la cantidad, entonces el campo se llena con ceros.

Veamos la estructura del encabezado. UDP usando analizador de red Tiburón de alambre:

Puertos UDP

Dado que se pueden ejecutar varios programas en la misma computadora, para entregar un paquete UDP a un programa específico, identificador único cada programa o número de puerto.

Número de puerto es un número condicional de 16 bits del 1 al 65535 que indica para qué programa está destinado el paquete.

Los puertos UDP brindan la capacidad de enviar y recibir mensajes UDP. El puerto UDP funciona como una única cola de mensajes para recibir todos los datagramas destinados al programa. indicado por el número puerto de protocolo. Esto significa que los programas UDP pueden recibir más de un mensaje a la vez.

Todos los números de puerto UDP inferiores a 1024 están reservados y registrados con la Autoridad de Números Asignados de Internet (IANA).
Los números de puerto UDP y TCP no se superponen.

Cada Puerto UDP identificado por un número de puerto reservado o conocido. La siguiente tabla muestra una lista parcial de los números de puertos UDP conocidos que utilizan los programas UDP estándar.

Usos UDP modelo sencillo transferencias, sin apretones de manos implícitos para garantizar la confiabilidad, el orden o la integridad de los datos. Por lo tanto, UDP proporciona un servicio poco confiable y los datagramas pueden llegar desordenados, duplicarse o desaparecer sin dejar rastro. UDP implica que la verificación y corrección de errores no son necesarias o deben ser realizadas por la aplicación. Las aplicaciones urgentes suelen utilizar UDP porque es preferible descartar paquetes en lugar de esperar paquetes retrasados, lo que puede no ser posible en sistemas en tiempo real. Si es necesario, corrija los errores en nivel de red interfaz, la aplicación puede utilizar TCP o SCTP diseñado para este propósito.

La naturaleza de UDP como protocolo sin estado también es útil para servidores que responden a pequeñas solicitudes de una gran cantidad de clientes, como DNS y aplicaciones de transmisión de medios como IPTV, voz sobre IP, protocolos de túnel IP y muchos juegos en línea.

Puertos de servicio

UDP no proporciona ninguna garantía de entrega de mensajes para el protocolo. nivel superior y no guarda el estado de los mensajes enviados. Por esta razón, a UDP a veces se le denomina protocolo de datagramas no confiables.

Antes de calcular la suma de comprobación, el mensaje UDP se rellena al final con cero bits hasta una longitud que sea múltiplo de 16 bits (el pseudoencabezado y los bits cero adicionales no se envían con el mensaje). Campo de suma de verificación en el encabezado UDP durante el cálculo de la suma de verificación enviado Los mensajes se aceptan como nulos.

Para calcular la suma de comprobación, el pseudoencabezado y el mensaje UDP se dividen en palabras (1 palabra = 2 bytes (octetos) = 16 bits). Luego se calcula el complemento bit a bit de la suma de todas las palabras con complemento bit a bit. El resultado se escribe en el campo correspondiente en el encabezado UDP.

Un valor de suma de verificación de cero está reservado y significa que el datagrama no tiene suma de verificación. Si la suma de comprobación calculada es igual a cero, el campo se rellena con unidades binarias.

Al recibir un mensaje, el destinatario vuelve a calcular la suma de verificación (teniendo en cuenta el campo suma de verificación), y si el resultado es número binario de dieciséis unos (es decir, 0xffff), entonces se considera que la suma de comprobación ha convergido. Si la suma no cuadra (los datos se corrompieron durante la transmisión), el datagrama se destruye.

Ejemplo de cálculo de suma de comprobación

Por ejemplo, calculemos la suma de comprobación de varias palabras de 16 bits: 0x398a, 0xf802, 0x14b2, 0xc281. Encuentra su suma con complemento bit a bit.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Ahora encontramos el complemento bit a bit del resultado resultante:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e o, en caso contrario - 0xffff − 0x08c1 = 0xf73e. Esta es la suma de comprobación deseada.

Al calcular la suma de comprobación, se vuelve a utilizar un pseudoencabezado que simula un encabezado IPv6 real:

bits	0 – 7								8 – 15								16 – 23								24 – 31
0	Dirección de origen
32
64
96
128	Dirección del destinatario
160
192
224
256	Longitud UDP
288	Ceros																								Siguiente título
320	Puerto de origen																Puerto de destino
352	Longitud																Suma de comprobación
384+	Datos

La dirección de origen es la misma que en el encabezado IPv6. Dirección del destinatario: destinatario final; si el paquete IPv6 no contiene un encabezado de enrutamiento, entonces esta será la dirección de destino del encabezado IPv6; de lo contrario, en el nodo inicial, esta será la dirección último elemento encabezado de enrutamiento y en el host receptor, la dirección del destinatario del encabezado IPv6. El valor del encabezado siguiente es igual al valor del protocolo: 17 para UDP. Longitud UDP: la longitud del encabezado y los datos UDP.

Fiabilidad y soluciones a problemas de sobrecarga.

Debido a su falta de confiabilidad, las aplicaciones UDP deben estar preparadas para algunas pérdidas, errores y duplicaciones. Algunos de ellos (por ejemplo, TFTP) pueden agregar opcionalmente mecanismos de confiabilidad elementales a nivel de aplicación.

Pero la mayoría de las veces, las aplicaciones UDP no utilizan estos mecanismos e incluso interfieren con ellas. La transmisión de medios, los juegos multijugador en tiempo real y VoIP son ejemplos de aplicaciones que suelen utilizar el protocolo UDP. En estos aplicaciones específicas La pérdida de paquetes no suele ser gran problema. Si la aplicación necesita alto nivel confiabilidad, entonces puede usar otro protocolo (TCP) o códigos de borrado.

Un problema potencial mayor es que, a diferencia de TCP, las aplicaciones basadas en UDP no necesariamente tienen buenos mecanismos para evitar y controlar la congestión. Las aplicaciones UDP sensibles a la congestión que consumen una parte importante del ancho de banda disponible pueden comprometer la estabilidad de Internet.

Los mecanismos de red se diseñaron para minimizar los efectos potenciales de la congestión durante cargas incontroladas de alta velocidad. Los elementos de red, como los enrutadores que utilizan colas de paquetes y técnicas de caída, suelen ser los únicos herramienta accesible para ralentizar el tráfico UDP excesivo. DCCP (Protocolo de control de congestión de datagramas) está diseñado como una solución parcial a este problema potencial al agregar mecanismos al host final para monitorear la congestión de transmisiones UDP de alta velocidad, como la transmisión de medios.

Aplicaciones

Numerosas aplicaciones clave de Internet utilizan UDP, incluido DNS (donde las consultas deben ser rápidas y consistir en una sola solicitud seguida de un único paquete de respuesta), el Protocolo simple de administración de red (SNMP), el Protocolo de información de enrutamiento (RIP) y la Configuración dinámica de host (DHCP). .

El tráfico de voz y vídeo normalmente se transporta mediante UDP. Los protocolos de transmisión de audio y video en vivo están diseñados para manejar pérdidas aleatorias de paquetes de modo que la calidad se degrade solo ligeramente en lugar de causar grandes retrasos cuando los paquetes perdidos se retransmiten. Debido a que tanto TCP como UDP operan en la misma red, muchas empresas han notado que el reciente aumento en el tráfico UDP de estas aplicaciones en tiempo real está obstaculizando el rendimiento de las aplicaciones TCP, como bases de datos o sistemas de contabilidad. Debido a que tanto las aplicaciones comerciales como las de tiempo real son importantes para las empresas, algunas consideran que el desarrollo de soluciones de calidad a los problemas es una prioridad absoluta.

Comparación de UDP y TCP

TCP es un protocolo orientado a la conexión, lo que significa que se requiere un "apretón de manos" para establecer una conexión entre dos hosts. Una vez establecida la conexión, los usuarios pueden enviar datos en ambas direcciones.

• Fiabilidad- TCP gestiona el reconocimiento, la retransmisión y el tiempo de espera de los mensajes. Se hacen numerosos intentos para transmitir el mensaje. Si se pierde en el camino, el servidor solicitará nuevamente la pieza perdida. Con TCP no faltan datos ni (en el caso de múltiples tiempos de espera) conexiones rotas.

• Orden- Si se envían dos mensajes de forma secuencial, el primer mensaje llegará primero a la aplicación del destinatario. Si los datos llegan en el orden incorrecto, TCP envía los datos desordenados a un búfer hasta que todos los datos puedan ordenarse y enviarse a la aplicación.

• pesadez- TCP requiere tres paquetes para establecer una conexión de socket antes de enviar datos. TCP monitorea la confiabilidad y la congestión.

• Enhebrado- los datos se leen como un flujo de bytes, no se transmiten designaciones especiales para los límites o segmentos del mensaje.

UDP es un protocolo sin conexión, basado en mensajes y más simple. Este tipo de protocolos no establecen una conexión dedicada entre dos hosts. La comunicación se logra pasando información en una dirección desde una fuente a un destinatario sin verificar la preparación o el estado del destinatario. Sin embargo, la principal ventaja de UDP sobre TCP está en las aplicaciones de Voz sobre Protocolo de Internet (VoIP), donde cualquier apretón de manos impediría una buena comunicación de voz. En VoIP se cree que usuarios finales proporcionará cualquier confirmación necesaria de recepción del mensaje en tiempo real.

• Faltón- cuando se envía un mensaje, no se sabe si llegará a su destino - puede perderse en el camino. No existen conceptos como confirmación, retransmisión, tiempo de espera.

• Trastorno- Si se envían dos mensajes al mismo destinatario, no se puede predecir el orden en que alcanzarán el objetivo.

• Ligereza- sin ordenamiento de mensajes, sin seguimiento de conexiones, etc. Es una pequeña capa de transporte diseñada en IP.

• Datagramas- los paquetes se envían individualmente y se comprueba su integridad sólo si llegan. Los paquetes tienen ciertos límites que se respetan una vez recibidos, lo que significa que una operación de lectura en el socket receptor producirá el mensaje tal como se envió originalmente.

• Sin control de sobrecarga- UDP por sí solo no evita la congestión. Es posible que las aplicaciones de gran ancho de banda provoquen un colapso de la congestión a menos que implementen controles a nivel de aplicación.

Enlaces RFC

• RFC 768 – Protocolo de datagramas de usuario
• RFC 2460 – Especificación del protocolo de Internet versión 6 (IPv6)
• RFC 2675 - Jumbogramas IPv6
• RFC 4113 – Base de información de gestión para la UDP
• RFC 5405: Directrices de uso de Unicast UDP para diseñadores de aplicaciones

Ver también

Campo de golf

• Kurose, JF; Ross, KW (2010). Redes de computadoras: un enfoque de arriba hacia abajo (5ª ed.). Boston, MA: Educación Pearson. ISBN 978-0-13-136548-3.
• Forouzan, B.A. (2000). TCP/IP: Conjunto de protocolos, 1ª ed. Nueva Delhi, India: Tata McGraw-Hill Publishing Company Limited.
• [correo electrónico protegido]. "Descripción general del protocolo UDP". IPv6.com. Consultado el 17 de agosto de 2011.
• Clark, diputado. (2003). Redes de datos IP e Internet, 1ª ed. West Sussex, Inglaterra: John Wiley & Sons Ltd.
• Postel, J. (agosto de 1980). RFC 768: Protocolo de datagramas de usuario. Grupo de trabajo de ingeniería de Internet. Obtenido de http://tools.ietf.org/html/rfc768
• Deering S. y Hinden R. (diciembre de 1998). RFC 2460: Protocolo de Internet, especificación versión 6 (IPv6). Grupo de trabajo de ingeniería de Internet. Obtenido de http://tools.ietf.org/html/rfc2460
• "El impacto de UDP en las aplicaciones de datos". networkrendimientodaily.com. Consultado el 17 de agosto de 2011.
• D. Comer. Conexión a Internet mediante TCP/IP. Capítulo 11. Protocolo UDP.

Protocolos TCP/IP básicos por niveles del modelo OSI (Lista de puertos TCP y UDP)
Físico
Conducto