Wer eine Architektur für das industrielle IoT entwirft, stößt früh auf eine Grundsatzfrage. Sollen Maschinen und Systeme Daten aktiv abfragen, oder sollen sie Ereignisse einfach melden? Genau hier trennen sich zwei Protokolle und zwei Denkmodelle. MQTT vs HTTP ist deshalb keine reine Geschmacksfrage, sondern eine Architekturentscheidung. HTTP folgt dem Modell Request/Response: Ein Client fragt, ein Server antwortet. MQTT folgt dem Modell Publish/Subscribe: Ein Sender meldet ein Ereignis, ein Broker verteilt es.
Die gute Nachricht vorweg: Es ist kein Entweder-oder. In modernen Unified-Namespace-Architekturen (UNS) übernehmen beide Protokolle klar getrennte Rollen. MQTT bildet das ereignisgetriebene Rückgrat für kontinuierliche Daten. HTTP bildet die Brücke für gezielte Abfragen zwischen Systemen. Dieser Artikel erklärt die Kernunterschiede, ordnet den Vergleich MQTT vs HTTP für OT- und IT-Architekten ein und zeigt, wo jedes Protokoll seine Stärken ausspielt.
MQTT vs HTTP: die Kernunterschiede im Überblick
Der Vergleich MQTT vs HTTP lässt sich auf wenige, klar unterscheidbare Dimensionen herunterbrechen. Sie betreffen das Kommunikationsmodell, die Verbindung, den Overhead, die Zuverlässigkeit und die Skalierung. Jede dieser Dimensionen wirkt sich anders auf eine Architektur aus. Wer sie einzeln betrachtet, trifft am Ende eine fundierte Entscheidung. Die folgende Grafik zeigt den grundlegenden Unterschied zwischen aktivem Abfragen und ereignisgetriebenem Verteilen.
Kommunikationsmodell: Request/Response vs. Publish/Subscribe
HTTP arbeitet nach dem Muster Request/Response. Der Client stellt eine Anfrage, der Server liefert eine Antwort. Ohne Anfrage passiert nichts. Ein Server kann von sich aus keine Daten schicken. Wer laufend aktuelle Werte braucht, muss deshalb regelmäßig nachfragen. Dieses aktive Abfragen heißt Polling.
MQTT arbeitet nach dem Muster Publish/Subscribe. Ein Sender publiziert eine Nachricht auf ein Topic. Ein Broker verteilt sie an alle interessierten Empfänger. Sender und Empfänger kennen sich nicht und sind zeitlich entkoppelt. Der Broker kann Daten aktiv an die Consumer pushen, sobald ein Ereignis eintritt.
Dieser Unterschied hat direkte Folgen für die Architektur. Beim Polling fragt der Client immer wieder, auch wenn sich nichts geändert hat. Viele dieser Anfragen bleiben ohne neuen Inhalt. Beim Push fließen dagegen nur echte Ereignisse. Die Quelle spricht einmal, der Broker verteilt an viele. Für die Frage MQTT vs HTTP ist das der entscheidende Denkwechsel.
Verbindungsmodell: persistente Verbindung vs. Verbindung pro Anfrage
MQTT hält eine einzige persistente TCP-Verbindung offen. Über kleine Keep-Alive-Pings bleibt sie am Leben. Neue Werte laufen ohne erneuten Verbindungsaufbau über denselben Kanal. Das spart Zeit und Ressourcen bei häufigen Nachrichten.
HTTP/1.1 baut traditionell pro Anfrage eine Verbindung auf und wieder ab. Keep-Alive und HTTP/2 mildern das ab, erreichen aber nicht dieselbe Effizienz wie ein dauerhaft offener Kanal. Bei tausenden kleinen Telemetriewerten pro Minute summiert sich dieser Aufwand spürbar.
Overhead und Effizienz: 2 Byte vs. hunderte Byte
Der wohl deutlichste Unterschied im Duell MQTT vs HTTP liegt im Overhead. Der feste MQTT-Header ist minimal klein. Er beginnt bei nur 2 Byte. HTTP transportiert dagegen umfangreiche Header als Klartext. Ein vollständiger Request samt Response kommt schnell auf 800 bis über 1.000 Byte.
Für kleine Telemetriepakete bedeutet das eine Reduktion des Overheads um mehr als 90 Prozent. In Mobilfunknetzen, bei batteriebetriebenen Sensoren oder bei nutzungsbasierten Kosten wirkt sich das direkt aus.
Ein einfaches Rechenbeispiel verdeutlicht die Größenordnung. Ein Sensor sendet einen Messwert pro Sekunde über 24 Stunden. Das ergibt rund 86.400 Nachrichten pro Tag. Bei MQTT fällt dabei ein minimaler Header-Overhead an. Bei HTTP summieren sich die Header auf ein Vielfaches davon. Über viele Sensoren und viele Tage hinweg wird daraus ein erheblicher Kosten- und Bandbreitenunterschied. Die folgende Grafik macht das Verhältnis anschaulich.
Zuverlässigkeit: MQTT QoS vs. HTTP-Statuscodes
MQTT kennt drei Zustellgarantien, die sogenannten QoS-Level. QoS 0 liefert höchstens einmal aus. Mit QoS 1 liefert der Broker mindestens einmal aus. QoS 2 liefert über einen vierstufigen Handshake genau einmal aus. Der Entwickler wählt die Garantie passend zum Anwendungsfall. Mehr dazu erklärt unser Artikel zu MQTT Quality of Service (QoS).
HTTP kennt keine solchen Zustellstufen. Es liefert Statuscodes wie 200 oder 503 zurück. Ob eine Nachricht ankommt, hängt von der Anwendung ab. Wiederholungen und Fehlerbehandlung muss die Applikation selbst umsetzen. In der Praxis genügt das für viele Abfragen. Für kontinuierliche Datenströme mit klaren Garantien ist die abgestufte QoS-Logik von MQTT jedoch der robustere Ansatz.
Echtzeit und Skalierung: Push vs. Polling
MQTT verteilt jedes Ereignis genau einmal an beliebig viele Subscriber. Ein neuer Consumer belastet die Quelle nicht zusätzlich. Der Broker übernimmt die Verteilung. So skaliert das Modell auf viele Empfänger.
HTTP kennt keinen Server-Push. Wer aktuelle Daten braucht, muss pollen. Jeder Consumer erzeugt eigene Anfragen an die Quelle. Bei vielen Consumern und kurzen Intervallen wächst die Last überproportional. Behelfslösungen wie Long-Polling, WebSockets oder Server-Sent Events existieren, ersetzen das native Push-Modell aber nicht.
Zusammenfassung der wichtigsten Unterschiede
Die folgende Tabelle fasst den Vergleich MQTT vs HTTP kompakt zusammen:
| Kriterium | MQTT | HTTP |
|---|---|---|
| Kommunikationsmodell | Publish/Subscribe über Broker | Request/Response, Client-initiiert |
| Verbindung | eine persistente TCP-Verbindung | Verbindung pro Anfrage (Keep-Alive mildert ab) |
| Header-Overhead | ab 2 Byte | oft 800 bis 1.000+ Byte |
| Server-Push | ja, nativ | nein (nur über Polling/WebSockets) |
| Zustellgarantie | QoS 0, 1, 2 | keine Stufen, nur Statuscodes |
| Zustand | Sessions, Last Will, Retained Messages | zustandslos (stateless) |
| Stärke | Verteilung von Ereignissen (1:n) | gezielte Abfragen (1:1) |
MQTT bietet zudem Funktionen, die HTTP fehlen. Dazu zählen persistente Sessions, das Last Will and Testament für den unerwarteten Verbindungsabbruch und Retained Messages für den letzten bekannten Wert. HTTP bleibt bewusst zustandslos. Diese Wahl vereinfacht die Skalierung von Webdiensten, passt aber weniger zu kontinuierlichen Maschinendaten.
Wann HTTP/REST trotzdem die richtige Wahl ist
Der Vergleich MQTT vs HTTP darf HTTP nicht kleinreden. Für viele Aufgaben ist HTTP das bessere Werkzeug. Sein zustandsloses Request/Response-Modell passt überall dort, wo ein System einen konkreten Wert gezielt anfordert. Genau das ist die Domäne von REST.
RESTful APIs bilden Ressourcen über klare CRUD-Operationen ab. Sie sind einfach zu verstehen und universell unterstützt. Nahezu jede Programmiersprache, jedes Tool und jede Firewall spricht HTTP. Proxys und Load Balancer sind darauf ausgelegt. Diese Firewall- und Proxy-Freundlichkeit macht HTTP zur pragmatischen Wahl für Integrationen über Netzwerkgrenzen hinweg.
Auch die Zustandslosigkeit ist hier ein Vorteil. Jede Anfrage steht für sich und trägt ihren gesamten Kontext. Das vereinfacht das Caching und die horizontale Skalierung von Diensten. Für einmalige oder seltene Abfragen ist dieses Modell schlank und robust. MQTT würde hier unnötige Komplexität hinzufügen.
Typische Einsatzfälle für HTTP im industriellen Umfeld sind:
- ERP- und MES-Abfragen: Ein System holt gezielt einen Auftrag oder einen Materialstamm. Die Antwort kommt einmalig und korreliert.
- Analytics-Pulls: Ein Analyse-Dienst fragt aggregierte Kennzahlen über eine API ab.
- RESTful CRUD: Konfigurationen und Stammdaten werden angelegt, gelesen, geändert und gelöscht.
- Dateitransfer: Größere Dateien lassen sich über HTTP unkompliziert übertragen.
Wie weit HTTP im industriellen IoT trägt und wo seine Grenzen liegen, vertieft unser Artikel zum REST-Interface im industriellen IoT. Wie sich solche Abfragen sauber in eine UNS-Architektur einfügen, zeigt der Beitrag zu industriellen APIs im Unified Namespace. Die grundsätzliche Frage synchron vs. asynchron behandelt zudem unser Artikel zu synchroner vs. asynchroner Kommunikation im UNS.
Fazit: MQTT als Rückgrat, HTTP als Brücke
Der Vergleich MQTT vs HTTP führt nicht zu einem Sieger. Er führt zu einer klaren Rollenteilung. Beide Protokolle lösen unterschiedliche Probleme und ergänzen sich in einer geschichteten Architektur. Wer sie bewusst kombiniert, baut ein robustes und skalierbares Fundament für das industrielle IoT. Die folgende Übersicht fasst zusammen, wann welches Protokoll die richtige Wahl ist. Drei zentrale Erkenntnisse:
- Zwei Denkmodelle: HTTP folgt Request/Response, MQTT folgt Publish/Subscribe. Die Wahl ist eine Architekturentscheidung, keine reine Geschmacksfrage.
- MQTT als Rückgrat: Für kontinuierliche Ereignisdaten an viele Consumer ist MQTT effizient, skalierbar und entkoppelt.
- HTTP als Brücke: Für gezielte, zustandslose Abfragen zwischen Systemen bleibt HTTP/REST die pragmatische Wahl.
Häufig gestellte Fragen (FAQ)
Ist MQTT schneller als HTTP? Für kleine, häufige Nachrichten ist MQTT meist effizienter. Der geringe Overhead und die persistente Verbindung senken Latenz und Last. Bei einer einzelnen, großen Abfrage kann HTTP dagegen gleichwertig oder besser sein. Die Frage MQTT vs HTTP hängt also vom Muster der Kommunikation ab.
MQTT oder REST: was soll ich nehmen? Nutze MQTT für kontinuierliche Ereignisse und die Verteilung an viele Consumer. Nutze REST für gezielte Abfragen und CRUD-Operationen zwischen Systemen. In der Praxis kombinieren viele Architekturen beide. Die Entscheidung MQTT vs REST folgt dem Use Case, nicht einer Grundsatzregel.
Ersetzt MQTT HTTP komplett? Nein. MQTT ersetzt HTTP nicht, sondern ergänzt es. HTTP bleibt für Request/Response, RESTful APIs und Dateitransfer relevant. MQTT übernimmt das ereignisgetriebene Rückgrat. Beide Protokolle koexistieren in modernen UNS-Architekturen.
Ist MQTT oder HTTP sicherer? Beide Protokolle setzen auf TLS für die Verschlüsselung. MQTT ergänzt das um eine Authentifizierung am Broker und eine feingranulare Rechtevergabe pro Topic. HTTP nutzt etablierte Mechanismen wie OAuth und API-Keys. Sicher sind beide, sofern sie korrekt konfiguriert werden.
