Die Entwicklung der Technologien im Bereich Software und Hardware, das Auftreten 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 riesige Datenmengen. Daher entsteht der Bedarf nach einer benutzerfreundlichen Systemarchitektur, die in der Lage ist, diese Daten zu verarbeiten, zu speichern und zu übertragen.
Derzeit werden für diese Zwecke Cloud-Dienste verwendet. Die immer beliebter werdende Fog-Computing-Paradigma kann jedoch die Cloud-Lösungen ergänzen, indem sie die IoT-Infrastruktur skalierbar und optimiert.
Die „Clouds“ können die meisten IoT-Anfragen abdecken. Zum Beispiel bieten sie Monitoring-Dienste, die schnelle Verarbeitung beliebiger Datenmengen, die von Geräten generiert werden, sowie deren Visualisierung. Fog-Computing hingegen ist bei der Lösung von Echtzeitanforderungen effektiver. Es bietet eine schnelle Reaktion auf Anfragen und minimiert die Verzögerung bei der Datenverarbeitung. Das heißt, Fog ergänzt die „Clouds“ und erweitert deren Möglichkeiten.
Die Hauptfrage ist jedoch eine andere: Wie sollte all dies im Kontext von IoT zusammenarbeiten? Welche Kommunikationsprotokolle werden bei der Arbeit in einem vereinten System IoT-Fog-Cloud am effektivsten sein?
Trotz der scheinbaren Dominanz von HTTP wird in IoT-, Fog- und Cloud-Systemen eine Vielzahl anderer Lösungen verwendet. Dies erklärt sich daraus, dass IoT funktionale Möglichkeiten vielfältiger Sensorsysteme mit Sicherheit, Kompatibilität und anderen Anforderungen, die von Nutzern gestellt werden, kombinieren muss.
Es gibt jedoch kein einheitliches Verständnis über die Referenzarchitektur und den Kommunikationsstandard. Daher ist die Schaffung eines neuen Protokolls oder die Anpassung eines bestehenden an spezifische IoT-Anforderungen eine der wichtigsten Herausforderungen für die IT-Community.
Welche Protokolle werden derzeit verwendet und was können sie anbieten? Lassen Sie uns das klären. Aber zunächst sollten wir die Prinzipien des Ökosystems besprechen, in dem Clouds, Fog und das Internet der Dinge interagieren.
IoT Fog-to-Cloud (F2C) Architektur
Sie haben sicher bemerkt, wie viel Mühe darauf verwendet wird, die Vorteile und Nutzen eines rationalen und koordinierten Managements von IoT, Clouds und Fog zu untersuchen. Falls nicht, hier sind gleich drei Initiativen zur Standardisierung: , und .
Wenn zuvor nur 2 Ebenen betrachtet wurden, die Cloud und die Endgeräte, führt die vorgeschlagene Architektur eine neue Ebene ein – die Fog-Computing. Die Fog-Ebene kann in mehrere Unterebenen unterteilt werden, abhängig von der Spezifikation der 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 Rechenressourcen, um Aufgaben zu lösen, die eine geringe Latenz erfordern. In demselben System sind die Clouds dafür verantwortlich, Aufgaben zu lösen, die große Rechenressourcen oder Speicherplatz für Daten erfordern.
Smartphones, Smartwatches und andere Gadgets können ebenfalls Teil des IoT sein. Solche Geräte verwenden in der Regel proprietäre Kommunikationsprotokolle von großen Herstellern. Die generierten IoT-Daten werden über das REST HTTP-Protokoll an die Fog-Ebene übertragen, welches Flexibilität und funktionale Kompatibilität bei der Erstellung von RESTful-Services gewährleistet. Dies ist wichtig im Hinblick auf die Notwendigkeit, die Abwärtskompatibilität mit der bestehenden Computerinfrastruktur sicherzustellen, die auf lokalen Computern, Servern oder Serverclustern läuft. Lokale Ressourcen, die als „Fog-Knoten“ bezeichnet werden, filtern die empfangenen Daten und verarbeiten sie lokal oder leiten sie zur weiteren Verarbeitung in die Cloud weiter.
Clouds unterstützen verschiedene Kommunikationsprotokolle, darunter am häufigsten AMQP und REST HTTP. Da HTTP allgemein bekannt ist und auf das Internet ausgelegt ist, könnte die Frage aufkommen: „Sollte man es nicht für die Arbeit mit IoT und Fog verwenden?“. Dieses Protokoll hat jedoch Leistungsprobleme. Dazu später mehr.
Insgesamt gibt es 2 Modelle von Kommunikationsprotokollen, die für unser System geeignet sind. Dies sind Anfrage-Antwort und Veröffentlichung-Abonnement. Das erste Modell ist bekannter, insbesondere in der Server-Client-Architektur. Der Client fordert Informationen vom Server an, und dieser erhält die Anfrage, verarbeitet sie und sendet eine Antwort zurück. Nach diesem Modell arbeiten die Protokolle REST HTTP und CoAP.
Das zweite Modell entstand aus der Notwendigkeit, eine asynchrone, verteilte, schwache Verbindung zwischen Datenquellen und den Empfängern dieser Daten bereitzustellen.
Das Modell sieht drei Beteiligte vor: den Publisher (Datenquelle), den Broker (Dispatcher) und den Subscriber (Empfänger). Hier muss der Client, der als Subscriber fungiert, keine Informationen vom Server anfordern. Statt Anfragen zu senden, 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. Und der Publisher veröffentlicht, wenn ein Ereignis zu einem bestimmten Thema eintritt, dieses Thema beim Broker, der die Daten zum abonnierten Thema an den Subscriber sendet.
Im Grunde basiert diese Architektur auf Ereignissen. Und dieses Interaktionsmodell ist für Anwendungen im IoT, in der Cloud und im Fog von Interesse, da es Skalierbarkeit ermöglicht und die Beziehung zwischen verschiedenen Geräten vereinfacht, die dynamische "viele-zu-viele"-Verbindung und asynchrone Kommunikation unterstützt. Zu den bekanntesten standardisierten Messaging-Protokollen, die das "Publish-Subscribe"-Modell verwenden, gehören MQTT, AMQP und DDS.
Offensichtlich hat das "Publish-Subscribe"-Modell viele Vorteile:
- Publisher und Subscriber müssen nichts voneinander wissen;
- Ein Subscriber kann Informationen von vielen verschiedenen Publishern erhalten, während ein Publisher Daten an viele verschiedene Subscribers senden kann (Prinzip "viele-zu-viele");
- Publisher und Subscriber müssen nicht gleichzeitig aktiv sein, um Informationen auszutauschen, da der Broker (der als Warteschlangensystem fungiert) Nachrichten für Clients speichern kann, die derzeit nicht mit dem Netzwerk verbunden sind.
Das "Request-Response"-Modell hat jedoch auch seine Stärken. In Fällen, in denen die Serverressourcen zur Bearbeitung von Anfragen mehrerer Clients kein Problem darstellen, kann es sinnvoll sein, bereits erprobte, zuverlässige Lösungen zu nutzen.
Es gibt auch Protokolle, die beide Modelle unterstützen. Zum Beispiel unterstützen XMPP und HTTP 2.0 die Option „Server Push“. Die IETF hat ebenfalls CoAP veröffentlicht. Um das Problem der Nachrichtenübermittlung zu lösen, wurden mehrere andere Lösungen geschaffen, wie das WebSocket-Protokoll oder die Nutzung des HTTP-Protokolls über QUIC (Quick UDP Internet Connections).
Im Fall von WebSockets, obwohl es zur Übertragung von Daten in Echtzeit vom Server zum Web-Client verwendet wird und permanente Verbindungen mit gleichzeitiger bidirektionaler Kommunikation bietet, ist es nicht für Geräte mit begrenzten Rechenressourcen geeignet. QUIC verdient auch Beachtung, da das neue Transportprotokoll viele neue Möglichkeiten bietet. Da QUIC jedoch noch nicht standardisiert ist, ist es verfrüht, seine potenziellen Anwendungen und Auswirkungen auf Lösungen im Bereich IoT vorherzusagen. Daher lassen wir WebSockets und QUIC in der Hinterhand für die Zukunft, werden aber vorerst nicht näher darauf eingehen.
Wer ist der liebste der Welt: Wir vergleichen Protokolle
Lassen Sie uns nun über die Stärken und Schwächen der Protokolle sprechen. Um es gleich vorwegzunehmen, es gibt keinen eindeutigen Führer. Jedes Protokoll hat seine eigenen Vorzüge/Nachteile.
Reaktionszeit
Eine der wichtigsten Eigenschaften von Kommunikationsprotokollen, insbesondere im Hinblick auf das Internet der Dinge, ist die Reaktionszeit. Aber unter den bestehenden Protokollen gibt es keinen unbestrittenen Gewinner, der unter verschiedenen Bedingungen die geringste Verzögerung aufweist. Stattdessen gibt es eine Vielzahl von Studien und Vergleichen der Protokollmöglichkeiten.
Zum Beispiel, Vergleiche der Effizienz von HTTP und MQTT bei der Arbeit mit IoT haben gezeigt, dass die Reaktionszeit für die Anfragen bei MQTT geringer ist als bei HTTP. Und bei der Empfangs- und Übertragungszeit (RTT) von MQTT und CoAP stellte sich heraus, dass der durchschnittliche RTT von CoAP um 20 % geringer ist als der von MQTT.
Anderes Die RTT-Tests der Protokolle MQTT und CoAP wurden in zwei Szenarien durchgeführt: im lokalen Netzwerk und im IoT-Netzwerk. Es stellte sich heraus, dass der durchschnittliche RTT im IoT-Netzwerk 2 bis 3 Mal höher ist. MQTT mit QoS0 zeigte bei Vergleich mit CoAP ein geringeres Ergebnis, während MQTT mit QoS1 aufgrund der ACK auf Anwendungsebene und Transportschicht einen höheren RTT aufwies. Für unterschiedliche QoS-Stufen betrugen die Verzögerungen im Netzwerk ohne Überlastung bei MQTT Millisekunden, während sie für CoAP Hunderte von Mikrosekunden betrugen. Es ist jedoch zu beachten, dass bei der Arbeit in weniger zuverlässigen Netzwerken MQTT, das über TCP arbeitet, ein ganz anderes Ergebnis zeigen wird.
Die Antwortzeiten der AMQP- und MQTT-Protokolle wurden durch Erhöhung der Nutzlast untersucht und zeigten, dass bei geringer Last die Verzögerungsniveaus nahezu identisch sind. Bei der Übertragung großer Datenmengen hingegen weist MQTT eine kürzere Antwortzeit auf. In einem weiteren CoAP wurde in einem Szenario der Maschinenkommunikation mit Geräten verglichen, die in Fahrzeugen installiert sind und mit Gas- und Wetter-Sensoren sowie GPS-Standortdiensten und Mobilfunknetz-Schnittstellen (GPRS) ausgestattet sind. Die Zeit, die benötigt wurde, um eine CoAP-Nachricht über ein Mobilfunknetz zu übertragen, war fast dreimal kürzer als die für HTTP-Nachrichten.
Es wurden Studien durchgeführt, die drei Protokolle, nicht nur zwei, miteinander verglichen. Zum Beispiel die Leistung der IoT-Protokolle MQTT, DDS und CoAP in einem medizinischen Anwendungsszenario unter Verwendung eines Netzwerkemulators. DDS übertraf MQTT in Bezug auf die gemessene Telemetrieverzögerung unter verschiedenen schlechten Netzwerkbedingungen. CoAP, das auf UDP basiert, funktionierte gut für Anwendungen, die eine schnelle Antwort benötigten, jedoch kam es aufgrund seiner UDP-Basis zu erheblichen unvorhersehbaren Paketverlusten.
Bandbreite
Die Effizienz der Nutzung der Bandbreite von MQTT und CoAP wurde als Anzahl der insgesamt über ein einziges Nachricht übermittelten Daten gewertet. CoAP wies bei der Übertragung kleiner Nachrichten eine niedrigere Bandbreite auf als MQTT. Im Vergleich der Protokolle hinsichtlich des Verhältnisses von nützlichen Informationsbytes zu den insgesamt übertragenen Bytes schnitt CoAP jedoch effizienter ab.
Bei der Bandbreitennutzung von MQTT, DDS (mit TCP als Transportprotokoll) und CoAP ergab, dass CoAP im Allgemeinen eine vergleichsweise niedrigere Bandbreitennutzung aufwies, die sich bei zunehmenden Paketverlusten im Netzwerk oder bei erhöhten Netzwerkverzögerungen nicht erhöhte, im Gegensatz zu MQTT und DDS, bei denen in den genannten Szenarien ein Anstieg der Bandbreitennutzung beobachtet wurde. In einem anderen Szenario waren viele Geräte beteiligt, die gleichzeitig Daten übertrugen, was in IoT-Umgebungen typisch ist. Die Ergebnisse zeigten, dass CoAP für höhere Lasten besser geeignet ist.
Bei geringer Last nutzte CoAP die niedrigste Bandbreite, gefolgt von MQTT und REST HTTP. Wenn jedoch die Größe der Nutzlasten zunahm, erzielte REST HTTP die besten Ergebnisse.
Stromverbrauch
Der Energieverbrauch ist immer ein wichtiges Thema, insbesondere im IoT-Bereich. Wenn Energieverbrauch von MQTT und HTTP vergleicht, verbraucht HTTP deutlich mehr. CoAP ist dagegen im Vergleich zu MQTT und ermöglicht ein effizientes Energiemanagement. In einfachen Szenarien eignet sich MQTT besser für den Austausch von Informationen in IoT-Netzwerken, insbesondere wenn es keine Leistungsbeschränkungen gibt.
Ein Experiment, das die Möglichkeiten von AMQP und MQTT in einer Testumgebung für mobile oder instabile drahtlose Netzwerke verglich, zeigte, dass AMQP mehr Sicherheitsfunktionen bietet, während MQTT energieeffizienter ist.
Sicherheit
Sicherheit ist ein weiterer entscheidender Aspekt, der 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 Varianten auch DDS.
TLS und DTLS beginnen mit dem Verbindungsaufbau zwischen Client- und Serverseite zur Übertragung unterstützter Cipher-Suites und Schlüssel. Beide Seiten einigen sich auf die Suiten, um zu gewährleisten, dass die weitere Kommunikation über einen sicheren Kanal erfolgt. Der Unterschied zwischen ihnen besteht in einigen kleinen Modifikationen, die es DTLS auf UDP-Basis ermöglichen, über unsichere Verbindungen zu arbeiten.
Bei auf mehrere unterschiedliche Implementierungen von TLS und DTLS stellte sich heraus, dass TLS die Aufgabe besser erfüllte. Angriffe auf DTLS waren erfolgreicher aufgrund seiner Fehlertoleranz.
Die größte Herausforderung dieser Protokolle besteht jedoch darin, dass sie ursprünglich nicht für den Einsatz im IoT konzipiert wurden und keine Verwendung in Fog oder Cloud vornahmen. Durch den Handshake fügen sie bei jeder Verbindungsherstellung zusätzlichen Verkehr hinzu, was die Rechenressourcen erschöpft. Im Durchschnitt gibt es einen Anstieg von 6,5% für TLS und 11% für DTLS bei der Overheadnutzlast im Vergleich zu Verbindungen ohne Sicherheitsstufe. In ressourcenreichen Umgebungen, die sich typischerweise in der Auf diesem Niveau wird es kein Problem sein, aber im Zusammenhang zwischen IoT und Nebelhöhe wird dies zu einer wichtigen Einschränkung.
Was soll man wählen? Eine eindeutige Antwort gibt es nicht. MQTT und HTTP scheinen die vielversprechendsten Protokolle zu sein, da sie als vergleichsweise reifere und stabilere Lösungen für IoT im Vergleich zu anderen Protokollen gelten.
Lösungen auf der Grundlage eines einheitlichen Kommunikationsprotokolls
Die Praxis einer einprotokolligen Lösung hat viele Nachteile. Zum Beispiel kann ein Protokoll, das für eine eingeschränkte Umgebung geeignet ist, in einem Bereich, der strenge Sicherheitsanforderungen hat, nicht funktionieren. Vor diesem Hintergrund bleibt uns kaum eine Möglichkeit, außer fast alle möglichen Lösungen auf der Basis eines Protokolls im Fog-to-Cloud-Ökosystem im IoT abzulehnen, außer MQTT und REST HTTP.
REST HTTP als einprotokollige Lösung
Es gibt ein gutes Beispiel für die Interaktion von Anfragen und Antworten über REST HTTP im Bereich IoT-to-Fog: . Tiere sind mit tragbaren Sensoren (IoT-Client, C) ausgestattet und werden über Cloud-Computing durch ein intelligentes Landwirtschaftssystem (Fog-Server, S) verwaltet.
Im Header der POST-Methode wird die zu ändernde Ressource (/farm/animals) sowie die HTTP-Version und der Inhaltstyp angegeben, der in diesem Fall ein JSON-Objekt ist, das die Viehfarm darstellt, die vom System verwaltet werden soll (Dulcinea/Kuh). Die Antwort des Servers zeigt an, dass die Anfrage erfolgreich war, indem der HTTPS-Statuscode 201 (Ressource erstellt) gesendet wird. Die GET-Methode sollte nur die angeforderte Ressource im URI (zum Beispiel /farm/animals/1) angeben, die die JSON-Darstellung des Tieres mit dieser ID vom Server zurückgibt.
Die PUT-Methode wird verwendet, wenn es notwendig ist, einen bestimmten Datensatz der Ressource zu aktualisieren. In diesem Fall wird im Ressourcen-URI der zu ändernde Parameter und der aktuelle Wert angegeben (zum Beispiel, der angibt, dass die Kuh gerade weidet, /farm/animals/1?status=weiden). Schließlich wird die DELETE-Methode gleichermaßen wie die GET-Methode verwendet, aber sie entfernt einfach die Ressource bei der Operation.
MQTT als einprotokollige Lösung
Nehmen wir dieselbe intelligente Farm, aber anstelle von 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 Farmserver) Raspberry Pi als MQTT-Client, der über die Installation der MQTT Paho-Bibliothek realisiert wird, die vollständig mit dem Mosquitto-Broker kompatibel ist.
Dieser Client entspricht dem Abstraktionslevel des IoT, das ein Gerät mit Entdeckungs- und Berechnungsfähigkeiten darstellt. Der Broker hingegen entspricht einem höheren Abstraktionslevel, das einen Fog-Computing-Knoten darstellt, der durch große Verarbeitungs- und Speicherkapazitäten gekennzeichnet ist.
Im vorgeschlagenen Szenario der „intelligenten Farm“ verbindet sich der Raspberry Pi mit einem Beschleunigungsmesser, GPS und Temperatursensoren und veröffentlicht die Daten dieser Sensoren im Fog-Knoten. Wie Sie sicherlich wissen, betrachtet MQTT Themen als Hierarchie. Ein MQTT-Publisher kann Nachrichten in einem bestimmten Satz von Themen veröffentlichen. In unserem Fall sind es 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 den GPS-Standort und die Bewegung der Tiere über den Beschleunigungsmesser messen, veröffentlicht der Client Updates (animalfarm/animal/GPS) und (animalfarm/animal/movement).
Diese Informationen werden an den Broker übermittelt, der sie vorübergehend in einer lokalen Datenbank speichern kann, falls später ein anderer interessierter Abonnent erscheint.
Neben dem lokalen Server, der als MQTT-Broker im Fog fungiert und dem die Raspberry Pis, die als MQTT-Clients agieren, Daten von den Sensoren senden, kann auf der Cloud-Ebene ein weiterer MQTT-Broker existieren. In diesem Fall können die an den lokalen Broker übermittelten Informationen 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. Mit dieser Architektur kann der Benutzer der mobilen Anwendung bei beiden Brokern angemeldet sein.
Im Falle eines Verbindungsabbruchs mit einem der Broker (zum Beispiel der Cloud) erhält der Endbenutzer Informationen von einem anderen (Fog). Dies ist ein charakteristisches Merkmal von kombinierten Systemen von Fog und Cloud Computing. Standardmäßig kann die mobile Anwendung so konfiguriert werden, dass sie zuerst eine Verbindung zu einem Fog MQTT-Broker herstellt und, falls dies fehlschlägt, zu einem MQTT-Broker in der Cloud verbindet. Diese Lösung ist nur eine von vielen in IoT-F2C-Systemen.
Multiprotokoll-Lösungen
Einprotokoll-Lösungen sind aufgrund ihrer einfacheren Implementierung beliebt. Aber es ist offensichtlich, dass es in IoT-F2C-Systemen sinnvoll ist, verschiedene Protokolle zu kombinieren. Der Sinn dahinter ist, dass auf verschiedenen Ebenen unterschiedliche Protokolle arbeiten können. Nehmen wir als Beispiel drei Abstraktionen: die IoT-, Fog- und Cloud-Computing-Ebenen. Geräte auf der IoT-Ebene gelten normalerweise als eingeschränkt. Für diese Übersicht betrachten wir die IoT-Ebenen als am stärksten eingeschränkt, die Cloud als am wenigsten eingeschränkt und Fog-Computing als „irgendwo dazwischen“. Daraus ergibt sich, dass zwischen IoT und Fog-Abstraktionen die aktuellen Protokolllösungen MQTT, CoAP und XMPP umfassen. Zwischen Fog und Cloud ist hingegen AMQP eines der Hauptprotokolle, das zusammen mit REST HTTP verwendet wird, das aufgrund seiner Flexibilität auch zwischen IoT und Fog-Schichten verwendet wird.
Das Hauptproblem besteht hier in der funktionalen Kompatibilität der Protokolle und der Einfachheit der Nachrichtenübertragung von einem Protokoll zu einem anderen. Idealerweise wird die Architektur des Internet of Things in Zukunft mit Cloud- und Fog-Ressourcen unabhängig vom verwendeten Kommunikationsprotokoll sein und eine gute Interoperabilität zwischen verschiedenen Protokollen gewährleisten.
Da dies momentan nicht der Fall ist, macht es Sinn, Protokolle zu kombinieren, die keine wesentlichen Unterschiede aufweisen. Zu diesem Zweck basiert eine mögliche Lösung auf der Kombination von zwei Protokollen, die denselben architektonischen Stil verfolgen, REST HTTP und CoAP. Eine andere vorgeschlagene Lösung basiert auf der Kombination von zwei Protokollen, die Interaktionen nach dem „Publish-Subscribe“-Modell anbieten, MQTT und AMQP. Die Verwendung ähnlicher Konzepte (sowohl MQTT als auch AMQP verwenden Broker, CoAP und HTTP verwenden REST) vereinfacht die Implementierung dieser Kombinationen und erfordert weniger Integrationsaufwand.
In Abbildung (a) sind zwei Modelle basierend auf Anfragen und Antworten, HTTP und CoAP, sowie deren mögliche Platzierung in der IoT-F2C-Lösung dargestellt. 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 sich zwischen Cloud und Fog befinden, ist REST HTTP eine sinnvolle Lösung.
Andererseits ist es für Geräte mit begrenzten Rechenressourcen, die sich zwischen den Ebenen Fog und IoT verbinden, effizienter, CoAP zu verwenden. Ein großes 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 „Publizieren-Abonnieren“-Interaktionsmusters in einem Szenario dargestellt, einschließlich MQTT und AMQP. Obwohl hypothetisch beide Protokolle für die Kommunikation zwischen Knoten auf jeder Abstraktionsebene genutzt werden könnten, sollte ihre Position auf der Basis 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 verwendet werden kann. AMQP ist besser für leistungsstärkere Geräte geeignet, die es ideal zwischen Fog- und Cloud-Knoten anordnen würden. Anstelle von MQTT könnte im IoT das Protokoll XMPP verwendet werden, da es als leichtgewichtig gilt. Es wird jedoch in ähnlichen Szenarien nicht so weit verbreitet eingesetzt.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Es ist unwahrscheinlich, dass eines der betrachteten Protokolle ausreicht, um die gesamte Kommunikation im System abzudecken, beginnend bei Geräten mit begrenzten Rechenressourcen bis hin zu Cloud-Servern. Die Untersuchung hat gezeigt, dass die beiden vielversprechendsten Optionen, die von Entwicklern häufiger verwendet werden, MQTT und RESTful HTTP sind. Diese beiden Protokolle sind nicht nur die am weitesten entwickelten und stabilsten, sondern beinhalten auch zahlreiche gut dokumentierte und erfolgreiche Implementierungen sowie Online-Ressourcen.
Dank seiner Stabilität und einfachen Konfiguration hat sich MQTT als Protokoll mit überlegener Leistung im IoT-Bereich für Geräte mit eingeschränkten Ressourcen bewährt. In Teilen des Systems, wo eingeschränkte Konnektivität und Batterieverbrauch kein Problem darstellen, wie in bestimmten Bereichen der Fog-Computing und den meisten Cloud-Diensten, ist RESTful HTTP eine einfache Wahl. CoAP sollte ebenfalls in Betracht gezogen werden, da es sich ebenfalls schnell als Standard für IoT-Kommunikation entwickelt und es sehr wahrscheinlich ist, dass es in naher Zukunft ein Stabilitäts- und Reifegrad erreicht, der dem von MQTT und HTTP entspricht. Der Standard befindet sich jedoch derzeit in der Entwicklung, was mit kurzfristigen Kompatibilitätsproblemen verbunden ist.
Was gibt es noch Nützliches im Blog zu lesen
→
→
→
→
→
Abonnieren Sie unseren -Kanal, um keinen Artikel zu verpassen! Wir schreiben nicht öfter als zweimal pro Woche und nur relevante Inhalte.
Quelle: habr.com
