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 (!)).