(movido de comentario a respuesta)
Como se menciona en otro póster, UDP puede afectar a otro tráfico (tanto UDP como TCP) si el remitente inunda el cable con paquetes. Como no hay negociación o negociación en UDP, el protocolo no tiene una forma natural de controlar la velocidad de envío.
Es absolutamente posible que alguien escriba un programa muy simple que pueda crear más tráfico del que puede manejar la red, lo que provocaría que los dispositivos de red a lo largo del camino llenen potencialmente sus buffers y no puedan reenviar ningún paquete que llegue mientras no haya Más espacio en el búfer.
- ¿Cuál es el diferente protocolo de enrutamiento y protocolo de reenvío? ¿Existe algún protocolo por parte de los investigadores para elegir el movimiento de datos de manera inteligente?
- ¿Qué es la "entrega de datagramas sin conexión" en TCP / IP?
- ¿Por qué VXLAN usa UDP en lugar de TCP como el protocolo de transporte subyacente?
- ¿Qué es un protocolo sin estado?
- En SSL y TLS, ¿por qué hay un Protocolo de especificaciones de cifrado de cambio separado en lugar de incluir un mensaje change_cipher_spec en el Protocolo de protocolo de enlace?
Los paquetes que se pierden no son deterministas, a menos que los dispositivos estén configurados con QoS o algún otro mecanismo de priorización de tráfico. Todo el tráfico que pasa por el dispositivo es vulnerable a la pérdida.
Los programas UDP que se preocupan por la entrega de mensajes lidiarán con la pérdida en la capa de aplicación
Pero TCP tiene mecanismos incorporados, y cuando se pierden paquetes, el protocolo comienza a retransmitir los paquetes perdidos, puede reducir el tamaño de las ventanas (aumentando el número de veces que el remitente espera acuses de recibo, lo que significa demoras adicionales), y puede volverse incapaz de reconstruir los paquetes enviados en orden antes de que el búfer se llene de datos incompletos. Todo esto significa transmisiones más lentas o posiblemente deshabilitadas mientras continúa la congestión.
