Pourquoi UDP avec fiabilité (implémenté au niveau de la couche Application) ne remplace-t-il pas TCP?

TCP offre une fiabilité au niveau de la couche transport, contrairement à UDP. Ainsi, UDP est rapide. Mais, un protocole au niveau de la couche application peut implémenter un mécanisme fiable lors de l'utilisation d'UDP.

En ce sens, pourquoi UDP avec fiabilité (implémenté sur la couche Application) ne remplace-t-il pas TCP dans le cas où UDP est plus rapide que TCP alors que nous avons besoin de fiabilité?

TCP est à peu près aussi rapide que vous pouvez faire quelque chose avec ses propriétés de fiabilité. Si vous avez seulement besoin, par exemple, d'un séquençage et d'une détection d'erreurs, UDP peut être fait pour fonctionner parfaitement bien. C'est la base de la plupart des protocoles en temps réel tels que la voix, le streaming vidéo, etc., où le décalage et la gigue sont plus importants que la correction d'erreur "absolue".

Fondamentalement, TCP dit que ses cours d' eau peuvent être invoquées par la suite. La vitesse dépend des différents temporisateurs, vitesses, etc. Le temps nécessaire pour résoudre les erreurs peut être imprévisible, mais les opérations de base sont aussi rapides que possible lorsqu'il n'y a pas d'erreurs. Si un système sait quelque chose sur les types d'erreurs qui sont probables, il pourrait être capable de faire quelque chose qui n'est pas possible avec TCP. Par exemple, si des erreurs sur un seul bit sont particulièrement probables, vous pouvez utiliser un codage correcteur d'erreurs pour ces erreurs sur les bits: cependant, cela est beaucoup mieux implémenté dans la couche liaison. Comme autre exemple, si de courtes rafales de perte de paquets entiers sont courantes, vous pouvez résoudre ce problème avec plusieurs transmissions sans attendre de perte, mais cela coûte évidemment cher en bande passante. Ou bien, ralentissez la vitesse jusqu'à ce que la probabilité d'erreur soit négligeable: également coûteux en bande passante. À la fin,

En termes d'implémentation, vous constaterez que les siècles de programmeur investis dans TCP le rendront plus rapide que tout ce que vous pourriez vous permettre de faire, ainsi que plus fiable dans les cas marginaux obscurs.

TCP fournit: une méthode omniprésente de connexion (essentielle lorsque les systèmes communicants n'ont pas de contrôle commun) donnant un flux d'octets fiable, ordonné (et dédupliqué), bidirectionnel, fenêtré, avec contrôle de la congestion sur les réseaux à sauts multiples à distance arbitraire.

Si une application ne nécessite pas d'ubiquité (votre logiciel s'exécute des deux côtés) ou n'a pas besoin de toutes les fonctionnalités de TCP, de nombreuses personnes utilisent de manière rentable d'autres protocoles, souvent au-dessus d'UDP. Les exemples incluent TFTP (minimaliste, avec une gestion des erreurs vraiment inefficace, QUIC qui est conçu pour réduire les frais généraux (toujours marqué comme expérimental), et des bibliothèques telles que lidgren, qui a un contrôle précis sur les fonctionnalités de fiabilité requises. [Merci commentateurs. ]

UDP avec fiabilité peut en effet se substituer à TCP. Nous en avons déjà un exemple: ça s'appelle QUIC .

De Wikipédia:

Entre autres applications, QUIC améliore les performances des applications Web orientées connexion qui utilisent actuellement TCP. Pour ce faire, il établit un certain nombre de connexions multiplexées entre deux points d'extrémité via le protocole UDP (User Datagram Protocol).

L'avantage d'utiliser UDP par rapport à la création d'un tout nouveau protocole de couche transport est que les routeurs et autres périphériques réseau le comprennent déjà.

Vous pouvez utiliser UDP pour implémenter la fonctionnalité TCP au niveau de la couche application (fiabilité, adaptabilité). Vous pourriez tout aussi bien utiliser TCP en premier lieu, sauf si quelque chose dont votre application a vraiment besoin ne peut pas être fait avec TCP. Si vous implémentez ces fonctions vous-même, vous finirez très probablement bien pire qu'avec TCP. La surcharge supplémentaire diminue également l'efficacité globale.

TCP n'est pas lent - il nécessite juste une poignée de main avant de transmettre et la fenêtre de transmission pour s'adapter au canal. Il peut très bien façonner son débit vers le canal de transmission à portée de main et s'adapter aux changements au cours du flux, ce que UDP ne peut pas faire (par lui-même).

Cependant, les protocoles au-dessus de la couche transport sont hors sujet ici.

Sur un réseau propre, ils sont assez équivalents. Il y a des cas où TCP se bloque pendant des périodes (Quelqu'un a-t-il déjà vu un écran HTTP se bloquer sur la charge?), Mais il ne fournira pas de déchets ou mélangera les paquets et abandonnera rarement complètement.

UDP peut donner à la couche application plus de contrôle sur le trafic au prix d'un énorme travail.

La réponse à votre question est, parfois, c'est fait de cette façon. Les jeux qui nécessitent une faible latence font souvent exactement cela. C'est beaucoup plus de travail, mais la capacité de contrôler exactement le nombre de paquets en attente que vous pouvez avoir et la fréquence à laquelle ils sont réessayés en vaut souvent la peine.

Donc, dans l'ensemble, la différence est que TCP est une très bonne implémentation à usage général, mais il y a des objectifs spécifiques que UDP peut faire que TCP fait très mal ou pas du tout - par exemple:

• NE JAMAIS abandonner (avec TCP, la connexion se bloque parfois et vous devez interrompre la connexion et la redémarrer)
• Envoi d'un flux rapide de paquets qui ne nécessitent pas de réponses et cela ne vous dérange pas d'en manquer occasionnellement (où seul le paquet le plus récent est important, tous les autres peuvent être supprimés) - pensez aux mises à jour de la position du jeu - vous pourriez en avoir un peu "Saut" plutôt qu'à chaque étape, mais vous obtenez le même résultat plus rapidement et de manière plus fiable.
• Traiter les réseaux aléatoires en analysant les pertes de paquets et en modifiant dynamiquement la fréquence et la rapidité de votre nouvelle tentative - peut-être même la taille maximale des paquets.

Mais en général, cela n'en vaut pas la peine, TCP est plutôt optimal, alors pourquoi faire tout le travail supplémentaire et ajouter une (grande) chance d'ajouter des bogues et des failles de sécurité?

UDP n'est pas rapide car c'est UDP. TCP n'est pas lent car c'est TCP.

Les deux protocoles sont conçus avec certaines garanties et TCP brut a plus de garanties que UDP brut.

Et la règle d'or est la suivante: le prix des garanties est la performance .

Rien ne vous interdit d'implémenter des garanties TCP sur UDP. Mais vous obtenez alors plus de garanties et vous devez donc en payer le prix. Par conséquent, vous réduisez les performances à TCP ou pire (en raison de la surcharge UDP). Sauf si vous connaissez une meilleure implémentation TCP, ce qui est peu probable. Et si vous le faites alors (espérons-le), vous le révélez et nous accélérons le TCP standard. Et nous sommes de retour là où nous avons commencé. :)

Vous pouvez également jouer avec ces garanties. Modifiez légèrement ceci, modifiez légèrement cela. Et puis vous vous retrouvez avec un protocole comme QUIC qui est sur UDP et il est très similaire à TCP + TLS. Dans de nombreux cas, il est plus rapide que TCP (bien que, selon cet article, la latence jusqu'à 5% et la mise en mémoire tampon jusqu'à 15%, ce qui n'est pas un gros problème), mais dans certains scénarios (par exemple, un réseau fiable ou pas besoin de chiffrement), il l'est en réalité plus lent (voir une explication ici ).

Vous pouvez également affaiblir ces garanties, puis cela a plus de sens. Par exemple, disons que vous diffusez en continu et que les anciens paquets ne sont donc pas intéressants. Seulement le plus récent. Mais la congestion est toujours importante. Vous prenez donc quelques garanties de TCP, mais pas toutes. Et oui, les gens le font (par exemple, les jeux en temps réel). Cela vous donne de meilleures performances au prix de certaines garanties.

Votre idée serait bonne dans l'espace lointain.

La bonne réponse est "cela dépend" et "car cela endommagerait le réseau dans son ensemble". TCP / IP est très gentil avec les réseaux et s'ajuste automatiquement à environ la bonne vitesse pour être rapide mais ne pas générer des tonnes de paquets de retour ICMP.

Lorsqu'un routeur avec pas assez de RAM reçoit soudainement beaucoup de n'importe quel type de paquet - disons de Tsunami, Bittorrent ou FDT - il le laisse tomber et renvoie à l'expéditeur un petit paquet de non-reconnaissance d'échec. Votre serveur UDP doit maintenant suivre et retransmettre cette partie manuellement. Certains routeurs FAI façonnent Bittorrent tant cela fait mal au tsunami?

Le protocole Tsunami utilise UDP avec un canal de contrôle en TCP. http://tsunami-udp.sourceforge.net/ J'ai trouvé une étude qui montre qu'elle est plus lente qu'une chose appelée FDT.

Le légendaire protocole Fast Data Transfer (FDT) du CERN est capable de saturer n'importe quel réseau en utilisant plusieurs flux TCP. Il est probablement plus rapide, car il provoque moins de retransmissions que le tsunami, qui inonde le réseau avec tant d'UDP, une partie ne le fait pas tout le long.

UDP est utilisé par des applications peu fiables: streaming audio, entrée / mise à jour de jeu IO, "ping" est en fait ICMP mais n'est pas garanti, Bittorrent, mosh ssh est incroyablement réactif, téléphonie VOIP, multidiffusion, DNS est envoyé via UDP AFAIK. Tout ce qui ne dérange pas le paquet manquant impair et peut "rattraper" instantanément.

TCP / IP était vraiment la meilleure invention qui permettait aux développeurs d'applications de définir et d'oublier. Un socket est une paire d'adresses IP et de ports, et a été conçu pour pouvoir être configuré et rester pendant des heures, des jours, voire des semaines sans se reconnecter. Email, web, IRC et littéralement toutes les applications tueuses utilisent TCP. Mais vous pouvez obtenir d'étranges pauses dans le téléchargement qui vont soudainement plus vite ... et dans l'espace lointain, les connexions peuvent expirer, ce qui rend les transferts de style tsunami meilleurs pour les transferts de fichiers interstellaires - vous pourriez être sur quelque chose là-bas !!

La preuve en est dans les remarques finales de cet extrait d'étude scientifique, qui mentionnent la distance croissante dont je parle concernant l'espace profond. De: https://uscholar.univie.ac.at/get/o:300623.pdf

Sans congestion, les performances de FDT et GridFTP avec TCP sont supérieures à Tsunami et UDT. Le débit le plus élevé de FDT est de 2,34 Gb / s avec un RTT de 1 ms, mais il diminue rapidement après 100 ms par rapport à GridFTP, qui fonctionne mieux que FDT lorsque la RTT de liaison est supérieure à 100 ms. Fait intéressant, le débit du tsunami n'a pas diminué avec l'augmentation du RTT, ce qui montre qu'il a le contrôle de congestion le plus efficace avec l'augmentation du RTT.

Là encore ... il existe en fait un protocole spatial qui ressemble beaucoup au courrier électronique, ce qui serait mieux pour l'espace. Les applications ne doivent pas se soucier des valeurs de délai d'expiration comme pour toujours.

TCP! = UDP + Fiabilité

TCP n'est pas simplement UDP avec une fiabilité accrue. TCP offre plus de fonctionnalités qu'une simple fiabilité. Vous pouvez lire à leur sujet dans de nombreux RFC.

N'importe laquelle de ces fonctionnalités "pourrait" être implémentée au niveau de la couche application. Finalement, il devient un point où vous commencez à réinventer la roue.

Pour n'en nommer que quelques-unes, TCP a ...

• Création et terminaison de connexions: effectue des prises de contact et des fermetures de connexions

• Contrôle de flux: garantit que l'expéditeur et le récepteur transmettent à des débits où les deux peuvent gérer le débit de données.

• Contrôle de congestion de bout en bout: permet aux nœuds d'extrémité de limiter leur débit en fonction des pertes. En savoir plus sur le démarrage lent, l'évitement de la congestion et la récupération rapide.

D'après mon expérience, UDP est utilisé lorsque la vitesse est un problème de fiabilité. Vous pouvez ajouter un niveau de fiabilité au niveau de l'application qui n'est pas 100% aussi fiable que TCP. Par exemple, si vous voulez toujours des performances rapides, vous pouvez implémenter la correction d'erreur directe (FEC) où vous transmettez les données plus d'une fois. Vous obtenez toujours de bonnes performances et un certain niveau de fiabilité (notez une fiabilité assez TCP) sans tout le bavardage aller-retour pour obtenir des paquets perdus. Le commerce est qu'il augmente l'utilisation du réseau mais peut convenir à des applications en temps réel comme les jeux ou le streaming.