¿Cómo funciona UDP cuando no hay un número de secuencia en su encabezado? ¿Cómo identifica un receptor que este es el orden correcto de un paquete?

Los paquetes UDP tienen IP de origen, IP de destino y números de puerto (src y dest) distintos. Por lo tanto, cada paquete siempre se origina en la fuente correcta y se recibe en el destino correcto. El orden entre paquetes en una secuencia puede ser impredecible dependiendo de las rutas de red, el almacenamiento en búfer y otras peculiaridades.

Si los datos originales enviados desde la fuente se dividieron en varias partes y se enviaron en paquetes UDP separados, surge el posible problema de recibir datos en un orden incorrecto.

Hay algunas formas de salir de esto:

1. Utilice TCP siempre que los datos originales deban reconstruirse de manera confiable (exactamente). TCP tiene sus gastos generales, pero vale la pena pagar el precio de los gastos generales para evitar hacer una lógica de reordenamiento compleja en su aplicación. Casi todos los protocolos conocidos hacen esto: FTP, HTTP / HTTPS, SSH, TELNET, etc.

2. Use UDP solo si su esquema de mensajería app-2-app no ​​depende del orden. Una situación general en la que esto podría ser cierto es si cada paquete (que lleva un fragmento de datos originales) también tiene la posición del fragmento dentro de los datos originales codificados en el paquete. Luego, independientemente del orden en que se reciben los paquetes, cada fragmento puede insertarse de manera precisa y confiable en los datos reconstruidos por su posición. Aún debe crear un esquema para verificar si la reconstrucción está completa y manejar los paquetes descartados. Los ejemplos incluyen SNMP, NFSv2, etc.

3. Los mensajes de estado únicos con toda la información codificada en cada paquete son adecuados para UDP. Especialmente cuando hay múltiples destinatarios, cada uno con listas de suscripción ligeramente diferentes, los paquetes UDP se pueden multidifundir de manera eficiente a los destinatarios sin mantener ningún estado en los remitentes. Esto es casi imposible de hacer en TCP sin agregar demasiada complejidad. Los ejemplos incluyen mensajes de estado de Hadoop, monitoreo de servicios, etc.

4. Los datos isócronos (multimedia, reproducción de video, etc.) que se vuelven obsoletos tan pronto como se pierde su fecha límite de tiempo no tienen ningún beneficio de las retransmisiones para garantizar la confiabilidad. A menudo, las piezas que faltan se predicen utilizando algoritmos estadísticos y de interpolación que funcionan bastante bien para ocultar los cuadros faltantes intermitentes. Una vez más, esto es muy adecuado para usar con multi-casting. P.ej. VoD.

En UDP, no hay re-secuenciación automática y control de flujo. Debe usar TCP si necesita hacer esto a nivel de protocolo. Alternativamente, los desarrolladores de aplicaciones pueden poner secuencias y aplicarlas a nivel de aplicación.

UDP maneja paquetes individuales, por lo que el orden no es (no puede) ser un concepto significativo para él. Si la aplicación en particular se preocupa por el pedido, tendrá que ocuparse de eso de alguna manera; UDP no puede (nunca tuvo la intención de poder) ayudarlo.