IoT, Nebel und Wolken: Über Technologie sprechen?

Die Entwicklung von Technologien im Bereich Software und Hardware sowie die Einführung neuer Kommunikationsprotokolle haben zur Erweiterung des Internet der Dinge (IoT) geführt. Die Anzahl der Geräte wächst von Tag zu Tag und sie generieren eine große Datenmenge. Daher besteht ein Bedarf an einer bequemen Systemarchitektur, die diese Daten verarbeiten, speichern und übertragen kann.

Jetzt nutzen sie Cloud-Dienste für diese Zwecke. Das ständig wachsende Foggy-Paradigma (Fog) kann Cloud-Lösungen jedoch durch Skalierung und Optimierung der IoT-Infrastruktur ergänzen.

Clouds können die meisten IoT-Anforderungen schließen. Zum Beispiel, um Überwachungsdienste bereitzustellen, eine schnelle Verarbeitung jeder von Geräten generierten Datenmenge sowie deren Visualisierung. Misty Computing ist effektiver bei der Lösung von Echtzeitproblemen. Sie bieten eine schnelle Antwort auf Anfragen und eine minimale Verzögerung bei der Datenverarbeitung. Das heißt, Nebel ergänzt genau die "Wolken", erweitert seine Fähigkeiten.

Die Hauptfrage ist jedoch anders: Wie sollte all dies im Kontext des IoT interagieren? Welche Kommunikationsprotokolle sind am effektivsten, wenn Sie in einem einheitlichen IoT-Fog-Cloud-System arbeiten?

Trotz der offensichtlichen Dominanz von HTTP verwenden IoT, Fog und Cloud eine Vielzahl anderer Lösungen. Dies liegt daran, dass IoT die Funktionalität einer Vielzahl von Gerätesensoren mit der Sicherheit, Interoperabilität und anderen Benutzeranforderungen kombinieren muss.

Hier ist nur eine einzige Vorstellung von der Referenzarchitektur und der Kommunikationsstandard ist einfach nicht da. Daher ist die Erstellung eines neuen Protokolls oder die Verfeinerung eines vorhandenen Protokolls für bestimmte IoT-Aufgaben eine der wichtigsten Aufgaben der IT-Community.

Welche Protokolle werden derzeit verwendet und was können sie bieten? Lass es uns richtig machen. Aber zuerst wollen wir die Prinzipien eines Ökosystems diskutieren, in dem Wolken, Nebel und das Internet der Dinge interagieren.

IoT Fog-to-Cloud-Architektur (F2C)

Sie müssen bemerkt haben, wie viel Aufwand darauf verwendet wurde, die Vorteile und den Nutzen einer rationalen und koordinierten Verwaltung von IoT, Wolken und Nebel zu untersuchen. Wenn nicht, gibt es bereits drei Standardisierungsinitiativen: OpenFog Consortium , Edge Computing Consortium und mF2C H2020 EU-Projekt .

Wenn früher nur 2 Ebenen, Clouds und Endgeräte berücksichtigt wurden, führt die vorgeschlagene Architektur eine neue Ebene ein - Fog Computing. In diesem Fall kann der Nebelpegel in mehrere Unterebenen unterteilt werden, abhängig von den Besonderheiten der Ressourcen oder einer Reihe von Richtlinien, die die Verwendung verschiedener Geräte in diesen Unterebenen bestimmen.

Wie könnte diese Abstraktion aussehen? Hier ist ein typisches IoT-Fog-Cloud-Ökosystem. IoT-Geräte senden Daten an leistungsfähigere Server und Computergeräte, um Aufgaben zu lösen, die eine geringe Latenz erfordern. Im selben System sind Clouds für die Lösung von Problemen verantwortlich, die eine große Menge an Rechenressourcen oder Datenspeicherplatz erfordern.



Smartphones, Smartwatches und andere Geräte können ebenfalls Teil des IoT sein. Solche Geräte verwenden jedoch in der Regel proprietäre Kommunikationsprotokolle großer Entwickler. Die generierten IoT-Daten werden über das REST-HTTP-Protokoll an die Nebelebene übergeben, das Flexibilität und Interoperabilität beim Erstellen von RESTful-Diensten bietet. Dies ist wichtig im Hinblick auf die Notwendigkeit der Abwärtskompatibilität mit der vorhandenen Computerinfrastruktur, die auf lokalen Computern, Servern oder einem Servercluster ausgeführt wird. Lokale Ressourcen, die als "Knoten des Nebels" bezeichnet werden, filtern die empfangenen Daten und verarbeiten sie lokal oder senden sie zur weiteren Berechnung an die Cloud.

Clouds unterstützen verschiedene Kommunikationsprotokolle, darunter AMQP und REST HTTP. Da HTTP für das Internet bekannt und inhaftiert ist, kann sich die Frage stellen: "Aber sollte ich es verwenden, um mit IoT und Nebel zu arbeiten?". Dieses Protokoll weist jedoch Leistungsprobleme auf. Dazu später mehr.

Im Allgemeinen gibt es zwei Modelle von Kommunikationsprotokollen, die für das von uns benötigte System geeignet sind. Dies ist ein Anfrage-Antwort- und Publikationsabonnement. Das erste Modell ist insbesondere in der Server-Client-Architektur bekannter. Der Client fordert Informationen vom Server an, empfängt die Anforderung, verarbeitet sie und gibt eine Antwortnachricht zurück. Die REST-HTTP- und CoAP-Protokolle funktionieren mit diesem Modell.

Das zweite Modell entstand aufgrund der Notwendigkeit, eine asynchrone, verteilte, schwache Kommunikation zwischen den Quellen, die Daten erzeugen, und den Empfängern dieser Daten bereitzustellen.



Das Modell umfasst drei Teilnehmer: den Herausgeber (Datenquelle), den Broker (Dispatcher) und den Abonnenten (Empfänger). Hier sollte der Client, der als Abonnent fungiert, keine Informationen vom Server anfordern. Anstatt Anforderungen zu senden, abonniert er bestimmte Ereignisse im System über einen Broker, der dafür verantwortlich ist, alle eingehenden Nachrichten zu filtern und zwischen Herausgebern und Abonnenten weiterzuleiten. Wenn der Herausgeber ein Ereignis zu einem bestimmten Thema eintritt, veröffentlicht er es an den Broker, der die Abonnentendaten zum angeforderten Thema sendet.

Im Wesentlichen ist diese Architektur ereignisgesteuert. Dieses Interaktionsmodell ist für Anwendungen in IoT, Cloud und Fog interessant, da es Skalierbarkeit bietet und die Verbindung zwischen verschiedenen Geräten vereinfacht, um dynamische Viele-zu-Viele-Kommunikation und asynchrone Kommunikation zu unterstützen. Zu den bekanntesten standardisierten Messaging-Protokollen, die das Publish-Subscribe-Modell verwenden, gehören MQTT, AMQP und DDS.

Offensichtlich hat das Publikations-Abonnement-Modell viele Vorteile:

• Verleger und Abonnenten müssen nicht über die Existenz des anderen Bescheid wissen.
• Ein Abonnent kann Informationen aus vielen verschiedenen Veröffentlichungen empfangen, und ein Verlag kann Daten an viele verschiedene Abonnenten senden (das Prinzip „viele zu viele“).
• Der Herausgeber und der Abonnent müssen nicht gleichzeitig für den Datenaustausch aktiv sein, da der Broker (der als Warteschlangensystem arbeitet) eine Nachricht für Clients speichern kann, die derzeit nicht mit dem Netzwerk verbunden sind.

Das Request-Response-Modell hat jedoch auch seine eigenen Stärken. In Fällen, in denen die Fähigkeiten der Serverseite zur Verarbeitung von Anforderungen mehrerer Clients kein Problem darstellen, ist es sinnvoll, bereits bewährte zuverlässige Lösungen zu verwenden.

Es gibt auch Protokolle, die beide Modelle unterstützen. Zum Beispiel XMPP und HTTP 2.0, die die Server-Push-Option unterstützen. Die IETF hat auch CoAP veröffentlicht. Um das Messaging-Problem zu lösen, wurden mehrere andere Lösungen erstellt, z. B. das WebSockets-Protokoll oder die Verwendung des HTTP-Protokolls über QUIC (Quick UDP Internet Connections).

Im Fall von WebSockets ist es nicht für Geräte mit begrenzten Rechenressourcen vorgesehen, obwohl es für die Echtzeit-Datenübertragung vom Server zum Webclient verwendet wird und konstante Verbindungen bei gleichzeitiger bidirektionaler Kommunikation bietet. QUIC verdient ebenfalls Aufmerksamkeit, da das neue Transportprotokoll viele neue Funktionen bietet. Da QUIC jedoch noch nicht standardisiert ist, ist es verfrüht, seine mögliche Anwendung und Auswirkungen auf IoT-Lösungen vorherzusagen. Wir lassen WebSockets und QUIC mit Blick auf die Zukunft im Gedächtnis, werden aber noch nicht näher darauf eingehen.

Wer auf der Welt ist am süßesten: Wir vergleichen Protokolle

Lassen Sie uns nun über die Stärken und Schwächen der Protokolle sprechen. Mit Blick auf die Zukunft machen wir sofort einen Vorbehalt, dass es keinen klaren Führer gibt. Jedes Protokoll hat einige Vor- und Nachteile.

Reaktionszeit

Eine der wichtigsten Eigenschaften von Kommunikationsprotokollen, insbesondere im Hinblick auf das Internet der Dinge, ist die Reaktionszeit. Unter den vorhandenen Protokollen gibt es jedoch keine Besonderheit, die ein Mindestmaß an Verzögerung beim Arbeiten unter verschiedenen Bedingungen aufweist. Es gibt jedoch eine ganze Reihe von Untersuchungen und Vergleichen der Protokollfunktionen.

Beispielsweise zeigten die Ergebnisse des Vergleichs der Wirksamkeit von HTTP und MQTT bei der Arbeit mit IoT, dass die Antwortzeit für Anforderungen von MQTT geringer ist als die von HTTP. Bei der Untersuchung der Empfangs- und Sendezeit (RTT) von MQTT und CoAP stellte sich heraus, dass die durchschnittliche RTT-CoAP 20% unter der von MQTT liegt.

Ein weiteres Experiment mit RTT für die Protokolle MQTT und CoAP wurde in zwei Szenarien durchgeführt: einem lokalen Netzwerk und einem IoT-Netzwerk. Es stellte sich heraus, dass die durchschnittliche RTT im IoT-Netzwerk 2-3 mal höher ist. MQTT mit QoS0 zeigte im Vergleich zu CoAP ein niedrigeres Ergebnis, und MQTT mit QoS1 zeigte aufgrund von ACK auf Anwendungs- und Transportebene eine höhere RTT. Für verschiedene QoS-Ebenen betrugen die Netzwerkverzögerungen ohne Überlastung für MQTT Millisekunden und für CoAP Hunderte von Mikrosekunden. Es ist jedoch zu beachten, dass MQTT, das auf TCP ausgeführt wird, bei der Arbeit in weniger zuverlässigen Netzwerken ein anderes Ergebnis zeigt.

Ein Vergleich der Antwortzeit für die AMQP- und MQTT-Protokolle durch Erhöhen der Nutzlast ergab, dass bei einer kleinen Last der Verzögerungspegel nahezu gleich ist. Bei der Übertragung großer Datenmengen zeigt MQTT jedoch eine geringere Antwortzeit. In einer anderen Studie wurde CoAP mit HTTP in einem Kommunikationsszenario von Maschine zu Maschine verglichen, wobei Geräte auf Fahrzeugen eingesetzt wurden, die mit Gassensoren, Wettersensoren, Standort (GPS) und einer Mobilfunknetzschnittstelle (GPRS) ausgestattet waren. Die Zeit zum Senden einer CoAP-Nachricht über ein Mobilfunknetz war fast dreimal kürzer als die Zeit zum Verwenden von HTTP-Nachrichten.

Es wurden Studien durchgeführt, in denen nicht zwei, sondern drei Protokolle verglichen wurden. Vergleichen Sie beispielsweise die Leistung der IoT-Protokolle MQTT, DDS und CoAP in einem medizinischen Anwendungsfall mithilfe eines Netzwerkemulators. DDS übertraf MQTT in Bezug auf die erfahrene Telemetrie-Latenz unter verschiedenen schlechten Netzwerkbedingungen. UDP-basiertes CoAP funktionierte gut für Anwendungen, die eine schnelle Antwort benötigten. Da es jedoch UDP-basiert war, gab es einen erheblichen unvorhersehbaren Paketverlust.

Durchsatz

Der Vergleich von MQTT und CoAP hinsichtlich der Bandbreitennutzung wurde als Berechnung der Gesamtmenge der pro Nachricht übertragenen Daten durchgeführt. CoAP zeigte beim Senden kleiner Nachrichten weniger Bandbreite als MQTT. Beim Vergleich der Wirksamkeit der Protokolle hinsichtlich des Verhältnisses der Anzahl nützlicher Informationsbytes zur Gesamtzahl der übertragenen Bytes war CoAP jedoch effektiver.

Bei der Analyse der Verwendung von MQTT, DDS (mit TCP als Transportprotokoll) und CoAP-Bandbreite stellte sich heraus, dass CoAP tendenziell einen relativ geringeren Bandbreitenverbrauch aufwies, der im Gegensatz zu einem Anstieg des Netzwerkpaketverlusts oder einer erhöhten Netzwerkverzögerung nicht zunahm MQTT und DDS, bei denen in den genannten Szenarien die Nutzung der Kanalkapazität zunahm. In einem anderen Szenario übertrug eine große Anzahl von Geräten gleichzeitig Daten, was in IoT-Umgebungen ein typischer Fall ist. Die Ergebnisse zeigten, dass es für eine höhere Last besser ist, CoAP zu verwenden.

Bei geringer Last verwendete CoAP die geringste Bandbreite, gefolgt von MQTT und HTTP REST. Wenn jedoch die Nutzlastgröße zunahm, erzielte REST-HTTP die besten Ergebnisse.

Stromverbrauch

Das Thema Energieverbrauch ist immer von großer Bedeutung, insbesondere im IoT-System. Wenn wir den Stromverbrauch von MQTT und HTTP vergleichen, „frisst“ HTTP viel mehr. Und CoAP ist energieeffizienter als MQTT, sodass Sie die Stromversorgung verwalten können. Darüber hinaus eignet sich MQTT in einfachen Szenarien besser für den Informationsaustausch im Internet der Dinge, insbesondere wenn keine Leistungsbeschränkungen bestehen.

Ein weiteres Experiment, bei dem die Funktionen von AMQP und MQTT auf einem Prüfstand für ein mobiles oder instabiles drahtloses Netzwerk verglichen wurden, zeigte, dass AMQP mehr Sicherheitsoptionen bietet, während MQTT energieeffizienter ist.

Sicherheit

Sicherheit ist ein weiteres wichtiges Thema, das beim Studium des Themas Internet der Dinge und Foggy / Cloud Computing angesprochen wird. Der Sicherheitsmechanismus basiert normalerweise auf TLS in HTTP, MQTT, AMQP und XMPP, auf oder DTLS in CoAP und unterstützt auch beide Versionen von DDS.

TLS und DTLS beginnen mit dem Aufbau der Kommunikation zwischen Client- und Serverseite, um unterstützte Cipher Suites und Schlüssel auszutauschen. Beide Parteien verhandeln Kits, um sicherzustellen, dass die weitere Kommunikation in einem sicheren Kanal stattfindet. Der Unterschied zwischen beiden besteht in kleinen Änderungen, die es UDP-basierten DTLS ermöglichen, über eine unzuverlässige Verbindung zu arbeiten.

Bei Testangriffen auf mehrere verschiedene TLS- und DTLS-Implementierungen stellte sich heraus, dass TLS bessere Arbeit geleistet hat. Die Angriffe auf DTLS waren aufgrund ihrer Fehlertoleranz erfolgreicher.

Das größte Problem bei diesen Protokollen ist jedoch, dass sie ursprünglich nicht für die Verwendung im Internet der Dinge (IoT) entwickelt wurden und keine Arbeiten im Nebel oder in der Wolke beinhalteten. Durch einen konsistenten Austausch (Handshake) fügen sie mit jeder Verbindung zusätzlichen Datenverkehr hinzu, wodurch die Rechenressourcen erschöpft werden. Im Durchschnitt steigt die Arbeitslast für TLS um 6,5% und für DTLS um 11% im Vergleich zur Kommunikation ohne Sicherheitsstufe. In ressourcenreichen Umgebungen, die normalerweise Cloud- basiert sind, ist dies kein Problem, dies wird jedoch zu einer wichtigen Einschränkung zwischen dem IoT und der Nebelebene.

Was soll ich wählen? Es gibt keine eindeutige Antwort. MQTT und HTTP scheinen die vielversprechendsten Protokolle zu sein, da sie im Vergleich zu anderen Protokollen als relativ ausgereiftere und stabilere Lösungen für IoT gelten.

Unified Communications-Protokolllösungen

Die Praxis einer Einzelprotokolllösung hat viele Nachteile. Beispielsweise funktioniert ein Protokoll, das eine eingeschränkte Umgebung erfüllt, möglicherweise nicht in einer Domäne mit strengen Sicherheitsanforderungen. Vor diesem Hintergrund müssen wir fast alle möglichen Lösungen, die auf einem Protokoll im Fog-to-Cloud-Ökosystem im IoT basieren, mit Ausnahme von MQTT und REST HTTP verwerfen.

REST HTTP als Einzelprotokolllösung

Es gibt ein gutes Beispiel für die Interaktion von IoT-zu-Nebel-REST-HTTP-Anforderungen und -Antworten: Smart Farm . Tiere sind mit tragbaren Sensoren (IoT-Client, C) ausgestattet und werden über Cloud Computing von einem Smart Farming-System (Fog Server, S) gesteuert.

Der Titel der POST-Methode gibt die zu ändernde Ressource (/ Farm / Tiere) sowie die HTTP-Version und den Inhaltstyp an. In diesem Fall handelt es sich um ein JSON-Objekt, das die vom System zu verwaltende Tierfarm darstellt (Dulcinea / Kuh). Eine Antwort vom Server zeigt an, dass die Anforderung erfolgreich war, indem ein HTTPS 201-Statuscode (Ressource erstellt) gesendet wurde. Die GET-Methode sollte nur die angeforderte Ressource in der URI angeben (z. B. / farm / animal / 1), die die JSON-Darstellung des Tieres mit dieser Kennung vom Server zurückgibt.

Die PUT-Methode wird verwendet, wenn Sie einen bestimmten Ressourceneintrag aktualisieren müssen. In diesem Fall wird der URI in der Ressource für den zu ändernden Parameter und den aktuellen Wert angegeben (z. B. um anzuzeigen, dass die Kuh gerade läuft, / farm / animal / 1? State = walk). Schließlich wird die DELETE-Methode gleichermaßen für die GET-Methode verwendet, löscht jedoch einfach die Ressource als Ergebnis der Operation.

MQTT als Einzelprotokolllösung



Nehmen Sie dieselbe Smart Farm, aber anstelle von REST-HTTP verwenden wir das MQTT-Protokoll. Der lokale Server mit der installierten Mosquitto-Bibliothek fungiert als Broker. In diesem Beispiel dient ein einfacher Computer (als Farmserver bezeichnet) Raspberry Pi als MQTT-Client, der durch die Installation der MQTT Paho-Bibliothek implementiert wird, die vollständig mit dem Mosquitto-Broker kompatibel ist.

Dieser Client entspricht der IoT-Abstraktionsschicht, die ein Gerät mit Erkennungs- und Rechenfunktionen darstellt. Der Vermittler hingegen entspricht einer höheren Abstraktionsebene, die den Rechenknoten des Nebels darstellt, der sich durch große Leistung bei der Verarbeitung und Speicherung von Daten auszeichnet.

Im vorgeschlagenen Smart Farm-Szenario stellt der Raspberry Pi eine Verbindung zu Beschleunigungsmesser, GPS und Temperatursensoren her und veröffentlicht Daten von diesen Sensoren im Nebelknoten. Wie Sie wahrscheinlich wissen, behandelt MQTT Themen als Hierarchie. Ein MQTT-Publisher kann bestimmte Themen veröffentlichen. In unserem Fall gibt es drei davon. Für einen Sensor, der die Temperatur in einem Tierstall misst, wählt der Kunde ein Thema (Tierfarm / Stall / Temperatur). Für Sensoren, die den GPS-Standort und die Tierbewegung über den Beschleunigungsmesser messen, veröffentlicht der Client Aktualisierungen (Tierfarm / Tier / GPS) und (Tierfarm / Tier / Bewegung).

Diese Informationen werden an den Broker übertragen, der sie vorübergehend in einer lokalen Datenbank speichern kann, falls später ein anderer interessierter Abonnent erscheint.

Zusätzlich zu dem lokalen Server, der als MQTT-Broker im Nebel fungiert und an den Raspberry Pi als MQTT-Clients Daten von Sensoren sendet, gibt es möglicherweise einen weiteren MQTT-Broker auf Cloud-Ebene. In diesem Fall können die an den lokalen Broker übertragenen Informationen vorübergehend in der lokalen Datenbank gespeichert und / oder an die Cloud gesendet werden. Der neblige MQTT-Broker wird in dieser Situation verwendet, um alle Daten mit dem Cloud-MQTT-Broker zu verknüpfen. Mit dieser Architektur kann ein Benutzer einer mobilen Anwendung beide Broker abonnieren.

Bei einem Verbindungsfehler mit einem der Broker (z. B. Cloud) erhält der Endbenutzer Informationen von einem anderen (nebligen). Dies ist ein Merkmal kombinierter Nebel- und Cloud-Computing-Systeme. Standardmäßig kann die mobile Anwendung für die erste Verbindung zum nebligen MQTT-Broker und im Fehlerfall für die Verbindung zum MQTT-Broker in der Cloud konfiguriert werden. Diese Lösung ist nur eine von vielen in IoT-F2C-Systemen.

Multiprotokoll-Lösungen

Einzelprotokolllösungen sind wegen ihrer einfacheren Implementierung beliebt. Es ist jedoch offensichtlich, dass es in IoT-F2C-Systemen sinnvoll ist, verschiedene Protokolle zu kombinieren. Der Punkt ist, dass verschiedene Protokolle auf verschiedenen Ebenen funktionieren können. Nehmen Sie zum Beispiel drei Abstraktionen: IoT-, Nebel- und Cloud-Computing-Ebenen. IoT-Geräte gelten im Allgemeinen als begrenzt. Betrachten wir für diese Überprüfung die IoT-Ebenen als am begrenztesten, die Wolke als am wenigsten begrenzt und die Nebelberechnung als „irgendwo in der Mitte“. Dann stellt sich heraus, dass zwischen IoT- und Nebelabstraktionen die aktuellen Protokollentscheidungen MQTT, CoAP und XMPP umfassen. Auf der anderen Seite zwischen Nebel und Wolke ist AMQP neben HTTP REST eines der Hauptprotokolle, das aufgrund seiner Flexibilität auch zwischen IoT und Nebelschichten verwendet wird.

Das Hauptproblem hierbei ist die Interoperabilität der Protokolle und die Einfachheit der Übersetzung von Nachrichten von einem Protokoll in ein anderes. Idealerweise wird die Architektur des IoT-Systems mit Cloud- und Nebelressourcen in Zukunft unabhängig vom verwendeten Kommunikationsprotokoll sein und eine gute Interoperabilität zwischen verschiedenen Protokollen bieten.



Da dies derzeit nicht der Fall ist, ist es sinnvoll, Protokolle zu kombinieren, die keine signifikanten Unterschiede aufweisen. Zu diesem Zweck basiert eine mögliche Lösung auf einer Kombination von zwei Protokollen, die demselben Architekturstil entsprechen, REST HTTP und CoAP. Eine andere vorgeschlagene Lösung basiert auf einer Kombination von zwei Protokollen, die eine Interaktion zwischen Veröffentlichung und Abonnement bieten, MQTT und AMQP. Die Verwendung enger Konzepte (sowohl MQTT als auch AMQP verwenden Broker, CoAP und HTTP verwenden REST) ​​vereinfacht die Implementierung dieser Kombinationen und erfordert weniger Integrationsaufwand.



Abbildung (a) zeigt zwei Modelle basierend auf Request-Response, HTTP und CoAP, und deren mögliche Platzierung in der IoT-F2C-Lösung.Da HTTP eines der bekanntesten und angepasstesten Protokolle in modernen Netzwerken ist, ist es unwahrscheinlich, dass es vollständig durch andere Messaging-Protokolle ersetzt wird. Unter den Knoten, die leistungsstarke Geräte zwischen Cloud und Nebel darstellen, ist HTTP REST eine intelligente Lösung.

Andererseits ist die Verwendung von CoAP für Geräte mit begrenzten Computerressourcen, die zwischen Nebel und IoT kommunizieren, effizienter. Einer der großen Vorteile von CoAP ist die Kompatibilität mit HTTP, da beide Protokolle auf REST-Prinzipien basieren.

Abbildung (b) zeigt zwei Interaktionsmodelle zwischen Veröffentlichung und Abonnement in einem Szenario, einschließlich MQTT und AMQP. Obwohl hypothetisch beide Protokolle für die Kommunikation zwischen Knoten auf jeder Abstraktionsebene verwendet werden können, sollte ihre Position basierend auf der Leistung bestimmt werden. MQTT wurde als vereinfachtes Protokoll für Geräte mit begrenzten Rechenressourcen entwickelt, sodass es für die Kommunikation zwischen IoT und Nebel verwendet werden kann. AMQP eignet sich besser für leistungsstärkere Geräte, die es idealerweise zwischen den Knoten Nebel und Wolke positionieren. Anstelle von MQTT kann IoT das XMPP-Protokoll verwenden, da es als leichtgewichtig gilt. In solchen Szenarien ist es jedoch nicht so weit verbreitet.

Schlussfolgerungen

Es ist unwahrscheinlich, dass eines der berücksichtigten Protokolle ausreicht, um die gesamte Kommunikation im System abzudecken, angefangen bei Geräten mit begrenzten Rechenressourcen bis hin zu Cloud-Servern. Die Studie zeigte, dass die beiden vielversprechendsten Optionen, die Entwickler häufiger verwenden, MQTT und RESTful HTTP sind. Diese beiden Protokolle sind nicht nur die ausgereiftesten und stabilsten, sondern umfassen auch viele gut dokumentierte und erfolgreiche Implementierungen und Online-Ressourcen.

Aufgrund seiner Stabilität und einfachen Konfiguration ist MQTT ein Protokoll, das im Laufe der Zeit seine hervorragende Leistung bewiesen hat, wenn es auf IoT-Ebene mit begrenzten Geräten verwendet wird. In Teilen des Systems, in denen eine eingeschränkte Kommunikation und ein begrenzter Batterieverbrauch kein Problem darstellen, z. B. in einigen Bereichen des Nebels und den meisten Cloud-Computing-Anwendungen, ist RESTful HTTP eine einfache Wahl. CoAP sollte ebenfalls berücksichtigt werden, da es sich auch schnell als IoT-Messaging-Standard entwickelt und wahrscheinlich in naher Zukunft ein ähnliches Stabilitäts- und Reifegrad wie MQTT und HTTP erreichen wird. Derzeit wird jedoch der Standard entwickelt, der mit kurzfristigen Kompatibilitätsproblemen verbunden ist.

Was sonst noch nützlich ist, lesen Sie im Cloud4Y- Blog

→ Der Computer macht Sie lecker
→ KI hilft bei der Untersuchung von Tieren in Afrika
→ Der Sommer ist fast vorbei. Es sind fast keine Daten durchgesickert
→ 4 Möglichkeiten zum Speichern von Backups in der Cloud
→ Auf einer einzelnen Bundesinformationsressource, die Bevölkerungsinformationen enthält

Abonnieren Sie unseren Telegrammkanal , um keinen weiteren Artikel zu verpassen! Wir schreiben nicht mehr als zweimal pro Woche und nur geschäftlich.