¿Por qué UDP + es un sistema de pedidos confiable de software más rápido que TCP?

Question

Algunos juegos actuales utilizan un sistema de red que transmite mensajes a través de UDP y garantiza que los mensajes sean confiables y estén ordenados.

Por ejemplo, RakNet es un popular motor de red de juegos. Utiliza solo UDP para sus conexiones y tiene un sistema completo para garantizar que los paquetes puedan ser confiables y ordenados si así lo desea.

Mi pregunta básica es, ¿qué pasa con eso? ¿No es TCP lo mismo que UDP ordenado y confiable? ¿Qué hace que sea mucho más lento que las personas tengan que reinventar la rueda básicamente?

Answer 1

General / Especialización

1. TCP es un sistema confiable de propósito general
2. UDP + lo que sea un sistema confiable de propósito especial.

Las cosas especializadas suelen ser mejores que las de uso general para las que están especializadas.

Transmisión / Mensaje

1. TCP está basado en transmisión
2. UDP está basado en mensajes

El envío de mapas discretos de información de juegos suele ser mejor para un paradigma basado en mensajes. Enviarlo a través de una secuencia es posible pero terriblemente ineficaz. Si desea enviar de manera confiable una gran cantidad de datos (transferencia de archivos), TCP es bastante efectivo. Es por eso que Bit-torrent usa UDP para mensajes de control y TCP para enviar datos.

Answer 2

Cambiamos de confiable a poco confiable en "league of legends" Hace aproximadamente un año debido a varias ventajas que desde entonces han demostrado ser ciertas:

1) La información anterior se vuelve irrelevante. Si envío un paquete de salud y no llega ... No quiero tener que esperar a que se reenvíe ese mismo paquete de salud cuando sé que ha cambiado.

2) El orden a veces no es necesario. Si envío diferentes mensajes a diferentes sistemas, puede que no sea necesario poner esos mensajes en orden. No fuerzo al cliente a esperar mensajes en orden.

3) No confiable no se respalda con mensajes ... es decir, espera de acuses de recibo, lo que significa que puede resolver los picos de pérdida mucho más rápidamente.

4) Puede controlar los reenvíos cuando sea necesariamente más eficiente. Como reempacar algo que no se envió a otro paquete. (TCP vuelve a empaquetar, pero puede hacerlo de manera más eficiente con conocimiento sobre cómo funciona su programa).

5) Control de flujo de mensajes, como descartar mensajes que son menos relevantes cuando la red aumenta repentinamente. El sistema de red puede elegir no reenviar mensajes menos relevantes cuando tiene un pico de pérdida. Con TCP, todavía tendría una cola de mensajes que intentan reenviar, lo que puede ser de menor prioridad.

6) Paquete de encabezado más pequeño ... realmente no necesito decir mucho sobre eso.

Answer 3

Hay mucha más diferencia entre UDP y TCP que solo la confiabilidad y la secuencia:

El meollo del asunto es el hecho de que UDP está sin conexión mientras que TCP está conectado . Esta simple diferencia conduce a una gran cantidad de otras diferencias que no voy a poder resumir razonablemente aquí. Puede leer el análisis a continuación para obtener muchos más detalles.

TCP - Análisis comparativo UDP

Answer 4

La respuesta en mi opinión son las dos palabras: "Control de congestión".

TCP hace todo lo posible para gestionar el ancho de banda de la ruta, para aprovecharla al máximo, pero para garantizar que haya espacio para otras aplicaciones. Esta es una tarea muy difícil, e inherentemente no es posible usar el 100% del ancho de banda el 100% del tiempo.

Con UDP, por otro lado, uno puede hacer su propio protocolo para enviar los paquetes al cable tan rápido como lo deseen; esto hace que el protocolo sea muy hostil para otras aplicaciones, pero puede obtener más "rendimiento". término corto. Por otro lado, es muy probable que si las condiciones son apropiadas, este tipo de protocolos podría contribuir a colapso de congestión .

Answer 5

TCP es un protocolo orientado a la transmisión, mientras que UDP es un protocolo orientado a mensajes. Por lo tanto, TCP hace más que solo confiabilidad y pedidos. Consulte esta publicación para obtener más detalles. Básicamente, los desarrolladores de RakNet agregaron la confiabilidad y el orden mientras lo mantenían como un protocolo orientado a mensajes, por lo que el resultado fue más liviano que TCP (que tiene que hacer más).

Answer 6

Este pequeño artículo es antiguo, pero sigue siendo bastante cierto cuando se trata de juegos. Explica los dos protocolos, y el caos que estas personas intentaron desarrollar un juego de Internet multijugador. " X-Wing vs Tie Fighter "

Lecciones aprendidas (Internet apesta)

Sin embargo, hay una advertencia para esto: corro / desarrollo un juego multijugador y he usado ambos. UDP fue mucho mejor para mi aplicación, pero mucha gente no podía jugar con UDP. Los enrutadores y demás bloquearon las conexiones. Así que cambié a "confiable" TCP Bueno ... ¿confiable? No lo creo. Envías un paquete, no hay errores, envías otro y se bloquea (excepción) en el medio del paquete. ¿Ahora qué paquetes lo hicieron? Entonces terminas escribiendo un protocolo confiable EN LA PARTE DE tcp, para simular UDP, pero estableces continuamente una nueva conexión cuando falla. Tomar sobre ineficiente.

UDP + Detener y esperar ARW = bueno

UDP + Protocolo de ventana deslizante = mejor

¿TCP + Protocolo de ventana deslizante con reconexión? = Granel sin valor. (En mi humilde opinión)

El otro efecto secundario son las aplicaciones multiproceso. TCP funciona bien para un tipo de sala de chat, ya que cada sala puede ser su propio hilo. Una sala puede albergar de 60 a 100 personas y funciona bien, ya que el hilo de la sala contiene los sockets para cada participante.

UDP, por otro lado, es mejor servido (IMO) por un hilo, pero cuando obtiene el paquete, debe analizarlo para averiguar de quién proviene (a través de la información enviada o RemoteEndPoint), luego pasar esos datos a el hilo de la sala de chat de una manera segura.

En realidad, tiene que hacer lo mismo con TCP, pero solo al conectarse.

Último punto. Recuerde que TCP simplemente generará un error y eliminará la conexión en cualquier momento, pero puede volver a conectarse en aproximadamente .5 segundos y enviar la misma información. La cosa más extraña con la que he trabajado.