¿Cuándo es apropiado utilizar UDP en lugar de TCP? [cerrado]
Dado que TCP garantiza la entrega de paquetes y, por lo tanto, puede considerarse "confiable", mientras que UDP no garantiza nada y los paquetes se pueden perder. ¿Cuál sería la ventaja de transmitir datos utilizando UDP en una aplicación en lugar de un flujo TCP? ¿En qué tipo de situaciones UDP sería la mejor opción y por qué?
Supongo que UDP es más rápido ya que no tiene la sobrecarga de crear y mantener una transmisión, pero ¿no sería eso irrelevante si algunos datos nunca llegan a su destino?
Esta es una de mis preguntas favoritas. UDP está muy mal entendido.
En situaciones en las que realmente desea obtener rápidamente una respuesta simple a otro servidor, UDP funciona mejor. En general, desea que la respuesta esté en un paquete de respuesta y está preparado para implementar su propio protocolo para mayor confiabilidad o para reenviarlo. DNS es la descripción perfecta de este caso de uso. Los costos de configuración de la conexión son demasiado altos (sin embargo, DNS también admite el modo TCP).
Otro caso es cuando estás entregando datos que pueden perderse porque los datos más nuevos que ingresan reemplazarán los datos/estado anteriores. Me vienen a la mente datos meteorológicos, transmisión de vídeo, un servicio de cotización de acciones (no utilizado para operaciones reales) o datos de juegos.
Otro caso es cuando administra una enorme cantidad de estado y desea evitar el uso de TCP porque el sistema operativo no puede manejar tantas sesiones. Este es un caso raro hoy en día. De hecho, ahora existen pilas TCP en el ámbito del usuario que se pueden utilizar para que el escritor de la aplicación pueda tener un control más detallado sobre los recursos necesarios para ese estado TCP. Antes de 2003, UDP era realmente el único juego que existía.
Otro caso es el del tráfico multicast. UDP se puede realizar multidifusión a varios hosts, mientras que TCP no puede hacerlo en absoluto.
Si se pierde un paquete TCP , se reenviará. Esto no es útil para aplicaciones que dependen del manejo de datos en un orden específico en tiempo real.
Los ejemplos incluyen transmisión de vídeo y especialmente VoIP (por ejemplo, Skype ). En esos casos, sin embargo, la caída de un paquete no es gran cosa: nuestros sentidos no son perfectos, por lo que es posible que ni siquiera nos demos cuenta. Es por eso que este tipo de aplicaciones utilizan UDP en lugar de TCP.
La "falta de fiabilidad" de la UDP es un formalismo. La transmisión no está absolutamente garantizada. En la práctica, casi siempre logran comunicarse. Simplemente no se reconocen ni se vuelven a intentar después de un tiempo de espera.
La sobrecarga al negociar un socket TCP y realizar el protocolo de enlace de los paquetes TCP es enorme. Realmente enorme. No hay una sobrecarga UDP apreciable.
Lo más importante es que puede complementar fácilmente UDP con un protocolo de entrega confiable que genera menos gastos generales que TCP. Lea esto: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
UDP es útil para transmitir información en una aplicación del tipo publicación-suscripción. IIRC, TIBCO hace un uso intensivo de UDP para notificar cambios de estado.
Cualquier otro tipo de "evento significativo" unidireccional o actividad de "registro" se puede manejar muy bien con paquetes UDP. Quiere enviar una notificación sin construir un socket completo. No se espera ninguna respuesta de los distintos oyentes.
Los mensajes del sistema de "latido del corazón" o "Estoy vivo" también son una buena opción. Perder uno no es una crisis. Faltan media docena (seguidas) sí.
Trabajo en un producto que admite comunicación UDP (IP) y TCP/IP entre cliente y servidor. Comenzó con IPX hace más de 15 años y se agregó soporte IP hace 13 años. Agregamos soporte TCP/IP hace 3 o 4 años. Se acerca una suposición descabellada: la proporción de códigos UDP a TCP es probablemente de aproximadamente 80/20. El producto es un servidor de bases de datos, por lo que la confiabilidad es fundamental. Tenemos que manejar todos los problemas impuestos por UDP (pérdida de paquetes, duplicación de paquetes, orden de paquetes, etc.) ya mencionados en otras respuestas. Rara vez hay problemas, pero a veces ocurren y por eso deben solucionarse. El beneficio de admitir UDP es que podemos personalizarlo un poco según nuestro propio uso y ajustar un poco más su rendimiento.
Cada red será diferente, pero el protocolo de comunicación UDP generalmente es un poco más rápido para nosotros. El lector escéptico se preguntará con razón si hemos implementado todo correctamente. Además, ¿qué se puede esperar de un chico con una reputación de 2 dígitos? No obstante, acabo de realizar una prueba por curiosidad. La prueba leyó 1 millón de registros (seleccione * de alguna tabla). Establecí la cantidad de registros que se devolverán con cada solicitud de cliente individual en 1, 10 y luego 100 (tres ejecuciones de prueba con cada protocolo). El servidor estaba a sólo dos saltos de distancia a través de una LAN de 100 Mbit. Los números parecían coincidir con lo que otros habían encontrado en el pasado (UDP es aproximadamente un 5% más rápido en la mayoría de las situaciones). Los tiempos totales en milisegundos fueron los siguientes para esta prueba en particular:
- 1 registro
- IP: 390.760 ms
- TCP: 416.903 ms
- 10 registros
- IP: 91.707 ms
- TCP: 95.662 ms
- 100 registros
- IP: 29.664 ms
- TCP: 30.968 ms
La cantidad total de datos transmitidos fue aproximadamente la misma tanto para IP como para TCP. Tenemos una sobrecarga adicional con las comunicaciones UDP porque tenemos algunas de las mismas cosas que se obtienen "gratis" con TCP/IP (sumas de verificación, números de secuencia, etc.). Por ejemplo, Wireshark demostró que una solicitud para el siguiente conjunto de registros tenía 80 bytes con UDP y 84 bytes con TCP.
