IoT-Protokolle: MQTT & CoAP#

Das Internet of Things (IoT) vernetzt Sensoren, Aktoren und eingebettete Geräte über das Netzwerk. Weil diese Geräte oft nur wenig Rechenleistung, Speicher und Akkukapazität haben, kommen dafür speziell leichtgewichtige Protokolle wie MQTT und CoAP zum Einsatz statt klassischer, overhead-lastiger Protokolle wie HTTP.

Typische IoT-Architektur#

Ein IoT-System besteht meist aus drei Ebenen: Endgeräte erfassen oder steuern die physische Welt, ein Gateway bündelt und übersetzt die Kommunikation, und im Backend werden Daten verarbeitet und gespeichert.

flowchart LR
    S["Sensor / Aktor\n(z.B. Temperaturfühler)"] --> G["Gateway\n(bündelt, übersetzt Protokolle)"]
    G --> C["Cloud / Backend\n(Datenverarbeitung, Speicherung)"]
    C --> D["Dashboard / App\n(Auswertung, Steuerung)"]
    C -.->|Steuerbefehl| G
    G -.->|Steuerbefehl| S

Warum leichtgewichtige Protokolle?#

Klassische Protokolle wie HTTP sind für IoT-Geräte oft ungeeignet:

Begrenzte Akkulaufzeit — jedes gesendete Byte und jede offene Verbindung kostet Energie
Geringe Bandbreite — viele IoT-Geräte funken über schmalbandige Funktechnik
Wenig Rechenleistung/Speicher — Mikrocontroller können komplexe Protokoll-Stacks oft nicht verarbeiten
Große Geräteanzahl — ein Server muss ggf. tausende gleichzeitige Verbindungen handhaben

MQTT — Message Queuing Telemetry Transport#

MQTT ist ein Publish/Subscribe-Protokoll: Geräte senden (publizieren) Nachrichten nicht direkt an einen Empfänger, sondern an einen zentralen Broker, der sie an alle interessierten Abonnenten verteilt. Sender und Empfänger kennen sich dabei nicht — sie sind über den Broker entkoppelt.

flowchart LR
    Sensor["Sensor\n(Publisher)"] -->|"PUBLISH\nTopic: haus/wohnzimmer/temperatur"| Broker["MQTT-Broker"]
    Broker -->|"Nachricht weiterleiten"| App["Smartphone-App\n(Subscriber)"]
    Broker -->|"Nachricht weiterleiten"| Log["Logging-Server\n(Subscriber)"]
    App -.->|"SUBSCRIBE\nhaus/wohnzimmer/temperatur"| Broker
    Log -.->|"SUBSCRIBE\nhaus/#"| Broker

Grundbegriffe#

Begriff	Bedeutung
Broker	Zentraler Vermittler, nimmt Nachrichten entgegen und verteilt sie
Topic	Hierarchischer „Kanalname" (z.B. `haus/wohnzimmer/temperatur`), an den publiziert/abonniert wird
Publisher	Sendet Nachrichten zu einem Topic
Subscriber	Abonniert ein Topic und empfängt dessen Nachrichten
Wildcard	`+` (eine Ebene) oder `#` (alle Unterebenen) zum Abonnieren mehrerer Topics gleichzeitig

Quality-of-Service-Level (QoS)#

MQTT bietet drei Zustellgarantien, die zwischen Zuverlässigkeit und Overhead abwägen:

QoS	Garantie	Einsatz
0	Höchstens einmal (fire and forget)	Häufige, unkritische Messwerte (z.B. Sekundentakt-Temperatur)
1	Mindestens einmal (Duplikate möglich)	Wichtige Ereignisse, bei denen Duplikate tolerierbar sind
2	Genau einmal (höchster Overhead)	Kritische Befehle (z.B. Türschloss öffnen)

MQTT läuft über TCP, Standardport 1883 (unverschlüsselt) bzw. 8883 (TLS-verschlüsselt).

CoAP — Constrained Application Protocol#

CoAP ist ein REST-ähnliches Protokoll für stark ressourcenbeschränkte Geräte. Es verwendet dieselben Methoden wie HTTP (GET, POST, PUT, DELETE), läuft aber über UDP statt TCP, um Verbindungsaufbau-Overhead zu vermeiden. Ein optionaler Bestätigungsmechanismus (Confirmable Messages) sorgt trotzdem für Zuverlässigkeit, wo nötig.

RESTful: Ressourcen werden über URIs angesprochen, z.B. coap://sensor.lokal/temperatur
UDP-basiert: geringerer Overhead und Energiebedarf als TCP
Client/Server statt Publish/Subscribe: Geräte werden direkt angefragt (es gibt aber Erweiterungen für Observe/Publish-Muster)
Standardport 5683 (unverschlüsselt), 5684 (mit DTLS-Verschlüsselung)

Vergleich: MQTT vs. CoAP vs. HTTP#

	MQTT	CoAP	HTTP
Transport	TCP	UDP	TCP
Kommunikationsmodell	Publish/Subscribe	Request/Response (RESTful)	Request/Response
Overhead	Gering	Sehr gering	Hoch
Typischer Einsatz	Viele Sensoren melden an zentrale Stelle	Direkte Geräteabfrage/-steuerung	Web-/Cloud-Anwendungen
Energieeffizienz	Gut	Sehr gut	Schlecht (für Constrained Devices)
Verschlüsselung	TLS (Port 8883)	DTLS (Port 5684)	TLS (HTTPS)

Prüfungsbeispiele#

„Ein Sensor soll seine Messwerte an mehrere Empfänger gleichzeitig verteilen, ohne die Empfänger zu kennen. Welches Protokollmodell eignet sich?"

→ MQTT mit seinem Publish/Subscribe-Modell — der Sensor publiziert nur an ein Topic, der Broker verteilt die Nachricht an alle Abonnenten, ohne dass Sender und Empfänger sich kennen müssen.

„Warum wird für viele IoT-Geräte UDP statt TCP bevorzugt?"

→ UDP spart den Verbindungsaufbau (Handshake) und laufenden Verbindungs-Overhead von TCP — das schont Energie und Bandbreite auf stark ressourcenbeschränkten Geräten. CoAP nutzt deshalb UDP, ergänzt aber optional eigene Bestätigungsmechanismen für Zuverlässigkeit.

„Ein Smart-Home-Türschloss soll einen Öffnungsbefehl garantiert genau einmal erhalten. Welches MQTT-QoS-Level ist passend?"

→ QoS 2 („genau einmal") — verhindert sowohl Nachrichtenverlust als auch doppelte Ausführung des kritischen Befehls, auf Kosten von mehr Protokoll-Overhead.

Quiz#

❓ Welches Kommunikationsmodell verwendet MQTT?

❓ Welches MQTT-QoS-Level garantiert, dass eine Nachricht genau einmal zugestellt wird?

❓ Über welches Transportprotokoll läuft CoAP, und warum?

❓ Welche Standardports nutzen MQTT (unverschlüsselt/TLS) und CoAP (unverschlüsselt/DTLS)?

Siehe auch#

embedded systeme — die Geräte, die IoT-Protokolle typischerweise sprechen
protokolle ports — vollständige Protokoll- und Portübersicht inkl. MQTT/CoAP
tcp ip — TCP vs. UDP im Detail
verschluesselung — TLS/DTLS als Verschlüsselung für MQTT/CoAP