MQTT-Messaging

MQTT ist ein offener Standard, der von der OASIS-Standardisierungsorganisation verwaltet und von der ISO international anerkannt wird. Er ist das primäre Protokoll, das Geräte und Anwendungen für die Kommunikation mit dem IoT Tool verwenden.

Hinweis: In „ 8.10 “ und späteren Versionen können Sie „ HTTP “-Messaging für Szenarien mit geringem Volumen verwenden. Verwenden Sie die Nachrichtenübermittlung „ HTTP “ nicht für Nachrichtenraten von mehr als 1000 Nachrichten pro Sekunde. HTTP Die Nachrichtenübermittlung erfordert einen TLS-Handshake und eine Authentifizierung für jede veröffentlichte Nachricht, und die Authentifizierung erfordert eine Datenbankabfrage für das Geräteauthentifizierungstoken. Diese Anforderungen belasten den Authentifizierungsdienst und die IoT Tool-Datenbank. Die MQTT-Messaging-Aufnahmeraten sind um 2 bis 3 Größenordnungen schneller als die von „ HTTP ”-Messaging.

MQTT ist ein Publish/Subscribe-Transportprotokoll, das für den effizienten Austausch von echtzeitnahen Daten zwischen Sensoren und mobilen Geräten konzipiert ist. Weitere Informationen finden Sie unter OASIS Message Queuing Telemetry Transport.

MQTT wird über TCP/IP ausgeführt; während es möglich ist, Code direkt an TCP/IP zu richten, können Sie auch eine Bibliothek verwenden, die die Details des MQTT-Protokolls für Sie handhabt. Es steht eine breite Auswahl an MQTT-Clientbibliotheken zur Verfügung. IBM trägt zur Entwicklung und Unterstützung mehrerer Clientbibliotheken bei, einschließlich derjenigen, die auf den folgenden Sites zur Verfügung stehen:

Standards und Anforderungen

Weitere Informationen zu den vom Tool IoT unterstützten MQTT-Versionen finden Sie unter Standards und Anforderungen.

Einschränkungen

Weitere Informationen zu den Einschränkungen und Beschränkungen, die für MQTT-Clients gelten, wenn sie mit dem IoT Tool verbunden sind, finden Sie unter Einschränkungen und Beschränkungen.

Portsicherheit

Geräte, Gateways und Anwendungen verbinden sich mit dem IoT Tool entweder über das MQTT- oder das HTTP -Protokoll.

Verbindungstyp Protokoll Portnummer
Sicher (TLS) MQTT und HTTPS 443

MQTT wird über TCP und WebSockets unterstützt. MQTT-Clients stellen eine Verbindung unter Verwendung von entsprechenden Berechtigungsnachweisen her, wie beispielsweise Authentifizierungstokens für Geräte bzw. API-Schlüssel und Tokens für Anwendungen. Die TLS-Berechtigungsnachweise werden immer verschlüsselt über sichere Ports gesendet.

Wenn Sie sichere MQTT-Nachrichten über Port 443 verwenden, vertrauen neuere Client-Bibliotheken automatisch dem Standardzertifikat, das vom IoT Tool bereitgestellt wird. Wenn dies für Ihre Client-Umgebung nicht der Fall ist, können Sie die vollständige Zertifikatskette von herunterladen messaging.pem und verwenden. Wenn Sie ein angepasstes Zertifikat hochladen, müssen Sie möglicherweise sicherstellen, dass die entsprechende Vertrauenskette zu Ihrer Clientumgebung hinzugefügt wird.

TLS

Sie müssen TLS in Ihrer Anwendung aktivieren, um das unsichere Senden von Daten zu vermeiden.

Weitere Informationen finden Sie in den folgenden Abschnitten:

Richtlinie für faire Nutzung

In „ 8.10 “ und späteren Versionen werden bei einer Fair-Use-Drosselung Lesevorgänge für Verbindungen angehalten, die das Verbindungslimit überschreiten. Die Drosselungsgrenzen für das IoT Tool gelten pro Gerät und basieren auf der Geräteklasse, z. B. Gerät, Gateway oder Anwendung. Diese Beschränkungen dienen dazu, Denial-of-Service-Angriffe ( DoS ) von Geräten zu verhindern. Die Drosselungsgrenzen skalieren nicht mit der Größe IoT der Tool-Bereitstellung. Die Drosselung gilt nicht für kurzlebige Verbindungen, die nur wenige Nachrichten senden, wie beispielsweise Verbindungen für HTTP Messaging-Clients. Weitere Informationen finden Sie unter Kontingente.

Um die Nachrichtenraten zu maximieren, stellen Sie sicher, dass Ihre IoT Tool-Datenaufzeichnungsanwendung die Last auf viele MQTT-Geräte oder -Anwendungen verteilt. Der IoT MQTT-Dienst ist dafür ausgelegt, viele Geräteverbindungen zu verwalten, wobei jedes Gerät mit niedrigen Raten veröffentlicht.

MQTT-Clientauthentifizierung

Jeder MQTT-Client erfordert eine eindeutige Client-ID. Wenn Sie versuchen, in Ihrer Organisation eine Verbindung für einen Client mithilfe einer Client-ID herzustellen, für die bereits eine Verbindung besteht, wird die zuerst hergestellte Verbindung getrennt.

Geräte und Gateways, die direkt mit dem IoT Tool verbunden sind, zeigen auf dem Dashboard ein Statussymbol an, um anzuzeigen, dass sie verbunden sind. Geräte, die indirekt über ein Gateway verbunden sind, werden als nicht verbunden angezeigt, da das Dashboard über ein Gateway verbundene Geräte nicht erkennt.

Servicequalitätsstufen für Messaging (QoS)

Das MQTT-Protokoll stellt drei Servicequalitäten für die Zustellung von Nachrichten zwischen Clients und Servern bereit. Die Messaging- QoS , die angegeben wird, wenn eine MQTT-Nachricht direkt veröffentlicht wird, wirkt sich auf die Messaging-Raten aus. In der folgenden Tabelle werden die QoS -Stufen beschrieben:
Tabelle 1. QoS -Stufen
Stufe Beschreibung
Höchstens einmal (QoS 0)

Die Servicequalitätsstufe 0 (QoS 0) ist der schnellste Übertragungsmodus. Die Nachricht wird höchstens einmal übermittelt oder sie wird möglicherweise überhaupt nicht übermittelt. Die Übermittlung über das Netz wird nicht bestätigt und die Nachricht wird nicht gespeichert. Die Nachricht geht möglicherweise verloren, wenn die Verbindung zum Client getrennt ist oder wenn der Server fehlschlägt.

Das MQTT-Protokoll erfordert nicht, dass Server Veröffentlichungen mit Servicequalitätsstufe 0 an einen Client weiterleiten. Wenn die Verbindung zum Client zum Zeitpunkt, an dem der Server die Publizierung empfängt, unterbrochen ist, wird die Publizierung in Abhängigkeit von der Serverimplementierung möglicherweise verworfen.

Wenn in einem Intervall echtzeitnahe Daten gesendet werden, verwenden Sie die Servicequalitätsstufe 0. Wenn eine einzelne Nachricht fehlt, ist dies nicht wirklich wichtig, da eine andere Nachricht, die neuere Daten enthält, kurz danach gesendet wird. In diesem Szenario führen die zusätzlichen Kosten einer höheren Servicequalität nicht zu einem materiellen Vorteil.
Mindestens einmal (QoS 1)

Bei einem QoS -Level 1 ( 1) wird die Nachricht immer mindestens einmal zugestellt. Wenn vor dem Erhalt der Bestätigung durch den Absender ein Fehler auftritt, kann eine Nachricht mehrere Male übermittelt werden. Die Nachricht muss lokal beim Absender gespeichert werden, bis der Absender die Bestätigung erhält, dass die Nachricht vom Empfänger publiziert wurde. Die Nachricht wird für den Fall gespeichert, dass sie erneut gesendet werden muss. Die zuverlässige Übermittlung der Nachricht an den MQTT-Broker bedeutet nicht, dass die Maximo® Monitor Nachricht verarbeitet wird.
Genau einmal (QoS 2)

Die QoS stufe 2 ( 2) bietet die zuverlässigste Nachrichtenübermittlung, hat jedoch auch die langsamste Übertragungsgeschwindigkeit. Die Nachricht wird immer genau einmal übermittelt und muss auch lokal beim Absender gespeichert werden, bis der Absender die Bestätigung erhält, dass die Nachricht vom Empfänger publiziert wurde. Die Nachricht wird für den Fall gespeichert, dass sie erneut gesendet werden muss. Mit der Servicequalitätsstufe 2 wird für Handshaking und Bestätigung eine ausgereiftere Sequenz als bei Stufe 1 verwendet, um sicherzustellen, dass Nachrichten nicht dupliziert werden. Die zuverlässige Übermittlung der Nachricht an den MQTT-Broker bedeutet nicht, dass die Maximo Monitor Nachricht verarbeitet wird.

Wenn Sie beim Senden von Befehlen bestätigen möchten, dass nur der angegebene Befehl ausgeführt wird und nur einmal ausgeführt wird, verwenden Sie die Servicequalitätsstufe 2. In diesem Beispiel können die zusätzlichen Gemeinkosten der Ebene 2 gegenüber anderen Ebenen vorteilhaft sein.
Lesen Sie die folgenden Leistungsaspekte, bevor Sie QoS 1 und QoS 2 verwenden:
  • Die Festplatten-E/A-Leistung ist für die Stufen „ QoS “ 1 und „ QoS “ 2 von entscheidender Bedeutung, da diese Stufen eine dauerhafte Festplattenkapazität in den IoT Tool-Messaging-Komponenten erfordern.
  • Die MQTT-Spezifikation stellt eine Vereinbarung zur Ablaufsteuerung auf Protokollebene zwischen Client und Server bereit. Der Client und der Server vereinbaren die zulässige Anzahl nicht bestätigter Nachrichten in der Sitzung. Wenn der Client keine verfügbaren Nachrichten-IDs hat, muss der Client die Veröffentlichung anhalten, bis IDs verfügbar sind. Nachrichten-IDs sind verfügbar, wenn Nachrichtenbestätigungen (ACK) empfangen werden. Weitere Informationen finden Sie unter OASIS Standard MQTT specification.

Datenaufnahmegeschwindigkeiten

Um höhere Datenaufnahmegeschwindigkeiten zu erreichen, verwenden Sie das MQTT-Messaging-Protokoll und halten Sie die Geräteverbindung geöffnet, während Sie Nachrichten veröffentlichen.

Das folgende MQTT-Messaging-Muster hält die Geräteverbindung geöffnet, bis alle Nachrichten veröffentlicht wurden:
MQTT CONNECT
MQTT PUBLISH
MQTT PUBLISH
MQTT PUBLISH
...
Das folgende MQTT-Messaging-Muster führt dazu, dass die Verbindung zwischen den Veröffentlichungsnachrichten getrennt wird. Verwenden Sie diesen Mustertyp nicht. Die Verwendung dieses Mustertyps führt zu geringeren Datenaufnahmegeschwindigkeiten.
MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
...

Die folgenden Faktoren beeinflussen die Datenaufnahmerate:

  • Das Nachrichtenprotokoll. MQTT ist ein Protokoll mit hohem Volumen. HTTP ist ein Protokoll mit geringem Volumen.
  • Das Messaging-Muster Schließen Sie MQTT-Sitzungen nicht nach jeder Veröffentlichung einer Nachricht, um die Datenaufnahmerate zu verbessern. Lassen Sie die Verbindung geöffnet.
  • Die Anzahl der Einheiten. Um die Datenaufnahme und Nachrichtenraten zu verbessern, verteilen Sie die Arbeitslast auf mehr Verbindungen.
  • Die Einheitenklasse. Die Fair-Use-Kontingente basieren auf der Geräteklasse.
  • QoS. Ein hohes Maß an Messaging-Zuverlässigkeit erfordert höhere Kosten.