MQTT vs. CoAP: Pub/Sub über TCP vs. Request/Response über UDP

MQTT vs CoAP ist eine Wahl zwischen zwei Protokollen, die für dieselbe Art von Hardware gebaut wurden, nämlich kleine batteriebetriebene Geräte in verlustbehafteten Netzen, und die dennoch auf entgegengesetzte Weise arbeiten. MQTT ist Publish/Subscribe über TCP mit einem Broker; CoAP ist RESTful Request/Response über UDP, direkt zwischen Endpunkten. Dieser Leitfaden vergleicht Transporte, Header, Sicherheit, Multicast und Datenfluss, damit Sie entscheiden können, was zu Ihren Geräten und Ihrem Backend passt.

Die Kurzfassung

Wenn Ihre Geräte eine TCP-Verbindung halten können und Ihre Daten mehrere Konsumenten in der Cloud erreichen sollen, ist MQTT mit einem Broker meist der einfachere Weg. Wenn Ihre Geräte in einem eingeschränkten IPv6-Netz wie 6LoWPAN oder Thread sitzen, die meiste Zeit schlafen und wie winzige Webserver adressiert werden, passt CoAP natürlich. Viele große Deployments nutzen CoAP im lokalen eingeschränkten Netz und MQTT von einem Gateway zur Cloud.

So funktioniert CoAP

CoAP (Constrained Application Protocol, RFC 7252) bringt das REST-Modell auf Mikrocontroller. Jedes Gerät stellt Ressourcen wie /sensors/temp bereit, und Clients wenden GET, POST, PUT und DELETE darauf an, genau wie bei HTTP, aber in einem kompakten Binärformat über UDP. Antworten tragen Codes, die an HTTP-Statuscodes angelehnt sind, zum Beispiel 2.05 Content oder 4.04 Not Found.

Da UDP keine Zustellgarantie bietet, ergänzt CoAP eine eigene schlanke Zuverlässigkeit: Eine Nachricht kann Confirmable (CON) sein, dann muss der Empfänger sie bestätigen, oder Non-confirmable (NON), also Fire-and-Forget. Neuübertragungen nutzen exponentielles Backoff.

CoAP hat außerdem eine Observe-Option (RFC 7641). Ein Client meldet Interesse an einer Ressource an, und der Server sendet bei jeder Änderung eine Benachrichtigung. Das ist das, was dem Subscribe von MQTT in CoAP am nächsten kommt, allerdings Punkt-zu-Punkt zwischen einem Client und einem Server.

So funktioniert MQTT

MQTT-Clients öffnen eine TCP-Verbindung (optional mit TLS) zu einem Broker, publizieren dann Nachrichten auf Topics und abonnieren Topic-Filter. Geräte sprechen nie direkt miteinander; der Broker übernimmt Fan-out, retained letzte bekannte Werte, persistente Sessions für Offline-Subscriber und Last-Will-Nachrichten bei unsauberen Verbindungsabbrüchen. Wenn das Broker-Konzept neu für Sie ist, beginnen Sie mit was ein MQTT-Broker ist, und für eine Schritt-für-Schritt-Einführung lesen Sie das MQTT-Tutorial.

MQTT vs. CoAP im Überblick

Transport: TCP vs. UDP

Der Transport ist die Wurzel der meisten Unterschiede. TCP liefert MQTT geordnete, zuverlässige Byteströme, kostet aber einen Drei-Wege-Handshake beim Verbinden und hält Zustand auf beiden Seiten. Auf einer verlustbehafteten Funkstrecke können TCP-Neuübertragungen und Head-of-Line-Blocking Latenz hinzufügen. Mehr zur Transportfrage finden Sie unter ist MQTT TCP oder UDP.

UDP erlaubt CoAP, einen Messwert in einem einzigen Datagramm ohne Verbindungsaufbau zu senden. Das passt zu Geräten, die kurz aufwachen, senden und wieder schlafen. Der Kompromiss: Die Anwendung, hier CoAP, muss Zuverlässigkeit, Deduplizierung und Überlastkontrolle selbst übernehmen, und Geräte hinter NAT werden schwer erreichbar, weil UDP-Zuordnungen schnell ablaufen.

Header-Größe und Overhead

Beide Protokolle sind kompakt. Ein MQTT-PUBLISH kann sehr klein sein, doch der Topic-String reist mit jeder Nachricht mit, sofern Sie keine Topic Aliases aus MQTT 5 nutzen. CoAP verwendet einen 4-Byte-Header, ein kurzes Token und als Deltas kodierte Optionen, sodass auch der URI-Pfad kompakt ist. In der Praxis liegt der Overhead pro Nachricht bei beiden im selben kleinen Bereich; der größere Unterschied ist der Verbindungs-Overhead (TCP und TLS bei MQTT gegenüber keinem oder DTLS bei CoAP).

Sicherheit: TLS vs. DTLS

MQTT nutzt TLS über TCP, denselben bewährten Stack, der HTTPS schützt, mit ausgereifter Unterstützung in Geräte-SDKs, Gateways und Cloud-Brokern. Ein verwalteter MQTT-Broker kümmert sich in der Regel um die Zertifikate; ConnectMQ zum Beispiel stellt ein Let's-Encrypt-Zertifikat auf Port 8883 für TLS und 8084 für sicheres WebSocket bereit.

CoAP nutzt DTLS, die Datagramm-Variante von TLS. Es funktioniert, doch Session-Zustand, Handshake-Neuübertragungen über verlustbehaftete Verbindungen und NAT-Rebinding erhöhen die Komplexität, und die Werkzeuge sind weniger verbreitet. OSCORE (RFC 8613) bietet Ende-zu-Ende-Objektsicherheit, die auch Proxys übersteht. Das ist in eingeschränkten Netzen mit mehreren Hops attraktiv, bringt aber ein eigenes Schlüsselmanagement mit sich.

Für beide Protokolle gilt dieselbe praktische Regel: Verschlüsseln Sie jeden Hop, der das Gerät verlässt, und verlassen Sie sich nie allein auf Netzwerkisolation. Der Leitfaden zu Best Practices für MQTT-Sicherheit behandelt Zugangsdaten, TLS und Topic-Design für MQTT-Deployments.

Observe vs. Subscribe

CoAP Observe und MQTT Subscribe liefern beide Aktualisierungen ohne Polling, doch die Topologie unterscheidet sich. Bei Observe meldet sich jeder interessierte Client beim Gerät selbst an. Zehn Dashboards bedeuten zehn Beobachter auf einem Mikrocontroller, der vielleicht nur Kilobytes an RAM hat. Bei MQTT publiziert das Gerät einmal an den Broker, und der Broker bedient beliebig viele Subscriber. Deshalb skaliert MQTT besser, wenn Daten viele Konsumenten haben, während CoAP gut funktioniert, wenn ein Controller mit vielen kleinen Geräten spricht.

Multicast und lokale Erkennung

Hier liegt der klare Vorteil von CoAP. Ein Client kann eine einzige Anfrage an eine IP-Multicast-Gruppe senden, etwa um alle Lichter einer Etage auszuschalten, und jedes Mitglied antwortet. Zusammen mit der Ressourcenerkennung über /.well-known/core eignet sich CoAP für lokale Gebäude- und Hausautomationsnetze, in denen Geräte sich ohne zentralen Server finden. MQTT kennt kein Multicast; jede Nachricht läuft über den Broker.

Ein verbreitetes Hybridmuster

Eingeschränkte Mesh-Netze und die Cloud haben unterschiedliche Anforderungen, daher setzen viele Systeme ein Gateway dazwischen:

1. Sensoren in einem Thread- oder 6LoWPAN-Mesh stellen CoAP-Ressourcen bereit.
2. Ein Border-Gateway beobachtet diese Ressourcen oder empfängt CoAP-POSTs.
3. Das Gateway publiziert jede Aktualisierung per MQTT mit TLS an einen Cloud-MQTT-Broker, zum Beispiel auf site1/floor2/room14/temperature.
4. Dashboards, Historians und Alarmdienste abonnieren den Broker.

In Gebäude- und Fabrikumgebungen ordnet das Gateway die Werte idealerweise in einen Unified Namespace (UNS) ein, dessen Topics der ISA-95-Hierarchie folgen, etwa acme/werk-muenchen/halle-2/raum-14/temperatur. So landen CoAP-Daten aus dem Mesh an derselben Stelle wie die Maschinendaten aus SPS und OPC-UA-Servern.

Hier ist die Cloud-Seite eines solchen Gateways in Python. Die CoAP-Verarbeitung hängt von Ihrer Bibliothek ab und wird daher durch eine Funktion dargestellt, die einen Messwert entgegennimmt; der MQTT-Teil ist vollständig.

import json
import ssl
import time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set("site1/gateway1/status", "offline", qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish("site1/gateway1/status", "online", qos=1, retain=True)

client.on_connect = on_connect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_start()

def forward_coap_reading(resource_path, value):
    """Aus Ihrem CoAP-Observe-Callback aufrufen."""
    topic = "site1/" + resource_path.strip("/").replace("sensors/", "")
    payload = json.dumps({"value": value, "ts": int(time.time())})
    client.publish(topic, payload, qos=1, retain=True)

# Beispiel: ein beobachteter Messwert von coap://[fd00::12]/sensors/floor2/room14/temperature
forward_coap_reading("/sensors/floor2/room14/temperature", 21.6)
time.sleep(2)

Um ohne Konto zu experimentieren, ersetzen Sie die Verbindung durch client.connect("broker.connectmq.com", 1883) mit einer beliebigen eindeutigen Client-ID und einem Topic-Präfix wie connectmq/demo/<random-id>/. Beachten Sie aber, dass der kostenlose öffentliche MQTT-Broker für jeden lesbar und nur für Tests gedacht ist, nicht für Produktionsdaten.

Wann Sie welches Protokoll wählen

Wählen Sie MQTT, wenn:

• Geräte über WLAN, Ethernet oder Mobilfunk verbunden sind und eine ausgehende TCP-Verbindung halten können.
• Daten mehrere Cloud-Konsumenten erreichen müssen.
• Sie retained Zustand, Online-Status über Last Will und Pufferung für Offline-Subscriber möchten.
• Sie ausgereifte, weit verfügbare Client-Bibliotheken und einen verwalteten MQTT-Broker bevorzugen.

Wählen Sie CoAP, wenn:

• Geräte in eingeschränkten IPv6-Meshes mit sehr wenig RAM und Energie laufen.
• Sie Multicast-Befehle oder lokale Erkennung ohne zentralen Server brauchen.
• Die Interaktion naturgemäß Request/Response ist, etwa das Lesen oder Schreiben einer Geräteeinstellung.

Liegt Ihr Projekt eher auf der MQTT-Seite, sind die Geräte aber extrem eingeschränkt oder ohne TCP, sehen Sie sich auch MQTT-SN an, das die Semantik von MQTT auf UDP und andere Datagramm-Transporte bringt.

Starten Sie mit ConnectMQ

Ob Ihre Geräte nativ MQTT sprechen oder über ein CoAP-Gateway: Die Cloud-Seite braucht einen zuverlässigen Broker. ConnectMQ ist ein verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS auf 8883 und einem Live-Topic-Explorer, mit dem Sie jedes Gateway prüfen, sobald es online geht. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, und verbinden Sie Ihr erstes Gateway in wenigen Minuten.

Häufig gestellte Fragen

Ist CoAP für batteriebetriebene Geräte besser als MQTT?

Für Geräte, die selten aufwachen und ein einzelnes Datagramm senden, kann es das sein, weil UDP den Verbindungsaufbau vermeidet. Für Geräte, die häufig melden oder Befehle empfangen müssen, ist die dauerhafte Verbindung von MQTT meist ebenso effizient und einfacher zu betreiben.

Braucht CoAP einen Broker?

Nein. CoAP-Clients sprechen direkt mit Geräteendpunkten. Proxys können Caching und Protokollübersetzung ergänzen, aber es gibt keinen zentralen Broker wie bei MQTT.

Können CoAP und MQTT zusammenarbeiten?

Ja. Häufig beobachtet ein Gateway CoAP-Ressourcen in einem lokalen Mesh und publiziert die Werte an einen MQTT-Broker in der Cloud. So erhalten Sie lokale Effizienz und Fan-out in der Cloud.

Unterstützt MQTT UDP?

Standard-MQTT läuft über TCP oder WebSocket. MQTT-SN ist ein verwandtes Protokoll für UDP und andere Datagramm-Netze, das in der Regel über ein Gateway an einen normalen MQTT-Broker angebunden wird.