MQTT vs. CoAP — zwei leichte IoT-Protokolle im Vergleich

MQTT: gut geeignet für

• ✓Viele Geräte, kleine Nachrichten: Ein Broker verteilt mühelos Messwerte von Tausenden Sensoren gleichzeitig.
• ✓Schmale Bandbreite: Der Verwaltungsanteil pro Nachricht (Overhead) ist extrem klein, eine komplette Datennachricht kommt mit wenigen Bytes plus Topic-Name aus, ein Bruchteil eines HTTP-Requests.
• ✓Instabile Verbindungen: Quittungsmechanismen (QoS) und die Abschiedsnachricht Last Will fangen Verbindungsabbrüche sauber ab.
• ✓Entkopplung: Sender und Empfänger kennen sich nicht, dadurch lassen sich neue Abonnenten jederzeit ergänzen, ohne die Sender anzufassen.
• ✓Firewall-freundlich: Der Client (so heisst jedes angeschlossene Gerät oder Programm) baut die Verbindung immer selbst nach aussen zum Broker auf. Auf der Geräteseite muss keine Tür in der Firewall (ein sogenannter Port) von aussen geöffnet werden; erreichbar sein muss nur der Broker.

MQTT: weniger geeignet für

• ✗Harte Echtzeit im Maschinentakt: Wenn jede Millisekunde zählt, etwa bei der Steuerung von Maschinenachsen, sind spezialisierte Maschinen-Netzwerke die richtige Wahl (Fachbegriffe: Feldbusse oder Industrial Ethernet, etwa PROFINET und EtherCAT).
• ✗Grosse Dateien: MQTT ist für kurze Meldungen gebaut, für Firmware-Updates, Bilder oder Videos eignet sich ein Dateitransfer über HTTP oder ein spezialisiertes Protokoll besser.
• ✗Klassisches Frage-Antwort-Muster: Wer gezielt eine Antwort auf eine Anfrage braucht, etwa eine App, die auf Knopfdruck Daten abruft, fährt mit HTTP, der gewohnten Web-Technik, meist einfacher.
• ✗Direktverbindungen ohne Infrastruktur: MQTT braucht immer einen Broker, für eine simple Punkt-zu-Punkt-Verbindung zwischen zwei Geräten ist das zu viel des Guten.

CoAP: gut geeignet für

• ✓Für stark eingeschränkte Geräte mit wenig RAM, Rechenleistung und Batterie, weil der 4-Byte-Header und UDP kaum Ressourcen verbrauchen.
• ✓Für verlustbehaftete Funknetze mit kleiner Bandbreite (z. B. 6LoWPAN), weil CoAP von Grund auf für kleine Pakete und gelegentliche Paketverluste ausgelegt ist.
• ✓Für Web-nahe Architekturen, weil das RESTful-Modell (GET/PUT/POST/DELETE auf URIs) direkt zu HTTP passt und sich per Proxy einfach überbrücken lässt.
• ✓Für ereignisgetriebene Überwachung, weil die OBSERVE-Erweiterung Änderungen aktiv pusht, statt das Gerät ständig abfragen zu lassen – das spart Strom und Funkzeit.
• ✓Für Massen-Geräteverwaltung, weil etablierte Standards wie LwM2M auf CoAP aufsetzen und Firmware-Updates und Konfiguration standardisiert abbilden.

CoAP: weniger geeignet für

• ✗Für die zuverlässige Übertragung grosser Datenmengen (Bilder, Logs, Streams), weil UDP dafür nicht gemacht ist; besser passt hier HTTP über TCP oder MQTT.
• ✗Für stark entkoppelte Ereignis-Verteilung an viele Abnehmer, weil CoAP im Kern Request/Response ist und keinen zentralen Broker hat; besser passt hier MQTT mit Publish/Subscribe.
• ✗Für harte Maschinen-Echtzeit im Millisekunden-Takt, weil CoAP darauf nicht ausgelegt ist; besser passen hier PROFINET oder EtherCAT.
• ✗Für Umgebungen, in denen UDP durch Firewalls oder NAT blockiert wird, weil CoAP dann schlecht durchkommt; besser passt hier ein TCP-basiertes Protokoll oder CoAP über TCP/WebSocket (RFC 8323).