Le développement des technologies dans le domaine des logiciels et du matériel, ainsi que l'émergence de nouveaux protocoles de communication, ont conduit à l'extension de l'Internet des Objets (IoT). Le nombre d'appareils augmente chaque jour et génère une énorme quantité de données. Cela crée le besoin d'une architecture système capable de traiter, stocker et transmettre ces données.
Aujourd'hui, des services cloud sont utilisés à cet effet. Cependant, la paradigme de plus en plus populaire des calculs en brouillard (Fog) peut compléter les solutions cloud en optimisant et en étendant l'infrastructure IoT.
Les "clouds" peuvent répondre à la plupart des besoins de l'IoT. Par exemple, ils assurent la surveillance des services, le traitement rapide de tous les volumes de données générés par les appareils et leur visualisation. En revanche, les calculs en brouillard sont plus efficaces pour résoudre des tâches en temps réel. Ils fournissent une réponse rapide aux requêtes et un délai minimal dans le traitement des données. Autrement dit, le Fog complète précisément le "cloud", en élargissant ses capacités.
Cependant, la question principale est la suivante : comment tout cela doit-il interagir dans le contexte de l'IoT ? Quels protocoles de communication seront les plus efficaces dans un système intégré IoT-Fog-Cloud ?
Malgré la domination apparente du HTTP, de nombreuses autres solutions sont utilisées dans les systèmes IoT, Fog et Cloud. Cela s'explique par le fait que l'IoT doit combiner les fonctionnalités variées des capteurs d'appareil avec la sécurité, la compatibilité et d'autres exigences des utilisateurs.
Il n'existe tout simplement pas de consensus sur une architecture de référence et un standard de communication. Par conséquent, la création d'un nouveau protocole ou l'amélioration d'un protocole existant pour des tâches spécifiques de l'IoT est l'une des questions les plus importantes auxquelles la communauté IT est confrontée.
Quels protocoles sont actuellement utilisés et que peuvent-ils offrir ? Analysons cela. Mais d'abord, discutons des principes de l'écosystème dans lequel interagissent les nuages, le brouillard et l'Internet des Objets.
Architecture IoT Fog-to-Cloud (F2C)
Vous avez sûrement remarqué les efforts considérables déployés pour étudier les avantages et les bénéfices d'une gestion rationnelle et coordonnée de l'IoT, des nuages et du brouillard. Si ce n'est pas le cas, voici trois initiatives de normalisation : , et .
Alors qu'auparavant, on ne considérait que deux niveaux, le cloud et les appareils finaux, l'architecture proposée introduit un nouveau niveau — le calcul en brouillard. Ce niveau de brouillard peut être divisé en plusieurs sous-niveaux, en fonction des spécificités des ressources ou de l'ensemble des politiques qui définissent l'utilisation de différents appareils à ces sous-niveaux.
À quoi pourrait ressembler cette abstraction ? Voici un écosystème typique IoT-Fog-Cloud. Les appareils IoT envoient des données vers des serveurs plus puissants et des dispositifs de calcul pour résoudre des problèmes nécessitant un faible niveau de latence. Dans ce système, les clouds sont responsables de la résolution de problèmes nécessitant une grande capacité de calcul ou un espace de stockage de données.
Les smartphones, montres intelligentes et autres gadgets peuvent également faire partie de l'IoT. Cependant, ces dispositifs utilisent généralement des protocoles de communication propriétaires des grands développeurs. Les données générées par l'internet des objets sont transmises au niveau du brouillard via le protocole REST HTTP, qui garantit flexibilité et compatibilité fonctionnelle lors de la création de services RESTful. Cela est crucial au regard de la nécessité d'assurer la rétrocompatibilité avec l'infrastructure informatique existante, fonctionnant sur des ordinateurs locaux, des serveurs ou un cluster de serveurs. Les ressources locales, appelées « nœuds de brouillard », filtrent les données reçues et les traitent localement ou les transmettent au cloud pour un traitement ultérieur.
Les clouds prennent en charge différents protocoles de communication, parmi lesquels AMQP et REST HTTP sont les plus courants. Puisque HTTP est bien connu et conçu pour Internet, une question peut se poser : « Ne faudrait-il pas l'utiliser pour interagir avec l'IoT et le brouillard ? ». Cependant, ce protocole présente des problèmes de performance. Nous en discuterons plus tard.
Dans l'ensemble, il existe deux modèles de protocoles de communication adaptés à notre système. Ce sont la demande-réponse et la publication-abonnement. Le premier modèle est plus largement connu, notamment dans l'architecture client-serveur. Le client demande des informations au serveur, qui reçoit la demande, la traite et renvoie un message de réponse. Les protocoles REST HTTP et CoAP fonctionnent selon ce modèle.
Le deuxième modèle est né de la nécessité d'assurer une communication asynchrone, distribuée et faiblement couplée entre les sources générant des données et les destinataires de ces données.
Le modèle implique trois participants : le publisher (source de données), le broker (dispatcher) et le subscriber (destinataire). Ici, le client, agissant en tant que subscriber, ne doit pas demander d'informations au serveur. Au lieu d'envoyer des requêtes, il s'abonne à des événements spécifiques dans le système via le broker, responsable de la filtration de tous les messages entrants et de leur acheminement entre publishers et subscribers. Quand un événement lié à un sujet particulier se produit, le publisher le publie auprès du broker, qui envoie les données au subscriber concernant le sujet demandé.
Cette architecture est essentiellement basée sur des événements. Ce modèle d'interaction est intéressant pour les applications IoT, cloud et fog grâce à sa capacité à garantir l'évolutivité et simplifier les interconnexions entre divers dispositifs, tout en maintenant une communication dynamique « plusieurs à plusieurs » et asynchrone. Parmi les protocoles de messagerie standardisés les plus connus utilisant le modèle « publication-abonnement », on peut citer MQTT, AMQP et DDS.
Il est évident que le modèle « publication-abonnement » présente de nombreux avantages :
- Les publishers et subscribers n'ont pas besoin de connaître l'existence l'un de l'autre;
- Un subscriber peut recevoir des informations de plusieurs publications différentes, tandis qu'un publisher peut envoyer des données à de nombreux subscribers différents (le principe des « plusieurs à plusieurs »);
- Publisher et subscriber ne doivent pas être actifs en même temps pour échanger des données, car le broker (opérant en tant que système de files d'attente) peut stocker un message pour des clients qui ne sont pas actuellement connectés au réseau.
Cependant, le modèle « requête-réponse » a aussi ses points forts. Dans les cas où les capacités du serveur à traiter les demandes de plusieurs clients ne posent pas de problème, il est logique d'utiliser des solutions éprouvées et fiables.
Il existe également des protocoles qui prennent en charge les deux modèles. Par exemple, XMPP et HTTP 2.0, qui supportent l'option « server push ». L'IETF a également publié CoAP. Dans une tentative de résoudre le problème de la messagerie, plusieurs autres solutions ont été créées, comme le protocole WebSockets ou l'utilisation du protocole HTTP via QUIC (Quick UDP Internet Connections).
Dans le cas des WebSockets, bien qu'il soit utilisé pour transmettre des données en temps réel du serveur vers le client web et assure des connexions permanentes avec une communication bidirectionnelle simultanée, il n'est pas destiné aux dispositifs ayant des ressources informatiques limitées. QUIC mérite également d'être mentionné, car ce nouveau protocole de transport offre de nombreuses nouvelles possibilités. Cependant, comme QUIC n'est pas encore standardisé, il est prématuré de prévoir son utilisation possible et son impact sur les solutions IoT. Ainsi, nous gardons WebSockets et QUIC en mémoire pour l'avenir, mais nous ne les étudierons pas plus en détail pour l'instant.
Qui est le plus aimable du monde : comparons les protocoles
Maintenant, parlons des forces et des faiblesses des protocoles. Pour anticiper, il convient de préciser qu'il n'existe pas de leader évident. Chaque protocole a ses avantages et inconvénients.
Temps de réponse
L'une des caractéristiques les plus importantes des protocoles de communication, en particulier pour l'Internet des objets, est le temps de réponse. Cependant, parmi les protocoles existants, il n'y a pas de gagnant incontesté démontrant le niveau de latence le plus bas dans différentes conditions. En revanche, il existe de nombreuses études et comparaisons des capacités des protocoles.
Par exemple, Les comparaisons de l'efficacité de HTTP et MQTT dans le cadre de l'IoT ont montré que le temps de réponse pour les requêtes de MQTT est inférieur à celui de HTTP. Et lors du temps de transmission (RTT) de MQTT et CoAP, il a été découvert que le RTT moyen de CoAP est de 20 % inférieur à celui de MQTT.
Autre Le RTT des protocoles MQTT et CoAP a été évalué dans deux scénarios : un réseau local et un réseau IoT. Il s'est avéré que le RTT moyen est de 2 à 3 fois plus élevé dans le réseau IoT. MQTT avec QoS0 a montré de moins bons résultats par rapport à CoAP, tandis que MQTT avec QoS1 a démontré un RTT plus élevé en raison des ACK aux niveaux application et transport. Pour différents niveaux de QoS, les délais dans le réseau sans surcharge pour MQTT étaient de quelques millisecondes, tandis que pour CoAP, ils étaient de centaines de microsecondes. Cependant, il convient de noter qu'en opérant dans des réseaux moins fiables, MQTT, fonctionnant sur TCP, produira des résultats complètement différents.
La latence des protocoles AMQP et MQTT par l'augmentation de la charge utile a montré qu'avec une faible charge, le niveau de latence est presque identique. Mais lors de la transmission de grandes quantités de données, MQTT démontre un temps de réponse plus court. De plus, dans une autre CoAP a été comparé à HTTP dans le scénario de communication machine à machine avec des dispositifs déployés sur des 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 transmettre un message CoAP via le réseau mobile a été presque trois fois plus court que le temps requis pour l'utilisation des messages HTTP.
Des études ont été menées qui ont comparé non pas deux, mais trois protocoles. Par exemple, la performance des protocoles IoT MQTT, DDS et CoAP dans un scénario d'application médicale à l'aide d'un émulateur de réseau. DDS a surpassé MQTT en termes de latence de télémétrie éprouvée dans diverses conditions réseau médiocres. CoAP basé sur UDP a bien fonctionné pour des applications nécessitant une réponse rapide, mais en raison de son fonctionnement sur UDP, il y a eu une perte de paquets significative et imprévisible.
Bande passante
La comparaison de MQTT et CoAP en termes d'efficacité d'utilisation de la bande passante a été réalisée par le comptage du total des données transférées par message. CoAP a montré une bande passante inférieure à celle de MQTT lors de l'envoi de petits messages. Toutefois, en comparant l'efficacité des protocoles en termes de rapport entre le nombre de bytes d'information utiles et le total des bytes transmis, CoAP s'est avéré plus efficace.
En cas L'utilisation de la bande passante MQTT, DDS (avec TCP comme protocole de transport) et CoAP a révélé que CoAP présentait généralement une consommation de bande passante relativement plus basse, qui n'augmentait pas avec une augmentation des pertes de paquets réseau ou d'une latence accrue, contrairement à MQTT et DDS, où une augmentation de l'utilisation de la bande passante a été observée dans les scénarios mentionnés. Dans un autre scénario, un grand nombre de dispositifs ont transmis des données simultanément, ce qui est un cas typique dans les environnements IoT. Les résultats ont montré qu'un usage plus élevé favorise CoAP.
Sous une faible charge, CoAP utilisait la bande passante la plus faible, suivi par MQTT et REST HTTP. Cependant, lorsque la taille des charges utiles augmentait, les meilleurs résultats revenaient à REST HTTP.
Consommation d'énergie
La question de la consommation d'énergie est toujours d'une grande importance, et dans un système IoT, elle l'est particulièrement. Si la consommation d'énergie de MQTT et HTTP, alors HTTP « consomme » beaucoup plus. Et CoAP est plus par rapport à MQTT, permettant de gérer la puissance. Dans des scénarios simples, MQTT est cependant plus adapté à l'échange d'informations dans les réseaux de l'internet des objets, surtout s'il n'y a pas de restrictions de puissance.
L'expérience comparant les capacités d'AMQP et de MQTT sur un banc d'essai dans un réseau sans fil mobile ou instable a montré qu'AMQP offre plus de fonctionnalités en termes de sécurité, alors que MQTT est plus économe en énergie.
Sécurité
La sécurité est une autre question cruciale soulevée lors de l'étude du thème de l'internet des objets et des calculs en cloud/edge. Le mécanisme de sécurité est généralement basé sur TLS dans HTTP, MQTT, AMQP et XMPP, ou DTLS dans CoAP, prenant en charge les deux options DDS.
TLS et DTLS commencent par un processus d'établissement de connexion entre le client et le serveur pour échanger des ensembles de chiffrement et des clés pris en charge. Les deux parties conviennent des ensembles pour garantir que les communications ultérieures se déroulent dans un canal sécurisé. La différence entre les deux réside dans de petites modifications qui permettent à DTLS, basé sur UDP, de fonctionner sur une connexion non fiable.
En cas Sur plusieurs réalisations différentes de TLS et DTLS, il a été constaté que TLS réussissait mieux à accomplir sa tâche. Les attaques sur DTLS ont été plus réussies en raison de sa tolérance aux erreurs.
Cependant, le plus gros problème de ces protocoles est qu'ils n'ont pas été conçus à l'origine pour être utilisés dans l'IoT et ne prévoient pas de fonctionner dans le brouillard ou le cloud. Par le biais d'un échange convenu (handshaking), ils ajoutent un trafic supplémentaire à chaque établissement de connexion, ce qui épuise les ressources de calcul. En moyenne, il y a une augmentation de 6,5 % pour TLS et de 11 % pour DTLS dans la surcharge par rapport à une communication sans niveau de sécurité. Dans des environnements riches en ressources, qui se trouvent généralement à cela ne posera pas de problème, mais dans les communications entre IoT et le niveau brouillard, cela devient une contrainte importante.
Que choisir alors ? 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 basées sur un seul protocole de communication
La pratique d'une solution à protocole unique présente de nombreux inconvénients. Par exemple, un protocole qui convient à un environnement limité peut ne pas fonctionner dans un domaine ayant des exigences strictes en matière de sécurité. Cela dit, nous devons écarter presque toutes les solutions possibles basées sur un seul protocole dans l'écosystème Fog-to-Cloud en IoT, à l'exception de MQTT et REST HTTP.
REST HTTP comme solution à protocole unique
Il existe un bon exemple d'interaction entre les requêtes et les réponses REST HTTP dans le domaine IoT-to-Fog : . Les animaux sont équipés de capteurs portables (client IoT, C) et sont gérés via une informatique cloud par un système de ferme intelligent (serveur Fog, S).
Dans l'en-tête de la méthode POST, la ressource à modifier (\/farm\/animals) est spécifiée, ainsi que la version HTTP et le type de contenu, qui dans ce cas est un objet JSON représentant la ferme d'élevage à laquelle le système doit se conformer (Dulcinée\/vache). La réponse du serveur indique que la demande a réussi en renvoyant un code d'état HTTPS 201 (ressource créée). La méthode GET doit uniquement indiquer la ressource demandée dans l'URI (par exemple, \/farm\/animals\/1), qui renvoie une 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 spécifique d'une ressource. Dans ce cas, l'URI pour le paramètre à modifier et la valeur actuelle (par exemple, indiquant qu'une vache est actuellement en pâturage, /farm/animals/1?state=walking) sont spécifiés dans la ressource. Enfin, la méthode DELETE est utilisée de la même manière que la méthode GET, mais elle supprime simplement la ressource en conséquence.
MQTT en tant que solution monoprotocol
Prenons la même ferme intelligente, mais au lieu d'utiliser REST HTTP, nous employons le protocole MQTT. Un serveur local avec la bibliothèque Mosquitto installée sert de courtier. Dans cet exemple, un simple ordinateur (désigné comme le serveur de la ferme) Raspberry Pi agit en tant que client MQTT, réalisé via l'installation de la bibliothèque MQTT Paho, totalement compatible avec le courtier Mosquitto.
Ce client correspond au niveau d'abstraction IoT représentant un dispositif avec des capacités de détection et de calcul. Le courtier, quant à lui, correspond à un niveau d'abstraction plus élevé, représentant un nœud de calcul en périphérie, caractérisé par de plus grandes capacités en matière de traitement et de stockage des données.
Dans le scénario proposé de la « ferme intelligente », le Raspberry Pi est connecté à un accéléromètre, à un GPS et à des capteurs de température, et publie les données de ces capteurs vers un nœud en périphérie. Comme vous le savez sûrement, MQTT considère les sujets comme une hiérarchie. Un éditeur MQTT peut publier des messages dans un ensemble spécifique de sujets. Dans notre cas, il y en a trois. Pour le capteur qui mesure la température dans l'abri des animaux, le client choisit le sujet (animalfarm/shed/temperature). Pour les capteurs qui mesurent la localisation GPS et le mouvement des animaux via l'accéléromètre, le client publie des mises à jour (animalfarm/animal/GPS) et (animalfarm/animal/movement).
Ces informations seront transmises au courtier, qui peut les conserver temporairement dans une base de données locale au cas où un autre abonné intéressé se manifesterait plus tard.
En plus du serveur local agissant en tant que courtier MQTT dans le brouillard et auquel les Raspberry Pi, agissant en tant que clients MQTT, envoient des données provenant 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 une base de données locale et/ou envoyées dans le cloud. Le courtier MQTT dans le brouillard est utilisé ici pour relier toutes les données au courtier MQTT dans le cloud. Avec cette architecture, l'utilisateur de l'application mobile peut être abonné aux deux courtiers.
En cas de défaillance de la connexion avec l'un des courtiers (par exemple, le cloud), l'utilisateur final recevra des informations de l'autre (brouillard). C'est une caractéristique typique des systèmes combinés de brouillard et de cloud. Par défaut, l'application mobile peut être configurée pour se connecter d'abord au courtier MQTT dans le brouillard, et en cas d'échec, se connecter au courtier MQTT dans le cloud. Cette solution est juste l'une des nombreuses dans les systèmes IoT-F2C.
Solutions multi-protocoles
Les solutions à protocole unique sont populaires en raison de leur mise en œuvre plus facile. Cependant, il est évident que dans les systèmes IoT-F2C, il est logique de combiner différents protocoles. L'idée est que différents protocoles peuvent fonctionner à différents niveaux. Prenons par exemple trois abstractions : les niveaux IoT, de brouillard et de cloud. Les dispositifs au niveau IoT sont généralement considérés comme limités. Pour cette revue, considérons les niveaux IoT comme les plus limités, les clouds comme les moins limités et le calcul de brouillard comme "quelque part au milieu". Il en résulte qu'entre IoT et les abstractions de brouillard, les solutions 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 REST HTTP, qui, grâce à sa flexibilité, est également utilisé entre IoT et les couches de brouillard.
Le principal problème ici est la compatibilité fonctionnelle des protocoles et la facilité de translation des messages d'un protocole à un autre. Idéalement, à l'avenir, l'architecture du système Internet des objets avec des ressources cloud et de brouillard sera indépendante du protocole de communication utilisé et assurera une bonne interopérabilité entre différents protocoles.
Puisqu'il n'en est pas ainsi en ce moment, il est judicieux de combiner des protocoles sans différences significatives. À cette fin, une solution potentielle est basée sur la combinaison de deux protocoles qui suivent le même style architectural, REST HTTP et CoAP. Une autre solution proposée repose sur la combinaison de deux protocoles qui offrent une communication selon le modèle « publication-abonnement », MQTT et AMQP. L'utilisation de concepts proches (à la fois MQTT et AMQP utilisent des courtiers, CoAP et HTTP utilisent REST) facilite 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 des requêtes-réponses, HTTP et CoAP, ainsi que leur possible intégration dans une solution IoT-F2C. Étant donné qu'HTTP est l'un des protocoles les plus connus et adaptés dans les réseaux modernes, il est peu probable qu'il soit totalement remplacé par d'autres protocoles de messagerie. Parmi les nœuds représentant des dispositifs puissants situés entre le cloud et la brume, REST HTTP est une solution judicieuse.
En revanche, pour les dispositifs avec des ressources computationnelles limitées, qui se connectent entre les niveaux de brume et IoT, il est plus efficace d'utiliser CoAP. Un des grands avantages de CoAP est en fait sa compatibilité avec HTTP, car les deux protocoles sont basés sur les principes REST.
La figure (b) montre deux modèles d'interaction « publication-abonnement » dans un même scénario, comprenant MQTT et AMQP. Bien que théoriquement les deux protocoles puissent être utilisés pour communiquer entre des nœuds à chaque niveau d'abstraction, leur emplacement doit être déterminé en fonction de la performance. MQTT a été conçu comme un protocole simplifié pour les dispositifs avec des ressources computationnelles limitées, il peut donc être utilisé pour la communication entre l'IoT et la brume. AMQP est mieux adapté aux dispositifs plus puissants, qui le positionneraient idéalement entre les nœuds de brume et de cloud. Au lieu de MQTT, le protocole XMPP peut être utilisé dans l'IoT, car il est considéré comme léger. Mais il n'est pas aussi largement utilisé dans de tels scénarios.
Conclusions
Il est peu probable qu'un des protocoles examinés suffise à couvrir toute la communication dans le système, allant des appareils aux ressources informatiques limitées jusqu'aux serveurs cloud. L'étude a montré que les deux options les plus prometteuses, souvent utilisées par les développeurs, sont MQTT et RESTful HTTP. Ces deux protocoles sont non seulement les plus matures et stables, mais incluent également de nombreuses implémentations bien documentées et réussies ainsi que des ressources en ligne.
Grâce à sa stabilité et à sa configuration simple, MQTT est un protocole qui a prouvé au fil du temps ses performances supérieures dans l'utilisation des appareils IoT à ressources limitées. Dans les parties du système où la connectivité limitée et la consommation d'énergie ne posent pas de problème, par exemple dans certains domaines de l'edge computing et la plupart des cloud computing, RESTful HTTP est un choix évident. Le CoAP doit également être pris en compte, car il se développe rapidement en tant que norme de communication IoT, et il est très probable qu'il atteigne bientôt un niveau de stabilité et de maturité similaire à MQTT et HTTP. Toutefois, la norme est encore en développement, ce qui pose des problèmes de compatibilité à court terme.
Quoi d'autre de полезного можна почитать в блоге
→
→
→
→
→
Abonnez-vous à notre -canal pour ne pas manquer le prochain article ! Nous écrivons pas plus de deux fois par semaine et uniquement sur des sujets pertinents.
Source : habr.com
