MQTT-Control-Pakete sind die 15 Nachrichtentypen, die Clients und Broker austauschen, von CONNECT bis AUTH, und jede MQTT-Interaktion setzt sich aus ihnen zusammen. Diese Referenz erklärt, was jedes Paket tut, wer es sendet, wie Sie es an seinem ersten Byte erkennen und wie es in Client-Debug-Logs aussieht. So können Sie eine Unterhaltung mit einem Broker verfolgen und genau bestimmen, wo sie schiefläuft, ob beim Sensor-Prototyp auf dem Schreibtisch oder beim Edge-Gateway, das Maschinendaten aus einer SPS in die Cloud überträgt.
MQTT-Control-Pakete im Überblick
Der Pakettyp steht in den oberen vier Bits des ersten Bytes jedes Pakets. MQTT 3.1.1 definiert die Typen 1 bis 14; MQTT 5 ergänzt Typ 15, AUTH. Typ 0 ist reserviert und nie gültig.
| Typ | Name | Richtung | Erstes Byte | Zweck |
|---|---|---|---|---|
| 1 | CONNECT | Client zum Broker | 0x10 | Session öffnen |
| 2 | CONNACK | Broker zum Client | 0x20 | Verbindung annehmen oder ablehnen |
| 3 | PUBLISH | Beide | 0x30-0x3F | Anwendungsnachricht zustellen |
| 4 | PUBACK | Beide | 0x40 | QoS-1-Publish bestätigen |
| 5 | PUBREC | Beide | 0x50 | QoS 2 Schritt 1: Publish empfangen |
| 6 | PUBREL | Beide | 0x62 | QoS 2 Schritt 2: Freigabe |
| 7 | PUBCOMP | Beide | 0x70 | QoS 2 Schritt 3: abgeschlossen |
| 8 | SUBSCRIBE | Client zum Broker | 0x82 | Subscriptions anfordern |
| 9 | SUBACK | Broker zum Client | 0x90 | Subscriptions gewähren oder ablehnen |
| 10 | UNSUBSCRIBE | Client zum Broker | 0xA2 | Subscriptions entfernen |
| 11 | UNSUBACK | Broker zum Client | 0xB0 | Unsubscribe bestätigen |
| 12 | PINGREQ | Client zum Broker | 0xC0 | Keep-Alive-Anfrage |
| 13 | PINGRESP | Broker zum Client | 0xD0 | Keep-Alive-Antwort |
| 14 | DISCONNECT | Client zum Broker (in MQTT 5 beide) | 0xE0 | Verbindung sauber schließen |
| 15 | AUTH | Beide (nur MQTT 5) | 0xF0 | Austausch bei erweiterter Authentifizierung |
Das erste Byte zu kennen ist praktisch, wenn Sie einen rohen Hex-Dump lesen: 0xC0 0x00 ist ein PINGREQ, 0x82 leitet ein SUBSCRIBE ein. Den Aufbau von Headern und Payloads auf Byte-Ebene behandelt der Leitfaden zur MQTT-Paketstruktur.
Control-Pakete im Debug-Log beobachten
Am einfachsten sehen Sie diese Pakete mit dem Flag -d der Mosquitto-Clients. Gegen den öffentlichen MQTT-Broker:
mosquitto_sub -h broker.connectmq.com -p 1883 -i pkt-demo-e41f \
-t "connectmq/demo/e41f/#" -q 1 -k 10 -d
Veröffentlichen Sie in einem zweiten Terminal eine Nachricht:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pkt-pub-e41f \
-t "connectmq/demo/e41f/temp" -m "22.1" -q 1 -d
Die Ausgabe des Subscribers sieht etwa so aus:
Client pkt-demo-e41f sending CONNECT
Client pkt-demo-e41f received CONNACK (0)
Client pkt-demo-e41f sending SUBSCRIBE (Mid: 1, Topic: connectmq/demo/e41f/#, QoS: 1, Options: 0x00)
Client pkt-demo-e41f received SUBACK
Subscribed (mid: 1): 1
Client pkt-demo-e41f received PUBLISH (d0, q1, r0, m1, 'connectmq/demo/e41f/temp', ... (4 bytes))
Client pkt-demo-e41f sending PUBACK (m1, rc0)
22.1
Client pkt-demo-e41f sending PINGREQ
Client pkt-demo-e41f received PINGRESP
Durch den Keep Alive -k 10 erscheint PINGREQ nach zehn Sekunden Inaktivität. In der PUBLISH-Zeile bedeutet d0, q1, r0, m1 DUP 0, QoS 1, Retain 0 und Message ID 1. Paho Python gibt mit client.enable_logger() ähnliche Zeilen aus, MQTT.js mit der Umgebungsvariablen DEBUG=mqttjs*.
Verbindungspakete: CONNECT, CONNACK, DISCONNECT
CONNECT ist immer das erste Paket, das ein Client sendet. Es enthält Protokollversion, Clean-Session- bzw. Clean-Start-Flag, Keep Alive, Client ID, optional einen Last Will sowie optional Benutzername und Passwort. In MQTT 5 trägt es außerdem Properties wie Session Expiry Interval, Receive Maximum und Topic Alias Maximum. Ein zweites CONNECT auf derselben Verbindung ist ein Protokollfehler.
CONNACK ist die Antwort des Brokers. Es enthält das Flag Session Present und einen Rückgabecode (3.1.1) bzw. Reason Code (MQTT 5). MQTT-5-Broker nutzen CONNACK-Properties zudem, um dem Client ihre Limits mitzuteilen: Maximum QoS, Maximum Packet Size, Topic Alias Maximum, ob Retain, Wildcards oder Shared Subscriptions verfügbar sind, und eine zugewiesene Client ID, falls der Client eine leere gesendet hat. Schlägt eine Verbindung fehl, ist CONNACK die erste Anlaufstelle; siehe MQTT-CONNACK-Rückgabecodes.
DISCONNECT schließt die Verbindung sauber. Ein Client, der vor dem Schließen des Sockets DISCONNECT sendet, unterdrückt seine Last-Will-Nachricht (außer in MQTT 5 mit Reason Code 0x04). In MQTT 3.1.1 sendet nur der Client DISCONNECT; in MQTT 5 kann auch der Broker eines senden, mit einem Reason Code, der den Grund erklärt, etwa 0x8E Session taken over oder 0x97 Quota exceeded. Sehen Sie eine Reconnect-Schleife, achten Sie auf vom Broker gesendete DISCONNECTs; der Leitfaden dazu, warum ein MQTT-Client ständig die Verbindung trennt, geht die Ursachen durch.
Publish-Pakete: PUBLISH und die Bestätigungen
PUBLISH überträgt die Anwendungsnachricht in beide Richtungen: vom Client zum Broker, wenn Sie veröffentlichen, vom Broker zum Client, wenn Sie empfangen. Die Flags im Fixed Header enthalten DUP, QoS und RETAIN.
Die Bestätigungen hängen vom QoS ab, ausführlich erklärt unter MQTT-QoS-Stufen:
| QoS | Paketablauf | Pakete pro Nachricht insgesamt |
|---|---|---|
| 0 | PUBLISH | 1 |
| 1 | PUBLISH, PUBACK | 2 |
| 2 | PUBLISH, PUBREC, PUBREL, PUBCOMP | 4 |
- PUBACK bestätigt eine QoS-1-Nachricht. Bis es eintrifft, behält der Sender die Nachricht und kann sie nach einem Reconnect mit gesetztem DUP erneut senden.
- PUBREC ist das „Ich habe sie“ des Empfängers bei QoS 2. Der Sender kann den Payload der Nachricht jetzt verwerfen.
- PUBREL teilt dem Empfänger mit, dass er die Nachricht an Subscriber freigeben darf und die Packet ID bald wiederverwendet werden kann.
- PUBCOMP schließt den QoS-2-Austausch ab.
Beachten Sie, dass jede Teilstrecke unabhängig ist. Ein QoS-1-Publish von einem Sensor zum Broker und eine QoS-2-Zustellung vom Broker an einen Subscriber, etwa ein MES, sind getrennte Austausche. In MQTT 5 tragen diese Bestätigungen Reason Codes, sodass PUBACK zum Beispiel 0x10 No matching subscribers oder 0x87 Not authorized melden kann.
Subscription-Pakete: SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK
SUBSCRIBE enthält einen Packet Identifier und einen oder mehrere Topic-Filter, jeweils mit angefordertem QoS. MQTT 5 ergänzt Subscription-Optionen wie No Local, Retain As Published und Retain Handling sowie einen optionalen Subscription Identifier.
SUBACK liefert pro Filter einen Code in derselben Reihenfolge zurück. Lesen Sie jeden Eintrag: Ein einzelnes SUBSCRIBE mit drei Filtern kann für zwei erfolgreich sein und für einen scheitern. In 3.1.1 lautet der Fehlerwert 0x80; MQTT 5 liefert konkrete Gründe wie 0x8F Topic Filter invalid oder 0x9E Shared Subscriptions not supported.
UNSUBSCRIBE und UNSUBACK spiegeln das für das Entfernen wider. MQTT 5 ergänzt UNSUBACK um Reason Codes pro Filter, darunter 0x11 No subscription existed.
Keep-Alive-Pakete: PINGREQ und PINGRESP
PINGREQ und PINGRESP sind Pakete von zwei Byte, die belegen, dass die Verbindung lebt, wenn kein anderer Verkehr fließt. Der Client sendet PINGREQ, wenn er innerhalb des Keep-Alive-Intervalls nichts gesendet hat; der Broker muss mit PINGRESP antworten. Hört der Broker für das 1,5-Fache des Keep Alive nichts, schließt er die Verbindung. Erhält der Client nicht in angemessener Zeit ein PINGRESP, sollte er die Verbindung als tot betrachten. Der Leitfaden zum MQTT-Keep-Alive-Intervall erklärt, wie Sie den Wert wählen.
AUTH: Die Ergänzung in MQTT 5
AUTH unterstützt erweiterte Authentifizierung, etwa Challenge-Response-Verfahren, über die Properties Authentication Method und Authentication Data. Es wird nach CONNECT für mehrstufige Austausche verwendet und kann auch eine erneute Authentifizierung auf einer bestehenden Verbindung starten. Die meisten Deployments, einschließlich Anmeldungen mit Benutzername und Passwort, senden nie AUTH. Es in einem Mitschnitt zu sehen ist daher ungewöhnlich, sofern Sie keine erweiterte Methode konfiguriert haben.
Debugging-Checkliste nach Paket
- Kein CONNACK? Das Problem liegt bei Netzwerk, Port oder TLS, nicht bei MQTT.
- CONNACK mit einem Code ungleich null? Zugangsdaten, Client ID oder Protokollversion.
- SUBACK mit 0x80 oder höher? Fehlerhafter Filter, fehlende Berechtigung oder nicht unterstützte Funktion.
- PUBLISH gesendet, aber kein PUBACK? QoS-Unterstützung und Verbindungsstatus prüfen.
- Wiederholte PINGREQ ohne PINGRESP? Die Verbindung ist halb tot; neu verbinden.
- Unerwartetes DISCONNECT vom Broker? Lesen Sie dessen Reason Code.
Jedes Paket bei ConnectMQ sehen
ConnectMQ unterstützt MQTT 3.1.1 und 5.0, sodass Sie sowohl den klassischen Paketablauf als auch MQTT-5-Reason-Codes und -Properties gegen denselben Broker beobachten können. Für das Gesamtbild lesen Sie, was ein MQTT-Broker mit diesen Paketen macht, oder folgen Sie dem vollständigen MQTT-Tutorial.
Auf ConnectMQ aufbauen
Wenn Sie von Experimenten zu Geräten übergehen, kümmert sich ein verwalteter MQTT-Broker um TLS, Zugangsdaten und Verfügbarkeit. Erstellen Sie unter app.connectmq.com ohne Kreditkarte einen kostenlosen Serverless-Broker und nutzen Sie beim Debuggen den browserbasierten Client und den Live-Topic-Explorer des Portals. Sie können die Optionen auch in unserem Leitfaden zum Markt für Cloud-MQTT-Broker vergleichen.
Häufig gestellte Fragen
Wie viele MQTT-Control-Pakettypen gibt es?
MQTT 5 definiert 15 Control-Pakettypen, nummeriert von 1 bis 15. MQTT 3.1.1 hat 14, weil das AUTH-Paket erst mit MQTT 5 hinzukam.
Welche Pakete verwendet eine QoS-2-Nachricht?
PUBLISH, PUBREC, PUBREL und PUBCOMP. Der vierstufige Handshake stellt sicher, dass die Nachricht zwischen diesem Sender und Empfänger genau einmal zugestellt wird.
Kann der Broker ein DISCONNECT-Paket senden?
Nur in MQTT 5. In MQTT 3.1.1 schließt der Broker einfach die Netzwerkverbindung; MQTT 5 erlaubt ihm, vorher ein DISCONNECT mit Reason Code zu senden.
Warum sehe ich PINGREQ in meinen Logs?
PINGREQ ist die Keep-Alive-Anfrage des Clients, die gesendet wird, wenn er für die Dauer des Keep-Alive-Intervalls inaktiv war. Regelmäßige Paare aus PINGREQ und PINGRESP sind normal und zeigen, dass die Verbindung gesund ist.
