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

25

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é?

mallea
la source
6
Pourquoi chaque application fournirait-elle son propre mécanisme de fiabilité alors qu'elle peut simplement s'appuyer sur un autre protocole largement disponible comme TCP?
Nakrule
14
et comment proposez-vous d'implémenter la fiabilité au niveau de la couche application sans ralentir la pile?
JFL
6
" Étant donné que l'en-tête UDP est plus petit que celui de TCP, nous pouvons tirer parti de la taille des données. " Le problème avec cette réflexion est que vous mangerez probablement une grande partie de la charge utile UDP avec des en-têtes de protocole de couche application qui diminueront les données utilisables dans le Charge utile UDP. La différence entre la taille d'en-tête TCP et UDP n'est que de 12 octets. De plus, UDP est vraiment conçu pour les petites charges utiles, par exemple 576 octets; rappelez-vous que UDP perdra simplement les datagrammes, et plus il y a de données dans un datagramme, plus il y a de données perdues quand un datagramme est perdu.
Ron Maupin
21
Stack Overflow regorge de programmeurs essayant, et échouant, de créer des protocoles de type TCP en utilisant UDP. Les programmeurs les plus expérimentés leur disent d'abandonner et d'utiliser simplement TCP. Ils pensent tous qu'ils peuvent faire un meilleur travail, mais c'est très peu probable.
Ron Maupin
11
Je sais que cela ne fait pas directement partie de votre question, mais une des raisons pour lesquelles UDP peut être meilleur est que vous ne pouvez implémenter que les pièces de fiabilité dont vous avez besoin. Avec TCP, vous obtenez la fiabilité de la commande et de la livraison. Cela signifie que TCP peut avoir un hoquet pendant qu'il attend qu'un message précédent soit renvoyé. Avec UDP, vous pouvez décider que tout ce que vous voulez est la livraison, mais si un message arrive en panne, vous n'attendez pas les manquants, vous les jetez simplement. Le piège auquel les gens se heurtent tente de répliquer TCP à 100%. Dans ce cas, utilisez simplement TCP.
William Mariager

Réponses:

47

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. ]

jonathanjo
la source
7
Les protocoles personnalisés "UDP avec fiabilité" sont également extrêmement courants dans les jeux vidéo. Il existe une tonne de bibliothèques de mise en réseau avec diverses implémentations. Ils veulent généralement que les paquets soient commandés et aient une correction d'erreur, sans vouloir la retransmission des paquets perdus (et recevoir des retards de tous les futurs paquets).
BlueRaja - Danny Pflughoeft
On dirait que vous dites "TCP est la solution générale optimale, donc il permet de le supporter nativement". +1
ikegami
1
@ BlueRaja-DannyPflughoeft Et parfois vous voulez des paquets fiables non ordonnés (par exemple des effets visuels appliqués aux joueurs à proximité).
user253751
@ BlueRaja-DannyPflughoeft si vous avez un exemple de bibliothèque de protocoles typique, je serai heureux d'intégrer dans la réponse
jonathanjo
1
@jonathanjo J'ai utilisé lidgren , qui prend en charge 5 méthodes de livraison différentes ( faites défiler vers le bas) . Unity et Unreal Engine ont également leurs propres API de mise en réseau qui sont construites sur UDP.
BlueRaja - Danny Pflughoeft
10

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à.

Andrea Corbellini
la source
QUIC a une caractéristique un peu différente de TCP. Dans certains cas (réseau fiable ou pas le cryptage nécessaire) , il est en fait plus lent: quora.com/...
capricieuse
Vous pouvez également ajouter des canaux de données WebRTC à la liste qui utilise UDP via sctp. En fait, lorsque les connexions UDP ne sont pas possibles entre pairs, WebRTC basculera sur TCP, ce qui entraînera une baisse notable des performances.
JSON
@freakish slower est une généralisation dans ce cas. Par exemple, QUIC ajoute des données supplémentaires aux paquets pour réduire la retransmission, ce qui affecte le débit mais pas la latence.
JSON
4

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.

Zac67
la source
3
"Vous pouvez utiliser UDP pour implémenter la fonctionnalité TCP au niveau de la couche application (fiabilité, adaptabilité)" - je crois que c'est pratiquement ainsi que QUIC, µTP et souvent SCTP sont déjà implémentés. (Malgré cela, je les considère généralement comme étant dans la moitié supérieure de la couche de transport, tandis que UDP se trouve dans la moitié inférieure.)
grawity
1
@grawity Cela dépend de votre POV - du point de vue de l'application, une couche intermédiaire est une extension de la couche de transport. Officiellement et du point de vue du réseau (appareil), tout cela fait partie de la couche application.
Zac67
4

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é?

Bill K
la source
3

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.

bizarre
la source
1

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.

Tomachi
la source
0

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.

Jaybers
la source
Vous pourriez décrire ces fonctionnalités supplémentaires comme une question de fiabilité, en fin de compte.
user207421