TLDR;
- TCP - orienté flux, nécessite une connexion, fiable, lent
- UDP - orienté message, sans connexion, peu fiable, rapide
Avant de commencer, rappelez-vous que tous les inconvénients de quelque chose sont une continuation de ses avantages . Il n'y a qu'un bon outil pour un travail, pas de panacée. TCP / UDP coexistent depuis des décennies, et pour une raison.
TCP
Il a été conçu pour être extrêmement fiable et il fait très bien son travail. C'est tellement complexe parce qu'il accomplit une tâche difficile: prouver un transport fiable sur le protocole IP non fiable.
Étant donné que toute la logique complexe de TCP est encapsulée dans la pile réseau, vous êtes libre de faire beaucoup de tâches de bas niveau laborieuses et sujettes aux erreurs dans la couche application.
Lorsque vous envoyez des données via TCP, vous écrivez un flux d'octets sur le socket de l'expéditeur où il est divisé en paquets, transmis dans la pile et envoyé sur le câble. Du côté du récepteur, les paquets sont réassemblés à nouveau en un flux continu d'octets.
Maintenir cette belle abstraction a un coût en termes de complexité et de performances. Si le premier paquet du flux d'octets est perdu, le récepteur retardera le traitement des paquets suivants même ceux qui sont déjà arrivés.
De plus, pour être fiable, TCP implémente ceci:
- TCP nécessite une connexion établie, ce qui nécessite 3 allers-retours (établissement de liaison à 3 voies "infâme").
- TCP a une fonction appelée «démarrage lent» lorsqu'il augmente progressivement la vitesse de transmission après l'établissement d'une connexion pour permettre à un récepteur de suivre les données.
- Chaque paquet envoyé doit être accusé de réception, sinon un expéditeur cessera d'envoyer plus de données
- Et ainsi de suite...
Tout cela est exacerbé dans les réseaux sans fil lents et peu fiables, tandis que TCP a été conçu pour les réseaux câblés où les retards sont prévisibles et la perte de paquets n'est pas si courante. De plus, comme beaucoup de gens l'ont déjà mentionné, pour certaines choses, TCP ne fonctionne tout simplement pas (DHCP). Cependant, le cas échéant, TCP fait toujours son travail exceptionnellement bien.
En utilisant une analogie avec le courrier, une session TCP est similaire à raconter une histoire à votre secrétaire qui la divise en courriers et envoie un service de courrier merdique à un éditeur. De l'autre côté, une autre secrétaire rassemble les courriers en un seul morceau de texte. Certains e-mails sont perdus, certains sont corrompus, une procédure très complexe est donc nécessaire pour une livraison fiable et votre article de 10 pages peut prendre beaucoup de temps pour parvenir à votre éditeur.
UDP
UDP, d'autre part, est orienté message, de sorte qu'un récepteur écrit un message (paquet) sur la socket, puis il est transmis à un récepteur tel quel, sans aucune division / assemblage.
Par rapport à TCP, sa spécification est très simple. Essentiellement, tout ce qu'il fait pour vous est d'ajouter une somme de contrôle au paquet afin qu'un récepteur puisse détecter sa corruption. Tout le reste doit être mis en œuvre par vous, développeur de logiciels. Maintenant, lisez la volumineuse spécification TCP et essayez de penser à en réimplémenter certaines parties.
Certaines personnes sont allées dans ce sens et ont obtenu des résultats très décents, au point que HTTP / 3 utilise QUIC - un protocole basé sur UDP. Cependant, c'est plus une exception. Les applications courantes d'UDP sont les applications de streaming audio / vidéo et de conférence comme Skype, Zoom ou Google Hangout où la perte de paquets n'est pas si importante par rapport à un délai introduit par TCP.