Qu'utilisez-vous lorsque vous avez besoin d'un UDP fiable?


92

Si vous avez une situation où une connexion TCP est potentiellement trop lente et une «connexion» UDP est potentiellement trop peu fiable, qu'utilisez-vous? Il existe différents protocoles UDP standard fiables, quelles expériences avez-vous avec eux?

Veuillez discuter d'un protocole par réponse et si quelqu'un d'autre a déjà mentionné celui que vous utilisez, envisagez de voter et d'utiliser un commentaire pour élaborer si nécessaire.

Je m'intéresse aux différentes options ici, dont TCP est à une extrémité de l'échelle et UDP à l'autre. Diverses options UDP fiables sont disponibles et chacune apporte certains éléments de TCP à UDP.

Je sais que souvent TCP est le bon choix, mais avoir une liste des alternatives est souvent utile pour aider à arriver à cette conclusion. Des choses comme Enet, RUDP, etc. qui sont construites sur UDP ont divers avantages et inconvénients, les avez-vous utilisés, quelles sont vos expériences?

Pour éviter tout doute, il n'y a plus d'informations, c'est une question hypothétique et j'espérais qu'elle susciterait une liste de réponses détaillant les différentes options et alternatives disponibles pour quelqu'un qui a besoin de prendre une décision.


1
Cette question semble être hors sujet car il s'agit d'un sondage pour les technologies
Dave Hillier

Ceux qui pensent que TCP est le meilleur dans tous les cas, veuillez lire: en.wikipedia.org/wiki/Bandwidth-delay_product
nullptr

Wikipedia a un joli tableau comparant divers aspects d'UDP, UDP Lite, TCP, Multipath TCP, SCTP, DCCP et RUDP . SCTP prend en charge la plupart des fonctionnalités de cette liste.
Evgeniy Berezovsky

@EugeneBeresovsky J'ai fait une petite recherche concernant le SCTP, la plupart des informations, y compris des réponses SO, datent de 2013 et avant La plupart des gens ont écrit à l'époque que l'adoption du SCTP était très faible.Je me demande comment ça se passe aujourd'hui? Aussi, voir ce fil stackoverflow.com/questions/1171555/…
Michael IV

L'adoption de @MichaelIvanov est vraiment faible. Mais si vous avez l'intention de l'utiliser dans votre centre de données, vous ne vous souciez pas de l'adoption à l'extérieur, tant que les commutateurs et les routeurs ne causent pas de problèmes (ce qui, dans un centre de données, ils ne devraient pas), et que vous avez un système d'exploitation et le support de la bibliothèque, qui peut être un problème, comme décrit dans l' une des réponses à la question à laquelle vous avez lié.
Evgeniy Berezovsky

Réponses:


25

Il est difficile de répondre à cette question sans quelques informations supplémentaires sur le domaine du problème. Par exemple, quel volume de données utilisez-vous? À quelle fréquence? Quelle est la nature des données? (par exemple, est-ce des données uniques, uniques? Ou est-ce un flux d'échantillons de données? etc.) Pour quelle plate-forme développez-vous? (par exemple bureau / serveur / intégré) Pour déterminer ce que vous entendez par «trop lent», quel support réseau utilisez-vous?

Mais en termes (très!) Généraux, je pense que vous allez devoir essayer très fort de battre TCP pour la vitesse, à moins que vous ne puissiez faire des hypothèses fermes sur les données que vous essayez d'envoyer.

Par exemple, si les données que vous essayez d'envoyer sont telles que vous pouvez tolérer la perte d'un seul paquet (par exemple, des données régulièrement échantillonnées où le taux d'échantillonnage est plusieurs fois supérieur à la bande passante du signal), vous pouvez probablement sacrifier une certaine fiabilité de la transmission en vous assurant que vous pouvez détecter la corruption des données (par exemple grâce à l'utilisation d'un bon CRC)

Mais si vous ne pouvez pas tolérer la perte d'un seul paquet, alors vous allez devoir commencer à introduire les types de techniques de fiabilité que TCP a déjà. Et, sans consacrer une quantité raisonnable de travail, vous constaterez peut-être que vous commencez à intégrer ces éléments dans une solution d'espace utilisateur avec tous les problèmes de vitesse inhérents.


4
Ok, je vais ajuster la question. Je suis plus intéressé par les avantages et les inconvénients des différents protocoles UDP fiables que par une réponse `` utiliser TCP '';)
Len Holgate

9
@Andrew - il est très FACILE de battre TCP dans deux cas: (1) votre application a des exigences de fiabilité plus légères que "toutes les données, toujours dans l'ordre, pas de doublons, pas de files d'attente excessives". Ou (2) vous utilisez la multidiffusion. UDP fiable est très courant pour les environnements de multidiffusion.
Tom

4
En outre, TCP souffre horriblement lorsqu'il est utilisé sur une connexion WAN (problèmes de longue distance). Pourquoi, simple. TCP utilise des fenêtres où les paquets de la fenêtre doivent être acquittés. Les protocoles ACK souffrent de la latence due à la distance de la ligne. Google: WAN TCP "speed of light"
Ajaxx

3
@Ajaxx, vous avez tout à fait raison à ce sujet, cependant, TCP / IP le fait exprès à cause de la dernière effondrement d'Internet. Si vous utilisez un protocole à haut débit sans aucun contrôle de congestion, honte à vous. Si vous possédez le réseau, devenez fou.
Kevin Nisbet

2
"où le taux d'échantillonnage est significativement plus élevé que le taux nyquist" - le taux d'échantillonnage est toujours deux fois le taux nyquist, par définition.
Steve le

27

Qu'en est-il du SCTP . C'est un protocole standard de l'IETF (RFC 4960)

Il a une capacité de segmentation qui pourrait aider à la vitesse.

Mise à jour: une comparaison entre TCP et SCTP montre que les performances sont comparables sauf si deux interfaces peuvent être utilisées.

Mise à jour: un bel article d'introduction .


C'est bien, je suis plus intéressé par les choses qui peuvent être construites sur UDP plutôt que sur IP, mais c'est certainement quelque chose qui s'inscrit dans l'espace des solutions.
Len Holgate

SCTP possède de nombreuses fonctionnalités intéressantes (telles que le multi-hébergement) et avec l'extension de fiabilité partielle (RFC 3758), c'est une option incroyablement flexible. Il est inclus dans les dernières versions du noyau Linux, mais pour Windows, vous devrez installer votre propre pile SCTP.
Andrew Johnson

6
SCTP peut être tunnelé sur UDP. tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt
Miles

Merci Miles, c'est un lien utile!
Len Holgate

1
Oui ... Mais quelque chose qui est construit sur UDP plutôt qu'au même niveau que UDP sera probablement plus facile à implémenter dans l'espace utilisateur, du moins sur Windows ...
Len Holgate

21

ENET - http://enet.bespin.org/

J'ai travaillé avec ENET en tant que protocole UDP fiable et j'ai écrit une version conviviale pour les sockets asynchrones pour un de mes clients qui l'utilise dans leurs serveurs. Cela fonctionne très bien mais je n'aime pas la surcharge que le ping d'égal à égal ajoute aux connexions autrement inactives; lorsque vous avez beaucoup de connexions, les envoyer régulièrement est un travail très chargé.

ENET vous donne la possibilité d'envoyer plusieurs «canaux» de données et que les données envoyées ne soient pas fiables, fiables ou séquencées. Il comprend également le ping peer to peer susmentionné qui agit comme un keep alive.


14

Nous avons des clients de l'industrie de la défense qui utilisent UDT (UDP-based Data Transfer) (voir http://udt.sourceforge.net/ ) et en sont très satisfaits. Je vois que c'est aussi une licence BSD amicale.


2
Pouvez-vous élaborer sur vos clients et leurs cas d'utilisation, notamment dans le secteur de la défense? Probablement pas, mais ça vaut le coup. J'ai en fait jeté l'idée à mes supérieurs à propos de l'UDT dans une application de transfert de fichiers, mais cela n'a pas encore vraiment abouti.
Thomas Owens

10

RUDP - Protocole de datagramme utilisateur fiable

Cela fournit:

  • Accusé de réception des paquets reçus
  • Windowing et contrôle de la congestion
  • Retransmission des paquets perdus
  • Overbuffering (plus rapide que le streaming en temps réel)

Il semble légèrement plus configurable en ce qui concerne le maintien en vie que ENet, mais cela ne vous donne pas autant d'options (c'est-à-dire que toutes les données sont fiables et séquencées, pas seulement les bits que vous décidez d'être). Il semble assez simple à mettre en œuvre.


Je regardais cela mais il ne semble pas y avoir beaucoup d'implémentations. Vous avez une recommandation?
Nicholas

Non désolé. Je n'ai pas fini par l'utiliser à la fin et j'allais toujours faire une implémentation à partir de zéro.
Len Holgate

9

Comme d'autres l'ont souligné, votre question est très générale, et si quelque chose est «plus rapide» que TCP dépend beaucoup du type d'application.

TCP est généralement aussi rapide que possible pour une diffusion fiable des données d'un hôte à un autre. Cependant, si votre application effectue beaucoup de petites rafales de trafic et attend des réponses, UDP peut être plus approprié pour minimiser la latence.

Il existe un juste milieu. L'algorithme de Nagle est la partie de TCP qui permet de garantir que l'expéditeur ne submerge pas le récepteur d'un grand flux de données, ce qui entraîne une congestion et une perte de paquets.

Si vous avez besoin de la livraison fiable et dans l'ordre de TCP, ainsi que de la réponse rapide d'UDP, et que vous n'avez pas à vous soucier de la congestion due à l'envoi de gros flux de données, vous pouvez désactiver l'algorithme de Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Comme je l'ai dit, en supposant que TCP est à une extrémité de l'échelle et UDP à l'autre, qu'y a-t-il d'autre.
Len Holgate

Si vous voulez être pédant, la plupart des protocoles discutés sont construits sur UDP.
smo le

L'hypothèse selon laquelle TCP est à une extrémité et UDP à l'autre extrémité est fausse. Par exemple, UDP n'a pas de contrôle de flux, vous pouvez facilement envoyer des paquets trop rapidement, ce qui oblige un routeur intermédiaire à tous les abandonner. Alors tu fais quoi? Ignorer les paquets perdus ou les renvoyer? Les renvoyer et vous finirez par réimplémenter TCP plus ou moins. Une autre option pour une communication fiable est SCTP.
nos

1
Une réponse rapide n'équivaut pas nécessairement à un débit élevé.
Matt

1
Je ne suis pas d'accord. Lorsque nagle est utilisé sur des protocoles basés sur TCP avec beaucoup de petits paquets, il les fusionnera et créera des paquets plus volumineux. Cela entraîne un léger retard dans l'envoi, donc le temps de latence peut augmenter très légèrement. Cependant, le débit peut être plus bas avec nagle désactivé car plus de paquets = plus d'en-têtes de paquets = plus de surcharge. Les paquets déposés sur un LAN sont généralement plus liés au remplissage des tampons d'entrée. Si vous avez beaucoup de clients qui envoient des données au même hôte, cela peut ne faire aucune différence. Je ne crois pas qu'éteindre et rallumer nagle va le faire dans la pratique.
Matt

8

Quiconque décide que la liste ci-dessus n'est pas suffisante et souhaite développer son propre UDP fiable devrait absolument jeter un coup d'œil à la spécification Google QUIC, car elle couvre de nombreux cas compliqués et des attaques de déni de service potentielles. Je n'ai pas encore joué avec une implémentation de ceci, et vous ne voudrez peut-être pas ou n'avez pas besoin de tout ce qu'il fournit, mais le document vaut la peine d'être lu avant de vous lancer dans une nouvelle conception UDP «fiable».

Un bon point de départ pour QUIC est ici , sur le blog Chromium.

Le document de conception QUIC actuel peut être trouvé ici .


4

Si vous avez une situation où une connexion TCP est potentiellement trop lente et une «connexion» UDP est potentiellement trop peu fiable, qu'utilisez-vous? Il existe différents protocoles UDP standard fiables, quelles expériences avez-vous avec eux?

Le mot clé dans votre phrase est «potentiellement». Je pense que vous devez vraiment vous prouver que TCP est, en fait, trop lent pour vos besoins si vous avez besoin de fiabilité dans votre protocole.

Si vous voulez obtenir de la fiabilité avec UDP, vous allez essentiellement ré-implémenter certaines des fonctionnalités de TCP en plus d'UDP, ce qui ralentira probablement les choses que d'utiliser simplement TCP en premier lieu.


Oui, Andrew Edgecombe l'a dit, mais, comme je l'ai dit, je m'intéresse aux avantages et aux inconvénients de QUELLES alternatives existent. Sans cette liste d'alternatives et leurs avantages et inconvénients, il est difficile de décider de ce qui est le mieux.
Len Holgate

Étant donné une fonction de fiabilité connue, parfois un flux UDP peut être réglé manuellement pour dépasser le flux TCP dans le système d'exploitation hte. Rare cependant.
Joshua

1
@ 17 sur 26, je suis d'accord avec Len Holgate, TCP sera plus lent qu'un UDP fiable dans certaines circonstances. Comme pour un réseau BDP élevé, supposons que vous ayez une connexion Internet de 1 Gbit / s de la Chine à NewYork, je suis sûr que TCP sera nul pour utiliser presque toute la vitesse de 1 Gbit / s. TCP est meilleur pour la plupart des connexions sur terre, mais pas pour un réseau avec un produit à délai de bande passante élevé.
nullptr



2

Avez-vous envisagé de compresser vos données?

Comme indiqué ci-dessus, nous manquons d'informations sur la nature exacte de votre problème, mais la compression des données pour les transporter pourrait aider.


1
Surtout avec les bibliothèques de compression modernes. Certains sont aussi rapides qu'un memcpy. par exemple lz4.
Matt

2

RUDP . De nombreux serveurs socket pour les jeux implémentent quelque chose de similaire.


-3

La meilleure façon d'obtenir la fiabilité à l'aide d'UDP est de renforcer la fiabilité dans le programme d'application lui-même (par exemple, en ajoutant des mécanismes d'acquittement et de retransmission)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.