MQTT-Tutorial

MQTT verstehen: den Weg einer Nachricht von Ende zu Ende verfolgen

Verbinden Sie einen Client, veröffentlichen Sie Telemetrie, abonnieren Sie ein Topic und machen Sie das Design anschließend mit bewussten Entscheidungen zu QoS, Sitzungen, Retain-Nachrichten und Sicherheit produktionsbereit.

Öffnen Sie den Leitfaden für öffentliche Broker Lesen Sie den Sicherheitsleitfaden

Das Modell

MQTT in vier Konzepten

MQTT hält Clients schlank, indem Verbindungsverwaltung, Topic-Matching und Zustellungskoordination in den Broker verlagert werden.

Broker

Nimmt Client-Verbindungen an, wertet Subscriptions aus und leitet jede Publish-Nachricht an passende Subscriber weiter.

Client

Jeder Sensor, jedes Gateway, jeder Dienst, jeder Browser oder jede Anwendung, die eine Verbindung herstellt, veröffentlicht, abonniert oder alle drei Funktionen ausführt.

Topic

Ein hierarchischer Pfad wie factory/line-1/motor-7/temperature, der Publisher und Subscriber voneinander entkoppelt.

Nachricht

Eine Payload mit Zustelloptionen wie QoS, Retain, Ablaufzeit und MQTT-5-Eigenschaften.

Erster Arbeitsablauf

Veröffentlichen und empfangen Sie Ihre erste Nachricht

Verwenden Sie zwei Terminals, damit Sie sehen können, wie der Broker den Veröffentlichungsclient vom Abonnenten entkoppelt.

01
Starten Sie den Abonnenten
Stellen Sie die Verbindung mit einer eindeutigen Client-ID her und abonnieren Sie das Topic vor dem Publish, damit die erste Live-Nachricht sichtbar ist.
02
Telemetriedaten veröffentlichen
Senden Sie mit demselben Broker und passenden Zugangsdaten eine kleine JSON-Payload exakt an dieses Topic.
03
Lieferung überprüfen
Prüfen Sie Topic, Payload, QoS, Zeitstempel und Client-Identität, bevor Sie Wildcards oder Retained Messages hinzufügen.

Terminal 1 · Abonnieren

mosquitto_sub \
  -h "$MQTT_HOST" -p 8883 \
  -u "$MQTT_USERNAME" -P "$MQTT_PASSWORD" \
  -i "tutorial-sub-01" \
  -t "factory/line-1/motor-7/telemetry" \
  -q 1 -v

Terminal 2 · Veröffentlichen

mosquitto_pub \
  -h "$MQTT_HOST" -p 8883 \
  -u "$MQTT_USERNAME" -P "$MQTT_PASSWORD" \
  -i "tutorial-pub-01" \
  -t "factory/line-1/motor-7/telemetry" \
  -q 1 \
  -m '{"temperature":61.8,"vibration":2.1}'

Liefersemantik

Wählen Sie QoS aus der Geschäftskonsequenz

Eine höhere QoS-Stufe erfordert zusätzliche Handshakes und mehr Zustand. Dadurch wird die Anwendung nicht automatisch korrekt.

QoS-Ebene
QoS-Ebene	Lieferung	Geeignet für	Abwägung
QoS 0	Höchstens einmal; keine Bestätigung	Häufige Telemetrie, bei der der nächste Messwert den letzten ersetzt	Geringster Overhead, aber Verlust ist möglich
QoS 1	Mindestens einmal; Duplikate sind möglich	Zustandsänderungen, Warnungen und Befehle mit idempotenten Consumern	Bestätigung und Deduplizierung sind erforderlich
QoS 2	Genau einmal auf der Protokollebene MQTT	Seltene Arbeitsabläufe mit einer genau einmal gemessenen Anforderung	Vierteiliger Handshake, mehr Status und mehr Latenz

Topic-Vertrag

Topics für Eigentum und Autorisierung gestalten

Ein Topic-Baum wird zu einem API. Sorgen Sie für Stabilität, dokumentieren Sie jede Ebene und machen Sie die Berechtigungsgrenzen deutlich.

Eine vorhersehbare Topic-Hierarchie

factory/{site}/{line}/{device}/{channel}

factory/shanghai/line-1/motor-7/telemetry
factory/shanghai/line-1/motor-7/state
factory/shanghai/line-1/motor-7/command

# Subscribe to telemetry from one line
factory/shanghai/line-1/+/telemetry

# Reserve broad multi-level subscriptions for trusted services
factory/shanghai/#

Verwenden Sie stabile Identifikatoren und speichern Sie Anzeigenamen in der Payload.

Separate Telemetrie-, Status- und Befehlsrichtungen.

Platzieren Sie niemals Geheimnisse oder persönliche Daten in Topic-Namen.

Gewähren Sie Wildcard-Zugriff nur dort, wo die Geräterolle dies erfordert.

Versionsverträge absichtlich brechen, statt Ad-hoc umzubenennen.

Payload-Schema, Einheiten, Frequenz, QoS und Zuständigkeit dokumentieren.

Produktionskontrolle

Wechseln Sie von einer erfolgreichen Demo zu einem zuverlässigen System

Eine Identität pro Gerät

Eindeutige Anmeldeinformationen machen Sperrung, Rotation, Prüfung und Vorfallumfang verwaltbar.

Bewusst konfigurierte Sessions

Wählen Sie Sitzungsablauf, Keepalive, Reconnect-Backoff und Offline-Warteschlangen passend zum erwarteten Netzwerkverhalten.

Gemessene Kapazität

Führen Sie Lasttests für Verbindungen, Subscriptions, Fan-out, Payload-Größe, Retained Messages und Reconnect-Stürme durch.

Nachvollziehbarer Betrieb

Verfolgen Sie Verbindungsfehler, Autorisierungsverweigerungen, Warteschlangentiefe, Übermittlungslatenz und Änderungen der Anmeldeinformationen.

Häufig gestellte Fragen zum MQTT-Tutorial

Funktioniert MQTT ohne Broker?

Das standardmäßige MQTT-Publish-Subscribe-Modell verwendet einen Broker, um Verbindungen zu akzeptieren, Topics abzugleichen und Nachrichten zuzustellen. Clients entdecken einander nicht oder leiten sie nicht direkt aneinander weiter.

Welchen MQTT QoS sollte ich zuerst wählen?

Beginnen Sie mit QoS 0 für häufig austauschbare Telemetrie und QoS 1 für Statusänderungen oder Befehle, die eintreffen müssen. Verwenden Sie QoS 2 erst, nachdem Sie die Kosten gemessen und eine genau einmalige Anforderung nachgewiesen haben.

Ist eine aufbewahrte Nachricht dasselbe wie der Nachrichtenverlauf?

Nein. Eine Retained Message speichert für neue Subscriber nur den letzten beibehaltenen Wert eines Topics. Verwenden Sie eine Datenbank oder einen Stream-Speicher, wenn Consumer Verlauf, Abfragen oder Replay benötigen.

Wofür werden die Ports 1883 und 8883 verwendet?

Port 1883 überträgt normalerweise einfach MQTT über TCP. Port 8883 überträgt üblicherweise MQTT über TLS. Produktionsclients sollten Zertifikate validieren und verschlüsselten Transport verwenden.

Lernen Sie weiter

Nutzen Sie die öffentliche Sandbox für einmalige Tests und vertiefen Sie dann die Sicherheits- und Architekturentscheidungen, die in der Produktion wichtig sind.