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
