{"id":4188,"date":"2026-04-28T10:54:28","date_gmt":"2026-04-28T08:54:28","guid":{"rendered":"https:\/\/g7itchme.wordpress.com\/?p=4188"},"modified":"2026-04-28T10:54:28","modified_gmt":"2026-04-28T08:54:28","slug":"mqtt-und-seine-alternativen-eine-technikhistorische-und-praktische-einordnung-der-iot-kommunikationsprotokolle","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/mqtt-und-seine-alternativen-eine-technikhistorische-und-praktische-einordnung-der-iot-kommunikationsprotokolle\/","title":{"rendered":"MQTT und seine Alternativen: Eine technikhistorische und praktische Einordnung der IoT-Kommunikationsprotokolle"},"content":{"rendered":"

Autor:<\/strong> DerSchneider<\/p>\n\n\n\n

\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Das Internet der Dinge (IoT) ist l\u00e4ngst aus den Labors in den industriellen und privaten Alltag gewandert. Millionen von Sensoren, Aktoren und Ger\u00e4ten 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\u00fcr ressourcenbeschr\u00e4nkte IoT-Ger\u00e4te 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.<\/p>\n\n\n\n

Dieser Artikel beleuchtet MQTT in seiner historischen Entwicklung, stellt die wichtigsten Alternativen gegen\u00fcber 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\u00e4nen.<\/p>\n\n\n\n

\n\n\n\n

Hauptteil<\/h2>\n\n\n\n

1. MQTT \u2013 Der Pionier der schmalen Pfade<\/h3>\n\n\n\n

1.1 Historische Wurzeln<\/h4>\n\n\n\n

Entwickelt in den sp\u00e4ten 1990er Jahren von IBM-Mitarbeitern Andy Stanford-Clark und Arlen Nipper, sollte MQTT urspr\u00fcnglich die Fern\u00fcberwachung von \u00d6lpipelines erm\u00f6glichen. Die Herausforderung bestand darin, \u00fcber satellitenbasierte Verbindungen mit extrem geringer Bandbreite und hoher Latenz sowie unzuverl\u00e4ssigen Verbindungen Daten zu \u00fcbertragen. Das Ergebnis war ein extrem leichtgewichtiges Protokoll mit minimalem Overhead (Header ab 2 Byte) und drei Qualit\u00e4tsdienst-Stufen (QoS 0\u20132).<\/p>\n\n\n\n

2014 wurde MQTT als OASIS-Standard ver\u00f6ffentlicht, 2019 folgte die ISO\/IEC 20922-Normierung. Die Version 3.1.1 ist bis heute die am weitesten verbreitete, w\u00e4hrend Version 5 (2019) Erweiterungen wie Reason Codes, Shared Subscriptions und Message Expiry einf\u00fchrte \u2013 ohne jedoch den schlanken Kern aufzubl\u00e4hen.<\/p>\n\n\n\n

1.2 Technisches Prinzip<\/h4>\n\n\n\n

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

QoS-Stufe<\/th>Bezeichnung<\/th>Garantie<\/th>Typische Anwendung<\/th><\/tr><\/thead>
0<\/td>At most once<\/td>Keine Best\u00e4tigung, m\u00f6glicher Verlust<\/td>Sensordaten mit hoher Rate<\/td><\/tr>
1<\/td>At least once<\/td>Zustellung garantiert, Duplikate m\u00f6glich<\/td>Steuerbefehle, Alarme<\/td><\/tr>
2<\/td>Exactly once<\/td>Einmalige Zustellung ohne Duplikate<\/td>Finanztransaktionen, Z\u00e4hler<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

1.3 Schw\u00e4chen im Fokus<\/h4>\n\n\n\n
    \n
  • Broker als Flaschenhals<\/strong>\u00a0und Singel Point of Failure (durch Clustering beherrschbar)<\/li>\n\n\n\n
  • Keine nativen Multicast-F\u00e4higkeiten<\/strong>\u00a0\u2013 jeder Client ben\u00f6tigt eigene Verbindung<\/li>\n\n\n\n
  • TCP-basiert<\/strong>\u00a0\u2192 Nachteile bei extrem instabilen Funkstrecken (Long Fat Networks)<\/li>\n\n\n\n
  • Niedrige Effizienz bei sehr kleinen Nutzlasten<\/strong>\u00a0(< 10 Byte) durch TCP-Header<\/li>\n<\/ul>\n\n\n\n

    Trotzdem: MQTT bleibt die erste Wahl f\u00fcr gesch\u00e4tzte 70\u201380 % aller typischen IoT-Projekte \u2013 von Smart Home \u00fcber Telematik bis zur Fabrikautomation.<\/p>\n\n\n\n

    2. Die Alternativen im Vergleich<\/h3>\n\n\n\n

    Kein Protokoll ist f\u00fcr alle Anwendungsf\u00e4lle ideal. Die folgende Tabelle gibt einen schnellen \u00dcberblick \u00fcber die wichtigsten Kandidaten, sortiert nach ihrer \u201eRessourcenfreundlichkeit\u201c:<\/p>\n\n\n\n

    Protokoll<\/th>Transport<\/th>Header-Min.<\/th>Architektur<\/th>QoS-Stufen<\/th>Echtzeit<\/th>Typische Dom\u00e4ne<\/th><\/tr><\/thead>
    MQTT<\/strong><\/td>TCP<\/td>2 Byte<\/td>Broker-basiert Pub\/Sub<\/td>3<\/td>nein<\/td>Allgemeines IoT, Industrie 4.0<\/td><\/tr>
    CoAP<\/strong><\/td>UDP<\/td>4 Byte<\/td>Request\/Response + Observe<\/td>2<\/td>begrenzt<\/td>Hochgradig beschr. Ger\u00e4te, 6LoWPAN<\/td><\/tr>
    AMQP<\/strong><\/td>TCP<\/td>8+ Byte<\/td>Message Queuing<\/td>Mehrere<\/td>nein<\/td>Enterprise, Finanzwesen<\/td><\/tr>
    DDS<\/strong><\/td>UDP\/TCP<\/td>variabel<\/td>Brokerless Data-Centric<\/td>23 Policies<\/td>ja<\/td>Autonomes Fahren, Medizintechnik<\/td><\/tr>
    HTTP\/2+SSE<\/strong><\/td>TCP<\/td>100+ Byte<\/td>Request\/Response + Stream<\/td>keine<\/td>nein<\/td>Web-Dashboards, Cloud-APIs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    2.1 CoAP \u2013 F\u00fcr die allerkleinsten Knoten<\/h4>\n\n\n\n

    Das Constrained Application Protocol (RFC 7252) wurde von der IETF speziell f\u00fcr Ger\u00e4te mit wenigen Kilobyte RAM und extrem niedrigem Energiebudget entworfen. Es l\u00e4uft \u00fcber UDP, was Verbindungsaufbau und Keep-Alive spart. Dank Multicast-Unterst\u00fctzung eignet es sich hervorragend f\u00fcr Gruppensteuerungen (z.B. ein Befehl \u201eLicht aus!\u201c an alle Lampen in einem Raum).<\/p>\n\n\n\n

    Eine oft \u00fcbersehene St\u00e4rke ist die einfache \u00dcbersetzung zu HTTP \u00fcber Cross-Proxy \u2013 REST-Entwickler f\u00fchlen sich sofort zu Hause. Nachteil: Das optionale \u201eObserve\u201c-Pattern f\u00fcr Publish\/Subscribe ist weniger ausgereift als MQTTs natives Modell.<\/p>\n\n\n\n

    \n

    Historischer Einschub:<\/strong> CoAP entstand parallel zu MQTT, aber aus einer anderen Denkschule \u2013 der IETF-Arbeitsgruppe f\u00fcr eingebettete Webdienste. W\u00e4hrend MQTT aus der Industrie kam, war CoAP akademischer und netzwerkn\u00e4her.<\/p>\n<\/blockquote>\n\n\n\n

    2.2 AMQP \u2013 Der Schwergewichts-Champion<\/h4>\n\n\n\n

    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 \u00fcber SASL. Das macht es zur ersten Wahl, wenn IoT-Daten nahtlos in Unternehmens-IT (ERP, Banking, Logistik) flie\u00dfen m\u00fcssen.<\/p>\n\n\n\n

    Allerdings erkauft man sich diese M\u00e4chtigkeit mit einem hohen Ressourcenverbrauch und einer steilen Lernkurve. Auf einem 8\u2011Bit-Mikrocontroller mit 2 KB RAM ist AMQP undenkbar. Auf einem Industrie-PC oder in der Cloud hingegen eine ausgezeichnete Wahl.<\/p>\n\n\n\n

    2.3 DDS \u2013 F\u00fcr Echtzeit ohne Kompromisse<\/h4>\n\n\n\n

    Das Data Distribution Service (standardisiert durch die OMG) ist unter Ingenieuren von autonomen Fahrzeugen, milit\u00e4rischen Drohnen und medizinischen Robotern bekannt. DDS kommt v\u00f6llig 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 \u201eData Space\u201c sorgt f\u00fcr Entdeckung und Verbindungsmanagement.<\/p>\n\n\n\n

    Mit 23 QoS-Policies (z.B. Deadline, LatencyBudget, TimeBasedFilter) bietet DDS eine Kontrolle, die MQTT und CoAP nicht einmal ann\u00e4hernd erreichen. Der Preis: Komplexit\u00e4t und ein erheblicher Speicherfu\u00dfabdruck (mehrere Megabyte). DDS ist nichts f\u00fcr batteriebetriebene Sensoren, aber die erste Wahl f\u00fcr Systeme, bei denen Kontrollverlust Menschenleben kosten k\u00f6nnte.<\/p>\n\n\n\n

    2.4 HTTP\/2 mit Server-Sent Events \u2013 Der Web-Weg<\/h4>\n\n\n\n

    HTTP ist allgegenw\u00e4rtig, 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\u00fcr reine \u00dcberwachungsdashboards im Browser ist das eine elegante L\u00f6sung \u2013 kein zus\u00e4tzlicher Broker, keine speziellen Ports, reine Web-Standards.<\/p>\n\n\n\n

    Allerdings fehlt ein QoS-Mechanismus, und die native Unterst\u00fctzung f\u00fcr dauerhafte Verbindungen ist begrenzt. Hybridans\u00e4tze mit MQTT over WebSocket sind oft die bessere Wahl, wenn beide Richtungen ben\u00f6tigt werden.<\/p>\n\n\n\n

    3. Kontroversen und offene Fragen<\/h3>\n\n\n\n

    3.1 Der unbew\u00e4ltigte Skalenbruch<\/h4>\n\n\n\n

    Viele Diskussionen in Fachforen drehen sich um die Frage: \u201eIst MQTT f\u00fcr gro\u00dfe Industrie-4.0-Projekte mit >100.000 Ger\u00e4ten geeignet?\u201c Die Antwort ist differenziert. Ja, mit leistungsf\u00e4higen Brokern wie EMQX oder HiveMQ, die Clustering und persistente Sessions beherrschen. Nein, wenn die Ger\u00e4te \u00fcber extrem schwankende Mobilfunknetze (NB-IoT, LTE-M) verbunden sind \u2013 hier k\u00f6nnen lange TCP-Timeouts und Keep-Alive-Timer die Batterien leersaugen. Genau an dieser Stelle wird CoAP \u00fcber UDP wieder interessant.<\/p>\n\n\n\n

    3.2 Security-Theater<\/h4>\n\n\n\n

    MQTT erlaubt Username\/Password in Klartext (nur verschl\u00fcsselt \u00fcber TLS), aber viele Projekte nutzen aus Kostengr\u00fcnden unverschl\u00fcsselte Verbindungen. Das ist fahrl\u00e4ssig. Die Alternative CoAP mit DTLS ist kryptografisch \u00e4hnlich sicher, verursacht aber ebenfalls einen Handshake-Overhead. DDS verf\u00fcgt \u00fcber eine eigene Security-Modell (DDS-Security), das die kryptografische Absicherung einzelner Topics erlaubt \u2013 ein Alleinstellungsmerkmal.<\/p>\n\n\n\n

    Die anhaltende Kontroverse um das \u201eProvisioning\u201c von Ger\u00e4tezertifikaten ist ungel\u00f6st. In der Praxis werden oft Hersteller-CAs missbraucht oder fest verdrahtete Secrets ausgeliefert \u2013 ein sicherheitstechnischer Albtraum.<\/p>\n\n\n\n

    4. Zuk\u00fcnftige Implikationen<\/h3>\n\n\n\n

    4.1 MQTT 5.1 unterwegs<\/h4>\n\n\n\n

    Die n\u00e4chste Iteration von MQTT (inoffiziell 5.1) wird voraussichtlich verbesserte Fehlercodes und eine noch effizientere Session-Verwaltung bringen. Gr\u00f6\u00dfere \u00c4nderungen sind nicht zu erwarten \u2013 das Protokoll ist erwachsen.<\/p>\n\n\n\n

    4.2 CoAP over QUIC<\/h4>\n\n\n\n

    Mit QUIC als moderne UDP-Alternative (von Google\/ IETF) k\u00f6nnte CoAP einen deutlichen Leistungssprung machen: schnellerer Verbindungsaufbau, integrierte Verschl\u00fcsselung, keine Head-of-Line-Blocking. Erste Experimente zeigen vielversprechende Ergebnisse f\u00fcr mobile IoT-Anwendungen.<\/p>\n\n\n\n

    4.3 Die R\u00fcckkehr des Brokers? \u2013 Zenoh<\/h4>\n\n\n\n

    Eine relativ neue Entwicklung ist Zenoh (Eclipse Foundation), das als \u201eZero Overhead Network Protocol\u201c MQTT, CoAP, DDS und andere in einer einheitlichen, brokergest\u00fctzten oder brokerlosen Architektur vereinen will. Ob es sich durchsetzt, bleibt abzuwarten \u2013 aber der Trend geht klar zu heterogenen, protokoll\u00fcbergreifenden Middlewares.<\/p>\n\n\n\n

    4.4 Industrieller Praxis-Trend: Gateway-Architekturen<\/h4>\n\n\n\n

    In der Praxis zeichnet sich ab, dass kein einzelnes Protokoll alle Anforderungen erf\u00fcllt. Kluge Architekturen setzen auf Gateways, die im Feld mit CoAP oder LoRaWAN kommunizieren und nach au\u00dfen MQTT oder AMQP sprechen. Azure IoT Edge, AWS Greengrass und Eclipse Hono sind Beispiele f\u00fcr diese mehrschichtige Strategie.<\/p>\n\n\n\n

    \n\n\n\n

    Fazit und Ausblick<\/h2>\n\n\n\n

    MQTT hat sich seinen Platz in der IoT-Welt redlich verdient. Es ist nicht perfekt, aber f\u00fcr die allermeisten Anwendungsf\u00e4lle gut genug, ausgereift und breit unterst\u00fctzt. Wer jedoch an die Grenzen st\u00f6\u00dft \u2013 sei es durch extreme Ressourcenknappheit, Echtzeitanforderungen oder komplexe Enterprise-Integration \u2013 sollte CoAP, DDS oder AMQP als ernsthafte Alternativen pr\u00fcfen.<\/p>\n\n\n\n

    Die Zukunft geh\u00f6rt nicht einem einzigen Protokoll, sondern einem intelligenten Zusammenspiel mehrerer. Der Technologiehistoriker wird eines Tages vielleicht die Jahre 2020 bis 2030 als die \u201ePhase der Protokollvielfalt\u201c bezeichnen \u2013 bevor sich ein neuer Quasi-Standard durchsetzt. Bis dahin gilt: Die Wahl des Protokolls ist eine Architekturentscheidung, keine Glaubensfrage.<\/p>\n\n\n\n

    \n\n\n\n

    Quellen<\/h2>\n\n\n\n
      \n
    • OASIS MQTT Standard, Version 3.1.1 und 5.0 (2014\/2019)<\/li>\n\n\n\n
    • IETF RFC 7252 \u2013 The Constrained Application Protocol (CoAP)<\/li>\n\n\n\n
    • IETF RFC 6455 \u2013 The WebSocket Protocol<\/li>\n\n\n\n
    • OMG DDS Specification, Version 1.4 (2015)<\/li>\n\n\n\n
    • OASIS AMQP 1.0 Standard (2012, ISO\/IEC 19464)<\/li>\n\n\n\n
    • Stanford-Clark, A., & Nipper, A. (1999): MQTT \u2013 Publish\/Subscribe for the Internet of Things. IBM Technical Report.<\/li>\n\n\n\n
    • Eclipse Foundation: \u201eMQTT Essentials \u2013 A Lightweight IoT Protocol\u201c (2022)<\/li>\n\n\n\n
    • Bormann, C. et al.: \u201eCoAP \u2013 An Application Protocol for Billions of Tiny Internet Nodes\u201c; IEEE Internet Computing, 2012.<\/li>\n\n\n\n
    • Prof. Dr. J. Schiller (FU Berlin): Vorlesungsskript \u201eKommunikationssysteme im IoT\u201c, 2023.<\/li>\n\n\n\n
    • IEEE Xplore: \u201ePerformance Comparison of MQTT and CoAP in Constrained Networks\u201c (Ali, A. et al., 2020)<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"

      Autor: DerSchneider Einleitung Das Internet der Dinge (IoT) ist l\u00e4ngst aus den Labors in den industriellen und privaten Alltag gewandert. Millionen von Sensoren, Aktoren und Ger\u00e4ten 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,46,26],"tags":[394,1239,2719,3425,4727,5610],"class_list":["post-4188","post","type-post","status-publish","format-standard","hentry","category-elektrotechnik","category-industrie-4-0","category-mit-den-handen","tag-amqp","tag-coap","tag-geratekommunikation","tag-iot-protokolle","tag-mqtt","tag-publish-subscribe"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/4188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=4188"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/4188\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=4188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=4188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=4188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}