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

Question

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?

Answer 1

UDP es más rápido que TCP, y la sencilla razón es que no existe un paquete de reconocimiento (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 más información recomiendo el sencillo, pero muy comprensible. Explicación de Skullbox (TCP vs.UDP)

Answer 2

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

A mayor escala, este comportamiento de TCP es lo que evita que Internet caiga en un "colapso de congestión".

Cosas que tienden a impulsar las aplicaciones hacia UDP:

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

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

• Hostilidad:En una fiesta LAN, es posible que no le importe si su navegador web funciona bien siempre y cuando envíe actualizaciones a la red lo más rápido posible.

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

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

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

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

Potencialmente, puede superar algunos problemas de latencia y rendimiento de TCP "conectando" varias conexiones TCP juntas;iSCSI hace esto para sortear 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).

Answer 3

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 los datos en un buffer y llenar un segmento de red completo, haciendo así un uso más eficiente del ancho de banda disponible.

UDP, por otro lado, coloca el paquete en el cable inmediatamente, congestionando así la red con muchos paquetes pequeños.

Probablemente no debería utilizar UDP a menos que tenga una razón muy específica para hacerlo.Especialmente porque puedes darle a TCP el mismo tipo de latencia que a 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).

Answer 4

con tolerancia a pérdidas

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

Básicamente, UDP no es "tolerante a pérdidas".Puedes enviar 100 paquetes a alguien y es posible que solo reciba 95 de esos paquetes y que algunos estén en el orden incorrecto.

Para cosas como transmisión de video y 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 demás cosas, un paquete faltante o "reorganizado" es fundamental.Tendría que escribir algún código adicional para ejecutarlo sobre UDP para volver a intentarlo si se omitieron cosas y hacer cumplir el orden correcto.Esto agregaría un poco de gastos generales en ciertos lugares.

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

Piénsalo de esta manera:Si se pierde un paquete, ¿preferiría obtener el siguiente paquete lo más rápido posible y continuar (use UDP), o realmente necesita los datos que faltan (use TCP)?Los gastos generales no importarán a menos que se encuentre en un escenario realmente extremo.

Answer 5

Qué protocolo 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.Roberto 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 de la red que utilizan TCP detectarán la "congestión" y reducirán sus tasas de envío.Sin embargo, UDP no tiene ningún mecanismo para evitar o controlar la congestión, y los remitentes que usan UDP continuarían enviando datos al mismo ritmo.Gradualmente, los remitentes TCP reducirían sus tasas de envío al mínimo y si los remitentes UDP tienen suficientes datos para enviar a través de la red, acapararían la mayor parte del ancho de banda disponible.Entonces, en tal caso, los remitentes UDP tendrán un mayor rendimiento, ya que obtienen la mayor parte 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, de utilizar las aplicaciones TCP para mejorar el rendimiento es abriendo múltiples conexiones TCP.De esa manera, aunque el rendimiento de cada conexión TCP pueda 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.

Answer 6

Cada conexión TCP requiere un protocolo de enlace inicial antes de que se transmitan los datos.Además, el encabezado TCP contiene una gran cantidad de sobrecarga destinada 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.

Answer 7

@Andrés, Siento disentir.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 necesitará multidifusión.Si es así, utilice UDP.

Answer 8

Cuando se habla de "qué es más rápido", hay al menos dos aspectos muy diferentes:rendimiento y latencia.

Si hablando de rendimiento - El control de flujo de TCP (como se menciona en otras respuestas) es extremadamente importante y hacer algo comparable con UDP, si bien es ciertamente posible, sería un gran dolor de cabeza (tm).Como resultado, usar UDP cuando lo necesite rendimiento, rara vez se considera una buena idea (a menos que desee obtener una ventaja injusta sobre TCP).

Sin embargo, si se habla 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 paquete, TCP esperará la retransmisión durante al menos 200 ms (1 segundo según el párrafo 2.4 de RFC6298, pero las implementaciones prácticas modernas 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). Por cierto, este efecto, conocido como Jefe de -Bloqueo de línea, es inherente a todos los flujos ordenados confiables, ya sean TCP o UDP confiable+ordenado.Para empeorar aún más 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 una pérdida de paquetes del 1% (lo cual no está mal para los estándares actuales) y tenemos un juego con 20 actualizaciones por segundo, esos retrasos 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 la razón por la que los desarrolladores de juegos suelen preferir UDP a TCP.

Sin embargo, cuando se utiliza 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, todo depende de CÓMO se utiliza 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 "ordenada confiable", todavía tienen que sufrir el bloqueo de cabecera de línea (por lo tanto, en caso de una doble pérdida de paquetes, en lugar de esos 600 ms obtendremos alrededor de 1,5*2*RTT - o para un RTT bastante bueno de 80 ms, es un retraso de ~250 ms, lo cual es una mejora, pero aún es posible hacerlo mejor).Por otro lado, si se utilizan técnicas discutidas en http://gafferongames.com/networked-physics/snapshot-compression/ y/o http://ithare.com/udp-from-mog-perspective/#low-latency-compression , ES posible eliminar por completo el bloqueo de cabecera de línea (por lo que, para una pérdida de doble paquete para un juego con 20 actualizaciones/segundo, el retraso será de 100 ms independientemente del 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 del 6-9% de firewalls feos que bloquean UDP), no parece Para ser una forma de implementar UDP sobre TCP sin incurrir en demasiadas latencias, consulte aquí: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (asegúrate de leer los comentarios también (!)).

Answer 9

Si necesita enviar rápidamente un mensaje a través de la red entre dos IP que ni siquiera se han comunicado todavía, entonces un UDP llegará al menos 3 veces más rápido, generalmente 5 veces más rápido.

Answer 10

En mi experiencia, UDP es un poco más rápido, pero no mucho.La elección no debe hacerse sobre el rendimiento sino sobre el contenido del mensaje y las técnicas de compresión.

Si es un protocolo con mensaje intercambio, Yo sugeriría que el ligero impacto en el rendimiento que recibe con TCP vale la pena.Se le proporciona una conexión entre dos puntos finales que le brindará todo lo que necesita.No intente fabricar su propio protocolo bidireccional confiable sobre UDP a menos que esté realmente seguro de lo que está emprendiendo.

Answer 11

Tenga en cuenta que TCP normalmente mantiene varios mensajes por 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 requerirá una increíble cantidad de trabajo.Existen aplicaciones válidas de UDP, pero si hace esta pregunta, la suya probablemente no lo sea.

Answer 12

Simplemente dejaré las cosas claras. TCP/UDP Son dos coches los que circulan por la carretera.Supongamos que las señales de tráfico y los obstáculos son errores. tcp cuida las señales de tráfico, respeta todo lo que le rodea.Conducción lenta porque le puede pasar algo al coche.Mientras UDP Simplemente se marcha, a toda velocidad sin respetar 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á.Mientras tcp se asegura de que todos los paquetes se envíen y reciban perfectamente, sin errores, por lo que el automóvil simplemente pasa obstáculos sin chocar.Espero que este sea un buen ejemplo para que entiendas, ¿Por qué? UDP Se prefiere en los juegos.Los juegos necesitan velocidad. tcp se prefiere en las descargas o los archivos descargados pueden estar dañados.

Answer 13

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

SCTP

Es un protocolo de capa de transporte independiente, pero se puede utilizar 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 perillas y giros para encender.

• para la entrega de mensajes
• Retransmisión automática de mensajes perdidos, con parámetros definidos por el usuario.

si algo de esto es necesario 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 patentada más similar

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

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

Answer 14

No tiene sentido hablar de TCP o UDP sin tener en cuenta el estado 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.

Answer 15

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

Tres cosas que quiero agregar a la discusión:

1. Puedes encontrar aquí 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 su pregunta usted mismo midiendo.
3. Implementé un punto de referencia en Python (ver esta pregunta SO).En promedio, 10^6 iteraciones, la diferencia para enviar 8 bytes es de aproximadamente 1 a 2 microsegundos para UDP.