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

https://stackoverflow.com/questions/107668

01-07-2019
|

Question

Si vous vous trouvez dans 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 fiables et standard, quelles expériences avez-vous avec eux?

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

Les différentes options m'intéressent ici, parmi lesquelles TCP est à une extrémité de l'échelle et UDP à l'autre. Diverses options UDP fiables sont disponibles et chacune apporte des éléments TCP à UDP.

Je sais que TCP est souvent le bon choix, mais il est souvent utile d’avoir une liste des solutions de rechange pour l’aider à tirer cette conclusion. Des choses comme Enet, RUDP, etc. qui sont construites sur UDP ont différents avantages et inconvénients, les avez-vous utilisées, quelles sont vos expériences?

Pour éviter toute ambiguïté, il n’ya pas plus d’informations. C’est une question hypothétique qui, j’espérais, obtiendrait une liste de réponses détaillant les différentes options et alternatives disponibles pour une personne devant prendre une décision.

La solution

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 unique, données uniques? Ou est-ce un flux de données d'échantillon? etc.) Pour quelle plateforme 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 faire de gros efforts pour battre tcp en termes de rapidité, à moins que vous ne puissiez faire certaines hypothèses 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 partie de la fiabilité de la transmission en vous assurant de pouvoir détecter la corruption des données (par exemple, en utilisant un bon crc)

Mais si vous ne pouvez pas tolérer la perte d'un seul paquet, vous devrez alors commencer à introduire les types de techniques de fiabilité déjà utilisés par tcp. Et, sans faire un travail raisonnable, vous constaterez peut-être que vous commencez à intégrer ces éléments dans une solution d’espace utilisateur comportant tous les problèmes de rapidité inhérents.

Autres conseils

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

Il a une capacité de segmentation qui pourrait aider à accélérer.

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

Mise à jour: un bel article d'introduction .

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

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

ENET vous offre la possibilité d’envoyer plusieurs "canaux" de données et d’éviter la fiabilité, la fiabilité ou l’ordre des données envoyées. Il inclut également le ping peer-to-peer mentionné ci-dessus qui agit comme un maintien en vie.

Certains clients de l’industrie de la défense utilisent le transfert de données UDT (voir http: //udt.sourceforge .net / ) et en sont très satisfaits. Je constate qu’il dispose également d’une licence amicale BSD.

RUDP - Protocole de datagramme fiable

Ceci fournit:

accusé de réception des paquets reçus
Contrôle des fenêtres et de la congestion
Retransmission des paquets perdus
Sur-tampon (plus rapide que la diffusion en temps réel)

Il semble légèrement plus configurable de conserver Alives que ENet, mais cela ne vous donne pas autant d’options (c’est-à-dire que toutes les données sont fiables et classées, et pas seulement les bits que vous décidez d’être). Il semble assez simple à mettre en œuvre.

Comme d'autres l'ont fait remarquer, votre question est très générale et le fait de savoir 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 la diffusion en continu fiable des données d’un hôte à un autre. Toutefois, si votre application génère beaucoup de petites rafales de trafic et attend des réponses, UDP peut être plus approprié pour réduire le temps de latence.

Il existe un terrain d'entente facile. L'algorithme de Nagle est la partie de TCP qui permet de s'assurer que l'expéditeur ne submerge pas le destinataire. d’un flux important de données, ce qui entraîne un encombrement et une perte de paquets.

Si vous avez besoin d'une livraison fiable et en ordre de TCP, ainsi que d'une réponse rapide de UDP, et que vous n'avez pas à vous soucier de l'encombrement lié à 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");

Quiconque estime que la liste ci-dessus ne suffit pas et souhaite développer son propre UDP fiable doit absolument se pencher sur la spécification Google QUIC, car elle couvre de nombreux cas complexes et de potentielles attaques par déni de service. Je n'ai pas encore joué à une implémentation de cela, et vous pouvez ne pas vouloir ou avoir besoin de tout ce qu'il fournit, mais le document mérite d'être lu avant de se lancer dans une nouvelle version "fiable". Conception UDP.

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

Le document de conception QUIC en cours se trouve ici .

Si vous vous trouvez dans 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 fiables et standard, quelles expériences avez-vous avec eux?

Le mot clé de 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 souhaitez obtenir la fiabilité du protocole UDP, vous allez essentiellement ré-implémenter certaines fonctionnalités de TCP au-dessus du protocole UDP, ce qui ralentira probablement les choses au-delà de la simple utilisation de TCP.

Protocole DCCP, normalisé dans le RFC 4340 , " Protocole de contrôle de la congestion de datagramme " peut être ce que vous recherchez.

Il semble que ait été implémenté dans Linux .

Peut-être RFC 5405 , "Instructions d'utilisation d'Unicast UDP pour les concepteurs d'applications " sera utile pour vous.

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

Comme indiqué ci-dessus, nous ne disposons pas d'informations sur la nature exacte de votre problème, mais la compression des données pour les transporter pourrait être utile.

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

Le meilleur moyen d'assurer la fiabilité à l'aide du protocole UDP est de renforcer la fiabilité du programme d'application lui-même (par exemple, en ajoutant des mécanismes d'accusé de réception et de retransmission)

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow