MQTT vs. CoAP vs. HTTP – Protokollwahl im IoT

Ein Temperatursensor sendet alle 5 Minuten einen Messwert, ein Ventil soll bei Grenzwert sofort reagieren, und ein Dashboard soll die Daten in Echtzeit anzeigen: In vielen Projekten scheitert nicht die Sensorik, sondern die Wahl des Kommunikationsprotokolls. Wer hier unsauber entscheidet, zahlt später mit unnötiger Komplexität, instabilen Verbindungen oder zu hohem Energieverbrauch.

Im IoT-Alltag tauchen drei Protokollfamilien besonders oft auf: MQTT, CoAP und HTTP. Sie lösen ähnliche Aufgaben, setzen aber unterschiedliche Schwerpunkte bei Transport, Zustandsmodell, Overhead und Betriebsfähigkeit in schwachen Netzen. Entscheidend ist nicht „das beste Protokoll“, sondern ein Protokoll, das zur Geräteklasse, zum Datenfluss und zum Betriebsmodell passt.

Welche Datenflüsse im IoT die Protokollwahl bestimmen

Telemetrie, Befehle und Zustandsabfragen sind unterschiedliche Lastprofile

IoT-Kommunikation besteht typischerweise aus drei Mustern: Telemetrie (Sensorwerte nach oben), Befehle (Aktorik nach unten) und Zustandsabfragen (on-demand). Telemetrie ist häufig, klein und tolerant gegenüber kurzen Verzögerungen. Befehle sind seltener, aber oft latenzkritisch und sollten robust zugestellt werden. Zustandsabfragen benötigen ein klares Request/Response-Modell, etwa für Geräteeigenschaften oder Diagnosewerte.

Die Protokollwahl beeinflusst dabei:

• wie effizient kleine Nachrichten übertragen werden (Overhead, Paketgröße, Verbindungsaufbau),
• wie gut „schlafende“ Geräte (Battery Powered) unterstützt werden,
• wie zuverlässig Zustellung und Reihenfolge abgebildet werden,
• wie einfach die Integration in Backend, Cloud oder Web-Apps gelingt.

Gerätetyp und Netz wirken stärker als „persönliche Vorlieben“

Ein Microcontroller mit wenigen hundert Kilobyte RAM verhält sich anders als ein Linux-Gateway. Ebenso unterscheiden sich Netzumgebungen: WLAN/LAN mit stabiler TCP-Konnektivität, Mobilfunk mit wechselnden IPs oder Low-Power-Funk mit knappen Payload-Größen. Das Protokoll muss zu diesen Rahmenbedingungen passen, sonst entstehen Workarounds (Polling, proprietäre Retries, Gateway-Sonderlogik), die den Betrieb teurer machen.

MQTT, CoAP und HTTP: Modelle, Stärken und Grenzen

MQTT: Publish/Subscribe für Telemetrie und Ereignisse

MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll über TCP. Geräte (Clients) veröffentlichen Nachrichten in Topics, ein Broker verteilt sie an Abonnenten. Das reduziert direkte Punkt-zu-Punkt-Verbindungen und passt gut zu Szenarien mit vielen Sensoren, mehreren Konsumenten (Monitoring, Alarming, Historian) und ereignisbasierter Logik.

Typische Vorteile im Feld:

• Entkopplung: Sensoren kennen keine Empfänger, nur Topics.
• Session- und Zustelloptionen (QoS) unterstützen robuste Übertragung bei Netzstörungen.
• Gute Eignung für Gateways, die viele Geräte bündeln und nach oben weiterleiten.

Grenzen entstehen dort, wo klassisches REST-Denken dominiert (Ressourcen lesen/schreiben), oder wo extrem kurze, sporadische Nachrichten ohne dauerhafte TCP-Verbindung gefordert sind. MQTT benötigt außerdem einen Broker als zentrale Komponente, die betrieben, abgesichert und überwacht werden muss.

CoAP: Ressourcenorientiert und sparsam für constrained Devices

CoAP (Constrained Application Protocol) orientiert sich am REST-Prinzip (Ressourcen, Methoden) und läuft typischerweise über UDP. Es wurde für sehr eingeschränkte Geräte und Netze entwickelt, in denen kurze Header und geringe Komplexität zählen. Statt dauerhaft offener Verbindungen kann CoAP gut mit kurzen Exchanges umgehen.

Stärken in der Praxis:

• Geringer Overhead bei kleinen Nutzdaten, geeignet für energiearme Endgeräte.
• Ressourcenmodell (z. B. /temp, /valve) erleichtert Geräte-APIs.
• Beobachtungsmechanismus (Observe) kann Server-Push ähnlich wie Subscriptions abbilden.

Herausforderungen ergeben sich beim Traversieren klassischer Unternehmensnetze (Firewalls, Proxies) und bei der Integration in Web-Ökosysteme, die stark auf HTTP ausgerichtet sind. Häufig landet CoAP deshalb am Edge und wird über Gateways in andere Protokolle übersetzt.

HTTP: Universell, aber nicht immer energie- oder latenzoptimal

HTTP ist allgegenwärtig: Libraries, Tools, Proxies, Auth-Systeme und Observability sind etabliert. Für IoT ist HTTP vor allem dann sinnvoll, wenn Geräte wie „kleine Web-Clients“ agieren, wenn ein Web-Backend bereits existiert oder wenn APIs schnell getestet und integriert werden müssen.

Im IoT-Feld zeigt HTTP zwei Gesichter:

• Sehr gute Integration in IT/Cloud (APIs, Gateways, Load Balancer, Logging).
• Relativ hoher Protokoll-Overhead und oft ungünstiges Polling-Verhalten bei Event-Use-Cases.

Für batteriebetriebene Geräte ist wiederholter Verbindungsaufbau oft der größere Energietreiber als die Nutzdaten. Für Aktorik mit harten Latenzanforderungen kann HTTP funktionieren, wenn die Verbindung stabil ist und Timeouts sauber gesetzt sind; in intermittierenden Netzen wird das schwieriger.

Vergleich nach Kriterien: Was im Projekt wirklich zählt

Einordnung nach Datenrichtung, Netz und Geräteklasse

Qualität der Zustellung: Zuverlässigkeit entsteht im Gesamtpaket

„Zuverlässig“ bedeutet im IoT je nach Use-Case etwas anderes: Muss ein Messwert garantiert ankommen oder reicht „best effort“? Muss ein Aktor-Befehl genau einmal ausgeführt werden? Viele Fehler entstehen, weil Applikationslogik und Protokollannahmen nicht zusammenpassen. Selbst bei Protokollen mit Zustelloptionen bleibt die Verantwortung für Idempotenz (gleiche Nachricht mehrfach ausführen ohne Schaden), Sequenzierung und Replay-Schutz oft in der Anwendung oder im Gateway.

Sicherheit und Betrieb: Auth, Verschlüsselung, Angriffsfläche

Transportverschlüsselung ist Pflicht, aber nicht der einzige Baustein

In der Praxis sollte Kommunikation grundsätzlich verschlüsselt und authentisiert werden, typischerweise über TLS (bei TCP) oder DTLS (bei UDP). Darüber hinaus sind Themen wie Schlüsselrotation, Gerätezertifikate, sichere Provisionierung und Rechtekonzepte entscheidend. Ohne sauberes Identitätsmodell entstehen später „geteilte“ Zugangsdaten oder unübersichtliche ACLs.

Auch das Betriebsmodell gehört zur Sicherheit: Ein Broker oder API-Gateway muss überwacht, aktualisiert und gegen Fehlkonfigurationen abgesichert werden. In Industrieumgebungen kommen häufig Zonen- und Segmentierungsprinzipien hinzu. Vertiefend dazu passt der Blick auf IoT-Gerätemanagement mit OTA-Updates, weil Wartbarkeit und Sicherheit im Feld zusammenhängen.

Minimierung von Angriffsflächen durch klare Rollen

Ein bewährtes Muster ist die Trennung von Rollen:

• Endgeräte sprechen ein schlankes Protokoll (MQTT oder CoAP) zu einem lokalen oder zentralen Knoten.
• Das Gateway übernimmt Protokollübersetzung, Filterung, Pufferung und Authentisierung.
• Backend-Dienste sprechen über HTTP-basierte APIs oder interne Message-Busse.

So bleibt die Komplexität auf den Komponenten, die einfacher zu patchen und zu überwachen sind.

Praxisbeispiele: So sieht die Protokollentscheidung im Alltag aus

Smart Building: Viele Sensoren, mehrere Auswertungen

In Gebäuden liefern Sensoren (CO2, Temperatur, Präsenz) kontinuierlich Daten. Gleichzeitig wollen Facility-Teams Dashboards, Alarmierungen und langfristige Reports. Hier spielt Publish/Subscribe seine Stärke aus: Sensoren veröffentlichen Werte, und verschiedene Dienste konsumieren sie unabhängig voneinander. Häufig entsteht eine Pipeline: Gerät → MQTT-Broker → Verarbeitung → Speicherung → Visualisierung. Falls lokale Regeln erforderlich sind (z. B. Lüftung sofort einschalten), lässt sich Logik auch nahe am Gateway ausführen; eine Einordnung dazu bietet Edge Computing im IoT.

Industrienahe Aktorik: Befehle müssen nachvollziehbar sein

Bei Ventilen, Relais oder Fördertechnik zählen Nachvollziehbarkeit und saubere Zustandsmodelle. Oft ist der Kern nicht das Protokoll, sondern die Modellierung: Welche Zustände gibt es, wie wird eine Befehlsquittung (Ack) umgesetzt, wie wird verhindert, dass alte Befehle erneut wirken? Hier kann MQTT mit klar definierten Topics für Command/Status funktionieren. CoAP passt gut, wenn ein ressourcenorientiertes Gerätemodell gewünscht ist (z. B. /state, /target) und das Netz UDP zulässt. HTTP wird häufig im übergeordneten Leitsystem genutzt, während die Feldebene ein anderes Protokoll nutzt.

Remote-Geräte über Mobilfunk: Intermittierende Konnektivität einplanen

Bei Geräten mit schwankender Verbindung (Baustellen, Container, mobile Assets) entscheidet weniger das „Protokoll auf dem Papier“ als das Verhalten bei Ausfällen: lokales Puffern, Wiederanlauf, Zeitstempel, deduplizieren. MQTT kann mit persistenter Session hilfreich sein, sofern Broker und Client sauber konfiguriert sind. CoAP punktet, wenn kurze, sporadische Nachrichten ohne dauerhafte Verbindung priorisiert werden. In beiden Fällen ist eine Gateway-Schicht oft der Stabilitätsanker.

Entscheidungshilfe: Auswahl in wenigen Schritten

• Wenn Telemetrie an mehrere Systeme verteilt werden soll und ein Brokerbetrieb möglich ist, spricht vieles für Publish/Subscribe mit MQTT.
• Wenn Endgeräte stark eingeschränkt sind und ein REST-ähnliches Ressourcenmodell gewünscht ist, ist CoAP ein passender Kandidat, oft kombiniert mit einem Gateway zur IT-Welt.
• Wenn bestehende Web-APIs, Identity-Provider und Standard-Observability genutzt werden sollen, ist HTTP für Gateways und Backend-Integration meist der pragmatische Weg.
• Für Aktorik: Idempotente Befehle, klare Quittungen und ein sauberes Zustandsmodell definieren, unabhängig vom Protokoll.
• Netzrealität prüfen: Firewalls, NAT, Paketverluste, Latenz und Sleep-Zyklen vorab testen, nicht erst nach dem Rollout.

Integration in Plattformen: Gateway-Design und Datenmodell nicht vergessen

Protokolle sind Transport, Semantik kommt oben drauf

Selbst die beste Protokollwahl löst nicht automatisch die Frage, wie Daten konsistent beschrieben werden: Einheiten, Zeitstempel, Sensor-IDs, Qualitätskennzeichen und Gerätestatus müssen in einem Datenmodell festgelegt werden. Ohne diese Semantik entstehen später schwer wartbare „Topic-Wildwuchs“ oder uneinheitliche REST-Endpunkte. Ein Gateway kann hier normalisieren, validieren und bei Bedarf Daten verdichten (z. B. Mittelwerte statt Rohdaten) – besonders wichtig bei limitierten Bandbreiten.

Testbarkeit und Betrieb: Was später Zeit spart

In der Umsetzung lohnt sich ein Fokus auf Betriebsdetails: saubere Timeout-Strategien, klare Retry-Politik, Limits für Message-Größen, sowie Logging auf Gateway/Broker/API-Ebene. Auch Lasttests mit realistischen Payloads (inkl. Peaks) verhindern Überraschungen. Die Wahl des Protokolls sollte deshalb immer zusammen mit Observability und Betriebskonzept betrachtet werden, nicht als reine Entwicklerentscheidung.