Le développement des technologies dans le domaine des logiciels et du matériel, l'émergence de nouveaux protocoles de communication ont conduit à l'expansion de l'Internet des objets (IoT). Le nombre d'appareils augmente de jour en jour et ils génèrent une énorme quantité de données. Par conséquent, un besoin se fait sentir d'une architecture de système pratique capable de traiter, de stocker et de transmettre ces données.
Maintenant, ils utilisent les services cloud à ces fins. Cependant, le paradigme brumeux (Fog) en constante évolution est en mesure de compléter les solutions cloud en faisant évoluer et en optimisant l'infrastructure IoT. Les nuages peuvent fermer la plupart des demandes IoT. Par exemple, pour fournir des services de surveillance, un traitement rapide de toute quantité de données générées par les appareils, ainsi que leur visualisation. L'informatique brumeuse est plus efficace pour résoudre les problèmes en temps réel. Ils fournissent une réponse rapide aux demandes et un délai minimum dans le traitement des données. Autrement dit, le brouillard complète exactement les «nuages», étend ses capacités.
Cependant, la question principale est différente: comment tout cela devrait-il interagir dans le contexte de l'IoT? Quels protocoles de communication seront les plus efficaces lorsque vous travaillez dans un système IoT-Fog-Cloud unifié?
Malgré l'apparente domination de HTTP, l'IoT, le brouillard et le cloud utilisent un grand nombre d'autres solutions. En effet, l'IoT doit combiner les fonctionnalités d'une variété de capteurs d'appareils avec la sécurité, l'interopérabilité et d'autres exigences des utilisateurs.
Voici juste une idée unique de l'architecture de référence et la norme de communication n'est tout simplement pas là. Par conséquent, la création d'un nouveau protocole ou le raffinement d'un protocole existant pour des tâches IoT spécifiques est l'une des tâches les plus importantes pour la communauté informatique.
Quels protocoles sont utilisés actuellement et que peuvent-ils offrir? Faisons les choses correctement. Mais d'abord, discutons des principes d'un écosystème dans lequel les nuages, le brouillard et l'Internet des objets interagissent.
Architecture IoT Fog-to-Cloud (F2C)
Vous devez avoir remarqué combien d'efforts ont été déployés pour explorer les avantages et les avantages de la gestion de l'IoT, des nuages et du brouillard de manière rationnelle et coordonnée. Sinon, il existe déjà trois initiatives de normalisation:
OpenFog Consortium ,
Edge Computing Consortium et
mF2C H2020 EU project .
Si auparavant seuls 2 niveaux, les nuages et les terminaux étaient pris en compte, l'architecture proposée introduisait un nouveau niveau: le calcul du brouillard. Dans ce cas, le niveau de brouillard peut être divisé en plusieurs sous-niveaux, selon les spécificités des ressources ou un ensemble de politiques qui déterminent l'utilisation de différents appareils dans ces sous-niveaux.
À quoi pourrait ressembler cette abstraction? Voici un écosystème IoT-Fog-Cloud typique. Les appareils IoT envoient des données vers des serveurs et des appareils informatiques plus puissants pour résoudre les tâches qui nécessitent une faible latence. Dans le même système, les nuages sont responsables de la résolution de problèmes nécessitant une grande quantité de ressources informatiques ou d'espace de stockage de données.
Les smartphones, les montres connectées et autres gadgets peuvent également faire partie de l'IoT. Mais de tels appareils, en règle générale, utilisent des protocoles de communication propriétaires de grands développeurs. Les données IoT générées sont transmises au niveau de brouillard via le protocole HTTP REST, qui offre flexibilité et interopérabilité lors de la création de services RESTful. Ceci est important compte tenu du besoin de compatibilité descendante avec l'infrastructure informatique existante exécutée sur des ordinateurs locaux, des serveurs ou un cluster de serveurs. Les ressources locales, appelées «nœuds du brouillard», filtrent les données reçues et les traitent localement ou les envoient au cloud pour des calculs ultérieurs.
Les nuages prennent en charge divers protocoles de communication, parmi lesquels AMQP et REST HTTP sont le plus souvent trouvés. Étant donné que HTTP est bien connu et emprisonné pour Internet, la question peut se poser: «Mais dois-je l'utiliser pour travailler avec l'IoT et le brouillard?». Cependant, ce protocole a des problèmes de performances. Plus d'informations à ce sujet plus tard.
En général, il existe 2 modèles de protocoles de communication adaptés au système dont nous avons besoin. Il s'agit d'une demande-réponse et d'une publication-abonnement. Le premier modèle est plus largement connu, notamment dans l'architecture serveur-client. Le client demande des informations au serveur, il reçoit la demande, la traite et renvoie un message de réponse. Les protocoles REST HTTP et CoAP fonctionnent sur ce modèle.
Le deuxième modèle est né de la nécessité de fournir une communication asynchrone, distribuée et faible entre les sources qui génèrent les données et les destinataires de ces données.
Le modèle implique trois participants: l'éditeur (source de données), le courtier (répartiteur) et l'abonné (destinataire). Ici, le client agissant en tant qu'abonné ne doit pas demander d'informations au serveur. Au lieu d'envoyer des demandes, il s'abonne à certains événements du système via un courtier chargé de filtrer tous les messages entrants et de les acheminer entre éditeurs et abonnés. Et l'éditeur, lorsqu'un événement se produit concernant un certain sujet, le publie au courtier, qui envoie les données d'abonné sur le sujet demandé.
En substance, cette architecture est pilotée par les événements. Et ce modèle d'interaction est intéressant pour les applications IoT, cloud, brouillard en raison de sa capacité à fournir une évolutivité et à simplifier l'interconnexion entre différents appareils, pour prendre en charge la communication dynamique plusieurs-à-plusieurs et la communication asynchrone. Parmi les protocoles de messagerie standardisés les plus connus utilisant le modèle de publication-abonnement figurent MQTT, AMQP et DDS.
De toute évidence, le modèle de publication-abonnement présente de nombreux avantages:
- Les éditeurs et les abonnés n'ont pas besoin de se connaître mutuellement;
- Un abonné peut recevoir des informations de nombreuses publications différentes, et un éditeur peut envoyer des données à de nombreux abonnés différents (le principe «plusieurs à plusieurs»);
- L'éditeur et l'abonné ne sont pas tenus d'être actifs simultanément pour l'échange de données, car le courtier (fonctionnant comme un système de file d'attente) pourra stocker un message pour les clients qui ne sont actuellement pas connectés au réseau.
Cependant, le modèle demande-réponse a également ses propres forces. Dans les cas où les capacités du côté serveur pour le traitement des demandes de plusieurs clients ne sont pas un problème, il est logique d'utiliser des solutions fiables déjà éprouvées.
Il existe également des protocoles qui prennent en charge les deux modèles. Par exemple, XMPP et HTTP 2.0 qui prennent en charge l'option push du serveur. L'IETF a également publié CoAP. Pour tenter de résoudre le problème de messagerie, plusieurs autres solutions ont été créées, telles que le protocole WebSockets ou en utilisant le protocole HTTP via QUIC (Quick UDP Internet Connections).
Dans le cas de WebSockets, bien qu'il soit utilisé pour le transfert de données en temps réel du serveur vers le client Web et fournit des connexions constantes avec une communication bidirectionnelle simultanée, il n'est pas destiné aux appareils avec des ressources informatiques limitées. QUIC mérite également l'attention, car le nouveau protocole de transport fournit de nombreuses nouvelles fonctionnalités. Mais comme QUIC n'est pas encore standardisé, il est prématuré de prédire son application possible et son impact sur les solutions IoT. Nous laissons donc WebSockets et QUIC en mémoire en vue de l'avenir, mais nous n'allons pas encore étudier plus en détail.
Qui dans le monde est le plus doux: nous comparons les protocoles
Parlons maintenant des forces et des faiblesses des protocoles. Pour l'avenir, nous faisons immédiatement une réserve qu'il n'y a pas de leader clair. Chaque protocole présente certains avantages / inconvénients.
Temps de réponseL'une des caractéristiques les plus importantes des protocoles de communication, notamment en ce qui concerne l'Internet des objets, est le temps de réponse. Mais parmi les protocoles existants, il n'y a pas d'exception démontrant un niveau minimum de retard lorsque l'on travaille dans des conditions différentes. Mais il y a tout un tas de recherches et de comparaisons des capacités de protocole.
Par exemple, les
résultats de la comparaison de l'efficacité de HTTP et de MQTT lors de l'utilisation de l'IoT ont montré que le temps de réponse pour les demandes de MQTT est inférieur à celui de HTTP. Et en
étudiant le temps de réception et de transmission (RTT) du MQTT et du CoAP, il s'est avéré que le RTT CoAP moyen est 20% inférieur à celui du MQTT.
Une autre
expérience avec RTT pour les protocoles MQTT et CoAP a été réalisée dans deux scénarios: un réseau local et un réseau IoT. Il s'est avéré que le RTT moyen est 2-3 fois plus élevé dans le réseau IoT. MQTT avec QoS0 a montré un résultat inférieur à celui de CoAP, et MQTT avec QoS1 a montré un RTT plus élevé en raison de l'ACK aux niveaux d'application et de transport. Pour différents niveaux de QoS, les retards du réseau sans congestion pour MQTT étaient de quelques millisecondes et pour CoAP, des centaines de microsecondes. Cependant, il convient de se rappeler que lorsque vous travaillez dans des réseaux moins fiables, MQTT exécuté au-dessus de TCP affichera un résultat différent.
La comparaison du temps de réponse pour les protocoles AMQP et MQTT en augmentant la charge utile a montré qu'avec une petite charge, le niveau de retard est presque le même. Mais lors de la transmission de grandes quantités de données, MQTT affiche un temps de réponse inférieur. Dans une autre
étude, CoAP a été comparé à HTTP dans un scénario de communication de machine à machine avec des appareils déployés au-dessus de véhicules équipés de capteurs de gaz, de capteurs météorologiques, de localisation (GPS) et d'une interface de réseau mobile (GPRS). Le temps nécessaire pour envoyer un message CoAP sur un réseau mobile était presque trois fois plus court que le temps nécessaire pour utiliser les messages HTTP.
Des études ont comparé non pas deux, mais trois protocoles. Par exemple,
comparer les performances des protocoles IoT MQTT, DDS et CoAP dans un cas d'utilisation médicale à l'aide d'un émulateur de réseau. DDS a surpassé MQTT en termes de latence de télémétrie expérimentée dans diverses conditions de réseau médiocres. CoAP basé sur UDP fonctionnait bien pour les applications nécessitant une réponse rapide, mais comme il était basé sur UDP, il y avait une perte de paquets imprévisible importante.
DébitLa comparaison du MQTT et du CoAP en termes d'utilisation de la bande passante a été effectuée en tant que calcul de la quantité totale de données transmises par message. CoAP a montré moins de bande passante que MQTT lors de l'envoi de petits messages. Mais en comparant l'efficacité des protocoles en termes de rapport entre le nombre d'octets d'informations utiles et le nombre total d'octets transmis, CoAP était plus efficace.
Lors de l'
analyse de l' utilisation du MQTT, du DDS (avec TCP comme protocole de transport) et de la bande passante CoAP, il s'est avéré que CoAP avait tendance à montrer une consommation de bande passante relativement inférieure, qui n'augmentait pas avec une augmentation de la perte de paquets réseau ou un délai réseau accru, contrairement à MQTT et DDS, où dans les scénarios mentionnés, il y a eu une augmentation de l'utilisation de la capacité des canaux. Dans un autre scénario, un grand nombre d'appareils transmettaient des données simultanément, ce qui est un cas typique dans les environnements IoT. Les résultats ont montré que pour une charge plus élevée, il est préférable d'utiliser CoAP.
Avec une charge légère, CoAP a utilisé le moins de bande passante, suivi de MQTT et HTTP REST. Cependant, lorsque la taille de la charge utile a augmenté, REST HTTP a obtenu les meilleurs résultats.
Consommation d'énergieLa question de la consommation d'énergie est toujours d'une grande importance, notamment dans le système IoT. Si nous
comparons la consommation d'énergie de MQTT et HTTP, alors HTTP «mange» beaucoup plus. Et CoAP est plus
économe en énergie que MQTT, vous permettant de gérer l'énergie. De plus, dans des scénarios simples, MQTT est plus adapté à l'échange d'informations sur Internet des objets, surtout s'il n'y a pas de restrictions de puissance.
Une autre expérience, qui a comparé les capacités d'AMQP et de MQTT sur un banc d'essai pour un réseau sans fil mobile ou instable, a montré qu'AMQP offre plus d'options de sécurité, tandis que MQTT est plus économe en énergie.
La sécuritéLa sécurité est un autre problème critique soulevé lors de l'étude du sujet de l'Internet des objets et de l'informatique brumeuse / cloud. Le mécanisme de sécurité est généralement basé sur TLS dans HTTP, MQTT, AMQP et XMPP, sur ou DTLS dans CoAP, et prend également en charge les deux versions de DDS.
TLS et DTLS commencent par le processus d'établissement de la communication entre les côtés client et serveur pour échanger les suites de chiffrement et les clés prises en charge. Les deux parties négocient des kits pour garantir la poursuite de la communication via un canal sécurisé. La différence entre les deux réside dans de petites modifications qui permettent au DTLS basé sur UDP de fonctionner sur une connexion peu fiable.
Lors
des attaques de test sur plusieurs implémentations TLS et DTLS différentes, il s'est avéré que TLS a fait un meilleur travail. Les attaques contre DTLS ont été plus réussies en raison de sa tolérance aux erreurs.
Cependant, le plus gros problème avec ces protocoles est qu'ils n'ont pas été initialement conçus pour être utilisés dans l'IoT et n'impliquaient pas de travail dans le brouillard ou le cloud. Grâce à un échange cohérent (prise de contact), ils ajoutent du trafic supplémentaire à chaque connexion, ce qui épuise les ressources informatiques. En moyenne, la charge de travail augmente de 6,5% pour TLS et de 11% pour DTLS par rapport à la communication sans niveau de sécurité. Dans les environnements riches en ressources qui sont généralement
basés sur le
cloud , cela ne sera pas un problème, mais cela devient une limitation importante entre l'IoT et le niveau de brouillard.
Que choisir? Il n'y a pas de réponse définitive. MQTT et HTTP semblent être les protocoles les plus prometteurs, car ils sont considérés comme des solutions relativement plus matures et plus stables pour l'IoT par rapport à d'autres protocoles.
Solutions de protocole de communications unifiées
La pratique d'une solution à protocole unique présente de nombreux inconvénients. Par exemple, un protocole qui satisfait un environnement limité peut ne pas fonctionner dans un domaine qui a des exigences de sécurité strictes. Dans cet esprit, il nous reste à rejeter presque toutes les solutions possibles basées sur un protocole dans l'écosystème Fog-to-Cloud dans IoT, à l'exception de MQTT et REST HTTP.
REST HTTP en tant que solution à protocole uniqueIl existe un bon exemple d'interaction entre la demande et la réponse HTTP IoT-to-Fog REST:
la batterie de serveurs intelligente . Les animaux sont équipés de capteurs portables (client IoT, C) et contrôlés via le cloud computing par un système d'élevage intelligent (serveur Fog, S).
Le titre de la méthode POST indique la ressource à modifier (/ ferme / animaux), ainsi que la version HTTP et le type de contenu, qui dans ce cas est un objet JSON représentant la ferme d'élevage que le système doit gérer (Dulcinée / vache). Une réponse du serveur indique que la demande a abouti en envoyant un code d'état HTTPS 201 (ressource créée). La méthode GET doit indiquer uniquement la ressource demandée dans l'URI (par exemple, / farm / animals / 1), qui renvoie la représentation JSON de l'animal avec cet identifiant depuis le serveur.
La méthode PUT est utilisée lorsque vous devez mettre à jour un enregistrement de ressource spécifique. Dans ce cas, l'URI est indiqué dans la ressource pour le paramètre à modifier et la valeur actuelle (par exemple, indiquant que la vache marche actuellement, / farm / animals / 1? State = walking). Enfin, la méthode DELETE est utilisée également pour la méthode GET, mais supprime simplement la ressource à la suite de l'opération.
MQTT comme solution à protocole unique
Prenez la même ferme intelligente, mais au lieu de REST HTTP, nous utilisons le protocole MQTT. Le serveur local sur lequel la bibliothèque Mosquitto est installée fait office de courtier. Dans cet exemple, un ordinateur simple (appelé serveur de ferme) Raspberry Pi sert de client MQTT, implémenté via l'installation de la bibliothèque MQTT Paho, qui est entièrement compatible avec le courtier Mosquitto.
Ce client correspond à la couche d'abstraction IoT représentant un appareil doté de capacités de détection et de calcul. L'intermédiaire, en revanche, correspond à un niveau d'abstraction plus élevé, représentant le nœud informatique du brouillard, qui se caractérise par une grande puissance en termes de traitement et de stockage des données.
Dans le scénario Smart Farm proposé, le Raspberry Pi se connecte à l'accéléromètre, au GPS et aux capteurs de température et publie les données de ces capteurs dans le nœud de brouillard. Comme vous le savez probablement, MQTT traite les sujets comme une hiérarchie. Un éditeur MQTT peut publier dans un ensemble spécifique de sujets. Dans notre cas, il y en a trois. Pour un capteur qui mesure la température dans une étable, le client sélectionne un thème (ferme animale / hangar / température). Pour les capteurs qui mesurent la position GPS et le mouvement des animaux à travers l'accéléromètre, le client publiera des mises à jour (ferme animale / animal / GPS) et (ferme animale / animal / mouvement).
Ces informations seront transmises au courtier, qui pourra les stocker temporairement dans une base de données locale au cas où un autre abonné intéressé apparaîtrait ultérieurement.
En plus du serveur local agissant en tant que courtier MQTT dans le brouillard et auquel Raspberry Pi, agissant en tant que clients MQTT, envoie des données à partir de capteurs, il peut y avoir un autre courtier MQTT au niveau du cloud. Dans ce cas, les informations transmises au courtier local peuvent être temporairement stockées dans la base de données locale et / ou envoyées au cloud. Le courtier MQTT brumeux dans cette situation est utilisé pour lier toutes les données avec le courtier MQTT cloud. Avec cette architecture, un utilisateur d'application mobile peut être abonné aux deux courtiers.
En cas d'échec de connexion avec l'un des courtiers (par exemple, cloud), l'utilisateur final recevra des informations d'un autre (brumeux). C'est une caractéristique des systèmes combinés de brouillard et de cloud computing. Par défaut, l'application mobile peut être configurée pour se connecter au courtier MQTT brumeux pour la première fois, et en cas d'échec, pour se connecter au courtier MQTT dans le cloud. Cette solution n'est que l'une des nombreuses fonctionnalités des systèmes IoT-F2C.
Solutions multiprotocoles
Les solutions à protocole unique sont populaires en raison de leur mise en œuvre plus facile. Mais il est évident que dans les systèmes IoT-F2C, il est logique de combiner différents protocoles. Le fait est que différents protocoles peuvent fonctionner à différents niveaux. Prenons, par exemple, trois abstractions: IoT, fog et cloud computing. Les appareils IoT sont généralement considérés comme limités. Pour cette revue, regardons les niveaux IoT comme les plus limités, le cloud le moins limité et le calcul du brouillard comme «quelque part au milieu». Il s'avère ensuite qu'entre l'IoT et les abstractions de brouillard, les décisions de protocole actuelles incluent MQTT, CoAP et XMPP. Entre le brouillard et le cloud, d'autre part, AMQP est l'un des principaux protocoles utilisés avec HTTP REST, qui en raison de sa flexibilité est également utilisé entre l'IoT et les couches de brouillard.
Le problème principal ici est l'interopérabilité des protocoles et la simplicité de traduction des messages d'un protocole à l'autre. Idéalement, à l'avenir, l'architecture du système IoT avec des ressources cloud et de brouillard sera indépendante du protocole de communication utilisé et fournira une bonne interopérabilité entre les différents protocoles.
Comme ce n'est pas le cas pour le moment, il est logique de combiner des protocoles qui ne présentent pas de différences significatives. À cette fin, une solution potentielle est basée sur une combinaison de deux protocoles qui adhèrent au même style architectural, REST HTTP et CoAP. Une autre solution proposée est basée sur une combinaison de deux protocoles offrant une interaction publication-abonnement, MQTT et AMQP. L'utilisation de concepts proches (MQTT et AMQP utilisent des courtiers, CoAP et HTTP utilisent REST), simplifie la mise en œuvre de ces combinaisons et nécessite moins d'efforts d'intégration.
La figure (a) montre deux modèles basés sur la demande-réponse, HTTP et CoAP, et leur placement possible dans la solution IoT-F2C. HTTP , , . , , , REST HTTP .
, , IoT, CoAP. CoAP HTTP, REST.
() «-» , MQTT AMQP. , . MQTT , IoT . AMQP , . MQTT IoT XMPP, . .
Conclusions
, , . , , , MQTT RESTful HTTP. , -.
, MQTT , IoT . , , , , RESTful HTTP . CoAP , IoT, , , MQTT HTTP. , .
Cloud4Y→
→
AI→
.→
4→
,Telegram -, ! .