¿Cuándo es apropiado usar UDP en lugar de TCP? [cerrado]


304

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 hacerlo a través de un flujo TCP? ¿En qué tipo de situaciones sería UDP 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 secuencia, pero ¿no sería irrelevante si algunos datos nunca llegan a su destino?


55
Además de sufrir una posible pérdida de paquetes, UDP no garantiza que solo recibirá el paquete una vez. Si tiene redes enrevesadas o mal configuradas, puede recibir el mismo paquete varias veces. ¡Solo un aviso porque la gente tiende a olvidar esto!
Brian Agnew

3
Ni siquiera garantiza el pedido de paquetes.
Mehrdad Afshari

19
TCP no garantiza la entrega , solo garantiza que si puede entregar los paquetes, estarán en el mismo orden en que fueron enviados.
Chaim Geretz

55
Por cierto, con frecuencia veo que la gente equipara la confiabilidad / entrega en orden a las retransmisiones TCP. Esos "expertos" le dirán que para superar los errores de transmisión en UDP, deberá volver a implementar TCP (mal) y, por lo tanto, también podría usar TCP. Esto no es verdad. Existen otras técnicas de recuperación de errores además de la retransmisión, que no sufren latencia o rendimiento degradado exponencialmente como resultado de tasas de error pequeñas pero no nulas.
Ben Voigt

TCP también garantiza que sabrá si el destino no recibió los paquetes.
csga5000

Respuestas:


354

Esta es una de mis preguntas favoritas. UDP es tan incomprendido.

En situaciones en las que realmente desea obtener una respuesta simple a otro servidor rápidamente, UDP funciona mejor. En general, desea que la respuesta esté en un paquete de respuesta, y está preparado para implementar su propio protocolo para confiabilidad o reenvío. DNS es la descripción perfecta de este caso de uso. Los costos de las configuraciones de conexión son demasiado altos (sin embargo, DNS también admite un modo TCP).

Otro caso es cuando está entregando datos que pueden perderse porque los datos más nuevos que ingresan reemplazarán esos datos / estado anteriores. Me vienen a la mente datos meteorológicos, transmisión de video, un servicio de cotización de acciones (no utilizado para el comercio real) o datos de juegos.

Otro caso es cuando está administrando una gran 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. De hecho, ahora hay pilas TCP de usuario que pueden usarse para que el escritor de la aplicación pueda tener un control más preciso sobre los recursos necesarios para ese estado TCP. Antes de 2003, UDP era realmente el único juego en la ciudad.

Otro caso es para el tráfico de multidifusión. UDP puede ser multidifundido a múltiples hosts, mientras que TCP no puede hacer esto en absoluto.


Gracias por la interesante respuesta. Actualmente tenemos un servidor que hace todo en UDP (requisito de alto ancho de banda), lo cual está bien porque realmente hay un solo salto (enrutamiento desactivado, ...), pero hemos notado que la reordenación de paquetes podría convertirse en un problema en algunas tarjetas de red defectuosas. ¿Qué pila TCP en modo de usuario (u otra pila controlada por flujo en modo de usuario) sugiere?
guiones

@dashesy: ​​¿puedes deshacerte del requisito de pedido? ¿Hay un número monotónicamente creciente dentro de la carga útil que pueda usar? Si es así, realmente no necesita una pila TCP de tierra de usuario completa.
drudru

@ drudru- sí, el número de secuencia está allí, es posible que deba amortiguar y eliminar el jitter. Gracias, eliminar una opción más siempre es genial.
guión

64

Si se pierde un paquete TCP , se reenviará. Eso no es útil para aplicaciones que dependen de datos manejados en un orden específico en tiempo real.

Los ejemplos incluyen transmisión de video y especialmente VoIP (por ejemplo, Skype ). En esos casos, sin embargo, un paquete descartado no es tan importante: nuestros sentidos no son perfectos, por lo que es posible que ni siquiera nos demos cuenta. Es por eso que este tipo de aplicaciones usan UDP en lugar de TCP.


16
Creo que lo tienes al revés. TCP reordena los paquetes para que los datos se entreguen en el pedido enviado. UDP no reordena y entrega datos en el orden en que los recibió.
Hans Malherbe

1
UDP no garantiza el pedido, sin embargo, puede numerar los paquetes y reordenarlos después de recuperarlos.
Kugel

77
@ Stephan202: Creo que tendría que estar en desacuerdo por no notar los paquetes descartados en Skype ;-)
Robert S. Barnes

66
@ Kugel: Solo tenga en cuenta que podría estar implementando una nueva pila TCP. Es poco probable que haga un mejor trabajo que el sistema operativo en esto.
erikkallen

1
@erikkallen: Si uno usara UDP para implementar un protocolo de nivel superior con los mismos requisitos que TCP diseñó para cumplir, sería poco probable que lo hiciera mucho mejor que los protocolos existentes. Por otro lado, algunas aplicaciones se benefician de la adición de algunas características al protocolo que un contenedor UDP podría manejar mejor que TCP.
supercat

56

La "falta de fiabilidad" de UDP es un formalismo. La transmisión no está absolutamente garantizada. Como cuestión práctica, casi siempre pasan. Simplemente no son reconocidos y reintentados después de un tiempo de espera.

La sobrecarga en la negociación de un socket TCP y el apretón de manos de los paquetes TCP es enorme. Realmente enorme No hay sobrecarga UDP apreciable.

Lo que es más importante, puede complementar fácilmente UDP con un poco de comunicación confiable que sea menos costosa que TCP. Lea esto: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP es útil para transmitir información en un tipo de aplicación de publicación-suscripción. IIRC, TIBCO hace un uso intensivo de UDP para la notificación de cambios de estado.

Cualquier otro tipo de actividad de "evento significativo" o "registro" unidireccional puede manejarse bien con paquetes UDP. Desea enviar notificaciones sin construir un socket completo. No espera ninguna respuesta de los distintos oyentes.

Los mensajes del sistema "heartbeat" o "I'm alive" también son una buena opción. Perder uno no es una crisis. Falta media docena (en una fila).


55
"Como cuestión práctica, casi siempre pasan". Depende en gran medida de la fiabilidad de las capas de red más bajas.
m0skit0

Además, ¿hay alguna diferencia entre planificar "pocos" pérdida de paquetes y "demasiada" pérdida de paquetes? La pérdida es la pérdida. tienes que planearlo de todos modos.
Sedat Kapanoglu

30

Trabajo en un producto que admite comunicación UDP (IP) y TCP / IP entre el cliente y el servidor. Comenzó con IPX hace más de 15 años con soporte de IP agregado hace 13 años. Agregamos soporte TCP / IP hace 3 o 4 años. Próxima suposición: la relación de código UDP a TCP es probablemente de aproximadamente 80/20. El producto es un servidor de base de datos, por lo que la confiabilidad es crítica. 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. Raramente hay problemas, pero a veces ocurren y, por lo tanto, deben manejarse. El beneficio de admitir UDP es que podemos personalizarlo un poco para nuestro propio uso y ajustar un poco más el rendimiento.

Cada red va a ser diferente, pero el protocolo de comunicación UDP generalmente es un poco más rápido para nosotros. El lector escéptico cuestionará correctamente si implementamos todo correctamente. Además, ¿qué puedes esperar de un chico con un representante de 2 dígitos? Sin embargo, acabo de hacer una prueba por curiosidad. La prueba leyó 1 millón de registros (seleccione * de alguna tabla). Establecí el número de registros para devolver con cada solicitud de cliente individual en 1, 10 y luego 100 (tres ejecuciones de prueba con cada protocolo). El servidor estaba a solo dos saltos en una LAN de 100Mbit. Los números parecen estar de acuerdo con lo que otros han 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. 1 registro
    • IP: 390,760 ms
    • TCP: 416,903 ms
  2. 10 registros
    • IP: 91,707 ms
    • TCP: 95,662 ms
  3. 100 registros
    • IP: 29,664 ms
    • TCP: 30,968 ms

La cantidad total de datos transmitidos fue casi la misma para IP y TCP. Tenemos sobrecarga adicional con las comunicaciones UDP porque tenemos algunas de las mismas cosas que obtienes "gratis" con TCP / IP (sumas de verificación, números de secuencia, etc.). Por ejemplo, Wireshark mostró que una solicitud para el siguiente conjunto de registros era de 80 bytes con UDP y 84 bytes con TCP.


¿Qué pasaría si lo hubiera desarrollado solo para TCP y comprara un mejor hardware en lugar de 5 veces más esfuerzo de codificación?
inf3rno

2
Gracias por los números concretos! La mejora del 5% es un poco decepcionante por la complejidad que agrega.
Sergei

1
¿Probablemente el 5% se debe a que se envía en una red local (a dos esperanzas de distancia)? Supongo que cuanto más lejos esté, mayor será la diferencia.
lepe

19

Ya hay muchas buenas respuestas aquí, pero me gustaría agregar un factor muy importante, así como un resumen. UDP puede lograr un rendimiento mucho más alto con el ajuste correcto porque no emplea control de congestión . El control de congestión en TCP es muy muyimportante. Controla la velocidad y el rendimiento de la conexión para minimizar la congestión de la red tratando de estimar la capacidad actual de la conexión. Incluso cuando los paquetes se envían a través de enlaces muy confiables, como en la red central, los enrutadores tienen memorias intermedias de tamaño limitado. Estos búferes se llenan hasta su capacidad y los paquetes se descartan, y TCP lo nota por la falta de un acuse de recibo, lo que limita la velocidad de la conexión a la estimación de la capacidad. TCP también emplea algo llamado inicio lento , pero el rendimiento (en realidad, la ventana de congestión ) se aumenta lentamente hasta que se caen los paquetes, y luego se baja y se vuelve a aumentar lentamente hasta que se caen los paquetes, etc. Esto hace que el rendimiento de TCP fluctúe. Puede ver esto claramente cuando descarga un archivo grande.

Debido a que UDP no está utilizando el control de congestión, puede ser más rápido y experimentar menos demora porque no buscará maximizar las memorias intermedias hasta el punto de caída, es decir, los paquetes UDP pasan menos tiempo en las memorias intermedias y llegan más rápido con menos demora. Debido a que UDP no emplea control de congestión, pero TCP sí, puede eliminar la capacidad de TCP que cede a flujos UDP.

Sin embargo, UDP sigue siendo vulnerable a la congestión y la caída de paquetes, por lo que su aplicación debe estar preparada para manejar estas complicaciones de alguna manera, probablemente utilizando retransmisión o códigos de corrección de errores.

El resultado es que UDP puede:

  • Logre un mayor rendimiento que TCP siempre que la velocidad de caída de la red esté dentro de los límites que la aplicación puede manejar.
  • Entregue paquetes más rápido que TCP con menos retraso.
  • Configure las conexiones más rápido ya que no hay un apretón de manos inicial para configurar la conexión
  • Transmita paquetes de multidifusión, mientras que TCP tiene que usar múltiples conexiones.
  • Transmita paquetes de tamaño fijo, mientras que TCP transmite datos en segmentos. Si transfiere un paquete UDP de 300 Bytes, recibirá 300 Bytes en el otro extremo. Con TCP, puede alimentar el socket de envío 300 Bytes, pero el receptor solo lee 100 Bytes, y tiene que descubrir de alguna manera que hay 200 Bytes más en el camino. Esto es importante si su aplicación transmite mensajes de tamaño fijo, en lugar de una secuencia de bytes.

En resumen, UDP puede usarse para cada tipo de aplicación que TCP puede, siempre y cuando también implemente un mecanismo de retransmisión adecuado. UDP puede ser muy rápido, tiene menos retraso, no se ve afectado por la congestión en una conexión, transmite datagramas de tamaño fijo y puede usarse para multidifusión.


1
Cuando las redes se congestionan lo suficiente como para causar la pérdida de paquetes, TCP intenta minimizar su impacto en otros usuarios de la red, mientras que muchas implementaciones basadas en UDP no lo hacen. Esto les permite obtener una porción mayor de un pastel decreciente, pero también reduce la cantidad total de ancho de banda útil disponible (por ejemplo, como consecuencia de una retransmisión innecesaria en los casos en que los datos se entregarían pero el remitente no se daría cuenta de eso)
supercat

En primer lugar, gracias por la gran respuesta, ¡realmente aprendí mucho de ella! Pero tengo una pregunta: ¿no ocurre la segmentación en la capa 3 (IP) debido a las limitaciones del adaptador Ethernet para todos los paquetes recibidos de la capa 4 (tanto TCP como UDP)? ¿Te refieres a algún otro tipo de segmentación que ocurre en TCP pero no en UDP? Realmente agradecería si me lo pudieras explicar.
RuslanSh

1
@Freezy. Tiene razón, la fragmentación de los paquetes que exceden la MTU del enlace (capa 2) ocurre en la capa 3-IP. Sin embargo, TCP es un protocolo basado en flujo y trata los datos como un flujo de bytes. TCP envía sus datos en segmentos para que quepan dentro de los paquetes IP, que se dimensionan de acuerdo con el MSS, por lo que la segmentación también ocurre en TCP. Sin embargo, la cantidad de datos que TCP pone en un segmento, o la cantidad de datos que lee su socket varía según muchos factores; Puede ser 1 byte o bytes MSS. Con UDP, el receptor siempre obtiene el número exacto de bytes que envió el transmisor, si el paquete no se pierde en el camino.
Andy

15

UDP tiene menos sobrecarga y es bueno para hacer cosas como transmitir datos en tiempo real como audio o video, o en cualquier caso, si está perdido si se pierden datos.


15

UDP es un protocolo sin conexión y se usa en protocolos como SNMP y DNS en los que los paquetes de datos que salen de orden son aceptables y la transmisión inmediata del paquete de datos es importante.

Se utiliza en SNMP ya que la administración de la red a menudo se debe hacer cuando la red está en tensión, es decir, cuando la transferencia de datos confiable y controlada por congestión es difícil de lograr.

Se utiliza en DNS ya que no implica el establecimiento de la conexión, evitando así retrasos en el establecimiento de la conexión.

salud


12

Una de las mejores respuestas que conozco para esta pregunta proviene del usuario zAy0LfpBZLC8mAC en Hacker News . Esta respuesta es tan buena que voy a citarla tal como está.

TCP tiene bloqueo de la cola de la cola, ya que garantiza la entrega completa y en orden, por lo que cuando un paquete se pierde en tránsito, tiene que esperar una retransmisión del paquete faltante, mientras que UDP entrega paquetes a la aplicación a medida que llegan , incluidos los duplicados y sin ninguna garantía de que llegue un paquete o en qué orden llegan (en realidad es esencialmente IP con números de puerto y una suma de verificación de carga útil (opcional) añadida), pero eso está bien para la telefonía, por ejemplo, donde generalmente simplemente no importa cuando faltan unos pocos milisegundos de audio, pero el retraso es muy molesto, por lo que no se molesta con las retransmisiones, simplemente suelta los duplicados, clasifica los paquetes reordenados en el orden correcto por unos pocos cientos de milisegundos de memoria intermedia de fluctuación , y si los paquetes no aparecen a tiempo o en absoluto, simplemente se omiten,posible interpolado donde sea compatible con el códec.

Además, una parte importante de TCP es el control de flujo, para asegurarse de obtener la mayor cantidad de througput posible, pero sin sobrecargar la red (lo cual es un poco redundante, ya que una red sobrecargada dejará caer sus paquetes, lo que significa que tendrá que hacerlo retransmite, lo que perjudica el rendimiento), UDP no tiene nada de eso, lo que tiene sentido para aplicaciones como la telefonía, ya que la telefonía con un códec dado necesita una cierta cantidad de ancho de banda, no se puede "ralentizar", y también ancho de banda adicional no hace que la llamada vaya más rápido.

Además de las aplicaciones en tiempo real / baja latencia, UDP tiene sentido para transacciones realmente pequeñas, como las búsquedas de DNS, simplemente porque no tiene el establecimiento de la conexión TCP y la sobrecarga de desmontaje, tanto en términos de latencia como en términos de uso de ancho de banda. Si su solicitud es más pequeña que una MTU típica y la respuesta probablemente también lo sea, puede hacerlo en una sola vuelta, sin necesidad de mantener ningún estado en el servidor, y el control de flujo también ordena y todo eso probablemente no sea particularmente útil para tales usos tampoco.

Y luego, puede usar UDP para construir sus propios reemplazos de TCP, por supuesto, pero probablemente no sea una buena idea sin una comprensión profunda de la dinámica de la red, los algoritmos TCP modernos son bastante sofisticados.

Además, supongo que debería mencionarse que hay más de UDP y TCP, como SCTP y DCCP. Actualmente, el único problema es que Internet (IPv4) está lleno de puertas de enlace NAT que hacen que sea imposible utilizar protocolos distintos de UDP y TCP en las aplicaciones de usuario final.


Puede ejecutar SCTP y DCCP sobre UDP.
Demi el

9

La transmisión de video es un ejemplo perfecto del uso de UDP.


Por favor proporcione algunos ejemplos.
Gaurav Singh el

"Video Streaming" es el ejemplo. Considere un partido en vivo transmitido por Hotstar.
Sisir

8

UDP tiene una sobrecarga más baja, como ya se dijo, es bueno para transmitir cosas como video y audio donde es mejor simplemente perder un paquete y luego tratar de reenviarlo y ponerse al día.

No hay garantías sobre la entrega de TCP, simplemente se le debe informar si el socket está desconectado o, básicamente, si los datos no van a llegar. De lo contrario, llega allí cuando llega allí.

Una gran cosa que la gente olvida es que udp está basado en paquetes, y tcp está basado en bytestream, no hay garantía de que el "paquete tcp" que envió sea el paquete que aparece en el otro extremo, se puede diseccionar en tantos paquetes como desean los enrutadores y las pilas. Por lo tanto, su software tiene la sobrecarga adicional de analizar bytes nuevamente en fragmentos de datos utilizables, que pueden tomar una buena cantidad de sobrecarga. UDP puede estar fuera de servicio, por lo que debe numerar sus paquetes o utilizar algún otro mecanismo para reordenarlos si lo desea. Pero si obtiene ese paquete udp, llega con todos los mismos bytes en el mismo orden en que se fue, sin cambios. Por lo tanto, el término paquete udp tiene sentido, pero el paquete tcp no necesariamente. TCP tiene su propio mecanismo de reintento y orden que está oculto a su aplicación,

UDP es mucho más fácil para escribir código en ambos extremos, básicamente porque no tiene que hacer y mantener las conexiones punto a punto. Mi pregunta es típicamente ¿dónde están las situaciones en las que desearía la sobrecarga de TCP? Y si toma atajos como asumir que un "paquete" tcp recibido es el paquete completo que se envió, ¿está mejor? (es probable que deseche dos paquetes si se molesta en verificar la longitud / contenido)


TCP tiene una garantía de entrega: el fragmento A se entregará a una aplicación antes del fragmento B, por lo tanto, si una aplicación reconoce (a nivel de aplicación) el fragmento B, sabe que se obtuvo el fragmento A. Pero esto también sucede en el nivel de manejo de TCP también.
Simeon Pilgrim

En TCP, uno puede delimitar con seguridad fragmentos de datos simplemente prefijando cada fragmento con su longitud. Dependiendo de la aplicación, uno puede prefijar cada fragmento con una longitud fija de un byte, dos bytes o cuatro bytes, o uno puede prefijar cada fragmento de tamaño 128 ^ N o menos con una longitud de N bytes. No es exactamente una gran sobrecarga. Tal diseño sería malo con protocolos que no garantizan la entrega en orden sin espacios, pero cuando se utiliza TCP, dicho diseño está bien.
supercat

si busca cantidades de datos de longitud fija, ni siquiera necesita la longitud, solo cuente los bytes a medida que entran ...
old_timer

1
@Super gato. Tienes toda la razón. Esto también significa que está agregando complejidad a su aplicación; complejidad que realmente se necesita en UDP. Por esta razón, TCP es mejor para transferir secuencias, como archivos. Pero hago exactamente lo que haces cuando quiero confiabilidad de los datos fragmentados, y tal vez seguridad adicional de TLS en el TCP superior.
Andy

5

La comunicación de red para videojuegos casi siempre se realiza a través de UDP.

La velocidad es de suma importancia y realmente no importa si se pierden actualizaciones ya que cada actualización contiene el estado actual completo de lo que el jugador puede ver.


55
normal, no el estado completo en absoluto, sino un delta desde el último reconocimiento, por lo tanto, las actualizaciones se hacen progresivamente más grandes.
Simeon Pilgrim

5

La pregunta clave estaba relacionada con "qué tipo de situaciones sería UDP la mejor opción [sobre tcp]"

Hay muchas respuestas excelentes anteriores, pero lo que falta es una evaluación formal y objetiva del impacto de la incertidumbre del transporte en el rendimiento del TCP.

Con el crecimiento masivo de las aplicaciones móviles, y los paradigmas "ocasionalmente conectados" o "ocasionalmente desconectados" que las acompañan, ciertamente hay situaciones en las que la sobrecarga de los intentos de TCP de mantener una conexión cuando las conexiones son difíciles de conseguir conduce a un fuerte caso para UDP y su naturaleza "orientada a mensajes".

Ahora no tengo los números matemáticos / de investigación / sobre esto, pero he producido aplicaciones que han funcionado de manera más confiable usando ACK / NAK y la numeración de mensajes a través de UDP de lo que podría lograrse con TCP cuando la conectividad era generalmente pobre y pobre. acabo de pasar el tiempo y el dinero de mi cliente tratando de conectarse. Obtienes esto en áreas regionales y rurales de muchos países occidentales ...


3

En algunos casos, que otros han destacado, la llegada garantizada de paquetes no es importante y, por lo tanto, usar UDP está bien. Hay otros casos en los que UDP es preferible a TCP.

Un caso único en el que desearía usar UDP en lugar de TCP es cuando está haciendo un túnel TCP sobre otro protocolo (por ejemplo, túneles, redes virtuales, etc.). Si hace un túnel TCP sobre TCP, los controles de congestión de cada uno interferirán entre sí. Por lo tanto, generalmente se prefiere hacer un túnel TCP sobre UDP (o algún otro protocolo sin estado). Consulte el artículo de TechRepublic: Comprensión de TCP sobre TCP: efectos del túnel TCP en el rendimiento y la latencia de extremo a extremo .


2

UDP se puede usar cuando una aplicación se preocupa más por los datos "en tiempo real" en lugar de la replicación exacta de datos. Por ejemplo, VOIP puede usar UDP y la aplicación se preocupará por reordenar paquetes, pero al final VOIP no necesita todos los paquetes, pero lo más importante es que necesita un flujo continuo de muchos de ellos. Tal vez aquí hay un "problema técnico" en la calidad de la voz, pero el objetivo principal es que reciba el mensaje y no que se recrea perfectamente en el otro lado. UDP también se usa en situaciones donde el gasto de crear una conexión y sincronizar con TCP supera la carga útil. Las consultas de DNS son un ejemplo perfecto. Un paquete de salida, un paquete de vuelta, por consulta. Si usa TCP, esto sería mucho más intenso. Si no recupera la respuesta DNS, simplemente vuelva a intentarlo.


2

UDP cuando la velocidad es necesaria y la precisión si los paquetes no lo son, y TCP cuando necesita precisión.

UDP a menudo es más difícil porque debe escribir su programa de tal manera que no dependa de la precisión de los paquetes.


2

No siempre es claro. Sin embargo, si necesita una entrega garantizada de paquetes sin pérdida y en la secuencia correcta, entonces TCP es probablemente lo que desea.

Por otro lado, UDP es apropiado para transmitir paquetes cortos de información donde la secuencia de la información es menos importante o donde los datos pueden caber en un solo paquete.

También es apropiado cuando desea transmitir la misma información a muchos usuarios.

Otras veces, es apropiado cuando envía datos secuenciados, pero si parte de ellos se pierde, no le preocupa demasiado (por ejemplo, una aplicación VOIP).

Algunos protocolos son más complejos porque lo que se necesita son algunas (pero no todas) de las características de TCP, pero más de lo que proporciona UDP. Ahí es donde la capa de aplicación tiene que implementar la funcionalidad adicional. En esos casos, UDP también es apropiado (por ejemplo, radio por Internet, el orden es importante pero no todos los paquetes deben pasar).

Ejemplos de dónde está / podría usarse 1) Un servidor horario que transmite la hora correcta a un montón de máquinas en una LAN. 2) Protocolos VOIP 3) Búsquedas DNS 4) Solicitar servicios LAN, por ejemplo, ¿dónde está? 5) Radio por Internet 6) y muchos otros ...

En Unix, puede escribir grep udp / etc / services para obtener una lista de los protocolos UDP implementados hoy ... hay cientos.


2

Mire la sección 22.4 de la Programación de red Unix de Steven , "Cuándo usar UDP en lugar de TCP".

Además, vea esta otra respuesta SO sobre la idea errónea de que UDP siempre es más rápido que TCP .

Lo que dice Steven se puede resumir de la siguiente manera:

  • Use UDP para transmisión y multidifusión ya que esa es su única opción (use multidifusión para cualquier aplicación nueva)
  • Puede usar UDP para aplicaciones simples de solicitud / respuesta, pero necesitará incorporar sus propios ataques, tiempos de espera y retransmisiones
  • No use UDP para la transferencia masiva de datos.

1
Un poco más de información sobre ese último punto, para cualquiera que se presente. TCP funciona para la transferencia masiva de datos, pero si no le importa que sus datos lleguen en orden de principio a fin, puede escribir un protocolo sobre UDP que podría ser más rápido, mucho más rápido en casos patológicos muy específicos. No es que no pueda hacer una transferencia masiva en UDP, no es que siempre tenga un peor desempeño; es tan difícil de implementar que raramente vale la pena molestarse.
ijw

1
Sí, puede usar UDP para la transferencia masiva y debe implementar su propio mecanismo de control. Si es un dolor de cabeza o no depende de tus habilidades de programación, pero definitivamente no siempre es peor. Tienes que saber lo que estás haciendo; Si no lo hace, sí, puede sufrir.
Andy

2

Sabemos que el UDP es un protocolo sin conexión, por lo que es

  1. adecuado para procesos que requieren una comunicación simple de solicitud-respuesta.
  2. adecuado para procesos que tienen flujo interno, control de errores
  3. adecuado para fundición amplia y multidifusión

Ejemplos específicos:

  • utilizado en SNMP
  • utilizado para algunos protocolos de actualización de ruta como RIP

2

Comparando TCP con UDP, los protocolos sin conexión como UDP aseguran la velocidad, pero no la confiabilidad de la transmisión de paquetes. Por ejemplo, en los videojuegos generalmente no se necesita una red confiable, pero la velocidad es lo más importante y el uso de UDP para juegos tiene la ventaja de reducir el retraso de la red.

ingrese la descripción de la imagen aquí


1

Desea usar UDP sobre TCP en los casos en que la pérdida de algunos datos en el camino no arruinará por completo los datos que se transmiten. Muchos de sus usos son en aplicaciones en tiempo real, como juegos (es decir, FPS, donde no siempre tienes que saber dónde está cada jugador en un momento dado, y si pierdes algunos paquetes en el camino, nuevo los datos le dirán correctamente dónde están los jugadores de todos modos) y la transmisión de video en tiempo real (un cuadro dañado no arruinará la experiencia de visualización).


Bueno, un cuadro corrupto arruinará esa parte de la visualización, pero no desea que se bloquee todos los últimos cuadros, mientras lo espera, si los cuadros posteriores tienen más valor que el cuadro perdido.
Simeon Pilgrim

1

Tenemos un servicio web que tiene miles de clientes winforms en la misma cantidad de PC. Las PC no tienen conexión con el backend DB, todo el acceso es a través del servicio web. Por lo tanto, decidimos desarrollar un servidor de registro central que escuche en un puerto UDP y todos los clientes envíen un paquete de registro de errores xml (utilizando el apéndice UDP log4net) que se descarga en una tabla DB al recibirlo. Dado que realmente no nos importa si se pierden algunos registros de errores y con miles de clientes, es rápido con un servicio de registro dedicado que no carga el servicio web principal.


0

Soy un poco reacio a sugerir UDP cuando TCP podría funcionar. El problema es que si TCP no funciona por alguna razón, debido a que la conexión es demasiado lenta o congestionada, es poco probable que cambiar la aplicación para usar UDP no sea útil. Una mala conexión también es mala para UDP. TCP ya hace un muy buen trabajo al minimizar la congestión.

El único caso que se me ocurre cuando se requiere UDP es para protocolos de difusión. En los casos en que una aplicación involucra dos hosts conocidos, es probable que UDP solo ofrezca beneficios de rendimiento marginal para un aumento sustancial de los costos de la complejidad del código.


Una aplicación en la que obtendrá mejores resultados de UDP es a través de la prueba de puesta, si un nodo intermedio está realizando la vigilancia del tráfico, ya que puede controlar la velocidad del paquete más fácilmente, ver el TCP que empujará los paquetes rápidamente y la interacción del TCP Las ventanas interactúan negativamente con la vigilancia.
Simeon Pilgrim

Esto sigue siendo una optimización, que debe seguir a las pruebas reales. Mi argumento es que aún debe intentar usar TCP primero, y solo probar alternativas cuando descubra que TCP no funciona por alguna razón. Elegir UDP porque teóricamente admite un mejor uso del ancho de banda es una forma de optimización prematura.
SingleNegationElimination

Oh, de acuerdo en el frente de optimización. Pero saber cuándo TCP podría ser el verso del problema, algo más ayuda cuando intentas resolver ese problema de rendimiento.
Simeon Pilgrim

-1

Solo use UDP si realmente sabe lo que está haciendo. UDP se encuentra en casos extremadamente raros hoy en día, pero el número de expertos (incluso con mucha experiencia) que tratarían de mantenerlo en todas partes parece estar fuera de proporción. Quizás disfruten implementando ellos mismos el código de manejo de errores y mantenimiento de la conexión.

Debería esperarse que TCP sea mucho más rápido con las tarjetas de interfaz de red modernas debido a lo que se conoce como impresión de suma de verificación . Sorprendentemente, a velocidades de conexión rápidas (como 1 Gbps), calcular una suma de verificación sería una gran carga para una CPU, por lo que se descarga al hardware NIC que reconoce los paquetes TCP para impresión, y no le ofrecerá el mismo servicio.


2
La descarga de suma de verificación UDP está disponible al igual que la descarga de suma de verificación TCP.
Ben Voigt

pero no validación de suma de verificación.
Pavel Radzivilovsky

1
Incluso los adaptadores de Ethernet de nivel de consumidor de hoy en día tienen descarga de suma de comprobación UDP tanto para transmitir como para recibir (la descarga de recepción está validando). Y vi esa característica en el hardware prosumidor hace una década, estoy seguro de que ha estado en las NIC de clase de servidor incluso más tiempo.
Ben Voigt

-2

UDP es perfecto para VoIP direccionado donde se debe enviar un paquete de datos, menos su confiabilidad ... El chat de video es un ejemplo de UDP (puede verificarlo mediante la captura de la red wirehark durante cualquier chat de video). Además, TCP no funciona con Protocolos DNS y SNMP. UDP no tiene ninguna sobrecarga, mientras que TCP tiene mucha sobrecarga

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.