Die Entwicklung von Software- und Hardware-Technologien sowie das Auftauchen neuer Kommunikationsprotokolle haben zu einer Expansion des Internets der Dinge (IoT) geführt. Die Anzahl der Geräte wächst täglich und sie erzeugen enorme Datenmengen. Daher ist ein benutzerfreundliches Systemarchitektur erforderlich, das diese Daten verarbeiten, speichern und übertragen kann.
Derzeit werden dafür Cloud-Dienste genutzt. Doch das immer beliebter werdende Paradigma des Fog Computing kann Cloud-Lösungen ergänzen, indem es die IoT-Infrastruktur skaliert und optimiert.
Clouds können die meisten Anforderungen des IoT abdecken. Zum Beispiel bieten sie Monitoring-Dienste, eine schnelle Verarbeitung beliebiger Datenmengen, die von Geräten erzeugt werden, sowie deren Visualisierung. Fog Computing hingegen ist effektiver bei der Lösung von Echtzeitanforderungen. Es sorgt für schnelle Reaktionszeiten auf Anfragen und minimale Verzögerungen bei der Datenverarbeitung. Das heißt, Fog ergänzt die Clouds und erweitert deren Möglichkeiten.
Die entscheidende Frage ist jedoch eine andere: Wie soll all dies im Kontext des IoT interagieren? Welche Kommunikationsprotokolle sind am effektivsten für eine integrierte IoT-Fog-Cloud-Systemarchitektur?
Trotz der scheinbaren Dominanz von HTTP gibt es in IoT-, Fog- und Cloud-Systemen eine Vielzahl anderer Lösungen. Dies liegt daran, dass IoT die Funktionalitäten unterschiedlicher Gerätesensoren mit Sicherheit, Kompatibilität und weiteren Anforderungen der Nutzer kombinieren muss.
Es existiert jedoch kein einheitliches Verständnis über eine Referenzarchitektur und Kommunikationsstandards. Daher ist die Entwicklung eines neuen Protokolls oder die Anpassung bestehender Protokolle an spezifische IoT-Anforderungen eine der dringendsten Herausforderungen für die IT-Community.
Welche Protokolle werden derzeit verwendet, und was können sie bieten? Lassen Sie uns das genauer betrachten. Doch zuerst wollen wir die Prinzipien des Ökosystems diskutieren, in dem Clouds, Fog und das Internet der Dinge zusammenarbeiten.
Die IoT Fog-to-Cloud (F2C) Architektur
Sie haben sicher schon festgestellt, wie viel Aufwand in die Erforschung der Vorteile und Nutzen fließt, die mit einem rationalen und koordinierten Management von IoT, Cloud und Fog verbunden sind. Falls nicht, hier sind gleich drei Standardisierungsinitiativen: , und .
Während früher nur zwei Ebenen betrachtet wurden, nämlich Clouds und Endgeräte, führt die vorgeschlagene Architektur eine neue Ebene ein – das Fog Computing. Diese Fog-Ebene kann in mehrere Unterebenen unterteilt werden, abhängig von den spezifischen Ressourcen oder einer Reihe von Richtlinien, die die Nutzung verschiedener Geräte in diesen Unterebenen definieren.
Wie könnte diese Abstraktion aussehen? Hier ist ein typisches IoT-Fog-Cloud-Ökosystem. IoT-Geräte senden Daten an leistungsfähigere Server und Recheneinheiten, um Aufgaben zu lösen, die eine niedrige Latenz erfordern. In diesem System sind die Clouds dafür verantwortlich, Aufgaben zu bearbeiten, die einen hohen Bedarf an Rechenressourcen oder Speicherplatz erfordern.
Smartphones, Smartwatches und andere Gadgets können ebenfalls Teil des IoT sein. Allerdings verwenden solche Geräte in der Regel proprietäre Kommunikationsprotokolle von großen Entwicklern. Die generierten IoT-Daten werden über das REST HTTP-Protokoll auf die Fog-Ebene übertragen, welches Flexibilität und funktionale Kompatibilität bei der Erstellung von RESTful-Diensten bietet. Dies ist wichtig, um die Rückwärtskompatibilität mit der bestehenden Recheninfrastruktur, die auf lokalen Computern, Servern oder Server-Clustern läuft, sicherzustellen. Lokale Ressourcen, die als „Fog-Knoten“ bezeichnet werden, filtern die empfangenen Daten und verarbeiten sie lokal oder leiten sie zur weiteren Berechnung in die Cloud weiter.
Clouds unterstützen verschiedene Kommunikationsprotokolle, darunter häufig AMQP und REST HTTP. Da HTTP allgemein bekannt und für das Internet optimiert ist, könnte die Frage aufkommen: „Sollten wir es nicht für die Arbeit mit IoT und Fog verwenden?“. Allerdings hat dieses Protokoll Leistungsprobleme. Darüber mehr später.
Insgesamt gibt es zwei Modelle von Kommunikationsprotokollen, die für unser System geeignet sind: das Anforderungs-Antwort-Modell und das Publish-Subscribe-Modell. Das erste Modell ist insbesondere in der Client-Server-Architektur weit verbreitet. Der Client fordert Informationen vom Server an, der den Antrag erhält, verarbeitet und eine Antwort zurücksendet. Protokolle wie REST HTTP und CoAP arbeiten nach diesem Modell.
Das zweite Modell entstand aus der Notwendigkeit, eine asynchrone, verteilte und schwache Verbindung zwischen Datenquellen, die Informationen generieren, und den Empfängern dieser Daten zu gewährleisten.
Das Modell berücksichtigt drei Akteure: den Publisher (Datenquelle), den Broker (Dispatcher) und den Subscriber (Empfänger). Hier muss der Client, der als Subscriber agiert, keine Informationen vom Server anfordern. Stattdessen abonniert er bestimmte Ereignisse im System über den Broker, der für die Filterung aller eingehenden Nachrichten und deren Weiterleitung zwischen Publishern und Subscribern verantwortlich ist. Wenn ein Ereignis zu einem bestimmten Thema auftritt, veröffentlicht der Publisher es beim Broker, der die angeforderten Daten an den Subscriber sendet.
Im Wesentlichen basiert diese Architektur auf einem Ereignismodell. Dieses Interaktionsmodell ist besonders interessant für Anwendungen im IoT, in der Cloud und im Edge Computing, da es Skalierbarkeit ermöglicht und die Verbindung zwischen verschiedenen Geräten vereinfacht, eine dynamische "Viele-zu-Viele"-Kommunikation sowie asynchrone Interaktionen unterstützt. Zu den bekanntesten standardisierten Messaging-Protokollen, die das "Publish-Subscribe"-Modell verwenden, zählen MQTT, AMQP und DDS.
Offensichtlich bietet das "Publish-Subscribe"-Modell zahlreiche Vorteile:
- Verleger und Abonnenten müssen sich nicht gegenseitig kennen;
- Ein Abonnent kann Informationen von vielen verschiedenen Verlegern erhalten, während ein Verleger Daten an zahlreiche Abonnenten senden kann (Prinzip "Viele-zu-Viele");
- Verleger und Abonnent müssen nicht gleichzeitig aktiv sein, um Daten auszutauschen, da der Broker (der als Warteschlangensystem fungiert) in der Lage ist, Nachrichten für Clients zu speichern, die derzeit nicht online sind.
Die Anfragemodell 'Request-Response' hat ebenfalls ihre Vorteile. In Fällen, in denen die Serverkapazitäten zur Bearbeitung von Anfragen mehrerer Kunden kein Problem darstellen, ist es sinnvoll, sich auf bewährte und zuverlässige Lösungen zu stützen.
Es gibt auch Protokolle, die beide Modelle unterstützen. Beispielsweise unterstützen XMPP und HTTP 2.0 die Option 'Server Push'. Die IETF hat auch CoAP veröffentlicht. Um das Problem des Nachrichtenaustauschs zu lösen, wurden mehrere andere Lösungen entwickelt, wie das WebSockets-Protokoll und die Nutzung von HTTP über QUIC (Quick UDP Internet Connections).
Im Fall von WebSockets, die für die Übertragung von Echtzeitdaten vom Server zum Web-Client verwendet werden und eine ständige Verbindung mit gleichzeitiger bidirektionaler Kommunikation ermöglichen, sind sie jedoch nicht für Geräte mit begrenzten Rechenressourcen geeignet. QUIC verdient ebenfalls Aufmerksamkeit, da dieses neue Transportprotokoll eine Vielzahl neuer Möglichkeiten eröffnet. Da QUIC jedoch noch nicht standardisiert ist, ist es verfrüht, seine potenziellen Anwendungen und Auswirkungen auf IoT-Lösungen vorherzusagen. Somit behalten wir WebSockets und QUIC im Hinterkopf für die Zukunft, möchten aber vorerst nicht näher darauf eingehen.
Wer ist der Liebste auf der Welt: Wir vergleichen Protokolle
Nun sprechen wir über die Stärken und Schwächen der Protokolle. Um es vorwegzunehmen, es gibt keinen klaren Gewinner. Jeder Protokoll hat seine Vorzüge und Nachteile.
Antwortzeit
Eine der wichtigsten Eigenschaften von Kommunikationsprotokollen, insbesondere im Hinblick auf das Internet der Dinge, ist die Reaktionszeit. Unter den existierenden Protokollen gibt es jedoch keinen eindeutigen Sieger, der in verschiedenen Bedingungen die geringste Verzögerung aufweist. Es gibt jedoch viele Studien und Vergleiche der Möglichkeiten der Protokolle.
Zum Beispiel Vergleiche der Effizienz von HTTP und MQTT im Zusammenhang mit IoT haben gezeigt, dass die Reaktionszeit für Anfragen bei MQTT geringer ist als bei HTTP. Bei der RTT (Round Trip Time) von MQTT und CoAP stellte sich heraus, dass der durchschnittliche RTT von CoAP um 20 % geringer ist als der von MQTT.
Ein weiteres zum RTT der Protokolle MQTT und CoAP wurde in zwei Szenarien durchgeführt: im lokalen Netzwerk und im IoT-Netzwerk. Es stellte sich heraus, dass der durchschnittliche RTT im IoT-Netzwerk 2-3 Mal höher ist. MQTT mit QoS0 zeigte im Vergleich zu CoAP niedrigere Ergebnisse, während MQTT mit QoS1 einen höheren RTT aufgrund von ACK auf der Anwendungsebene und der Transportschicht aufwies. Für verschiedene QoS-Stufen lagen die Verzögerungen im nicht überlasteten Netzwerk bei MQTT im Millisekundenbereich und bei CoAP im Bereich von Hunderten von Mikrosekunden. Es ist jedoch zu beachten, dass MQTT, das auf TCP basiert, in weniger zuverlässigen Netzwerken ganz andere Ergebnisse zeigen kann.
Die Reaktionszeiten der Protokolle AMQP und MQTT in Bezug auf die erhöhte Last zeigen, dass bei geringer Belastung die Latenz nahezu gleich bleibt. Doch bei der Übertragung großer Datenmengen weist MQTT eine geringere Reaktionszeit auf. In einer weiteren wurden CoAP und HTTP in einem Szenario der Maschinenkommunikation mit Geräten verglichen, die auf Fahrzeugen bereitgestellt sind und mit Gas-, Wetter- und GPS-Sensoren sowie einem mobilen Netzwerkinterface (GPRS) ausgestattet sind. Die für die Übertragung einer CoAP-Nachricht über das mobile Netzwerk benötigte Zeit war fast dreimal kürzer als die für HTTP-Nachrichten.
Es wurden auch Studien durchgeführt, in denen nicht zwei, sondern drei Protokolle verglichen wurden. Beispielsweise wurde die Leistung der IoT-Protokolle MQTT, DDS und CoAP in einem medizinischen Anwendungsszenario unter Verwendung eines Netzwerksimulators untersucht. DDS übertraf MQTT hinsichtlich der gemessenen Telemetrieverzögerung unter verschiedenen schlechten Netzwerkbedingungen. CoAP, das auf UDP basiert, funktionierte gut für Anwendungen, die eine schnelle Reaktionszeit benötigten; jedoch kam es aufgrund der UDP-Basis zu erheblichen, unvorhersehbaren Paketverlusten.
Durchsatz
Die Effizienz von MQTT und CoAP hinsichtlich der Bandbreitennutzung wurde durch die Berechnung der insgesamt übertragenden Daten pro Nachricht bewertet. CoAP zeigte eine geringere Bandbreite als MQTT beim Senden kleiner Nachrichten. Im Vergleich der Protokolle hinsichtlich des Verhältnisses von nützlichen Informationsbytes zu insgesamt übertragenen Bytes erwies sich CoAP jedoch als effizienter.
Mit Bei der Analyse der Bandbreitennutzung von MQTT, DDS (mit TCP als Transportprotokoll) und CoAP stellte sich heraus, dass CoAP in der Regel ein vergleichsweise niedrigeres Bandbreitenverbrauch aufwies, das sich nicht erhöht hat, wenn die Netzwerklatenz oder Paketverluste zunahmen. Im Gegensatz dazu zeigten MQTT und DDS in diesen Szenarien einen Anstieg der Bandbreitennutzung. In einem anderen Szenario waren viele Geräte gleichzeitig mit der Datenübertragung beschäftigt, was in IoT-Umgebungen typisch ist. Die Ergebnisse zeigten, dass CoAP bei höherer Auslastung vorteilhafter ist.
Bei geringer Last zeigte CoAP die niedrigste Bandbreitennutzung, gefolgt von MQTT und REST HTTP. Mit zunehmender Payload-Größe erzielte jedoch REST HTTP die besten Ergebnisse.
Energieverbrauch
Die Frage des Energieverbrauchs ist immer von großer Bedeutung, insbesondere im IoT-Bereich. Wenn den Stromverbrauch von MQTT und HTTP, dann "verbraucht" HTTP deutlich mehr. CoAP ist dagegen im Vergleich zu MQTT und ermöglicht eine bessere Energieverwaltung. In einfachen Szenarien eignet sich MQTT jedoch besser für den Informationsaustausch in IoT-Netzen, insbesondere wenn keine Leistungsbeschränkungen bestehen.
Ein Experiment, in dem die Fähigkeiten von AMQP und MQTT in einer mobilen oder instabilen drahtlosen Netzwerkumgebung verglichen wurden, zeigte, dass AMQP mehr Sicherheitsfunktionen bietet, während MQTT energieeffizienter ist.
Sicherheit
Die Sicherheit ist eine weitere zentrale Frage, die beim Studium des Internets der Dinge und von Fog-/Cloud-Computing angesprochen wird. Der Sicherheitsmechanismus basiert in der Regel auf TLS in HTTP, MQTT, AMQP und XMPP oder DTLS in CoAP und unterstützt beide Optionen von DDS.
TLS und DTLS beginnen mit einem Verbindungsaufbau zwischen dem Client und dem Server, um unterstützte Cipher-Suites und Schlüssel auszutauschen. Beide Seiten einigen sich auf die Suiten, um sicherzustellen, dass die weitere Kommunikation über einen sicheren Kanal erfolgt. Der Unterschied zwischen ihnen liegt in kleinen Modifikationen, die DTLS auf UDP-Basis ermöglichen, um über unsichere Verbindungen zu arbeiten.
Mit Bei mehreren verschiedenen Implementierungen von TLS und DTLS stellte sich heraus, dass TLS die Aufgabe besser bewältigte. Angriffe auf DTLS waren erfolgreicher, da es fehlertolerant ist.
Dennoch besteht das größte Problem dieser Protokolle darin, dass sie ursprünglich nicht für den Einsatz im IoT konzipiert wurden und nicht für den Betrieb in der Edge oder Cloud gedacht sind. Durch den Handshake-Mechanismus fügen sie bei jedem Verbindungsaufbau zusätzlichen Traffic hinzu, was die Rechenressourcen belastet. Im Durchschnitt gibt es eine Erhöhung von 6,5 % für TLS und 11 % für DTLS in der Overheadlast im Vergleich zur Kommunikation ohne Sicherheitsstufe. In ressourcenreichen Umgebungen, die normalerweise in Auf diesem Niveau wird es kein Problem sein, aber in Bezug auf IoT und den Nebelgrad wird dies zu einer wichtigen Einschränkung.
Was sollte man wählen? Eine eindeutige Antwort gibt es nicht. MQTT und HTTP erscheinen als die vielversprechendsten Protokolle, da sie als relativ ausgereifte und stabilere Lösungen für IoT im Vergleich zu anderen Protokollen gelten.
Lösungen, die auf einem einheitlichen Kommunikationsprotokoll basieren
Die Praxis eines protokollbasierten Lösungsansatzes hat viele Nachteile. Zum Beispiel könnte ein Protokoll, das in einer eingeschränkten Umgebung funktioniert, nicht in einem Bereich mit strengen Sicherheitsanforderungen bestehen. Vor diesem Hintergrund bleibt uns nichts anderes übrig, als praktisch alle möglichen Lösungen, die auf einem einzigen Protokoll in der Fog-to-Cloud-Ökosystem im IoT basieren, abzulehnen, mit Ausnahme von MQTT und REST HTTP.
REST HTTP als ein protokollbasiertes Lösung
Es gibt ein gutes Beispiel für die Interaktion von Anfragen und Antworten über REST HTTP im Bereich IoT-to-Fog: . Tiere werden mit tragbaren Sensoren (IoT-Client, C) ausgestattet und durch Cloud-Computing durch ein intelligentes Landwirtschaftssystem (Fog-Server, S) gesteuert.
Im Titel der POST-Methode wird die zu ändernde Ressource (/farm/animals), die HTTP-Version sowie der Inhaltstyp angegeben, der in diesem Fall ein JSON-Objekt ist, das die Viehfarm repräsentiert, die vom System verwaltet werden soll (Dulcinea/Kuh). Die Antwort des Servers bestätigt, dass die Anfrage erfolgreich war, indem der HTTPS-Statuscode 201 (Ressource erstellt) gesendet wird. Die GET-Methode sollte nur die angeforderte Ressource im URI angeben (z.B. /farm/animals/1), die eine JSON-Darstellung des Tieres mit dieser ID vom Server zurückgibt.
Die PUT-Methode wird verwendet, wenn eine bestimmte Ressource aktualisiert werden soll. In diesem Fall wird im Ressourcen-URI der Parameter angegeben, der geändert werden muss, zusammen mit dem aktuellen Wert (z.B. um anzuzeigen, dass die Kuh gerade weidet, /farm/animals/1?zustand=weiden). Schließlich wird die DELETE-Methode ebenfalls wie die GET-Methode verwendet, entfernt jedoch einfach die Ressource als Ergebnis der Operation.
MQTT als einprotokollierte Lösung
Nehmen wir dasselbe intelligente Farmkonzept, aber statt REST HTTP verwenden wir das MQTT-Protokoll. Ein lokaler Server mit der installierten Mosquitto-Bibliothek fungiert als Broker. In diesem Beispiel dient ein einfacher Computer (bezeichnet als Farm-Server) Raspberry Pi als MQTT-Client, der durch die Installation der vollständig mit dem Mosquitto-Broker kompatiblen MQTT Paho-Bibliothek realisiert wird.
Dieser Client entspricht dem IoT-Abstraktionsniveau, das ein Gerät mit Entdeckungs- und Berechnungsmöglichkeiten darstellt. Der Broker hingegen repräsentiert ein höheres Abstraktionsniveau, das einen Fog-Computing-Knoten darstellt, der durch hohe Leistungsfähigkeiten in Bezug auf Datenverarbeitung und -speicherung gekennzeichnet ist.
Im vorgeschlagenen Szenario der "Smart Farm" verbindet sich der Raspberry Pi mit einem Accelerometer, GPS und Temperatursensoren und veröffentlicht diese Daten in einem Fog-Node. Wie Sie vermutlich wissen, betrachtet MQTT Themen als Hierarchie. Ein MQTT-Publisher kann Nachrichten in einer bestimmten Themenmenge veröffentlichen. In unserem Fall sind das drei. Für den Sensor, der die Temperatur im Tierstall misst, wählt der Client das Thema (animalfarm/shed/temperature). Für die Sensoren, die die GPS-Position und die Bewegung der Tiere über das Accelerometer erfassen, veröffentlicht der Client Updates (animalfarm/animal/GPS) und (animalfarm/animal/movement).
Diese Informationen werden an den Broker übertragen, der sie vorübergehend in einer lokalen Datenbank speichern kann, falls später ein anderer interessierter Abonnent auftaucht.
Neben einem lokalen Server, der als MQTT-Broker im Fog agiert und an den Raspberry Pis, die als MQTT-Clients fungieren, Sensordaten senden, kann auf der Cloud-Ebene ein weiterer MQTT-Broker vorhanden sein. In diesem Fall können die Informationen, die an den lokalen Broker gesendet werden, vorübergehend in einer lokalen Datenbank gespeichert und/oder in die Cloud gesendet werden. Der Fog-MQTT-Broker wird in dieser Situation verwendet, um alle Daten mit dem Cloud-MQTT-Broker zu verknüpfen. Bei dieser Architektur kann der Benutzer der mobilen Anwendung über beide Broker abonniert sein.
Wenn die Verbindung zu einem der Broker (zum Beispiel dem Cloud-Broker) unterbrochen wird, erhält der Endbenutzer Informationen vom anderen (Fog-Broker). Dies ist eine typische Eigenschaft kombinierter Systeme von Fog- und Cloud-Computing. Standardmäßig kann die mobile Anwendung so konfiguriert werden, dass sie zuerst eine Verbindung zum Fog-MQTT-Broker herstellt, und im Falle eines Fehlers zur Verbindung mit dem MQTT-Broker in der Cloud wechselt. Diese Lösung ist nur eine von vielen in IoT-F2C-Systemen.
Multiprotocol-Lösungen
Ein-Protokoll-Lösungen sind aufgrund ihrer einfacheren Implementierung beliebt. Doch es ist klar, dass es in IoT-F2C-Systemen sinnvoll ist, verschiedene Protokolle zu kombinieren. Der Grund liegt darin, dass auf unterschiedlichen Ebenen verschiedene Protokolle arbeiten können. Nehmen wir zum Beispiel drei Abstraktionen: die Ebenen IoT, Fog und Cloud-Computing. Geräte auf der IoT-Ebene werden normalerweise als eingeschränkt betrachtet. Für diesen Überblick betrachten wir die IoT-Ebenen als die am stärksten begrenzten, die Cloud als die am wenigsten begrenzten und das Fog-Computing als etwas dazwischen. Daraus ergibt sich, dass die aktuellen Protokolllösungen zwischen IoT und Fog-Abstraktionen MQTT, CoAP und XMPP umfassen. Zwischen Fog und Cloud hingegen ist AMQP eines der hauptsächlich verwendeten Protokolle, zusammen mit REST HTTP, das aufgrund seiner Flexibilität auch zwischen IoT und Fog-Schichten eingesetzt wird.
Das Hauptproblem besteht hier in der funktionalen Kompatibilität der Protokolle und der einfachen Übertragung von Nachrichten von einem Protokoll zu einem anderen. Idealerweise wird die Architektur des Internets der Dinge in Zukunft unabhängig von dem verwendeten Kommunikationsprotokoll sein und eine gute Interoperabilität zwischen verschiedenen Protokollen gewährleisten.
Da dies derzeit nicht der Fall ist, macht es Sinn, Protokolle zu kombinieren, die keine wesentlichen Unterschiede aufweisen. Ein potenzielles Lösungskonzept basiert auf der Kombination zweier Protokolle, die denselben architektonischen Stil verfolgen: REST HTTP und CoAP. Eine andere vorgeschlagene Lösung beruht auf der Verbindung zweier Protokolle, die eine Interaktion nach dem "Publish-Subscribe"-Modell anbieten: MQTT und AMQP. Die Verwendung ähnlicher Konzepte (sowohl MQTT als auch AMQP nutzen Broker, CoAP und HTTP verwenden REST) erleichtert die Implementierung dieser Kombinationen und erfordert weniger Integrationsaufwand.
Das Bild (a) zeigt zwei Modelle basierend auf Anfragen-Antworten, HTTP und CoAP, sowie ihre mögliche Integration in die 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 Nachrichtenprotokolle ersetzt wird. Unter den Knoten, die leistungsstarke Geräte darstellen, die zwischen Cloud und Fog bestehen, ist REST HTTP eine sinnvolle Lösung.
Auf der anderen Seite ist CoAP für Geräte mit begrenzten Rechenressourcen, die zwischen den Ebenen Fog und IoT kommunizieren, effizienter. Ein großer Vorteil von CoAP ist tatsächlich seine Kompatibilität mit HTTP, da beide Protokolle auf den Prinzipien von REST basieren.
In Abbildung (b) sind zwei Modelle des «Publish-Subscribe»-Interaktionsmusters in einem Szenario dargestellt, die MQTT und AMQP umfassen. Obwohl theoretisch 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 Fog eingesetzt werden kann. AMQP eignet sich besser für leistungsstärkere Geräte, die es ideal zwischen Fog- und Cloud-Knoten positionieren würden. Anstelle von MQTT kann in IoT-Szenarien auch das XMPP-Protokoll verwendet werden, da es als leichtgewichtig gilt. Allerdings wird es in solchen Szenarien nicht so häufig eingesetzt.
Fazit
Es ist unwahrscheinlich, dass eines der betrachteten Protokolle ausreicht, um die gesamte Kommunikation im System abzudecken, von Geräten mit begrenzten Rechenressourcen bis hin zu Cloud-Servern. Die Untersuchung hat gezeigt, dass die beiden vielversprechendsten Optionen, die von Entwicklern häufig verwendet werden, MQTT und RESTful HTTP sind. Diese beiden Protokolle sind nicht nur die ausgereiftesten und stabilsten, sondern verfügen auch über zahlreiche gut dokumentierte und erfolgreiche Implementierungen sowie Online-Ressourcen.
Dank seiner Stabilität und einfachen Konfiguration hat sich MQTT als Protokoll erwiesen, das über die Zeit hinweg eine hervorragende Leistung im IoT-Bereich mit beschränkten Geräten bietet. In Bereichen, wo eine eingeschränkte Verbindung und niedriger Energieverbrauch keine Probleme darstellen, wie z.B. in bestimmten Bereichen des Edge-Computings und den meisten Cloud-Anwendungen, ist RESTful HTTP eine einfache Wahl. Auch CoAP sollte in Betracht gezogen werden, da es sich ebenfalls schnell zu einem Standard für die IoT-Kommunikation entwickelt und es sehr wahrscheinlich ist, dass es in naher Zukunft eine Stabilität und Reife erreicht, die mit MQTT und HTTP vergleichbar ist. Der Standard befindet sich jedoch momentan in der Entwicklung, was kurzfristige Kompatibilitätsprobleme mit sich bringt.
Was gibt es sonst noch Interessantes im Blog zu lesen?
→
→
→
→
→
Abonnieren Sie unseren -Kanal, um keinen neuen Artikel zu verpassen! Wir schreiben höchstens zweimal pro Woche und nur wenn es notwendig ist.
Quelle: habr.com
