UDP vs TCP, ¿cuánto más rápido es? [cerrado]

Para el intercambio de mensajes de protocolo general, que puede tolerar cierta pérdida de paquetes. ¿Cuánto más eficiente es UDP sobre TCP?

UDP es más rápido que TCP, y la razón simple es porque su paquete de reconocimiento inexistente (ACK) que permite un flujo continuo de paquetes, en lugar de TCP que reconoce un conjunto de paquetes, calculado utilizando el tamaño de la ventana TCP y el tiempo de ida y vuelta (RTT)

Para obtener más información, recomiendo la explicación simple pero muy comprensible de Skullbox (TCP vs. UDP)

La gente dice que lo más importante que TCP le brinda es la confiabilidad. Pero eso no es realmente cierto. Lo más importante que TCP le brinda es el control de congestión: puede ejecutar 100 conexiones TCP a través de un enlace DSL, todo a una velocidad máxima, y ​​las 100 conexiones serán productivas, porque todas "perciben" el ancho de banda disponible. Pruebe eso con 100 aplicaciones UDP diferentes, todas enviando paquetes lo más rápido posible, y vea qué tan bien funcionan las cosas para usted.

En una escala mayor, este comportamiento TCP es lo que evita que Internet se bloquee en un "colapso de congestión".

Cosas que tienden a empujar las aplicaciones hacia UDP:

• Semántica de entrega grupal: es posible hacer una entrega confiable a un grupo de personas mucho más eficientemente que el reconocimiento punto a punto de TCP.

• Entrega fuera de orden: en muchas aplicaciones, siempre que obtenga todos los datos, no le importa en qué orden llegue; puede reducir la latencia a nivel de aplicación aceptando un bloqueo fuera de orden.

• Antipático: en una fiesta LAN, es posible que no le importe si su navegador web funciona bien siempre que esté enviando actualizaciones a la red lo más rápido posible.

Pero incluso si le importa el rendimiento, probablemente no quiera usar UDP:

• Ahora está enganchado a la confiabilidad, y muchas de las cosas que puede hacer para implementar la confiabilidad pueden terminar siendo más lentas de lo que TCP ya hace.

• Ahora no es amigable con la red, lo que puede causar problemas en entornos compartidos.

• Lo más importante, los firewalls te bloquearán.

Potencialmente, puede superar algunos problemas de latencia y rendimiento de TCP "conectando" múltiples conexiones TCP juntas; iSCSI hace esto para evitar el control de congestión en las redes de área local, pero también puede hacerlo para crear un canal de mensajes "urgentes" de baja latencia (el comportamiento "URGENTE" de TCP está totalmente roto).

En algunas aplicaciones, TCP es más rápido (mejor rendimiento) que UDP.

Este es el caso cuando se realizan muchas escrituras pequeñas en relación con el tamaño de MTU. Por ejemplo, leí un experimento en el que se enviaba un flujo de paquetes de 300 bytes a través de Ethernet (MTU de 1500 bytes) y TCP era un 50% más rápido que UDP .

La razón es que TCP intentará almacenar en búfer los datos y completar un segmento de red completo, haciendo así un uso más eficiente del ancho de banda disponible.

UDP, por otro lado, pone el paquete en el cable inmediatamente, lo que congestiona la red con muchos paquetes pequeños.

Probablemente no debería usar UDP a menos que tenga una razón muy específica para hacerlo. Especialmente porque puede darle a TCP el mismo tipo de latencia que UDP deshabilitando el algoritmo de Nagle (por ejemplo, si está transmitiendo datos de sensores en tiempo real y no le preocupa congestionar la red con muchos paquetes pequeños).

con tolerancia a la pérdida

¿Quieres decir "con tolerancia a la pérdida"?

Básicamente, UDP no es "tolerante a pérdidas". Puede enviar 100 paquetes a alguien, y es posible que solo reciban 95 de esos paquetes, y algunos podrían estar en el orden incorrecto.

Para cosas como la transmisión de video y los juegos multijugador, donde es mejor perder un paquete que retrasar todos los demás paquetes detrás de él, esta es la opción obvia

Sin embargo, para la mayoría de las otras cosas, un paquete faltante o 'reorganizado' es crítico. Tendría que escribir un código adicional para ejecutarlo encima de UDP para volver a intentarlo si las cosas se perdieron, y aplicar el orden correcto. Esto agregaría un poco de sobrecarga en ciertos lugares.

Afortunadamente, algunas personas muy muy inteligentes han hecho esto, y lo llamaron TCP.

Piénselo de esta manera: si un paquete se pierde, preferiría obtener el siguiente paquete lo más rápido posible y continuar (use UDP), o realmente necesita esos datos faltantes (use TCP). La sobrecarga no importará a menos que se encuentre en un escenario realmente marginal.

El protocolo que funciona mejor (en términos de rendimiento), UDP o TCP, realmente depende de las características de la red y del tráfico de la red. Robert S. Barnes, por ejemplo, señala un escenario en el que TCP funciona mejor (escrituras de pequeño tamaño). Ahora, considere un escenario en el que la red está congestionada y tiene tráfico TCP y UDP. Los remitentes en la red que utilizan TCP detectarán la 'congestión' y reducirán sus tarifas de envío. Sin embargo, UDP no tiene ningún mecanismo para evitar la congestión o el control de congestión, y los remitentes que usan UDP continuarán bombeando datos a la misma velocidad. Gradualmente, los remitentes TCP reducirían sus tasas de envío al mínimo y si los remitentes UDP tienen suficientes datos para ser enviados a través de la red, acumularían la mayor parte del ancho de banda disponible. Entonces, en tal caso, Los remitentes UDP tendrán un mayor rendimiento, ya que obtienen el pastel más grande del ancho de banda de la red. De hecho, este es un tema de investigación activo: cómo mejorar el rendimiento de TCP en presencia de tráfico UDP. Una forma, que yo sepa, usando qué aplicaciones TCP pueden mejorar el rendimiento es abriendo múltiples conexiones TCP. De esa manera, aunque el rendimiento de cada conexión TCP puede ser limitado, la suma total del rendimiento de todas las conexiones TCP puede ser mayor que el rendimiento de una aplicación que utiliza UDP.

Cuando se habla de "lo que es más rápido", existen al menos dos aspectos muy diferentes: rendimiento y latencia.

Si se habla de rendimiento , el control de flujo de TCP (como se menciona en otras respuestas) es extremadamente importante y hacer algo comparable a través de UDP, aunque ciertamente posible, sería un gran dolor de cabeza (tm). Como resultado, usar UDP cuando necesita rendimiento , rara vez califica como una buena idea (a menos que desee obtener una ventaja injusta sobre TCP).

Sin embargo, si hablamos de latencias , todo es completamente diferente. Si bien en ausencia de pérdida de paquetes, TCP y UDP se comportan de manera extremadamente similar (cualquier diferencia, si la hay, es marginal): después de que se pierde el paquete, todo el patrón cambia drásticamente.

Después de cualquier pérdida de paquetes, TCP esperará la retransmisión durante al menos 200 ms (1 segundo por el párrafo 2.4 del RFC6298, pero las implementaciones modernas prácticas tienden a reducirlo a 200 ms). Además, con TCP, incluso aquellos paquetes que llegaron al host de destino no se entregarán a su aplicación hasta que se reciba el paquete faltante (es decir, toda la comunicación se retrasa ~ 200 ms) - BTW, este efecto, conocido como Head-of -El bloqueo de línea es inherente a todas las secuencias ordenadas confiables, ya sea TCP o confiable + UDP ordenado. Para empeorar las cosas, si el paquete retransmitido también se pierde, entonces hablaremos de un retraso de ~ 600 ms (debido al llamado retroceso exponencial, la primera retransmisión es de 200 ms y la segunda es de 200 * 2 = 400 ms). Si nuestro canal tiene un 1% de pérdida de paquetes (lo cual no es malo para los estándares actuales), y tenemos un juego con 20 actualizaciones por segundo: tales demoras de 600 ms se producirán en promedio cada 8 minutos. Y como 600 ms es más que suficiente para que te maten en un juego de ritmo rápido, bueno, es bastante malo para el juego. Estos efectos son exactamente por qué los gamedevs a menudo prefieren UDP sobre TCP.

Sin embargo, cuando se usa UDP para reducir las latencias, es importante darse cuenta de que simplemente "usar UDP" no es suficiente para obtener una mejora sustancial de la latencia, se trata de CÓMO está usando UDP. En particular, si bien las bibliotecas RUDP generalmente evitan ese "retroceso exponencial" y usan tiempos de retransmisión más cortos; si se usan como una secuencia "confiable ordenada", todavía tienen que sufrir Bloqueo de cabecera de línea (por lo tanto, en caso de un doble pérdida de paquetes, en lugar de esos 600 ms obtendremos aproximadamente 1.5 * 2 * RTT, o para un RTT de 80 ms bastante bueno, es un retraso de ~ 250 ms, lo cual es una mejora, pero aún es posible hacerlo mejor). Por otro lado, si usa técnicas discutidas en http://gafferongames.com/networked-physics/snapshot-compression/ y / o http: // ithare. , ES posible eliminar por completo el bloqueo de Head-of-Line (por lo que para una pérdida de doble paquete para un juego con 20 actualizaciones / segundo, el retraso será de 100 ms independientemente de RTT).

Y como nota al margen: si tiene acceso solo a TCP pero no a UDP (como en el navegador, o si su cliente está detrás de uno de 6-9% de firewalls feos que bloquean UDP), parece que hay una manera de implemente UDP-sobre-TCP sin incurrir en demasiadas latencias, consulte aquí: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (asegúrese de leer los comentarios también (!)).

Cada conexión TCP requiere un protocolo de enlace inicial antes de transmitir los datos. Además, el encabezado TCP contiene muchos gastos generales destinados a diferentes señales y detección de entrega de mensajes. Para un intercambio de mensajes, UDP probablemente será suficiente si una pequeña posibilidad de falla es aceptable. Si se debe verificar el recibo, TCP es su mejor opción.

@Andrés , le ruego que difiera. UDP es la opción en algunos tipos de aplicaciones debido a los requisitos de rendimiento. Un ejemplo clásico es la videoconferencia. Este tipo de aplicación no responde bien al control TCP.

Otro aspecto a tener en cuenta es si vas a necesitar multidifusión. Si es así, use UDP.

Si necesita enviar rápidamente un mensaje a través de la red entre dos IP que aún no han hablado, entonces un UDP llegará al menos 3 veces más rápido, generalmente 5 veces más rápido.

Solo dejaré las cosas claras. TCP / UDP son dos autos que se manejan en la carretera. supongamos que las señales de tráfico y los obstáculos son errores TCP se preocupa por las señales de tráfico, respeta todo a su alrededor. Conduzca despacio porque algo le puede pasar al automóvil. Si bien UDP simplemente se aleja, la velocidad máxima no respeta las señales de tráfico. Nada, un conductor loco. UDP no tiene recuperación de errores, si hay un obstáculo, simplemente chocará con él y luego continuará. Si bien TCP se asegura de que todos los paquetes se envíen y reciban perfectamente, no hay errores, por lo tanto, el automóvil simplemente pasa obstáculos sin chocar. Espero que este sea un buen ejemplo para que entiendas, ¿Por qué TCP? UDP es preferido en los juegos. El juego necesita velocidad. se prefiere en descargas, o los archivos descargados pueden estar dañados.

UDP es un poco más rápido en mi experiencia, pero no por mucho. No se debe elegir el rendimiento sino el contenido del mensaje y las técnicas de compresión.

Si se trata de un protocolo con intercambio de mensajes , sugeriría que el muy leve impacto en el rendimiento que recibe con TCP vale más que la pena. Te dan una conexión entre dos puntos finales que te dará todo lo que necesitas. No intente fabricar su propio protocolo bidireccional confiable sobre UDP a menos que esté realmente seguro de lo que está haciendo.

Tenga en cuenta que TCP generalmente mantiene múltiples mensajes en el cable. Si desea implementar esto en UDP, tendrá mucho trabajo si desea hacerlo de manera confiable. Su solución será menos confiable, menos rápida o una cantidad increíble de trabajo. Hay aplicaciones válidas de UDP, pero si hace esta pregunta, probablemente la suya no lo sea.

Se han realizado algunos trabajos para permitir que el programador tenga los beneficios de ambos mundos.

SCTP

Es un protolol de capa de transporte independiente, pero se puede usar como una biblioteca que proporciona una capa adicional sobre UDP. La unidad básica de comunicación es un mensaje (asignado a uno o más paquetes UDP). Hay control de congestión incorporado. El protocolo tiene botones y twiddles para encender

• en orden de entrega de mensajes
• retransmisión automática de mensajes perdidos, con parámetros definidos por el usuario

si se necesita algo de esto para su aplicación particular.

Un problema con esto es que el establecimiento de la conexión es un proceso complicado (y por lo tanto lento)

Otras cosas similares

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Una cosa experimental propietaria más similar

• https://en.wikipedia.org/wiki/QUIC

Esto también trata de mejorar el protocolo de enlace triple de TCP y cambiar el control de congestión para tratar mejor las líneas rápidas.

No tiene sentido hablar de TCP o UDP sin tener en cuenta la condición de la red. Si la red entre los dos puntos tiene una calidad muy alta, UDP es absolutamente más rápido que TCP, pero en algún otro caso, como la red GPRS, TCP puede ser más rápido y más confiable que UDP.

La configuración de la red es crucial para cualquier medición. Hace una gran diferencia, si se está comunicando a través de enchufes en su máquina local o con el otro extremo del mundo.

Tres cosas que quiero agregar a la discusión:

1. Puedes encontrar aqui un muy buen artículo sobre TCP vs. UDP en el contexto del desarrollo del juego.
2. Además, iperf ( jperf mejorar iperf con una GUI) es una herramienta muy buena para responder tu pregunta midiendo.
3. Implementé un punto de referencia en Python (ver esta pregunta SO ). En promedio de 10 ^ 6 iteraciones, la diferencia para enviar 8 bytes es de aproximadamente 1-2 microsegundos para UDP.