Non, UDP reste supérieur en termes de latence des performances et sera toujours plus rapide, en raison de la philosophie des 2 protocoles - en supposant que vos données de communication ont été conçues pour UDP ou toute autre communication avec pertes en tête.
TCP crée une abstraction dans laquelle tous les paquets du réseau arrivent, et ils arrivent dans l'ordre exact dans lequel ils ont été envoyés. Pour mettre en œuvre une telle abstraction sur un canal avec perte, il doit implémenter des retransmissions et des délais d'attente, qui prennent du temps. Si vous envoyez 2 mises à jour sur TCP et qu'un paquet de la première mise à jour est perdu, vous ne verrez pas la deuxième mise à jour jusqu'à ce que:
- La perte de la première mise à jour est détectée.
- Une retransmission de la première mise à jour est demandée.
- la retransmission est arrivée et a été traitée.
Peu importe la rapidité avec laquelle cela est fait en TCP, car avec UDP, vous ignorez simplement la première mise à jour et utilisez la seconde, la plus récente, en ce moment. Contrairement à TCP, UDP ne garantit pas que tous les paquets arrivent et il ne garantit pas qu’ils arrivent dans l’ordre.
Pour cela, vous devez envoyer le bon type de données et concevoir votre communication de manière à ce que la perte de données soit acceptable.
Si vous avez des données où chaque paquet doit arriver et que les paquets doivent être traités par votre jeu dans l'ordre dans lequel ils ont été envoyés, UDP ne sera pas plus rapide. En fait, utiliser UDP dans ce cas serait probablement plus lent parce que vous reconstruisez TCP et que vous l'implémentez au moyen d'UDP, auquel cas vous pourriez aussi bien utiliser TCP.
EDIT - Ajout de quelques informations supplémentaires pour intégrer / adresser certains des commentaires:
Normalement, le taux de perte de paquets sur Ethernet est très faible, mais il devient beaucoup plus élevé une fois que le WiFi est impliqué ou si l'utilisateur a un téléchargement en cours. Supposons que nous avons une perte de paquets parfaitement uniforme de 0,01% (aller simple, pas aller-retour). Sur un jeu de tir à la première personne, les clients doivent envoyer des mises à jour chaque fois que quelque chose se passe, par exemple lorsque le curseur de la souris tourne le lecteur, ce qui se produit environ 20 fois par seconde. Ils pourraient également envoyer des mises à jour par image ou selon un intervalle fixe, soit 60 à 120 mises à jour par seconde. Étant donné que ces mises à jour sont envoyées à des moments différents, elles seront / devraient être envoyées dans un paquet par mise à jour. Dans une partie à 16 joueurs, les 16 joueurs envoient ces 20 à 120 paquets par seconde au serveur, ce qui donne un total de 320 à 120 paquets par seconde. Avec notre taux de perte de paquets de 0,01%, nous nous attendons à perdre un paquet toutes les 5,2 à 31,25 secondes.
Sur chaque paquet que nous recevons après le paquet perdu, nous enverrons un DupAck, et après le 3ème DupAck, l'expéditeur retransmettra le paquet perdu . Donc, le temps requis par TCP pour lancer la retransmission est de 3 paquets, plus le temps nécessaire au dernier DupAck pour arriver à l'expéditeur. Ensuite, nous devons attendre la retransmission pour arriver, donc nous attendons au total 3 paquets + 1 latence aller-retour. La latence aller-retour est généralement de 0 à 1 ms sur un réseau local et de 50 à 200 ms sur Internet. Trois paquets arriveront généralement en 25 ms si nous envoyons 120 paquets par seconde et en 150 ms si nous envoyons 20 paquets par seconde.
En revanche, avec UDP, nous récupérons un paquet perdu dès que nous obtenons le prochain paquet. Nous perdons donc 8,3 ms si nous envoyons 120 paquets par seconde et 50 ms si nous envoyons 20 paquets par seconde.
Avec TCP, les choses se gâtent si nous devons également prendre en compte Nagle (si le développeur oublie de désactiver la fusion des envois, ou ne peut pas désactiver les ACK retardés ), éviter la congestion du réseau ou si la perte de paquets est suffisamment grave pour que nous puissions en tenir compte plusieurs. pertes de paquets (y compris Ack et DupAck perdus). Avec UDP, nous pouvons facilement écrire du code plus rapide parce que nous ne nous soucions tout simplement pas d'être un bon citoyen du réseau, contrairement à TCP.