networking - tabla - UDP vs TCP, ¿cuánto más rápido es?
tcp vs udp diferencias (15)
con pérdida tolerante
¿Te refieres a "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 pueden 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
Para la mayoría de las otras cosas, sin embargo, un paquete faltante o ''reorganizado'' es crítico. Tendría que escribir un código adicional para ejecutar en la parte superior de UDP para volver a intentar si se olvidaron cosas, y aplicar el orden correcto. Esto agregaría un poco de sobrecarga en ciertos lugares.
Afortunadamente, algunas personas muy inteligentes han hecho esto y lo han llamado 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 (usar UDP), o realmente necesita esa información faltante (use TCP). La sobrecarga no importará a menos que estés en un escenario realmente marginal.
Para el intercambio de mensajes de protocolo general, que puede tolerar alguna pérdida de paquetes. ¿Cuánto más eficiente es UDP sobre TCP?
Cada conexión TCP requiere un primer apretón de manos 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 sea suficiente si una pequeña posibilidad de falla es aceptable. Si se debe verificar el recibo, TCP es su mejor opción.
Cuando se habla de "lo que es más rápido", hay al menos dos aspectos muy diferentes: rendimiento y latencia.
Si hablamos de rendimiento - el control de flujo de TCP (como se menciona en otras respuestas), es extremadamente importante y hacer cualquier cosa comparable a través de UDP, aunque ciertamente es 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 muy similar (cualquier diferencia, si la hay, es marginal), una vez 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 por párrafo 2.4 de RFC6298, pero las implementaciones modernas prácticas tienden a reducirlo a 200 ms). Además, con TCP, incluso aquellos paquetes que alcanzaron el host de destino, no serán entregados a su aplicación hasta que se reciba el paquete faltante (es decir, toda la comunicación se retrasa en ~ 200 ms) - Por cierto, este efecto, conocido como Head of -Line Blocking, es inherente a todas las transmisiones ordenadas confiables, ya sea TCP o UDP confiable + ordenado. Para empeorar las cosas, si el paquete retransmitido también se pierde, entonces hablaremos de una demora de ~ 600 ms (debido a lo que se denomina retroceso exponencial, la primera retransmisión es de 200 ms y la segunda es 200 * 2 = 400 ms). Si nuestro canal tiene un 1% de pérdida de paquetes (lo que no está mal para los estándares actuales), y tenemos un juego con 20 actualizaciones por segundo, tales demoras de 600ms ocurrirán en promedio cada 8 minutos. Y como 600ms es más que suficiente para matarte en un juego vertiginoso, bueno, es bastante malo para el juego. Estos efectos son exactamente los motivos por los que los juegos 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 de latencia sustancial, todo se trata de CÓMO está usando UDP. En particular, mientras que las bibliotecas RUDP generalmente evitan ese "retroceso exponencial" y usan tiempos de retransmisión más cortos: si se usan como un flujo "confiable", aún deben sufrir un bloqueo de cabecera (por lo que en caso de un doble pérdida de paquetes, en lugar de esos 600ms obtendremos aproximadamente 1.5 * 2 * RTT, o para un RTT de 80ms bastante bueno, es un retraso de ~ 250ms, lo cual es una mejora, pero aún es posible hacerlo mejor). Por otro lado, si usa las técnicas descritas en http://gafferongames.com/networked-physics/snapshot-compression/ y / o http://ithare.com/udp-from-mog-perspective/#low-latency-compression , es posible eliminar el bloqueo de cabecera de línea por completo (por lo que para una pérdida de paquete doble para un juego con 20 actualizaciones / segundo, la demora 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 feos firewalls que bloquean UDP), parece que hay una manera de implementar UDP-over-TCP sin incurrir en demasiadas latencias, consulte aquí: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (asegúrese de leer también los comentarios (!)).
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 donde TCP tiene un mejor rendimiento (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 usan TCP detectarán la "congestión" y reducirán sus tasas de envío. Sin embargo, UDP no tiene ningún mecanismo para evitar la congestión o el control de la congestión, y los remitentes que usan UDP continuarían inyectando 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 enviar a través de la red, almacenarían la mayor parte del ancho de banda disponible. Por lo tanto, en tal caso, los remitentes UDP tendrán un mayor rendimiento, ya que obtienen la mayor cantidad de 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, mediante la cual las aplicaciones TCP pueden mejorar el rendimiento, es abriendo múltiples conexiones TCP. De esta forma, aunque el rendimiento de cada conexión TCP pueda estar limitado, la suma total del rendimiento de todas las conexiones TCP puede ser mayor que el rendimiento de una aplicación que utiliza UDP.
En algunas aplicaciones, TCP es más rápido (mejor rendimiento) que UDP.
Este es el caso cuando se hacen muchas pequeñas escrituras en relación con el tamaño de MTU. Por ejemplo, leí un experimento en el que se enviaba una secuencia de paquetes de 300 bytes a través de Ethernet (1500 bytes MTU) y el TCP era un 50% más rápido que UDP .
La razón es porque TCP tratará de almacenar los datos y llenar un segmento de red completo haciendo un uso más eficiente del ancho de banda disponible.
UDP, por otro lado, pone el paquete en el cable inmediatamente, con lo que congestiona la red con muchos paquetes pequeños.
Probablemente no deberías usar UDP a menos que tengas una razón muy específica para hacerlo. Especialmente dado que puede darle a TCP el mismo tipo de latencia que UDP desactivando el algoritmo Nagle (por ejemplo, si está transmitiendo datos de sensores en tiempo real y no está preocupado por congestionar la red con muchos paquetes pequeños).
La configuración de la red es crucial para cualquier medición. Hace una gran diferencia, si se está comunicando a través de sockets en su máquina local o con el otro lado del mundo.
Tres cosas que quiero agregar a la discusión:
- Puede encontrar here un muy buen artículo sobre TCP vs. UDP en el contexto del desarrollo de juegos.
- Además, iperf ( jperf mejora iperf con una GUI) es una herramienta muy buena para responder tu pregunta midiendo.
- Implementé un punto de referencia en Python (vea esta pregunta SO ). En promedio de 10 ^ 6 iteraciones, la diferencia para enviar 8 bytes es de aproximadamente 1-2 microsegundos para UDP.
La gente dice que lo más importante que te ofrece TCP es la fiabilidad. Pero eso no es realmente cierto. Lo más importante que TCP le brinda es el control de la congestión: puede ejecutar 100 conexiones TCP a través de un enlace DSL a toda velocidad, y las 100 conexiones serán productivas, ya que todas "perciben" el ancho de banda disponible. Pruébalo con 100 diferentes aplicaciones UDP, todas empujando paquetes tan rápido como puedan, y observa qué tan bien te salen las cosas.
En una escala mayor, este comportamiento de TCP es lo que evita que Internet se bloquee en un "colapso de la congestión".
Cosas que tienden a impulsar aplicaciones hacia UDP:
Semántica de entrega grupal: es posible realizar entregas confiables a un grupo de personas de manera mucho más eficiente que el reconocimiento punto a punto de TCP.
Entrega fuera de servicio: en muchas aplicaciones, siempre y cuando obtenga todos los datos, no importa qué orden llegue; puede reducir la latencia del nivel de la aplicación al aceptar un bloque fuera de servicio.
Incompatibilidad: en una fiesta de LAN, es posible que no le importe si su navegador web funciona bien siempre que esté enviando actualizaciones a la red tan rápido como sea posible.
Pero incluso si le importa el rendimiento, probablemente no quiera ir con UDP:
Ahora está a la vanguardia de la confiabilidad, y muchas de las cosas que podría hacer para implementar la confiabilidad pueden ser más lentas que lo que TCP ya hace.
Ahora no eres compatible con la red, lo que puede causar problemas en entornos compartidos.
Lo que es más importante, los firewalls lo bloquearán.
Es posible que supere algunos problemas de latencia y rendimiento de TCP al "enlazar" varias conexiones TCP juntas; iSCSI hace esto para evitar el control de congestión en redes de área local, pero también puede hacerlo para crear un canal de mensajes "urgente" de baja latencia (el comportamiento "URGENTE" de TCP está totalmente roto).
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 otro caso como la red GPRS, TCP puede ser más rápido y más confiable que UDP.
Se ha hecho algo de trabajo para permitir que el programador tenga los beneficios de ambos mundos.
SCTP
Es un protolol de capa de transporte independiente, pero puede usarse como una biblioteca que proporciona 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
Una cosa experimentada propietaria más similar
Esto también intenta mejorar el handshake triple de TCP y cambiar el control de congestión para tratar mejor las líneas rápidas.
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 lo que le rodea. Conducción lenta porque algo le puede pasar al automóvil. Mientras que UDP simplemente se va, a toda velocidad no respeta las señales de tráfico. Nada, un conductor enojado. UDP no tiene recuperación de errores. Si hay un obstáculo, simplemente colisionará con él y luego continuará. Mientras que TCP se asegura de que todos los paquetes se envíen y reciban a la perfección, no hay errores, por lo tanto, el automóvil simplemente pasa obstáculos sin colisionar. Espero que este sea un buen ejemplo para que entiendas, por qué UDP es preferible en los juegos. El juego necesita velocidad. TCP se prefiere en las descargas, o los archivos descargados pueden estar dañados.
Tenga en cuenta que TCP generalmente mantiene múltiples mensajes en el cable. Si desea implementar esto en UDP tendrá mucho trabajo si lo desea de manera confiable. Su solución va a ser menos confiable, menos rápida o una cantidad increíble de trabajo. Existen aplicaciones válidas de UDP, pero si hace esta pregunta, probablemente la suya no.
UDP es más rápido que TCP, y la razón simple es porque su paquete de confirmación inexistente (ACK) permite un flujo continuo de paquetes, en lugar de TCP que reconoce un conjunto de paquetes, calculado utilizando el tamaño de ventana TCP y el tiempo de ida y vuelta (RTT )
Para más información, recomiendo la explicación simple, pero muy comprensible de Skullbox (TCP vs. UDP)
UDP es un poco más rápido en mi experiencia, pero no por mucho. La elección no debe hacerse sobre el rendimiento sino sobre el contenido del mensaje y las técnicas de compresión.
Si se trata de un protocolo con intercambio de mensajes, sugeriría que vale la pena el pequeño golpe de rendimiento que llevas con TCP. Te dan una conexión entre dos puntos finales que te proporcionarán todo lo que necesitas. No intente fabricar su propio protocolo confiable de dos vías sobre UDP a menos que esté realmente seguro de lo que está haciendo.
@Andrew , me @Andrew diferir. UDP es la elecció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 de TCP.
Otro aspecto a tener en cuenta es si va a necesitar multidifusión. Si es así, usa UDP.