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 génère une énorme quantité de données. Par conséquent, il existe un besoin pour une architecture système pratique capable de traiter, stocker et transmettre ces données.
Désormais, les services cloud sont utilisés à ces fins. Cependant, le paradigme de Fog Computing (Fog), de plus en plus populaire, peut compléter les solutions cloud en faisant évoluer et en optimisant l'infrastructure IoT.
Les cloud sont capables de couvrir la plupart des demandes IoT. Par exemple, pour assurer la surveillance des services, le traitement rapide de toute quantité de données générées par les appareils, ainsi que leur visualisation. Le brouillard informatique est plus efficace pour résoudre des problèmes en temps réel. Ils offrent une réponse rapide aux demandes et une latence minimale dans le traitement des données. Autrement dit, Fog complète les « nuages » et étend ses capacités.
Cependant, la question principale est différente : comment tout cela doit-il interagir dans le contexte de l’IoT ? Quels protocoles de communication seront les plus efficaces lorsque l’on travaille dans un système combiné IoT-Fog-Cloud ?
Malgré l'apparente domination du HTTP, il existe un grand nombre d'autres solutions utilisées dans les systèmes IoT, Fog et Cloud. En effet, l'IoT doit combiner les fonctionnalités d'une variété de capteurs d'appareils avec la sécurité, la compatibilité et d'autres exigences des utilisateurs.
Mais il n’existe tout simplement pas d’idée unique sur l’architecture de référence et la norme de communication. Par conséquent, la création d’un nouveau protocole ou la modification d’un protocole existant pour des tâches IoT spécifiques est l’une des tâches les plus importantes auxquelles est confrontée la communauté informatique.
Quels protocoles sont actuellement utilisés et que peuvent-ils offrir ? Voyons cela. Mais d’abord, discutons des principes de l’écosystème dans lequel les nuages, le brouillard et l’Internet des objets interagissent.
Architecture IoT du brouillard au cloud (F2C)
Vous avez probablement remarqué combien d'efforts sont déployés pour explorer les avantages et les bénéfices associés à une gestion intelligente et coordonnée de l'IoT, du cloud et du brouillard. Si ce n’est pas le cas, voici trois initiatives de normalisation : , и .
Si auparavant seuls deux niveaux étaient pris en compte, les nuages et les terminaux, l'architecture proposée introduit un nouveau niveau : le fog computing. Dans ce cas, le niveau de brouillard peut être divisé en plusieurs sous-niveaux, en fonction des spécificités des ressources ou d'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 à des serveurs et des appareils informatiques plus rapides pour résoudre des problèmes nécessitant une faible latence. Dans le même système, les nuages sont chargés de résoudre des problèmes qui nécessitent une grande quantité de ressources informatiques ou d’espace de stockage de données.
Les smartphones, montres intelligentes et autres gadgets peuvent également faire partie de l'IoT. Mais ces appareils utilisent généralement des protocoles de communication propriétaires de grands développeurs. Les données IoT générées sont transférées vers la couche Fog via le protocole HTTP REST, qui offre flexibilité et interopérabilité lors de la création de services RESTful. Ceci est important compte tenu de la nécessité d’assurer une compatibilité ascendante 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 de brouillard », filtrent les données reçues et les traitent localement ou les envoient vers le cloud pour des calculs ultérieurs.
Les cloud prennent en charge différents protocoles de communication, les plus courants étant AMQP et REST HTTP. Puisque HTTP est bien connu et adapté à Internet, la question peut se poser : « ne devrions-nous pas l’utiliser pour travailler avec l’IoT et le brouillard ? Cependant, ce protocole présente des problèmes de performances. Nous en reparlerons 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 de requête-réponse et de publication-abonnement. Le premier modèle est plus connu, notamment dans l’architecture serveur-client. Le client demande des informations au serveur, et le serveur 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 un couplage asynchrone, distribué et lâche entre les sources générant des données et les destinataires de ces données.
Le modèle suppose trois participants : un éditeur (source de données), un courtier (répartiteur) et un abonné (récepteur). Ici, le client agissant en tant qu'abonné n'a pas besoin de demander d'informations au serveur. Au lieu d'envoyer des requêtes, 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 des données sur le sujet demandé à l'abonné.
Essentiellement, cette architecture est basée sur les événements. Et ce modèle d'interaction est intéressant pour les applications dans l'IoT, le cloud, le brouillard en raison de sa capacité à assurer l'évolutivité et à simplifier l'interconnexion entre différents appareils, à prendre en charge la communication dynamique plusieurs-à-plusieurs et la communication asynchrone. Certains des protocoles de messagerie standardisés les plus connus qui utilisent un modèle de publication-abonnement incluent MQTT, AMQP et DDS.
Évidemment, le modèle publication-abonnement présente de nombreux avantages :
- Les éditeurs et les abonnés n'ont pas besoin de connaître leur existence respective ;
- Un abonné peut recevoir des informations provenant de nombreuses publications différentes, et un éditeur peut envoyer des données à de nombreux abonnés différents (principe plusieurs à plusieurs) ;
- L'éditeur et l'abonné n'ont pas besoin d'être actifs en même temps pour communiquer, car le courtier (fonctionnant comme un système de file d'attente) pourra stocker le message pour les clients qui ne sont pas actuellement connectés au réseau.
Cependant, le modèle demande-réponse a aussi ses points forts. Dans les cas où la capacité du serveur à gérer plusieurs requêtes client ne pose pas de problème, il est logique d'utiliser des solutions éprouvées et fiables.
Il existe également des protocoles prenant en charge les deux modèles. Par exemple, XMPP et HTTP 2.0, qui prennent en charge l'option « server push ». L'IETF a également publié un CoAP. Pour tenter 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 sur QUIC (Quick UDP Internet Connections).
Dans le cas des WebSockets, bien qu'ils soient utilisés pour transférer des données en temps réel d'un serveur vers un client Web et qu'ils fournissent des connexions persistantes avec une communication bidirectionnelle simultanée, ils ne sont pas destinés aux appareils disposant de ressources informatiques limitées. QUIC mérite également qu'on s'y intéresse, car le nouveau protocole de transport offre de nombreuses nouvelles opportunité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 gardons donc WebSockets et QUIC à l’esprit en pensant à l’avenir, mais nous ne les étudierons pas plus en détail pour l’instant.
Qui est le plus mignon du monde : comparaison des protocoles
Parlons maintenant des forces et des faiblesses des protocoles. Pour l’avenir, faisons immédiatement une réserve : il n’y a pas de leader clair. Chaque protocole présente certains avantages/inconvénients.
Temps de réponse
L’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 de gagnant clair qui démontre le niveau minimum de latence lorsque l'on travaille dans différentes conditions. Mais il existe tout un tas de recherches et de comparaisons sur les capacités des protocoles.
Par exemple, des comparaisons de l'efficacité de HTTP et de MQTT lors de l'utilisation de l'IoT ont montré que le temps de réponse aux requêtes pour MQTT est inférieur à celui pour HTTP. Et quand Le temps d'aller-retour (RTT) de MQTT et CoAP a révélé que le RTT moyen de CoAP est inférieur de 20 % à celui de MQTT.
Autre avec RTT pour les protocoles MQTT et CoAP a été réalisé dans deux scénarios : réseau local et réseau IoT. Il s’est avéré que le RTT moyen est 2 à 3 fois plus élevé dans un 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 des ACK au niveau des couches application et transport. Pour différents niveaux de QoS, la latence du réseau sans congestion était de quelques millisecondes pour MQTT et de centaines de microsecondes pour CoAP. Cependant, il convient de rappeler que lorsque vous travaillez sur des réseaux moins fiables, MQTT exécuté sur TCP affichera un résultat complètement différent.
Le temps de réponse des protocoles AMQP et MQTT en augmentant la charge utile a montré qu'avec une charge légère, le niveau de latence est presque le même. Mais lors du transfert de grandes quantités de données, MQTT démontre des temps de réponse plus courts. dans un de plus 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 capteurs de localisation (GPS) et d'une interface de réseau mobile (GPRS). Le temps nécessaire pour transmettre un message CoAP sur le réseau mobile était presque trois fois plus court que le temps nécessaire pour utiliser des messages HTTP.
Des études ont été menées comparant non pas deux, mais trois protocoles. Par exemple, performances 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 testée dans diverses conditions de réseau médiocres. CoAP basé sur UDP fonctionnait bien pour les applications qui nécessitaient des temps de réponse rapides. Cependant, étant donné qu'il était basé sur UDP, il y avait une perte de paquets imprévisible et importante.
Bande passante
MQTT et CoAP en termes d'efficacité de la bande passante ont été réalisés sous la forme d'un calcul de la quantité totale de données transmises par message. CoAP a montré un débit inférieur à celui de MQTT lors de la transmission 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 transférés, CoAP s'est avéré plus efficace.
à en utilisant MQTT, DDS (avec TCP comme protocole de transport) et la bande passante CoAP, il a été constaté que CoAP présentait généralement une consommation de bande passante relativement plus faible, qui n'augmentait pas avec l'augmentation de la perte de paquets réseau ou de la latence réseau, contrairement à MQTT et DDS, où il y avait une augmentation de l’utilisation de la bande passante dans les scénarios mentionnés. Un autre scénario impliquait un grand nombre d’appareils transmettant des données simultanément, ce qui est typique des environnements IoT. Les résultats ont montré que pour une utilisation plus élevée, il est préférable d'utiliser CoAP.
Sous une charge légère, CoAP utilisait le moins de bande passante, suivi de MQTT et REST HTTP. Cependant, lorsque la taille des charges utiles augmentait, REST HTTP obtenait les meilleurs résultats.
Consommation d'énergie
La question de la consommation d’énergie est toujours d’une grande importance, et notamment dans un système IoT. Si Alors que MQTT et HTTP consomment de l’électricité, HTTP en consomme beaucoup plus. Et CoAP, c'est plus par rapport à MQTT, permettant la gestion de l'énergie. Cependant, dans des scénarios simples, MQTT est plus adapté à l'échange d'informations sur les réseaux Internet des objets, surtout s'il n'y a pas de restrictions de puissance.
Une expérience comparant les capacités d'AMQP et de MQTT sur un banc d'essai de réseau sans fil mobile ou instable a révélé qu'AMQP offre plus de capacités de sécurité tandis 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 du brouillard/cloud computing. Le mécanisme de sécurité est généralement basé sur TLS dans HTTP, MQTT, AMQP et XMPP, ou DTLS dans CoAP, et prend en charge les deux variantes 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 ensembles pour garantir que la communication ultérieure s'effectue sur 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.
à Plusieurs implémentations différentes de TLS et DTLS ont révélé que TLS faisait un meilleur travail. Les attaques contre DTLS ont eu plus de succès 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 n’étaient pas destinés à fonctionner dans le brouillard ou le cloud. Grâce à l'établissement de liaison, ils ajoutent du trafic supplémentaire à chaque établissement de connexion, ce qui épuise les ressources informatiques. En moyenne, il y a une augmentation de 6,5 % pour TLS et de 11 % pour DTLS en termes de surcharge par rapport aux communications sans couche de sécurité. Dans les environnements riches en ressources, généralement situés sur niveau, cela ne sera pas un problème, mais dans le lien entre l'IoT et le niveau de brouillard, cela devient une limitation importante.
Que choisir ? Il n'y a pas de réponse claire. MQTT et HTTP semblent être les protocoles les plus prometteurs car ils sont considérés comme des solutions IoT comparativement plus matures et plus stables par rapport aux autres protocoles.
Solutions basées sur un protocole de communication unifié
La pratique d’une solution à protocole unique présente de nombreux inconvénients. Par exemple, un protocole adapté à un environnement restreint peut ne pas fonctionner dans un domaine soumis à des exigences de sécurité strictes. Dans cet esprit, nous devons abandonner presque toutes les solutions possibles à protocole unique dans l’écosystème Fog-to-Cloud dans l’IoT, à l’exception de MQTT et REST HTTP.
REST HTTP comme solution à protocole unique
Il existe un bon exemple de la manière dont les requêtes et réponses HTTP REST interagissent dans l’espace IoT-to-Fog : . Les animaux sont équipés de capteurs portables (client IoT, C) et contrôlés via le cloud computing par un système d'agriculture intelligent (serveur Fog, S).
L'en-tête de la méthode POST précise la ressource à modifier (/farm/animals) ainsi que la version HTTP et le type de contenu, qui dans ce cas est un objet JSON représentant la ferme d'animaux que le système doit gérer (Dulcinea/cow). . La réponse du serveur indique que la requête a abouti en envoyant le code d'état HTTPS 201 (ressource créée). La méthode GET doit spécifier uniquement la ressource demandée dans l'URI (par exemple, /farm/animals/1), qui renvoie une représentation JSON de l'animal avec cet ID depuis le serveur.
La méthode PUT est utilisée lorsqu'un enregistrement de ressource spécifique doit être mis à jour. Dans ce cas, la ressource précise l'URI du 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 de la même manière que la méthode GET, mais supprime simplement la ressource à la suite de l'opération.
MQTT comme solution à protocole unique
Prenons la même ferme intelligente, mais au lieu de REST HTTP, nous utilisons le protocole MQTT. Un serveur local sur lequel la bibliothèque Mosquitto est installée fait office de courtier. Dans cet exemple, un simple ordinateur (appelé serveur de ferme) Raspberry Pi sert de client MQTT, implémenté via une installation de la bibliothèque Paho MQTT, entièrement compatible avec le courtier Mosquitto.
Ce client correspond à une couche d'abstraction IoT représentant un appareil doté de capacités de détection et de calcul. Le médiateur, quant à lui, correspond à un niveau d'abstraction plus élevé, représentant un nœud de brouillard informatique caractérisé par une plus grande capacité de traitement et de stockage.
Dans le scénario de ferme intelligente 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 vers un nœud de brouillard. Comme vous le savez probablement, MQTT traite les sujets comme une hiérarchie. Un seul éditeur MQTT peut publier des messages sur un ensemble spécifique de sujets. Dans notre cas, il y en a trois. Pour un capteur mesurant la température dans une étable, le client sélectionne un thème (ferme d'animaux/hangar/température). Pour les capteurs qui mesurent la localisation GPS et le mouvement des animaux via l'accéléromètre, le client publiera des mises à jour sur (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é se présenterait ultérieurement.
En plus du serveur local, qui fait office de courtier MQTT dans le brouillard et auquel les Raspberry Pi, agissant en tant que clients MQTT, envoient les données des 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 vers le cloud. Le courtier Fog MQTT dans cette situation est utilisé pour associer toutes les données au courtier cloud MQTT. Avec cette architecture, un utilisateur d'application mobile peut être abonné aux deux courtiers.
Si la connexion à l'un des courtiers (par exemple, cloud) échoue, l'utilisateur final recevra des informations de l'autre (brouillard). Il s’agit d’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 d'abord au courtier Fog MQTT, et en cas d'échec, pour se connecter au courtier cloud MQTT. Cette solution n’est qu’une parmi tant d’autres dans les systèmes IoT-F2C.
Solutions multiprotocoles
Les solutions à protocole unique sont populaires en raison de leur mise en œuvre plus facile. Mais il est clair 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 couches de l'IoT, du brouillard et du cloud computing. Les appareils au niveau IoT sont généralement considérés comme limités. Pour cet aperçu, considérons les niveaux IoT comme les plus contraints, le cloud comme le moins contraint et le brouillard informatique comme « quelque part au milieu ». Il s’avère alors qu’entre l’IoT et les abstractions de brouillard, les solutions de protocole actuelles incluent MQTT, CoAP et XMPP. Entre brouillard et cloud, en revanche, AMQP est l'un des principaux protocoles utilisés, avec REST HTTP, qui, en raison de sa flexibilité, est également utilisé entre les couches IoT et brouillard.
Le principal problème ici est l’interopérabilité des protocoles et la facilité de transfert de messages d’un protocole à un autre. Idéalement, à l’avenir, l’architecture d’un système Internet des objets avec ressources cloud et brouillard sera indépendante du protocole de communication utilisé et assurera une bonne interopérabilité entre les différents protocoles.
Comme ce n’est pas le cas actuellement, il est logique de combiner des protocoles qui ne présentent pas de différences significatives. À cette fin, une solution potentielle repose sur une combinaison de deux protocoles qui suivent le même style architectural, REST HTTP et CoAP. Une autre solution proposée est basée sur une combinaison de deux protocoles offrant une communication publication-abonnement, MQTT et AMQP. L'utilisation de concepts similaires (MQTT et AMQP utilisent des courtiers, CoAP et HTTP utilisent REST) rend ces combinaisons plus faciles à mettre en œuvre et nécessitent moins d'efforts d'intégration.
La figure (a) montre deux modèles basés sur requête-réponse, HTTP et CoAP, et leur placement possible dans une solution IoT-F2C. Étant donné que HTTP est l’un des protocoles les plus connus et adoptés sur les réseaux modernes, il est peu probable qu’il soit complètement remplacé par d’autres protocoles de messagerie. Parmi les nœuds représentant des appareils puissants situés entre le cloud et le brouillard, REST HTTP est une solution intelligente.
En revanche, pour les appareils dotés de ressources informatiques limitées qui communiquent entre les couches Fog et IoT, il est plus efficace d'utiliser CoAP. L’un des gros avantages de CoAP est en fait sa compatibilité avec HTTP, puisque les deux protocoles sont basés sur les principes REST.
La figure (b) montre deux modèles de communication publication-abonnement dans le même scénario, notamment MQTT et AMQP. Bien que les deux protocoles puissent hypothétiquement être utilisés pour la communication entre les nœuds de chaque couche d'abstraction, leur position doit être déterminée en fonction des performances. MQTT a été conçu comme un protocole léger pour les appareils dotés de ressources informatiques limitées, il peut donc être utilisé pour la communication IoT-Fog. AMQP est plus adapté aux appareils plus puissants, ce qui le positionnerait idéalement entre les nœuds de brouillard et de nuages. 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.
résultats
Il est peu probable que l'un des protocoles discutés soit suffisant pour couvrir toutes les communications d'un système, depuis les appareils dotés de ressources informatiques limitées jusqu'aux serveurs cloud. L'étude a révélé que les deux options les plus prometteuses que les développeurs utilisent le plus sont MQTT et RESTful HTTP. Ces deux protocoles sont non seulement les plus matures et les plus stables, mais incluent également de nombreuses implémentations et ressources en ligne bien documentées et réussies.
En raison de sa stabilité et de sa configuration simple, MQTT est un protocole qui a prouvé ses performances supérieures au fil du temps lorsqu'il est utilisé au niveau IoT avec des appareils limités. Dans les parties du système où les communications limitées et la consommation de la batterie ne posent pas de problèmes, comme certains domaines de brouillard et la plupart des cloud computing, RESTful HTTP est un choix facile. CoAP doit également être pris en compte car il évolue également rapidement en tant que norme de messagerie IoT et il est probable qu'il atteindra un niveau de stabilité et de maturité similaire à MQTT et HTTP dans un avenir proche. Mais la norme évolue actuellement, ce qui entraîne des problèmes de compatibilité à court terme.
Que pouvez-vous lire d'autre sur le blog ?
→
→
→
→
→
Abonnez-vous à notre -channel, pour ne pas rater le prochain article ! Nous n'écrivons pas plus de deux fois par semaine et uniquement pour affaires.
Source: habr.com