Die Entwicklung von Technologien im Bereich Software und Hardware sowie die Entstehung neuer Kommunikationsprotokolle haben zur Ausweitung des Internets der Dinge (IoT) geführt. Die Anzahl der Geräte wächst von Tag zu Tag und sie erzeugen riesige Datenmengen. Daher besteht Bedarf an einer komfortablen Systemarchitektur, die diese Daten verarbeiten, speichern und übertragen kann.
Für diese Zwecke werden mittlerweile Cloud-Dienste genutzt. Das immer beliebter werdende Fog-Computing-Paradigma (Fog) kann jedoch Cloud-Lösungen durch Skalierung und Optimierung der IoT-Infrastruktur ergänzen.
Clouds sind in der Lage, die meisten IoT-Anfragen abzudecken. Zum Beispiel für die Überwachung von Diensten, die schnelle Verarbeitung beliebiger von Geräten generierter Datenmengen sowie deren Visualisierung. Fog Computing ist bei der Lösung von Echtzeitproblemen effektiver. Sie bieten eine schnelle Reaktion auf Anfragen und minimale Latenz bei der Datenverarbeitung. Das heißt, Fog ergänzt die „Wolken“ und erweitert ihre Fähigkeiten.
Die Hauptfrage ist jedoch eine andere: Wie soll das alles im Kontext des IoT zusammenwirken? Welche Kommunikationsprotokolle sind am effektivsten, wenn in einem kombinierten IoT-Fog-Cloud-System gearbeitet wird?
Trotz der offensichtlichen Dominanz von HTTP gibt es eine Vielzahl anderer Lösungen, die in IoT-, Fog- und Cloud-Systemen eingesetzt werden. Denn IoT muss die Funktionalität verschiedener Gerätesensoren mit der Sicherheit, Kompatibilität und anderen Anforderungen der Nutzer kombinieren.
Es gibt jedoch einfach keine einheitliche Vorstellung von der Referenzarchitektur und dem Kommunikationsstandard. Daher ist die Erstellung eines neuen Protokolls oder die Änderung 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 herausfinden. Aber lassen Sie uns zunächst die Prinzipien des Ökosystems diskutieren, in dem Wolken, Nebel und das Internet der Dinge interagieren.
IoT Fog-to-Cloud (F2C)-Architektur
Sie haben wahrscheinlich bemerkt, wie viel Mühe darauf verwendet wird, die Vorteile und Vorteile zu erkunden, die mit einem intelligenten und koordinierten Management von IoT, Cloud und Fog verbunden sind. Wenn nicht, dann sind hier drei Standardisierungsinitiativen: , и .
Wurden bisher nur 2 Ebenen betrachtet, Clouds und Endgeräte, dann führt die vorgeschlagene Architektur eine neue Ebene ein – Fog Computing. In diesem Fall kann die Fog-Ebene 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 schnellere Server und Computergeräte, um Probleme zu lösen, die eine geringe Latenz erfordern. Im selben System sind Clouds für die Lösung von Problemen verantwortlich, die große Mengen an Rechenressourcen oder Datenspeicherplatz erfordern.
Auch Smartphones, Smartwatches und andere Gadgets können 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 Fog-Schicht übertragen, was für Flexibilität und Interoperabilität bei der Erstellung von RESTful-Diensten sorgt. Dies ist angesichts der Notwendigkeit wichtig, die Abwärtskompatibilität mit der vorhandenen Computerinfrastruktur sicherzustellen, die auf lokalen Computern, Servern oder einem Servercluster ausgeführt wird. Lokale Ressourcen, sogenannte „Fog Nodes“, filtern die empfangenen Daten und verarbeiten sie lokal oder senden sie zur weiteren Berechnung an die Cloud.
Clouds unterstützen verschiedene Kommunikationsprotokolle, die gebräuchlichsten sind AMQP und REST HTTP. Da HTTP bekannt und auf das Internet zugeschnitten ist, stellt sich möglicherweise die Frage: „Sollten wir es nicht verwenden, um mit IoT und Fog zu arbeiten?“ Dieses Protokoll weist jedoch Leistungsprobleme auf. Mehr dazu später.
Im Allgemeinen gibt es zwei Modelle von Kommunikationsprotokollen, die für das von uns benötigte System geeignet sind. Dies sind Request-Response und Publish-Subscribe. Das erste Modell ist allgemeiner bekannt, insbesondere in der Server-Client-Architektur. Der Client fordert Informationen vom Server an, und der Server empfängt die Anfrage, verarbeitet sie und gibt eine Antwortnachricht zurück. Die Protokolle REST HTTP und CoAP arbeiten nach diesem Modell.
Das zweite Modell entstand aus der Notwendigkeit, eine asynchrone, verteilte, lose Kopplung zwischen den Quellen, die Daten erzeugen, und den Empfängern dieser Daten bereitzustellen.
Das Modell geht von drei Teilnehmern aus: einem Herausgeber (Datenquelle), einem Broker (Dispatcher) und einem Abonnenten (Empfänger). Hierbei muss der als Subscriber agierende Client keine Informationen vom Server anfordern. Anstatt Anfragen zu senden, abonniert es bestimmte Ereignisse im System über einen Broker, der dafür verantwortlich ist, alle eingehenden Nachrichten zu filtern und sie zwischen Herausgebern und Abonnenten weiterzuleiten. Und wenn ein Ereignis zu einem bestimmten Thema auftritt, veröffentlicht der Herausgeber es an den Broker, der Daten zum angeforderten Thema an den Abonnenten sendet.
Im Wesentlichen ist diese Architektur ereignisbasiert. Und dieses Interaktionsmodell ist für Anwendungen in IoT, Cloud und Fog interessant, da es Skalierbarkeit bietet und die Verbindung zwischen verschiedenen Geräten vereinfacht sowie dynamische Viele-zu-Viele-Kommunikation und asynchrone Kommunikation unterstützt. Zu den bekanntesten standardisierten Messaging-Protokollen, die ein Publish-Subscribe-Modell verwenden, gehören MQTT, AMQP und DDS.
Offensichtlich hat das Publish-Subscribe-Modell viele Vorteile:
- Herausgeber und Abonnenten müssen nicht voneinander wissen;
- Ein Abonnent kann Informationen aus vielen verschiedenen Publikationen erhalten und ein Herausgeber kann Daten an viele verschiedene Abonnenten senden (Many-to-Many-Prinzip);
- Der Herausgeber und der Abonnent müssen für die Kommunikation nicht gleichzeitig aktiv sein, da der Broker (der als Warteschlangensystem fungiert) in der Lage ist, die Nachricht für Clients zu speichern, die derzeit nicht mit dem Netzwerk verbunden sind.
Allerdings hat das Request-Response-Modell auch seine Stärken. In Fällen, in denen die Fähigkeit der Serverseite, mehrere Client-Anfragen zu verarbeiten, kein Problem darstellt, ist es sinnvoll, 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 Option „Server Push“ unterstützen. Auch die IETF hat ein CoAP veröffentlicht. Um das Messaging-Problem zu lösen, wurden mehrere andere Lösungen entwickelt, beispielsweise das WebSockets-Protokoll oder die Verwendung des HTTP-Protokolls über QUIC (Quick UDP Internet Connections).
Im Fall von WebSockets wird es zwar dazu verwendet, Daten in Echtzeit von einem Server an einen Web-Client zu übertragen und dauerhafte Verbindungen bei gleichzeitiger bidirektionaler Kommunikation bereitzustellen, es ist jedoch nicht für Geräte mit begrenzten Rechenressourcen gedacht. Auch QUIC verdient Aufmerksamkeit, da das neue Transportprotokoll viele neue Möglichkeiten bietet. Da QUIC jedoch noch nicht standardisiert ist, ist es verfrüht, seine mögliche Anwendung und Auswirkungen auf IoT-Lösungen vorherzusagen. Daher behalten wir WebSockets und QUIC mit Blick auf die Zukunft im Auge, werden sie aber vorerst nicht näher untersuchen.
Wer ist der süßeste der Welt: Protokolle vergleichen
Lassen Sie uns nun über die Stärken und Schwächen von Protokollen sprechen. Mit Blick auf die Zukunft müssen wir gleich einen Vorbehalt anbringen: Es gibt keinen eindeutigen Anführer. Jedes Protokoll hat einige Vor- und Nachteile.
Antwortzeit
Eine der wichtigsten Eigenschaften von Kommunikationsprotokollen, insbesondere im Zusammenhang mit dem Internet der Dinge, ist die Reaktionszeit. Aber unter den bestehenden Protokollen gibt es keinen klaren Gewinner, der die minimale Latenz beim Arbeiten unter verschiedenen Bedingungen aufweist. Es gibt jedoch eine ganze Reihe von Untersuchungen und Vergleichen der Protokollfähigkeiten.
Zum Beispiel kann die Vergleiche der Wirksamkeit von HTTP und MQTT bei der Arbeit mit IoT zeigten, dass die Antwortzeit für Anfragen bei MQTT kürzer ist als bei HTTP. Und wann Die Roundtrip-Zeit (RTT) von MQTT und CoAP ergab, dass die durchschnittliche RTT von CoAP 20 % geringer ist als die von MQTT.
Andere mit RTT für die Protokolle MQTT und CoAP wurde in zwei Szenarien durchgeführt: lokales Netzwerk und IoT-Netzwerk. Es stellte sich heraus, dass die durchschnittliche RTT in einem IoT-Netzwerk zwei- bis dreimal höher ist. MQTT mit QoS2 zeigte im Vergleich zu CoAP ein geringeres Ergebnis, und MQTT mit QoS3 zeigte aufgrund von ACKs auf der Anwendungs- und Transportebene eine höhere RTT. Für verschiedene QoS-Stufen betrug die Netzwerklatenz ohne Überlastung Millisekunden für MQTT und Hunderte von Mikrosekunden für CoAP. Es ist jedoch zu beachten, dass MQTT, das auf TCP ausgeführt wird, bei der Arbeit in weniger zuverlässigen Netzwerken ein völlig anderes Ergebnis liefert.
Die Reaktionszeit für die AMQP- und MQTT-Protokolle durch Erhöhung der Nutzlast zeigte, dass die Latenz bei geringer Last nahezu gleich ist. Bei der Übertragung großer Datenmengen weist MQTT jedoch kürzere Antwortzeiten auf. in einem weiteren CoAP wurde mit HTTP in einem Maschine-zu-Maschine-Kommunikationsszenario verglichen, bei dem Geräte auf dem Dach von Fahrzeugen eingesetzt wurden, die mit Gassensoren, Wettersensoren, Standortsensoren (GPS) und einer Mobilfunknetzschnittstelle (GPRS) ausgestattet waren. Der Zeitaufwand für die Übertragung einer CoAP-Nachricht über das Mobilfunknetz war fast dreimal kürzer als der Zeitaufwand für die Verwendung von HTTP-Nachrichten.
Es wurden Studien durchgeführt, in denen nicht zwei, sondern drei Protokolle verglichen wurden. Zum Beispiel, Leistung der IoT-Protokolle MQTT, DDS und CoAP in einem medizinischen Anwendungsszenario mithilfe eines Netzwerkemulators. DDS übertraf MQTT hinsichtlich der getesteten Telemetrielatenz unter verschiedenen schlechten Netzwerkbedingungen. UDP-basiertes CoAP funktionierte gut für Anwendungen, die schnelle Antwortzeiten erforderten. Da es jedoch UDP-basiert war, kam es zu erheblichen unvorhersehbaren Paketverlusten.
Durchsatz
MQTT und CoAP im Hinblick auf die Bandbreiteneffizienz wurden als Berechnung der gesamten pro Nachricht übertragenen Datenmenge durchgeführt. CoAP hat bei der Übertragung kleiner Nachrichten einen geringeren Durchsatz als MQTT gezeigt. Beim Vergleich der Effizienz von Protokollen im Hinblick auf das Verhältnis der Anzahl nützlicher Informationsbytes zur Gesamtzahl der übertragenen Bytes erwies sich CoAP jedoch als effektiver.
bei Unter Verwendung von MQTT, DDS (mit TCP als Transportprotokoll) und CoAP-Bandbreite wurde festgestellt, dass CoAP im Allgemeinen einen vergleichsweise geringeren Bandbreitenverbrauch aufwies, der im Gegensatz zu MQTT und DDS nicht mit zunehmendem Netzwerkpaketverlust oder erhöhter Netzwerklatenz zunahm eine Erhöhung der Bandbreitenauslastung in den genannten Szenarien. In einem anderen Szenario übertragen viele Geräte gleichzeitig Daten, was typisch für IoT-Umgebungen ist. Die Ergebnisse zeigten, dass es für eine höhere Auslastung besser ist, CoAP zu verwenden.
Bei geringer Last verbrauchte CoAP die geringste Bandbreite, gefolgt von MQTT und REST HTTP. Als jedoch die Größe der Nutzlasten zunahm, erzielte REST HTTP die besten Ergebnisse.
Stromverbrauch
Das Thema Energieverbrauch ist immer von großer Bedeutung, insbesondere in einem IoT-System. Wenn Während MQTT und HTTP Strom verbrauchen, verbraucht HTTP viel mehr. Und CoAP ist mehr im Vergleich zu MQTT, was eine Energieverwaltung ermöglicht. In einfachen Szenarien eignet sich MQTT jedoch besser für den Informationsaustausch in Internet-of-Things-Netzwerken, insbesondere wenn keine Leistungsbeschränkungen bestehen.
Ein Experiment, bei dem die Fähigkeiten von AMQP und MQTT auf einem Teststand für mobile oder instabile drahtlose Netzwerke verglichen wurden, ergab, dass AMQP mehr Sicherheitsfunktionen bietet, während MQTT energieeffizienter ist.
Sicherheit
Sicherheit ist ein weiteres kritisches Thema, das bei der Untersuchung des Themas Internet der Dinge und Fog/Cloud Computing angesprochen wird. Der Sicherheitsmechanismus basiert typischerweise auf TLS in HTTP, MQTT, AMQP und XMPP oder DTLS in CoAP und unterstützt beide DDS-Varianten.
TLS und DTLS beginnen mit dem Prozess des Aufbaus der Kommunikation zwischen der Client- und der Serverseite, um unterstützte Verschlüsselungssammlungen und Schlüssel auszutauschen. Beide Parteien verhandeln Sätze, um sicherzustellen, dass die weitere Kommunikation auf einem sicheren Kanal erfolgt. Der Unterschied zwischen den beiden liegt in kleinen Modifikationen, die es UDP-basiertem DTLS ermöglichen, über eine unzuverlässige Verbindung zu funktionieren.
bei Mehrere unterschiedliche Implementierungen von TLS und DTLS ergaben, dass TLS bessere Arbeit leistete. Angriffe auf DTLS waren aufgrund seiner Fehlertoleranz erfolgreicher.
Das größte Problem bei diesen Protokollen besteht jedoch darin, dass sie ursprünglich nicht für den Einsatz im IoT konzipiert wurden und nicht dafür gedacht waren, im Nebel oder in der Cloud zu funktionieren. Durch Handshaking fügen sie bei jedem Verbindungsaufbau zusätzlichen Datenverkehr hinzu, was Rechenressourcen beansprucht. Im Durchschnitt steigt der Overhead bei TLS um 6,5 % und bei DTLS um 11 % im Vergleich zur Kommunikation ohne Sicherheitsschicht. In ressourcenreichen Umgebungen, die sich typischerweise auf befinden Ebene wird dies kein Problem darstellen, aber im Zusammenhang zwischen IoT und Nebelebene wird dies zu einer wichtigen Einschränkung.
Was auszusuchen? Es gibt keine klare Antwort. MQTT und HTTP scheinen die vielversprechendsten Protokolle zu sein, da sie im Vergleich zu anderen Protokollen als vergleichsweise ausgereiftere und stabilere IoT-Lösungen gelten.
Lösungen basierend auf einem einheitlichen Kommunikationsprotokoll
Die Praxis einer Ein-Protokoll-Lösung hat viele Nachteile. Beispielsweise funktioniert ein Protokoll, das für eine eingeschränkte Umgebung geeignet ist, möglicherweise nicht in einer Domäne mit strengen Sicherheitsanforderungen. Vor diesem Hintergrund müssen wir fast alle möglichen Einzelprotokolllösungen im Fog-to-Cloud-Ökosystem im IoT außer MQTT und REST HTTP verwerfen.
REST HTTP als Einzelprotokolllösung
Es gibt ein gutes Beispiel dafür, wie REST-HTTP-Anfragen und -Antworten im IoT-to-Fog-Bereich interagieren: . Die Tiere sind mit tragbaren Sensoren ausgestattet (IoT-Client, C) und werden über Cloud Computing von einem Smart-Farming-System (Fog-Server, S) gesteuert.
Der Header der POST-Methode gibt die zu ändernde Ressource (/farm/animals) sowie die HTTP-Version und den Inhaltstyp an, in diesem Fall ein JSON-Objekt, das die Tierfarm darstellt, die das System verwalten soll (Dulcinea/cow). . Die Antwort vom Server zeigt an, dass die Anfrage erfolgreich war, indem der HTTPS-Statuscode 201 (Ressource erstellt) gesendet wird. Die GET-Methode darf nur die angeforderte Ressource im URI angeben (z. B. /farm/animals/1), wodurch eine JSON-Darstellung des Tieres mit dieser ID vom Server zurückgegeben wird.
Die PUT-Methode wird verwendet, wenn ein bestimmter Ressourceneintrag aktualisiert werden muss. In diesem Fall gibt die Ressource den URI für den zu ändernden Parameter und den aktuellen Wert an (zeigt beispielsweise an, dass die Kuh gerade läuft, /farm/animals/1? state=walking). Schließlich wird die DELETE-Methode genauso verwendet wie die GET-Methode, löscht jedoch lediglich die Ressource als Ergebnis der Operation.
MQTT als Einzelprotokolllösung
Nehmen wir dieselbe Smart Farm, verwenden jedoch anstelle von REST HTTP das MQTT-Protokoll. Als Broker fungiert ein lokaler Server mit installierter Mosquitto-Bibliothek. In diesem Beispiel dient ein einfacher Computer (als Farmserver bezeichnet), Raspberry Pi, als MQTT-Client, implementiert durch eine Installation der Paho MQTT-Bibliothek, die vollständig mit dem Mosquitto-Broker kompatibel ist.
Dieser Client entspricht einer IoT-Abstraktionsschicht, die ein Gerät mit Erfassungs- und Rechenfunktionen darstellt. Der Mediator hingegen entspricht einer höheren Abstraktionsebene und stellt einen Fog-Computing-Knoten dar, der sich durch eine größere Verarbeitungs- und Speicherkapazität auszeichnet.
Im vorgeschlagenen Smart-Farm-Szenario stellt der Raspberry Pi eine Verbindung zum Beschleunigungsmesser, GPS und Temperatursensoren her und veröffentlicht Daten von diesen Sensoren an einen Nebelknoten. Wie Sie wahrscheinlich wissen, behandelt MQTT Themen als Hierarchie. Ein einzelner MQTT-Herausgeber kann Nachrichten zu einer bestimmten Themengruppe veröffentlichen. In unserem Fall sind es drei davon. Für einen Sensor, der die Temperatur in einem Tierstall misst, wählt der Kunde ein Thema (Tierhof/Stall/Temperatur). Für Sensoren, die den GPS-Standort und die Tierbewegung über den Beschleunigungsmesser messen, veröffentlicht der Kunde Aktualisierungen zu (Tierfarm/Tier/GPS) und (Tierfarm/Tier/Bewegung).
Diese Informationen werden an den Broker weitergeleitet, der sie vorübergehend in einer lokalen Datenbank speichern kann, für den Fall, dass später ein weiterer interessierter Abonnent hinzukommt.
Neben dem lokalen Server, der im Nebel als MQTT-Broker fungiert und an den Raspberry Pis als MQTT-Clients Sensordaten senden, kann es auf Cloud-Ebene einen weiteren MQTT-Broker geben. In diesem Fall können die an den lokalen Broker übermittelten Informationen vorübergehend in einer lokalen Datenbank gespeichert und/oder an die Cloud gesendet werden. Der Fog-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.
Wenn die Verbindung zu einem der Broker (z. B. Cloud) ausfällt, erhält der Endbenutzer Informationen vom anderen (Fog). Dies ist ein charakteristisches Merkmal kombinierter Fog- und Cloud-Computing-Systeme. Standardmäßig kann die mobile App so konfiguriert werden, dass sie zuerst eine Verbindung zum Fog-MQTT-Broker herstellt und, falls dies fehlschlägt, eine Verbindung zum Cloud-MQTT-Broker herstellt. Diese Lösung ist nur eine von vielen in IoT-F2C-Systemen.
Multiprotokolllösungen
Einzelprotokolllösungen erfreuen sich aufgrund ihrer einfacheren Implementierung großer Beliebtheit. Es ist aber klar, dass es in IoT-F2C-Systemen sinnvoll ist, verschiedene Protokolle zu kombinieren. Die Idee ist, dass verschiedene Protokolle auf unterschiedlichen Ebenen arbeiten können. Nehmen wir zum Beispiel drei Abstraktionen: die Schichten des IoT, Fog und Cloud Computing. Geräte auf IoT-Ebene gelten im Allgemeinen als begrenzt. Betrachten wir für diesen Überblick die IoT-Stufen als die am stärksten eingeschränkten, die Cloud als die am wenigsten eingeschränkten und Fog Computing als „irgendwo in der Mitte“. Es stellt sich heraus, dass neben IoT und Fog-Abstraktionen zu den aktuellen Protokolllösungen auch MQTT, CoAP und XMPP gehören. Zwischen Fog und Cloud hingegen ist AMQP neben REST HTTP eines der Hauptprotokolle, das aufgrund seiner Flexibilität auch zwischen IoT und Fog Layer zum Einsatz kommt.
Das Hauptproblem hierbei ist die Interoperabilität der Protokolle und die einfache Übertragung von Nachrichten von einem Protokoll auf ein anderes. Im Idealfall ist die Architektur eines Internet-of-Things-Systems mit Cloud- und Fog-Ressourcen künftig unabhängig vom verwendeten Kommunikationsprotokoll und gewährleistet eine gute Interoperabilität zwischen verschiedenen Protokollen.
Da dies derzeit nicht der Fall ist, ist es sinnvoll, Protokolle zu kombinieren, die keine wesentlichen Unterschiede aufweisen. Zu diesem Zweck basiert eine mögliche Lösung auf einer Kombination zweier Protokolle, die demselben Architekturstil folgen: REST HTTP und CoAP. Ein weiterer Lösungsvorschlag basiert auf einer Kombination zweier Protokolle, die Publish-Subscribe-Kommunikation ermöglichen: MQTT und AMQP. Durch die Verwendung ähnlicher Konzepte (sowohl MQTT als auch AMQP verwenden Broker, CoAP und HTTP verwenden REST) sind diese Kombinationen einfacher zu implementieren und erfordern weniger Integrationsaufwand.
Abbildung (a) zeigt zwei auf Anfrage und Antwort basierende Modelle, HTTP und CoAP, und ihre mögliche Platzierung in einer IoT-F2C-Lösung. Da HTTP eines der bekanntesten und am weitesten verbreiteten 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 darstellen, die zwischen der Cloud und dem Nebel sitzen, ist REST HTTP eine intelligente Lösung.
Andererseits ist es für Geräte mit begrenzten Rechenressourcen, die zwischen der Fog- und IoT-Schicht kommunizieren, effizienter, CoAP zu verwenden. Einer der großen Vorteile von CoAP ist tatsächlich seine Kompatibilität mit HTTP, da beide Protokolle auf REST-Prinzipien basieren.
Abbildung (b) zeigt zwei Publish-Subscribe-Kommunikationsmodelle im selben Szenario, einschließlich MQTT und AMQP. Obwohl beide Protokolle hypothetisch für die Kommunikation zwischen Knoten auf jeder Abstraktionsschicht verwendet werden könnten, sollte ihre Position auf der Grundlage der Leistung bestimmt werden. MQTT wurde als leichtes Protokoll für Geräte mit begrenzten Rechenressourcen entwickelt und kann daher für die IoT-Fog-Kommunikation verwendet werden. AMQP eignet sich eher für leistungsstärkere Geräte, die es idealerweise zwischen Nebel- und Wolkenknoten positionieren würden. Anstelle von MQTT kann im IoT das XMPP-Protokoll verwendet werden, da es als leichtgewichtig gilt. In solchen Szenarien wird es jedoch nicht so häufig verwendet.
Befund
Es ist unwahrscheinlich, dass eines der besprochenen Protokolle ausreicht, um die gesamte Kommunikation in einem System abzudecken, von Geräten mit eingeschränkter Rechenleistung bis hin zu Cloud-Servern. Die Studie ergab, dass die beiden vielversprechendsten Optionen, die Entwickler am häufigsten nutzen, 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 seine überlegene Leistung im Laufe der Zeit bei der Verwendung auf IoT-Ebene mit begrenzten Geräten unter Beweis gestellt hat. In Teilen des Systems, in denen eingeschränkte Kommunikation und Batterieverbrauch kein Problem darstellen, wie etwa einige Fog-Domänen und die meisten Cloud-Computing-Umgebungen, ist RESTful HTTP eine einfache Wahl. CoAP sollte ebenfalls berücksichtigt werden, da es sich auch als IoT-Messaging-Standard rasant weiterentwickelt und wahrscheinlich in naher Zukunft einen ähnlichen Stabilitäts- und Reifegrad wie MQTT und HTTP erreichen wird. Allerdings entwickelt sich der Standard derzeit weiter, was kurzfristig zu Kompatibilitätsproblemen führt.
Was können Sie sonst noch auf dem Blog lesen?
→
→
→
→
→
Abonnieren Sie unseren -Kanal, um den nächsten Artikel nicht zu verpassen! Wir schreiben höchstens zweimal pro Woche und nur geschäftlich.
Source: habr.com