Choisir le protocole approprié pour l'application IoT


12

Nous avons à l'œuvre un scénario IoT dans lequel le Thing / Constrained Device envoie sa position GPS dans un intervalle régulier à un serveur donné. Le dispositif contraint est une carte de type Arduino qui est alimentée par batterie et utilise un blindage GSM / SIM pour la connectivité. Ce sont nos objectifs de conception:

  • Maximiser la durée de vie de la batterie
  • Minimiser le transfert de données

À des fins de test, nous avons utilisé HTTP, ce qui génère des messages d'environ 500 octets, mais il est temps d'utiliser un protocole plus approprié pour la transmission des données. Certaines des caractéristiques du transfert de données sont les suivantes:

  • La charge utile est assez petite, normalement inférieure à 50 octets (assez loin des MTU typiques, c'est-à-dire que tout devrait tenir dans un package IP)
  • Les données doivent être envoyées environ une fois par minute . Une certaine variance n'est pas critique.
  • C'est OK de perdre quelques messages
  • À l'heure actuelle, l'appareil n'a besoin d'aucune réponse de la part du serveur r (mais cela pourrait changer à l'avenir). Le serveur ne doit pas non plus démarrer de conversation avec les appareils.

Jusqu'à présent, nous avons pensé à ces possibilités:

  • Protocole personnalisé sur TCP . Cela éliminerait les en-têtes HTTP, ce qui rend le message 10 fois plus petit. C'est notre approche fiable / conservatrice.
  • Protocole personnalisé sur UDP . Comme UDP a des en-têtes plus petits et pas de surcharge pour la fiabilité, nous nous attendons à être assez efficaces. Comme indiqué, perdre un message ici ou il n'y a pas de problème ... cependant, il pourrait y avoir d'autres problèmes de non-fiabilité que nous ne connaissons pas.
  • MQTT (standard sur TCP): avec presque pas de surcharge existante par rapport à TCP, cela pourrait aussi être une option ... cependant, nous n'avons pas trop d'expérience avec la technologie GSM / SIM, et nous ne savons pas comment une connexion MQTT continue fonctionnerait de cette façon, et si la bande passante du rythme cardiaque de connexion vaut pour un tel transfert de données à basse fréquence.
  • CoAP (standard sur UDP): semble également prometteur. Juste 4 octets de surcharge pour les en-têtes et travaillant sur UDP. Des risques inconnus d'UDP sont cependant là.

Quelqu'un peut-il donner un indice? Merci d'avance.


1
@RichardChambers dans ce scénario, la fiabilité n'est pas si importante. Nous pouvons nous permettre de perdre des paquets ici ou là. Ackn'est pas nécessaire. Je pense que travailler sur la fiabilité par-dessus UDP n'a pas trop de sens, c'est à cela que sert TCP.
bgusach

1
Je ne réinventerais pas la roue en concevant un protocole personnalisé. Un google de CoAP vs MQTT vous donnera plus de considérations. Avez-vous besoin de pérenniser votre solution, c.-à-d. gérer à l'avenir des exigences plus strictes (garanties de perte, temps de réponse, interopérabilité, etc.)? Les appareils sont-ils NAT? Existe-t-il un regroupement d'appareils derrière les passerelles? Beaucoup d'inconnues ...
Gambit Support

Réponses:


6

Quelques réflexions sur mon expérience avec TCP, UDP et MQTT ainsi que quelques ressources supplémentaires à revoir.

Avec UDP, j'ai rencontré le problème d'échec silencieux dans lequel une application sur un nœud de réseau, le client, ne voit que certains des messages UDP qui ont été envoyés. Il y a trop de raisons pour lesquelles le trafic réseau peut mal tourner. Le problème avec UDP est que les paquets peuvent être jetés à peu près chaque fois que l'un des nœuds du chemin réseau entre le producteur de paquets et le consommateur de paquets le justifie. Voir le sujet Wikipedia Perte de paquets .

La question est de savoir quel est votre taux de perte dans n'importe quel contexte de réseau actuel. Donc, s'il s'agit d'une communication au sein d'un LAN ou d'un sous-réseau, votre taux de perte peut être faible. Sur un WAN ou sur Internet, votre taux de perte peut être assez élevé. Les paquets UDP sont rejetés pour un certain nombre de raisons et acheminés, mais les conditions du réseau le permettent avec cette décroissance du nombre de sauts. L'envoi de paquets dans le grand vide sans aucune responsabilité laisse ouverte la possibilité d'échecs silencieux.

Il semble que dans votre cas, un simple accusé de réception avec retransmission après un délai d'attente sans recevoir d'acquittement suffirait.

J'ai fait des messages XML sur une connexion TCP maintenue et cela a très bien fonctionné. J'avais une couche qui livrait des messages complets chacun dans un tampon à la couche application à gérer. J'ai utilisé XML pour emballer le message avec une balise de début XML pour le début du message et une balise de fin XML pour savoir quand le message entier a été reçu.

TCP a quelques fonctionnalités telles que l'ordre séquentiel des paquets, aucune répétition et le fait d'être un mécanisme de transport connecté signifie que vous savez si l'autre extrémité disparaît ou non, même si cela peut prendre un certain temps à le découvrir. La connexion et la déconnexion peuvent introduire des retards mais pas trop lourdes dans des conditions normales, bien que les conditions du réseau puissent ralentir le débit TCP.

MQTT est un protocole qui est transporté par une couche de transport réseau, normalement TCP. MQTT utilise un modèle de publication / abonnement, il n'y a donc aucun stockage de message. Ainsi, lorsqu'un éditeur publie un message si l'abonné n'est pas connecté au moment où il se connecte, il ne verra pas le message. MQTT est à peu près en temps réel, je suppose que c'est la partie télémétrie de l'acronyme. J'aime MQTT pour les petits messages et j'ai fait quelques expériences avec la charge utile JSON via MQTT en utilisant Mosquitto. Voir cet article Remise de messages fiable avec Mosquitto (MQTT) avec un aperçu de MQTT et de la qualité de service. Et consultez ce bref article avec des liens vers des ressources, notamment un exemple d'application IoT - MQTT Publish and Subscriber C Code .

Mes expériences avec MQTT en utilisant du texte JSON et une base de données SQLite3 dans l'abonné pour stocker les messages se trouvent à https://github.com/RichardChambers/raspberrypi/tree/master/mqtt bien que la source soit en C et soit assez désordonnée.

Voici une vidéo de 13 minutes # 144 Protocoles Internet: CoAP vs MQTT, Network Sniffing, et préparation pour IKEA Tradfri Hacking . Ceci est un article intéressant sur CoAP, Constrained Application Protocol: CoAP est le protocole «moderne» de l'IoT . Il y a cette somme de CoAP:

Les premiers adoptants conviennent que le protocole d'application contraint fonctionne extrêmement bien pour les réseaux et les périphériques contraints. Quelque chose de moins connu: "Sur un réseau sans fil très encombré - Wi-Fi ou cellulaire - CoAP peut continuer à fonctionner là où un protocole TCP (Transmission Control Protocol) comme MQTT ne parvient même pas à terminer une prise de contact, "Dit Vermillard.

En effet, contrairement à la plupart des autres protocoles IoT, CoAP est basé sur UDP. En d'autres termes, cela signifie pas de poignée de main de protocole ou de correction d'erreur comme cela se produit avec TCP. "CoAP peut ne pas être aussi fiable que HTTP ou garantir la livraison de messages comme MQTT, mais il est extrêmement rapide", a noté Matthieu. "Si vous acceptez que certains messages ne soient pas reçus, vous pouvez envoyer beaucoup plus de messages dans le même délai."

Il y a quelques autres tels que AMQP, STOMP et CBOR que vous pourriez également consulter. Voir le site web standard CBOR ainsi que cette thèse, Implémentation et évaluation du protocole CBOR . Voir cet article, Choix de votre protocole de messagerie: AMQP, MQTT ou STOMP qui compare et contraste l'AMQP, MQTT et STOMP et se termine par une note sur le courtier RabitMQ:

J'espère que cela peut aider beaucoup de personnes à commencer à naviguer dans la soupe protocolaire pour chacun de vos cas d'utilisation. Comme il est courant pour les entreprises d'avoir de nombreuses applications ayant des besoins différents, il est certainement possible que vous ayez besoin des trois courtiers pour différentes applications. C'est là qu'intervient un courtier polyglotte solide multiprotocole comme RabbitMQ, car il peut envoyer STOMP, MQTT ou AMQP et en retirer l'un des autres. Vous n'avez pas besoin d'être verrouillé par l'un de ces protocoles - les trois sont pris en charge par le courtier RabbitMQ, ce qui en fait un choix idéal pour l'interopérabilité entre les applications. L'architecture du plugin permet également à RabbitMQ d'évoluer pour prendre en charge des versions supplémentaires ou mises à jour de ces protocoles à l'avenir.

Ce package de partage de diapositives d'une soixantaine de diapositives fait une comparaison et un contraste entre quatre protocoles IoT différents en examinant les besoins de deux groupes IoT différents, les consommateurs et les industriels, qui ont des besoins différents en matière de fiabilité et de robustesse. Quelle est la bonne norme de messagerie pour l'IoT? .


4

Cela ressemble à une application parfaite pour UDP: la topologie client-serveur (pub / sub non requise), tolérante à la perte de paquets et les grands écarts entre les transmissions de paquets simples signifient que l'arrivée en panne n'est pas un problème.

Les économies dans l'établissement de la connexion et les frais généraux de paquets fonctionneront bien en votre faveur.

Vous avez juste besoin d'atténuer le problème de panne silencieuse. Beaucoup de façons de le faire, mais ma suggestion serait que le serveur réponde à chaque fois qu'il reçoit x (par exemple 10) paquets. De cette façon, le client sait combien de ses paquets transitent, et s'il est inférieur à un seuil, il peut augmenter la fréquence des transmissions pour contrer la perte de paquets. Si rien ne passe, alors TCP ne va pas aider de toute façon, il vaut donc mieux mettre le client en mode détresse jusqu'à ce que la condition disparaisse.

La perte de paquets UDP sur Internet n'est généralement pas élevée, et si c'est le cas, il s'agit généralement d'un phénomène transitoire. Le GSM fournit une certaine mise en mémoire tampon et une évaluation du signal radio, donc offre une certaine tolérance au bruit parasite de toute façon.


4

Êtes-vous contraint à l'extérieur d'utiliser GSM / SIM?

Une alternative peut être d'utiliser un réseau LoRa qui:

  • sont hautement optimisés pour les petites charges utiles
  • sont conçus pour une consommation d'énergie minimale (et donc une durée de vie maximale de la batterie)
  • sont à longue portée par conception
  • avoir des classes de connexion (toujours activées, reconnues, non acquittées)
  • avoir des fenêtres de téléchargement planifiées (par exemple, pour les mises à jour du micrologiciel ou les accusés de réception RX)

Vous pouvez vous connecter à une infrastructure LoRa communautaire ou commerciale existante dans la plupart des pays, ou vous pouvez déployer vos propres concentrateurs LoRa si cela était plus approprié.

Il existe un développement actif à l'échelle mondiale et une disponibilité aisée des écrans de prototypage (par exemple pour Arduino).


1
Une fois par minute, comme mentionné dans la question, il est beaucoup trop fréquent pour correspondre aux intervalles de transmission recommandés pour les nœuds LoRa.
Chris Stratton

1
D'accord 1 min c'est trop souvent. Bien que @bgusach ne mentionne pas l'application. Si la charge utile peut être codée en binaire pour réduire la taille et si un intervalle de 3 à 5 minutes (ou même 10 minutes) est utilisable, cela pourrait être idéal. Quoi qu'il en soit, juste une suggestion car je note qu'elle n'a pas été mentionnée précédemment dans les réponses.
BrendanMcL

1
Oui, si je le lis correctement, quelque chose comme 50 octets à quatre minutes d'intervalle pourrait à peine convenir; mais cela nécessite une vérification, il pourrait facilement être désactivé par au moins un facteur de deux.
Chris Stratton

1
Intéressant, mais nous sommes contraints par le GSM / SIM (cela est destiné à être un bien de consommation, quelque chose qui peut être acheté et utilisé n'importe où sans autre infrastructure que le réseau téléphonique).
bgusach

3

Je préférerais une réponse HTTP minimale avec les données JSON ... une réponse HTTP peut être bien inférieure au transfert HTTP de 500 octets, et vous restez compatible avec de nombreux clients pour les applications Web RESTful.

Un message HTTP minimum (par exemple avec un résultat JSON) avec environ 130 octets de données HTTP ressemble à:

HTTP/1.1 200 OK
Server: ProprietaryAndroid
Connection: close
Content-Type: application/json
{
  "lat": "42.00000",
  "long": "10.00000"
}

si vous souhaitez simplement ENVOYER des données de votre application au serveur, vous pouvez simplement utiliser un HTTP GET où vous définissez les paramètres d'URL lat / long. La demande contient encore moins de données que la réponse.

GET /?lat=42.00000&long=10.0000 HTTP/1.1
Host: 192.168.0.2 
User-Agent: Proprietary
Accept: */* 
Connection: close

7
Merci pour votre réponse, mais je ne vois pas votre point avec la réponse HTTP. Nous voulons nous débarrasser de l'ensemble du protocole HTTP pour enregistrer le transfert de données. Et en plus de cela, utiliser GETpour modifier les ressources est la Wrong Thing™chose à faire
bgusach

Convenez avec vous du côté architectural que d'autres verbes comme POST (comme le verbe universel) sont quant à eux plus courants dans les API REST. Cela dépend du niveau de maturité dans lequel vous développez votre API REST. Je voulais juste montrer comment un HTTP peut être minimisé, tout en conservant l'avantage de la simplicité d'implémentation et de la compatibilité avec les frameworks existants (client et serveur), tout en gardant la lisibilité humaine. Répondre avec un échantillon de réponse était déroutant ... Si vous voulez ENVOYER les données, bien sûr, vous utiliseriez un message POST ou GET - dans le cas d'un POST, avec le contenu json que j'ai montré dans mon premier échantillon.
Christoph Bimminger

3

Il n'y a pas de "meilleur" protocole. Juste un grand nombre de compromis à considérer:

  • Vos appareils seront-ils sur des réseaux aléatoires avec des ports aléatoires bloqués? Si c'est le cas, il pourrait être préférable d'utiliser HTTPS.

  • Si vous envoyez UDP, vous pouvez toujours envoyer les N dernières mesures à chaque fois, de sorte que la perte de petits paquets soit ignorée. Vous pouvez également envoyer un paquet ACK, transformant UDP en un protocole fiable. (La plupart des protocoles au-dessus d'UDP le font.)

  • Vos clients se soucieront-ils si leurs données sont exposées non chiffrées? Vos clients se soucieront-ils si des pirates informatiques peuvent injecter de mauvaises données dans ces connexions non chiffrées? (Si c'est le cas, vous souhaiterez peut-être le chiffrement.)

  • Que se passe-t-il si quelqu'un flaire votre protocole et manipule les données? Pouvez-vous empêcher un appareil d'écraser des données pour un autre?

  • Combien d'appareils disposerez-vous au maximum? Comment allez-vous gérer tous ces appareils? Comment allez-vous acheminer les données là où elles doivent aller? Comment gérez-vous la maintenance et les mises à niveau de votre infrastructure de serveur? Si vous n'avez pas d'expérience, vous surestimez probablement votre capacité à gérer de nombreuses connexions simultanées. Il peut être préférable d'externaliser auprès d'un fournisseur (et d'utiliser leurs protocoles, tels que AWS IoT).


3

Nous avons un test exact comparant le taux de transmission HTTP vs MQTT, voir test2 , dans votre scénario actuel, MQTT vous apportera 50 fois moins de trafic (et de batterie) que HTTP.

Il n'y a fondamentalement aucune différence entre MQTT et TCP ordinaire (en taille de message). Je dirais même qu'il n'y a fondamentalement aucune différence entre TCP simple et message binaire et JSON dans la charge utile MQTT. De cette façon, il est beaucoup plus pratique d'utiliser MQTT + JSON et de s'appuyer sur ces technologies pour la livraison et la représentation des données. Nommez simplement vos clés plus ou moins courtes.

Concernant UDP, si la transmission est une fois par minute, il est préférable d'utiliser TCP. Si la transmission est effectuée toutes les 10 à 20 minutes ou plus, vous pouvez considérer UDP comme une solution plus efficace pour le trafic / la batterie. Si vous essayez de développer votre propre protocole avec les ACK, je vous recommande d'utiliser MQTT ou TCP et de vous concentrer uniquement sur votre analyse de rentabilisation.

En général - plus vous l'implémentez facilement, meilleurs sont les résultats que vous pouvez obtenir dans les plus brefs délais. Si j'étais vous, dans ce cas, je ferais mieux de tester UDP + propre format binaire et MQTT + JSON et de sélectionner l'un d'entre eux. Ou même juste commencé à partir de MQTT + JSON, puis pensez si cela convient à mon cas.


1
Je mentionnerai ici quelques mots contre l'UDP. Nous maintenons un grand système de gestion de flotte GPS SaaS (plus de 1 million de véhicules connectés) ayant des clients dans plus de 100 pays à travers le monde. Et récemment, nous avons découvert que les fournisseurs Internet basés aux États-Unis bloquent les paquets UDP sortant des États-Unis pour une raison quelconque, même pour les applications M2M. Cela a commencé il y a quelques mois, mais c'est très douloureux, je vous recommande donc de sélectionner le protocole basé sur TCP (MQTT) et de vous fier aux normes mondiales. Un jour et dans certains pays, vous serez même obligé d'utiliser MQTT sur des websockets pour maintenir la connexion. Juste un petit conseil.
shal
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.