TCP o UDP para un juego multijugador?

Esta es una pregunta que veo mucho. La mayoría de la gente dice que UDP siempre es mejor para juegos en tiempo real que TCP. Según tengo entendido, TCP intenta reenviar paquetes una y otra vez hasta que el otro lado los recibe, mientras que a UDP no le importa.

La mayoría de las cosas que he leído es que UDP es imprescindible para cualquier juego en tiempo real y TCP es terrible. Pero la cuestión es que la mayoría de las personas parecen implementar alguna forma de TCP sobre UDP de todos modos. Y también escuché que la diferencia entre los dos es insignificante dado que ya no estamos en los 80 y que Internet ahora es bastante rápido y confiable.

¿Mi comprensión general aquí es incorrecta? ¿Alguien puede aclarar esto por mí?

game-development networking tcp

— flooblebit
fuente

internet is now pretty fast and reliableNo, no es. El ancho de banda ha aumentado dramáticamente, sí, pero la latencia sigue siendo bastante alta. Con TCP puro, necesita que el tiempo de tic del servidor sea mayor que la latencia máxima asequible, a menos que realice la compresión de paquetes, que se realiza mejor en el cliente a través de UDP. El problema es que cierta información en un juego debe ser confiable, mientras que otra debe ser rápida. Los protocolos personalizados además de UDP lo permiten, así como un montón de propietarios que le brindan todo lo que necesita en un paquete agradable.

— Ordous

No implementan exactamente TCP sobre UDP. Hay algunas características que ofrece TCP que son deseables y que se implementan sobre UDP. Un punto importante del uso de UDP es que si envía un paquete que contiene el estado mundial en un momento t0que nunca se recibe, entonces envía el nuevo estado mundial a tiempo t1, no tiene que esperar hasta que el cliente realmente reciba el primer paquete, que ya está obsoleto

— Vincent Savard

@Ordous Creo que esto responde a mi pregunta :) Gracias

— flooblebit

También tenga en cuenta que UDP es propenso a la suplantación de IP que podría hacer que su servidor esté abierto a ataques DDoS si eso es una preocupación. Puede evitar eso si tiene una conexión TCP de "control" que envía la dirección IP de los clientes y otros detalles al servidor que luego acepta los paquetes UDP de la dirección "autenticada". También es posible que tenga que implementar su propia capa de cifrado ya que no hay estándares abiertos para eso en UDP.

— ARau

@ blownie55 buenos puntos allí

— Naresh Kumar

Respuestas:

Depende de si está hablando de punto a punto, cliente / servidor con los usuarios que ejecutan el servidor, o cliente / servidor con un centro de datos que ejecuta el servidor. Solo en el último caso, Internet es realmente rápido y confiable. Equipos de los usuarios son no garantiza que sea rápido, y ciertamente no serán fiables.

UDP le permite un mayor control sobre el tipo de implementación tipo TCP que está realizando. Le brinda una mayor flexibilidad para ejecutar paquetes fuera de servicio, descartar paquetes que considere innecesarios mientras reintenta paquetes que considera importantes, ese tipo de cosas. Pero esto solo debe hacerse si es necesario y si tiene la experiencia necesaria.

Si puede prescindir de esa flexibilidad, TCP funciona lo suficientemente bien y le ahorra mucho tiempo. Incluso los estudios profesionales (como uno en el que trabajé) usan TCP si no necesitan absolutamente UDP, y tienen personas dedicadas a la programación en red.

— Kevin Fee
fuente

También sugeriría que "para qué" importa, por ejemplo, para un sistema de chat en el juego, ni siquiera consideraría UDP. La otra cosa que consideraría (al menos para el "servidor del cliente") es qué tan eficientemente el servidor puede manejar el tráfico: las NIC modernas tienen muchas cosas de "descarga" incorporadas para TCP (división y fusión de paquetes, clasificación de paquetes en flujos, etc) que están diseñados para reducir la sobrecarga de la CPU, y la mayoría de eso no puede funcionar para UDP.

— Brendan

Las cosas pueden cambiar ahora que QUIC ( en.wikipedia.org/wiki/QUIC ) que formará parte de HTTP / 3 que usa UDP y está encriptado usando TLS por defecto. Tomará algún tiempo para que esto esté ampliamente disponible y es algo que esperamos. Más detalles sobre algunos problemas que deben ser manejados aquí blog.cloudflare.com/the-road-to-quic

— ARau

Sería una suposición decir "Internet ahora es bastante rápido y confiable" como señaló @Ordous, y también es peligroso.

La razón por la cual el protocolo UDP + personalizado para los paquetes críticos para la entrega hace magia en la mayoría de los juegos es que, en ocasiones, podría estar "bien" si pierde algún paquete (solo para, por ejemplo, eventos secundarios no críticos para completar el juego) , también hay momentos en los que "no está del todo bien" perder algunos datos, por ejemplo, el movimiento del cursor, etc. (No me dedico al desarrollo del juego para vivir así que perdón por mis ejemplos vagos)

UDP no pierde el tiempo empujándolos una y otra vez, por defecto.

Y, por cierto, muchos juegos parecen tener paquetes "aceptables para perder a veces" más que "siempre deben entregarse sin fallas". Por lo tanto, hacer un ajuste natural para esta tarea.

Todo lo que se necesitaba en UDP era usar un protocolo personalizado que solo ayudara a entregar los paquetes "siempre necesitan entregar sin fallas" correctamente, dejando el resto de los datos del juego a merced de la conexión de red.

Ahora, decidir qué tipo de tráfico conforma la mayor parte de TUS datos que se transmitirán te ayudará a decidir mejor.

El punto en contra de TCP sería que el tiempo dedicado a los reintentos podría gastarse en enviar paquetes que importan AHORA.

También existe la posibilidad de que, si hay algún problema durante la transmisión, TCP podría caer en cascada en un escenario de juego más desglosado para el usuario, arruinando su experiencia en comparación con UDP + Custom Stack (Esta última parte es solo una corazonada. Dejaré esto a otros expertos aquí para comentar sobre esto. Me encantaría conocer las posibilidades de este escenario).

— Naresh Kumar
fuente