MQTT und seine Alternativen: Eine technikhistorische und praktische Einordnung der IoT-Kommunikationsprotokolle

Autor: DerSchneider

Einleitung

Das Internet der Dinge (IoT) ist längst aus den Labors in den industriellen und privaten Alltag gewandert. Millionen von Sensoren, Aktoren und Geräten tauschen kontinuierlich Nachrichten aus. Doch hinter dieser schier endlosen Datenflut steht eine unsichtbare, aber entscheidende Komponente: das Kommunikationsprotokoll. Seit gut einem Jahrzehnt hat sich MQTT (Message Queuing Telemetry Transport) als eine Art Standard für ressourcenbeschränkte IoT-Geräte etabliert. Doch es ist nicht das einzige Pferd im Stall. CoAP, AMQP, DDS und selbst HTTP/2 buhlen um die Gunst der Entwickler und Systemarchitekten.

Dieser Artikel beleuchtet MQTT in seiner historischen Entwicklung, stellt die wichtigsten Alternativen gegenüber und hilft bei der Frage: Welches Protokoll passt zu welchem Szenario? Dabei geht es nicht um eine simple Bestenliste, sondern um eine differenzierte Betrachtung von Eigenschaften, Kompromissen und Einsatzdomänen.

Hauptteil

1. MQTT – Der Pionier der schmalen Pfade

1.1 Historische Wurzeln

Entwickelt in den späten 1990er Jahren von IBM-Mitarbeitern Andy Stanford-Clark und Arlen Nipper, sollte MQTT ursprünglich die Fernüberwachung von Ölpipelines ermöglichen. Die Herausforderung bestand darin, über satellitenbasierte Verbindungen mit extrem geringer Bandbreite und hoher Latenz sowie unzuverlässigen Verbindungen Daten zu übertragen. Das Ergebnis war ein extrem leichtgewichtiges Protokoll mit minimalem Overhead (Header ab 2 Byte) und drei Qualitätsdienst-Stufen (QoS 0–2).

2014 wurde MQTT als OASIS-Standard veröffentlicht, 2019 folgte die ISO/IEC 20922-Normierung. Die Version 3.1.1 ist bis heute die am weitesten verbreitete, während Version 5 (2019) Erweiterungen wie Reason Codes, Shared Subscriptions und Message Expiry einführte – ohne jedoch den schlanken Kern aufzublähen.

1.2 Technisches Prinzip

MQTT nutzt ein Publish-Subscribe-Modell mit einem zentralen Broker. Publisher senden Nachrichten an thematische Adressen (Topics, z.B. fabrik/halle3/temperatur). Subscriber drücken ihr Interesse an bestimmten Topics aus, der Broker leitet die Nachrichten weiter. Diese Entkopplung von Sender und Empfänger erlaubt eine dynamische, skalierbare Architektur.

1.3 Schwächen im Fokus

• Broker als Flaschenhals und Singel Point of Failure (durch Clustering beherrschbar)
• Keine nativen Multicast-Fähigkeiten – jeder Client benötigt eigene Verbindung
• TCP-basiert → Nachteile bei extrem instabilen Funkstrecken (Long Fat Networks)
• Niedrige Effizienz bei sehr kleinen Nutzlasten (< 10 Byte) durch TCP-Header

Trotzdem: MQTT bleibt die erste Wahl für geschätzte 70–80 % aller typischen IoT-Projekte – von Smart Home über Telematik bis zur Fabrikautomation.

2. Die Alternativen im Vergleich

Kein Protokoll ist für alle Anwendungsfälle ideal. Die folgende Tabelle gibt einen schnellen Überblick über die wichtigsten Kandidaten, sortiert nach ihrer „Ressourcenfreundlichkeit“:

2.1 CoAP – Für die allerkleinsten Knoten

Das Constrained Application Protocol (RFC 7252) wurde von der IETF speziell für Geräte mit wenigen Kilobyte RAM und extrem niedrigem Energiebudget entworfen. Es läuft über UDP, was Verbindungsaufbau und Keep-Alive spart. Dank Multicast-Unterstützung eignet es sich hervorragend für Gruppensteuerungen (z.B. ein Befehl „Licht aus!“ an alle Lampen in einem Raum).

Eine oft übersehene Stärke ist die einfache Übersetzung zu HTTP über Cross-Proxy – REST-Entwickler fühlen sich sofort zu Hause. Nachteil: Das optionale „Observe“-Pattern für Publish/Subscribe ist weniger ausgereift als MQTTs natives Modell.

Historischer Einschub: CoAP entstand parallel zu MQTT, aber aus einer anderen Denkschule – der IETF-Arbeitsgruppe für eingebettete Webdienste. Während MQTT aus der Industrie kam, war CoAP akademischer und netzwerknäher.

2.2 AMQP – Der Schwergewichts-Champion

Das Advanced Message Queuing Protocol ist das Gegenteil eines minimalistischen Protokolls. Es bietet Transaktionen, persistente Queues, komplexe Routing-Topologien (Direct, Fanout, Topic, Header) und eine detaillierte Sicherheitsarchitektur über SASL. Das macht es zur ersten Wahl, wenn IoT-Daten nahtlos in Unternehmens-IT (ERP, Banking, Logistik) fließen müssen.

Allerdings erkauft man sich diese Mächtigkeit mit einem hohen Ressourcenverbrauch und einer steilen Lernkurve. Auf einem 8‑Bit-Mikrocontroller mit 2 KB RAM ist AMQP undenkbar. Auf einem Industrie-PC oder in der Cloud hingegen eine ausgezeichnete Wahl.

2.3 DDS – Für Echtzeit ohne Kompromisse

Das Data Distribution Service (standardisiert durch die OMG) ist unter Ingenieuren von autonomen Fahrzeugen, militärischen Drohnen und medizinischen Robotern bekannt. DDS kommt völlig ohne Broker aus: Jeder Peer kommuniziert direkt (via UDP-Multicast oder TCP-Point-to-Point) mit allen anderen, die an denselben Topics interessiert sind. Ein globaler „Data Space“ sorgt für Entdeckung und Verbindungsmanagement.

Mit 23 QoS-Policies (z.B. Deadline, LatencyBudget, TimeBasedFilter) bietet DDS eine Kontrolle, die MQTT und CoAP nicht einmal annähernd erreichen. Der Preis: Komplexität und ein erheblicher Speicherfußabdruck (mehrere Megabyte). DDS ist nichts für batteriebetriebene Sensoren, aber die erste Wahl für Systeme, bei denen Kontrollverlust Menschenleben kosten könnte.

2.4 HTTP/2 mit Server-Sent Events – Der Web-Weg

HTTP ist allgegenwärtig, und mit HTTP/2 (Header-Kompression, Multiplexing, Server-Push) ist es gar nicht mehr so ineffizient. Server-Sent Events (SSE) bieten einen Einweg-Push vom Server zum Client. Für reine Überwachungsdashboards im Browser ist das eine elegante Lösung – kein zusätzlicher Broker, keine speziellen Ports, reine Web-Standards.

Allerdings fehlt ein QoS-Mechanismus, und die native Unterstützung für dauerhafte Verbindungen ist begrenzt. Hybridansätze mit MQTT over WebSocket sind oft die bessere Wahl, wenn beide Richtungen benötigt werden.

3. Kontroversen und offene Fragen

3.1 Der unbewältigte Skalenbruch

Viele Diskussionen in Fachforen drehen sich um die Frage: „Ist MQTT für große Industrie-4.0-Projekte mit >100.000 Geräten geeignet?“ Die Antwort ist differenziert. Ja, mit leistungsfähigen Brokern wie EMQX oder HiveMQ, die Clustering und persistente Sessions beherrschen. Nein, wenn die Geräte über extrem schwankende Mobilfunknetze (NB-IoT, LTE-M) verbunden sind – hier können lange TCP-Timeouts und Keep-Alive-Timer die Batterien leersaugen. Genau an dieser Stelle wird CoAP über UDP wieder interessant.

3.2 Security-Theater

MQTT erlaubt Username/Password in Klartext (nur verschlüsselt über TLS), aber viele Projekte nutzen aus Kostengründen unverschlüsselte Verbindungen. Das ist fahrlässig. Die Alternative CoAP mit DTLS ist kryptografisch ähnlich sicher, verursacht aber ebenfalls einen Handshake-Overhead. DDS verfügt über eine eigene Security-Modell (DDS-Security), das die kryptografische Absicherung einzelner Topics erlaubt – ein Alleinstellungsmerkmal.

Die anhaltende Kontroverse um das „Provisioning“ von Gerätezertifikaten ist ungelöst. In der Praxis werden oft Hersteller-CAs missbraucht oder fest verdrahtete Secrets ausgeliefert – ein sicherheitstechnischer Albtraum.

4. Zukünftige Implikationen

4.1 MQTT 5.1 unterwegs

Die nächste Iteration von MQTT (inoffiziell 5.1) wird voraussichtlich verbesserte Fehlercodes und eine noch effizientere Session-Verwaltung bringen. Größere Änderungen sind nicht zu erwarten – das Protokoll ist erwachsen.

4.2 CoAP over QUIC

Mit QUIC als moderne UDP-Alternative (von Google/ IETF) könnte CoAP einen deutlichen Leistungssprung machen: schnellerer Verbindungsaufbau, integrierte Verschlüsselung, keine Head-of-Line-Blocking. Erste Experimente zeigen vielversprechende Ergebnisse für mobile IoT-Anwendungen.

4.3 Die Rückkehr des Brokers? – Zenoh

Eine relativ neue Entwicklung ist Zenoh (Eclipse Foundation), das als „Zero Overhead Network Protocol“ MQTT, CoAP, DDS und andere in einer einheitlichen, brokergestützten oder brokerlosen Architektur vereinen will. Ob es sich durchsetzt, bleibt abzuwarten – aber der Trend geht klar zu heterogenen, protokollübergreifenden Middlewares.

4.4 Industrieller Praxis-Trend: Gateway-Architekturen

In der Praxis zeichnet sich ab, dass kein einzelnes Protokoll alle Anforderungen erfüllt. Kluge Architekturen setzen auf Gateways, die im Feld mit CoAP oder LoRaWAN kommunizieren und nach außen MQTT oder AMQP sprechen. Azure IoT Edge, AWS Greengrass und Eclipse Hono sind Beispiele für diese mehrschichtige Strategie.

Fazit und Ausblick

MQTT hat sich seinen Platz in der IoT-Welt redlich verdient. Es ist nicht perfekt, aber für die allermeisten Anwendungsfälle gut genug, ausgereift und breit unterstützt. Wer jedoch an die Grenzen stößt – sei es durch extreme Ressourcenknappheit, Echtzeitanforderungen oder komplexe Enterprise-Integration – sollte CoAP, DDS oder AMQP als ernsthafte Alternativen prüfen.

Die Zukunft gehört nicht einem einzigen Protokoll, sondern einem intelligenten Zusammenspiel mehrerer. Der Technologiehistoriker wird eines Tages vielleicht die Jahre 2020 bis 2030 als die „Phase der Protokollvielfalt“ bezeichnen – bevor sich ein neuer Quasi-Standard durchsetzt. Bis dahin gilt: Die Wahl des Protokolls ist eine Architekturentscheidung, keine Glaubensfrage.

Quellen

• OASIS MQTT Standard, Version 3.1.1 und 5.0 (2014/2019)
• IETF RFC 7252 – The Constrained Application Protocol (CoAP)
• IETF RFC 6455 – The WebSocket Protocol
• OMG DDS Specification, Version 1.4 (2015)
• OASIS AMQP 1.0 Standard (2012, ISO/IEC 19464)
• Stanford-Clark, A., & Nipper, A. (1999): MQTT – Publish/Subscribe for the Internet of Things. IBM Technical Report.
• Eclipse Foundation: „MQTT Essentials – A Lightweight IoT Protocol“ (2022)
• Bormann, C. et al.: „CoAP – An Application Protocol for Billions of Tiny Internet Nodes“; IEEE Internet Computing, 2012.
• Prof. Dr. J. Schiller (FU Berlin): Vorlesungsskript „Kommunikationssysteme im IoT“, 2023.
• IEEE Xplore: „Performance Comparison of MQTT and CoAP in Constrained Networks“ (Ali, A. et al., 2020)