Quand on parle de "ce qui est plus rapide" - il y a au moins deux aspects très différents: le débit et la latence.
Si parler de débit - le contrôle de flux TCP (comme mentionné dans d'autres réponses), est extrêmement important et faire quelque chose de comparable sur UDP, bien que cela soit certainement possible, serait un gros mal de tête (tm). Par conséquent, l'utilisation d'UDP lorsque vous avez besoin d'un débit est rarement considérée comme une bonne idée (sauf si vous souhaitez obtenir un avantage indu sur TCP).
Cependant, si l'on parle de latences - le tout est complètement différent. Alors qu'en l'absence de perte de paquets, TCP et UDP se comportent de manière extrêmement similaire (toute différence, le cas échéant, étant marginale) - après la perte du paquet, le modèle entier change radicalement.
Après toute perte de paquets, TCP attendra la retransmission pendant au moins 200 ms (1 seconde par paragraphe 2.4 de la RFC6298, mais les implémentations modernes pratiques tendent à la réduire à 200 ms). De plus, avec TCP, même les paquets qui ont atteint l'hôte de destination - ne seront pas livrés à votre application jusqu'à ce que le paquet manquant soit reçu (c'est-à-dire que toute la communication est retardée de ~ 200 ms) - BTW, cet effet, appelé Head-of -Le blocage de ligne, est inhérent à tous les flux ordonnés fiables, qu'ils soient TCP ou UDP fiables + ordonnés. Pour aggraver encore les choses - si le paquet retransmis est également perdu, nous parlerons alors d'un retard de ~ 600 ms (en raison de ce que l'on appelle une interruption exponentielle, la première retransmission est de 200 ms et la seconde de 200 * 2 = 400 ms). Si notre canal a 1% de perte de paquets (ce qui n'est pas mauvais selon les normes actuelles), et nous avons un jeu avec 20 mises à jour par seconde - de tels retards de 600 ms se produiront en moyenne toutes les 8 minutes. Et comme 600 ms est plus que suffisant pour vous tuer dans un jeu au rythme rapide - eh bien, c'est assez mauvais pour le gameplay. Ces effets expliquent pourquoi gamedev préfère souvent UDP à TCP.
Cependant, lorsque vous utilisez UDP pour réduire les latences - il est important de réaliser que simplement "utiliser UDP" n'est pas suffisant pour obtenir une amélioration substantielle de la latence, tout dépend de COMMENT vous utilisez UDP. En particulier, bien que les bibliothèques RUDP évitent généralement cette «interruption exponentielle» et utilisent des temps de retransmission plus courts - si elles sont utilisées comme un flux «ordonné fiable», elles doivent quand même souffrir d'un blocage en tête de ligne (donc en cas de double perte de paquets, au lieu de ces 600 ms, nous obtiendrons environ 1,5 * 2 * RTT - ou pour un très bon RTT de 80 ms, c'est un retard de ~ 250 ms, ce qui est une amélioration, mais il est toujours possible de faire mieux). D'autre part, si vous utilisez des techniques décrites dans http://gafferongames.com/networked-physics/snapshot-compression/ et / ou http: // ithare. , il est possible d'éliminer complètement le blocage de tête de ligne (donc pour une perte de double paquet pour un jeu avec 20 mises à jour / seconde, le retard sera de 100 ms quel que soit le RTT).
Et en guise de remarque - si vous n'avez accès qu'à TCP mais pas à UDP (comme dans un navigateur, ou si votre client est derrière l'un des 6-9% de pare-feu laids bloquant UDP) - il semble y avoir un moyen de implémentez UDP-over-TCP sans encourir trop de latences, voir ici: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (assurez-vous de lire également les commentaires (!)).