MQTT-Features, die vom MQTT-Broker von Azure Event Grid unterstützt werden

Message Queuing Telemetry Transport (MQTT) ist ein Veröffentlichungs-Abonnement-Messagingtransportprotokoll, das für eingeschränkte Umgebungen entwickelt wurde. MQTT ist effizient, skalierbar und zuverlässig, was es für die Kommunikation in IoT-Szenarien (Internet der Dinge) beliebt macht. Der MQTT-Broker unterstützt Clients, die Nachrichten über MQTT v3.1.1, MQTT v3.1.1 über WebSockets, MQTT v5 und MQTT v5 über WebSockets veröffentlichen und abonnieren. Der MQTT-Broker unterstützt auch die Kommunikation zwischen verschiedenen MQTT-Versionen (MQTT 3.1.1 und MQTT 5).

Der MQTT-Broker in Azure Event Grid unterstützt auch Geräte und Dienste, die MQTT-Nachrichten über HTTPS senden, was die Integration mit Nicht-MQTT-Clients vereinfacht. Event Grid ermöglicht ihnen das Senden von MQTT-Nachrichten an die Cloud zur Datenanalyse, -speicherung und -visualisierung unter anderen Anwendungsfällen. Diese Funktion steht derzeit als Vorschau zur Verfügung.

MQTT v5 führte viele Verbesserungen gegenüber MQTT v3.1.1 ein, um eine nahtlosere, transparentere und effizientere Kommunikation zu ermöglichen. Folgendes wurde hinzugefügt:

• Bessere Fehlerberichterstellung.
• Transparentere Kommunikation mit Clients durch Funktionen wie Benutzereigenschaften und Inhaltstyp
• Mehr Kontrolle für Clients über die Kommunikation durch Features wie Nachrichten- und Sitzungsablauf.
• Standardmäßige wichtige Muster wie das Anforderung-Antwort-Muster.

Verbindungsfluss

Ihre MQTT-Clients müssen über Transport Layer Security (TLS) 1.2 oder TLS 1.3 verbunden sein. Wenn Sie versuchen, diesen Schritt zu überspringen, treten Verbindungsfehler auf.

Wenn Sie eine Verbindung mit dem MQTT-Broker herstellen, verwenden Sie die folgenden Ports für die Kommunikation über MQTT:

• MQTT v3.1.1 und MQTT v5 an TCP-Port 8883
• MQTT v3.1.1 über WebSocket und MQTT v5 über WebSocket über TCP-Port 443

Das CONNECT-Paket sollte die folgenden Eigenschaften enthalten:

• Das Feld ClientId ist erforderlich und muss den Sitzungsnamen des Clients enthalten. Der Sitzungsname muss für den gesamten Namespace eindeutig sein. Sie können den Authentifizierungsnamen des Clients als Sitzungsnamen verwenden, wenn jeder Client eine Sitzung pro Client verwendet. Wenn ein Client mehrere Sitzungen verwendet, muss er für jede seiner Sitzungen unterschiedliche Werte für ClientId verwenden.
• Das Feld Username ist erforderlich, wenn Sie bei der Erstellung des Namespace keinen Wert in alternativeAuthenticationNameSources ausgewählt haben. In diesem Fall müssen Sie den Authentifizierungsnamen Ihres Clients im Feld Username angeben. Dieser Name muss mit dem angegebenen Authentifizierungsnamen und dem Wert im Zertifikatsfeld des Clients übereinstimmen, der bei der Erstellung der Clientressource angegeben wurde.

Erfahren Sie mehr über Clientauthentifizierung.

Unterstützung für mehrere Sitzungen

Die Unterstützung für mehrere Sitzungen ermöglicht Ihren MQTT-Anwendungsclients eine besser skalierbare und zuverlässigere Implementierung, indem sie eine Verbindung mit dem MQTT-Broker mit mehreren aktiven Sitzungen gleichzeitig herstellen.

Konfiguration von Namespaces

Bevor Sie dieses Feature verwenden, müssen Sie den Namespace so konfigurieren, dass mehrere Sitzungen pro Client zugelassen werden. Führen Sie die folgenden Schritte aus, um mehrere Sitzungen pro Client im Azure-Portal zu konfigurieren:

1. Navigieren Sie im Azure-Portal zu Ihrem Namespace.
2. Ändern Sie unter Konfiguration den Wert für Maximale Clientsitzungen pro Authentifizierungsname in die gewünschte Anzahl von Sitzungen pro Client.
3. Wählen Sie Übernehmen.

Verbindungsfluss

Die CONNECT-Pakete für jede Sitzung sollten die folgenden Eigenschaften umfassen:

• Geben Sie die Eigenschaft Username im CONNECT-Paket an, um den Namen Ihrer Clientauthentifizierung anzugeben.
• Geben Sie die Eigenschaft ClientID im CONNECT-Paket an, um den Sitzungsnamen anzugeben, z. B. wenn es einen oder mehrere Werte für die Client-ID für jeden Benutzernamen gibt.

Beispielsweise ermöglichen die folgenden Kombinationen von Username und ClientId im CONNECT-Paket der Client-Mgmt-application, über drei unabhängige Sitzungen eine Verbindung mit dem MQTT-Broker herzustellen:

• Erste Sitzung:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session1
• Zweite Sitzung:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session2
• Dritte Sitzung:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session3

Weitere Informationen finden Sie unter Einrichten mehrerer Sitzungen für einen einzelnen Client.

Verwalten von Sitzungen

• Wenn ein Client versucht, die aktive Sitzung eines anderen Clients zu übernehmen, indem er seinen Sitzungsnamen mit einem anderen Authentifizierungsnamen angibt, wird seine Verbindungsanforderung mit einem Fehler vom Typ „Nicht autorisiert“ abgelehnt. Wenn beispielsweise Client B versucht, eine Verbindung mit Sitzung 123 herzustellen, die zu diesem Zeitpunkt Client A zugewiesen ist, wird die Verbindungsanforderung von Client B abgelehnt. Wenn derselbe Client jedoch versucht, die Verbindung mit denselben Sitzungsnamen und demselben Authentifizierungsnamen erneut herzustellen, kann er seine vorhandene Sitzung übernehmen.
• Wenn eine Clientressource gelöscht wird, ohne ihre Sitzung zu beenden, können andere Clients diesen Sitzungsnamen nicht verwenden, bis die Sitzung abläuft. Wenn beispielsweise Client B eine Sitzung mit dem Sitzungsnamen 123 erstellt und dann gelöscht wird, kann Client A erst nach Ablauf der Sitzung eine Verbindung mit Sitzung 123 herstellen.
• Der Grenzwert für die Anzahl der Sitzungen pro Client gilt jederzeit für Online- und Offlinesitzungen. Beispiel: Angenommen, ein Namespace mit den maximalen Clientsitzungen pro Authentifizierungsname ist auf 1 festgelegt. Client A stellt eine Verbindung mit der persistenten Sitzung 123 her und wird dann getrennt. Client A kann keine Verbindung mit der neuen Sitzung 456 herstellen, da seine Sitzung 123 noch aktiv ist, auch wenn er offline ist. Dementsprechend wird empfohlen, dass derselbe Client immer wieder mit denselben statischen Sitzungsnamen verbunden wird, anstatt bei jeder erneuten Verbindung einen neuen Sitzungsnamen zu generieren.

MQTT-Features

Der MQTT-Broker von Event Grid unterstützt die folgenden MQTT-Features.

Dienstqualität

Der MQTT-Broker unterstützt die QoS-Stufen 0 und 1, die die garantierte Zustellung von PUBLISH- und SUBSCRIBE-Paketen zwischen Clients und dem MQTT-Broker definieren.

• QoS 0 garantiert eine einmalige Zustellung: Der Abonnent bestätigt keine Nachrichten mit QoS 0, und der Herausgeber sendet sie nicht erneut.
• QoS 1 garantiert eine mindestens einmalige Zustellung: Der Abonnent bestätigt Nachrichten, und der Herausgeber sendet sie erneut, wenn sie nicht bestätigt wurden.

QoS ermöglicht es Ihren Clients, die Effizienz und Zuverlässigkeit der Kommunikation zu steuern.

Persistente Sitzungen

Der MQTT-Broker unterstützt persistente Sitzungen für MQTT v3.1.1, sodass der MQTT-Broker Informationen über die Sitzung eines Clients speichert, wenn die Verbindung unterbrochen wird, um die Zuverlässigkeit der Kommunikation zu gewährleisten. Diese Informationen umfassen die Abonnements des Clients sowie verpasste oder nicht bestätigte QoS 1-Nachrichten. Clients können eine persistente Sitzung konfigurieren, indem sie das cleanSession-Flag im CONNECT-Paket auf false setzen.

Sauberer Start und Sitzungsablauf

MQTT v5 führte die Neustart- und Sitzungsablauffunktionen als Verbesserung gegenüber MQTT v3.1.1 bei der Behandlung von Sitzungspersistenz ein. Der saubere Start ermöglicht es einem Client, eine neue Sitzung mit dem MQTT-Broker zu starten, nachdem alle vorherigen Sitzungsdaten verworfen wurden. Der Sitzungsablauf ermöglicht es einem Client, den MQTT-Broker zu informieren, wenn eine inaktive Sitzung als abgelaufen gilt und automatisch entfernt wird.

Im CONNECT-Paket kann ein Client das Clean Start-Flag auf true setzen. Ein Client kann aus Sicherheitsgründen oder zur Vermeidung potenzieller Datenkonflikte, die während der vorherigen Sitzung aufgetreten sein könnten, auch ein kurzes Sitzungsablaufintervall festlegen. Ein Client kann das Clean Start-Flag auch auf false setzen oder ein langes Sitzungsablaufintervall setzen, um die Zuverlässigkeit und Effizienz persistenter Sitzungen sicherzustellen.

Konfiguration des maximalen Ablaufintervalls der Sitzung

Sie können das maximal zulässige Sitzungsablaufintervall für alle Clients konfigurieren, die eine Verbindung mit dem Event Grid-Namespace herstellen. Bei MQTT v3.1.1-Clients wird der konfigurierte Grenzwert als Standardintervall für den Ablauf von Sitzungen für alle persistenten Sitzungen verwendet. Für MQTT v5-Clients wird der konfigurierte Grenzwert als Maximalwert für die Sitzungsablaufintervall-Eigenschaft des im CONNECT-Paket angewendet. Jeder Wert, der den Grenzwert überschreitet, wird angepasst. Der Standardwert für diese Namespace-Eigenschaft beträgt eine Stunde und kann auf bis zu acht Stunden erweitert werden. Führen Sie die folgenden Schritte aus, um das maximale Sitzungsablaufintervall im Azure-Portal zu konfigurieren:

1. Navigieren Sie im Azure-Portal zu Ihrem Namespace.
2. Ändern Sie unter Konfiguration den Wert für das maximale Sitzungsablaufintervall in Stunden in den gewünschten Grenzwert.
3. Wählen Sie Übernehmen.

Sitzungsüberlauf

Der MQTT-Broker unterhält eine Warteschlange mit Nachrichten für jede aktive MQTT-Sitzung, die nicht verbunden ist, bis der Client sich erneut mit dem MQTT-Broker verbindet, um die Nachrichten in der Warteschlange zu empfangen. Wenn ein Client keine Verbindung herstellt, um die in der Warteschlange befindlichen QoS 1-Nachrichten zu empfangen, sammelt die Sitzungswarteschlange Nachrichten, bis sie ihren Grenzwert von 100 Nachrichten oder 1 MB erreicht. Nachdem die Warteschlange während der Lebensdauer der Sitzung ihren Grenzwert erreicht hat, wird die Sitzung beendet.

Last Will and Testament-Nachrichten

Last Will and Testament (LWT) benachrichtigt Ihre MQTT-Clients mit den abrupten Trennungen anderer MQTT-Clients. Sie können LWT verwenden, um einen vorhersehbaren und zuverlässigen Flow der Kommunikation zwischen MQTT-Clients bei unerwarteten Verbindungsunterbrechungen zu gewährleisten. Diese Funktion ist besonders wertvoll in Szenarien, in denen Echtzeitkommunikation, Systemzuverlässigkeit und koordinierte Aktionen von entscheidender Bedeutung sind. Clients, die an komplexen Aufgaben zusammenarbeiten, können auf LWT-Nachrichten voneinander reagieren, indem sie ihr Verhalten anpassen, Aufgaben neu verteilen oder bestimmte Verantwortlichkeiten übernehmen, um die Leistung und Stabilität des Systems aufrechtzuerhalten.

Um LWT zu verwenden, kann ein Client die Will-Nachricht und das Will-Thema angeben, und die restlichen Eigenschaften des Willens im CONNECT-Paket während der Verbindung angeben. Wenn der Client abrupt getrennt wird, veröffentlicht der MQTT-Broker die Will-Nachricht an alle Clients, die das Will-Thema abonniert haben. Um das Rauschen von schwankenden Trennungen zu verringern, kann der Client das Verzögerungsintervall auf einen Wert festlegen, der größer als 0 ist. Wenn der Client in diesem Fall abrupt getrennt wird, die Verbindung jedoch wiederhergestellt wird, bevor das Verzögerungsintervall abläuft, wird die Will-Nachricht nicht veröffentlicht.

Benutzereigenschaften

Der MQTT-Broker unterstützt Benutzereigenschaften in PUBLISH-Paketen von MQTT v5, mit denen Sie benutzerdefinierte Schlüssel/Wert-Paare in den Nachrichtenkopf einfügen können, um mehr Kontext zur Nachricht bereitzustellen. Die Anwendungsfälle für Benutzereigenschaften sind vielfältig. Sie können dieses Feature verwenden, um den Zweck oder den Ursprung der Nachricht anzugeben, sodass der Empfänger die Nachricht verarbeiten kann, ohne die Nutzdaten analysieren zu müssen, und somit Computingressourcen spart. Beispielsweise könnte eine Nachricht mit einer Benutzereigenschaft, die ihren Zweck als „Warnung“ angibt, eine andere Verarbeitungslogik auslösen als eine mit dem Zweck „Information“.

Anforderung/Antwort-Muster

MQTT v5 hat Felder im PUBLISH-Paketheader von MQTT eingeführt, die den Kontext für die Antwortnachricht im Anforderung/Antwort-Muster bereitstellen. Zu diesen Feldern gehören ein Antwortthema und eine Korrelations-ID, die der Antwortdienst ohne vorherige Konfiguration in der Antwort verwenden kann. Die Antwortinformationen ermöglichen eine effizientere Kommunikation für das Anforderung/Antwort-Standardmuster, das in Command-and-Control-Szenarien verwendet wird.

Ablaufintervall der Nachricht

In MQTT v5 ermöglicht das Ablaufintervall für Nachrichten eine konfigurierbare Lebensdauer. Das Ablaufintervall für Nachrichten ist definiert als das Zeitintervall zwischen dem Zeitpunkt, an dem eine Nachricht im MQTT-Broker veröffentlicht wird, und dem Zeitpunkt, an dem der Broker die Nachricht verwerfen muss, wenn sie nicht übermittelt wurde. Dieses Feature ist in Szenarien nützlich, in denen Nachrichten nur für eine bestimmte Zeit gültig sind, z. B. bei zeitabhängigen Befehlen, Echtzeitdatenströmen oder Sicherheitswarnungen. Durch Festlegen eines Ablaufintervalls für Nachrichten kann der MQTT-Broker veraltete Nachrichten automatisch entfernen. Dieser Schritt stellt sicher, dass den Abonnenten nur relevante Informationen zur Verfügung stehen. Wenn das Ablaufintervall einer Nachricht auf Null festgelegt ist, bedeutet dies, dass die Nachricht niemals ablaufen sollte.

Themenaliase

In MQTT v5 ermöglichen Themenaliase einem Client, einen kürzeren Alias anstelle des vollständigen Themennamens in der veröffentlichten Nachricht zu verwenden. Der MQTT-Broker verwaltet eine Zuordnung zwischen dem Themenalias und dem aktuellen Themennamen. Mit diesem Feature können Sie Netzwerkbandbreite sparen und die Größe des Nachrichtenheaders reduzieren, insbesondere bei Themen mit langen Namen. Dies ist nützlich in Szenarien, in denen dasselbe Thema wiederholt in mehreren Nachrichten veröffentlicht wird, z. B. in Sensornetzwerken. Der MQTT-Broker unterstützt bis zu 10 Themenaliasse. Ein Client kann ein Topic Alias-Feld für Themenaliase im PUBLISH-Paket verwenden, um den vollständigen Themennamen durch den entsprechenden Alias zu ersetzen.

Flusssteuerung

In MQTT v5 bezieht sich die Flusssteuerung auf den Mechanismus zur Verwaltung der Rate und Größe von Nachrichten, die ein Client verarbeiten kann. Um die Flusssteuerung zu konfigurieren, legen Sie die Parameter Maximum Packet Size und Receive Maximum im CONNECT-Paket fest. Mit dem Parameter Receive Maximum kann der Client die Anzahl der vom Broker gesendeten Nachrichten auf die Anzahl der Nachrichten beschränken, die der Client verarbeiten kann. Der Parameter Maximum Packet Size definiert die maximale Größe der Pakete, die der Client empfangen kann. Der MQTT-Broker hat eine Nachrichtengrößenbeschränkung von 512 KiB. Dieses Feature gewährleistet die Zuverlässigkeit und Stabilität der Kommunikation bei eingeschränkten Geräten mit begrenzter Verarbeitungsgeschwindigkeit oder Speicherkapazität.

Negative Bestätigungen und vom Server initiiertes DISCONNECT-Paket

Bei MQTT v5 kann der MQTT-Broker negative Bestätigungen und vom Server initiierte Trennungspakete senden, die dem Client weitere Informationen über Fehler bei der Nachrichtenzustellung oder Verbindung liefern. Diese Features helfen dem Client bei der Diagnose der Fehlerursache und bei der Ergreifung geeigneter Aktionen zur Entschärfung des Problems. Der MQTT-Broker verwendet die in der MQTT v5-Spezifikation definierten Ursachencodes.

Nachrichtensortierung

MQTT v5 gewährleistet bei Verwendung der QoS-Stufe 1 die Reihenfolge der Nachrichtenübermittlung innerhalb jedes Themas und jedes Clients, was für Workflows, die eine Sequenzintegrität erfordern, von entscheidender Bedeutung ist. Es eignet sich ideal für Szenarien wie Telemetrie, Befehlsausführung und Zeitreihendaten.

Die Sortierung über verschiedene Themen hinweg oder das Senden von Nachrichten mit unterschiedlichen QoS-Ebenen ist jedoch nicht gewährleistet. Für weitere Informationen kontaktieren Sie uns unter askmqtt@microsoft.com.

Zugewiesene Client-IDs

MQTT v5 führt Unterstützung für zugewiesene Clientbezeichner ein, wodurch der MQTT-Broker eine eindeutige Client-ID generieren und zurückgeben kann, wenn der Client keine bereitstellt. Die Unterstützung dieses Features durch den MQTT-Broker gewährleistet ein nahtloses Clientonboarding und sorgt dafür, dass Clients keine eigenen Bezeichner verwalten müssen. Dies ist besonders hilfreich in Szenarien, in denen die Clientbereitstellung dynamisch ist oder geräte keine vorkonfigurierte Identität haben. Zugewiesene Client-IDs können aus der CONNACK-Antwort abgerufen und für zukünftige Sitzungen wiederverwendet werden, um eine konsistente Identifizierung aufrechtzuerhalten.

Verwalten von Grenzwerten für Clientbezeichner und Sitzungen in MQTT

• Zugewiesene Client-IDs ermöglichen Clients das Herstellen einer Verbindung ohne Angabe vordefinierter Bezeichner, wodurch temporäre oder persistente Sitzungen aktiviert werden.
• Clients können verhindern, dass sie gesperrt werden, indem sie kurze Sitzungsablaufintervalle während der ersten Verbindung verwenden und die zugewiesene Client-ID für die zukünftige Verwendung speichern.
• Bei Firmwareupdates oder Zurücksetzungen sollten Clients entweder ihre bekannte Client-ID beibehalten oder bescheidene Sitzungsablaufintervalle verwenden, um längere Sperrungen zu vermeiden.
• Die Namespacekonfiguration kann die Sitzungsgrenzwerte pro Client erhöhen, um Unterbrechungen während Updates oder Rollbacks zu minimieren.

Aktuelle Einschränkungen

Der MQTT-Broker wird in Zukunft weitere MQTT v5- und MQTT v3.1.1-Features hinzufügen, um sich stärker an die MQTT-Spezifikationen anzupassen. In der folgenden Liste werden die aktuellen Unterschiede zwischen Features beschrieben, die vom MQTT Vermittler und den MQTT-Spezifikationen unterstützt werden:

Aktuelle Einschränkungen von MQTT v5

MQTT v5 unterscheidet sich derzeit in den folgenden Punkten von der MQTT v5-Spezifikation:

• Gemeinsame Abonnements werden noch nicht unterstützt.
• Das maximale Verzögerungsintervall beträgt 300.
• Maximaler QoS-Wert ist 1.
• Maximale Paketgröße beträgt 512 KiB
• Abonnementbezeichner werden nicht unterstützt.
• Maximaler Wert für den Themenalias ist 10. Der Server weist derzeit keine Themenaliase für ausgehende Nachrichten zu. Clients können Themenaliasse innerhalb des festgelegten Grenzwerts zuweisen und verwenden.
• CONNACK gibt die Eigenschaft Response Information nicht zurück, selbst wenn die CONNECT-Anforderung die Eigenschaft Request Response Information enthält.
• Benutzereigenschaften in CONNECT-, SUBSCRIBE-, DISCONNECT-, PUBACK- und AUTH-Paketen werden vom Dienst nicht verwendet und daher nicht unterstützt. Wenn eine dieser Anforderungen Benutzereigenschaften enthält, schlägt die Anforderung fehl.
• Wenn der Server ein PUBACK-Paket von einem Client mit einem nicht erfolgreichen Antwortcode empfängt, wird die Verbindung beendet.
• Das Keepalive-Maximum beträgt 1.160 Sekunden.

Aktuelle Einschränkungen von MQTTv3.1.1

MQTT v5 unterscheidet sich derzeit in folgenden Punkten von der MQTT v3.1.1-Spezifikation:

• QoS 2 wird nicht unterstützt. Eine Veröffentlichungsanforderung mit einem RETAIN-Flag oder QoS2 schlägt fehl und schließt die Verbindung.
• Das Keepalive-Maximum beträgt 1.160 Sekunden.

Codebeispiele

Dieses Repository enthält Codebeispiele in C#, C und Python, die zeigen, wie Telemetriedaten und Befehle gesendet sowie Warnungen übertragen werden. Die über die Beispiele erstellten Zertifikate sind für Tests geeignet, eignen sich jedoch nicht für Produktionsumgebungen.

Verwandte Inhalte

Weitere Informationen zu MQTT finden Sie in der MQTT v5-Spezifikation. Weitere Informationen zum MQTT-Broker finden Sie unter:

• Clientauthentifizierung
• Einrichten mehrerer Sitzungen für einen einzelnen Client