TCP a un blocage de tête de file d'attente, car il garantit une livraison complète et dans l'ordre, donc quand un paquet est perdu en transit, il doit attendre une retransmission du paquet manquant, tandis qu'UDP livre des paquets à l'application dès leur arrivée , y compris les doublons et sans aucune garantie qu'un paquet arrive ou l'ordre dans lequel il arrive (c'est vraiment essentiellement IP avec des numéros de port et une somme de contrôle (facultative) de charge utile ajoutée), mais c'est très bien pour la téléphonie, par exemple, où il est généralement n'a tout simplement pas d'importance quand quelques millisecondes d'audio sont manquantes, mais le retard est très ennuyeux, donc ne vous embêtez pas avec les retransmissions, vous déposez simplement les doublons, triez les paquets réorganisés dans le bon ordre pendant quelques centaines de millisecondes de tampon de gigue , et si les paquets n'apparaissent pas à temps ou pas du tout, ils sont simplement ignorés,possible interpolé là où il est pris en charge par le codec.
En outre, une partie importante de TCP est le contrôle de flux, pour vous assurer d'obtenir le plus de débit possible, mais sans surcharger le réseau (ce qui est un peu redondant, car un réseau surchargé supprimera vos paquets, ce qui signifie que vous devrez faire retransmets, ce qui nuit au débit), UDP n'a rien de tout cela - ce qui est logique pour des applications comme la téléphonie, car la téléphonie avec un codec donné a besoin d'une certaine quantité de bande passante, vous ne pouvez pas le "ralentir" et une bande passante supplémentaire également ne fait pas passer l'appel plus vite.
En plus des applications en temps réel / à faible latence, UDP est logique pour les très petites transactions, telles que les recherches DNS, simplement parce qu'il n'a pas d'établissement de connexion TCP et de surcharge de démontage, à la fois en termes de latence et en termes d'utilisation de la bande passante. Si votre demande est plus petite qu'un MTU typique et que la répétition l'est probablement aussi, vous pouvez faire cela en un seul aller-retour, sans avoir besoin de garder un état sur le serveur, et de contrôler le flux de commande et tout ce qui n'est probablement pas particulièrement utile pour de telles utilisations non plus.
Et puis, vous pouvez utiliser UDP pour créer vos propres remplacements TCP, bien sûr, mais ce n'est probablement pas une bonne idée sans une compréhension approfondie de la dynamique du réseau, les algorithmes TCP modernes sont assez sophistiqués.
En outre, je suppose qu'il convient de mentionner qu'il existe plus que UDP et TCP, tels que SCTP et DCCP. Le seul problème actuellement est que l'Internet (IPv4) regorge de passerelles NAT qui rendent impossible l'utilisation de protocoles autres que UDP et TCP dans les applications d'utilisateur final.