MQTT vs. HTTP für IoT: Welches Protokoll solltest du nutzen?

HTTP treibt das Web an; MQTT wurde für Maschinen in unzuverlässigen Netzen entwickelt. Beide laufen über TCP, beide lassen sich mit TLS absichern, und beide können JSON transportieren. Der Unterschied liegt im Kommunikationsmodell – und genau dieses Modell entscheidet, welches Protokoll zu deinem IoT-Workload passt. Dieser Artikel vergleicht beide ehrlich, auch dort, wo HTTP die bessere Wahl ist.

Zwei unterschiedliche Kommunikationsmodelle

HTTP ist Request/Response. Ein Client fragt einen bestimmten Server nach einer bestimmten Ressource und wartet auf die Antwort. Der Server kann nicht von sich aus sprechen: Muss ein Gerät von einer Änderung erfahren, muss es pollen, einen langen Request offen halten oder einen zusätzlichen Mechanismus wie Server-Sent Events oder WebSockets nutzen.

MQTT ist Publish/Subscribe. Clients verbinden sich mit einem Broker und halten die Verbindung offen. Publisher senden Nachrichten an Topics; der Broker pusht sie an jeden Subscriber dieses Topics. Sender und Empfänger müssen nichts voneinander wissen. Wenn das Modell neu für dich ist, lies zuerst Was ist MQTT?.

MQTT vs. HTTP im Vergleich

Overhead und Akkulaufzeit

Ein minimales MQTT-Paket wie PINGREQ ist gerade einmal 2 Bytes groß, und ein Publish ergänzt einen kleinen Header nur um Topic-Namen und Payload. Ein HTTP-Request enthält eine Request-Zeile, einen Host-Header und oft User-Agent-, Content-Type-, Authorization- und Cookie-Header – als Text, bei jedem Request. Sendet ein Sensor alle paar Sekunden einen 20-Byte-Messwert, dominiert dieses Drumherum den Traffic.

Der Verbindungsaufbau wiegt noch schwerer. Jede neue HTTPS-Verbindung kostet einen TCP- und einen TLS-Handshake, also Funkzeit und Akku auf einem Mobilfunkgerät. MQTT zahlt diesen Preis einmal und nutzt die Verbindung danach in beide Richtungen. HTTP-Keep-Alive und HTTP/2 verkleinern den Abstand, geben dem Server aber keine Möglichkeit, zum Gerät zu pushen.

Zuverlässigkeit in schlechten Netzen

MQTT hat Zustellsemantik im Protokoll. QoS 1 und 2 bestätigen Nachrichten und wiederholen sie, persistente Sessions puffern Nachrichten für Clients, die wegfallen, Retained Messages geben einem neuen Subscriber sofort den letzten bekannten Wert, und ein Last Will informiert alle, wenn ein Gerät ohne Abschied verschwindet. Bei HTTP baust du all das selbst: Retries, Idempotency Keys, einen Status-Speicher und einen Heartbeat-Endpunkt.

Sicherheit

Beide Protokolle setzen für die Verschlüsselung auf TLS, keines ist also von Natur aus sicherer. Der Unterschied liegt darin, wo autorisiert wird. Eine HTTP-API authentifiziert jeden Request, meist mit einem Token, und autorisiert ihn pro Endpunkt. Ein MQTT-Broker authentifiziert einmal beim CONNECT (Benutzername/Passwort, Client-Zertifikate oder in MQTT 5 Enhanced Authentication) und autorisiert danach jedes Publish und Subscribe anhand von Zugriffsregeln auf Topic-Ebene. Eine durchdachte Topic-Hierarchie ist daher Teil deines Sicherheitsmodells: Eine Regel wie dieses Gerät darf nur in seinen eigenen Teilbaum publishen lässt sich leicht formulieren, wenn Topics die Geräte-ID enthalten.

Skalierung

HTTP-Services skalieren horizontal hinter einem Load Balancer, weil jeder Request unabhängig ist. MQTT-Broker halten Zustand für jeden verbundenen Client – Subscriptions, Sessions, Nachrichten in flight –, daher bedeutet Skalieren auf große Flotten, den Broker zu clustern oder einen Anbieter zu nutzen, der das tut. Auf Consumer-Seite verteilen Shared Subscriptions aus MQTT 5 Nachrichten auf mehrere Backend-Worker. Keiner der beiden Ansätze ist insgesamt schwieriger; sie verlagern die Komplexität nur an unterschiedliche Stellen.

Derselbe Messwert, zwei Wege

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

Bei HTTP entscheidet die API, wer den Messwert als Nächstes bekommt. Bei MQTT können ein Dashboard, ein Datenbank-Writer und ein Alerting-Service alle testmqtt/+/temp abonnieren, ohne dass das Gerät von ihnen weiß.

Live-Messwerte im Browser abonnieren

Wann du MQTT einsetzen solltest

• Häufige Telemetrie von vielen Geräten.
• Befehle an Geräte hinter NAT oder Firewalls senden – sie verbinden sich nach außen, der Broker pusht hinein.
• Echtzeit-Dashboards und Alarme, die Push statt Polling brauchen.
• Eingeschränkte Hardware, volumenbasierte Verbindungen oder akkubetriebene Geräte.
• Ein Event, das von mehreren unabhängigen Services konsumiert wird.

Wann du HTTP einsetzen solltest

• Abfragen und Verwalten von Ressourcen (Geräteregister, Einstellungen, Benutzerkonten) über eine REST-API.
• Große Dateiübertragungen wie Firmware-Images, Logs oder Kamera-Snapshots.
• Seltene, einmalige Uploads, bei denen sich eine offene Verbindung nicht lohnt.
• Öffentliche APIs für Dritte, die Standard-Web-Tooling, Caching und Auth erwarten.

Und was ist mit Browsern?

Browser können keine rohen MQTT-Verbindungen öffnen, aber MQTT läuft problemlos über WebSockets, die als HTTP-Upgrade-Request beginnen. So bekommen Web-Dashboards Live-Push über dieselben Topics, die auch deine Geräte nutzen. Ports und Setup findest du unter MQTT über WebSockets.

Fazit

Nimm MQTT für ereignisgesteuerte, bidirektionale Kommunikation mit vielen Geräten; nimm HTTP für ressourcenorientierte APIs und große Datenübertragungen. Wenn du unsicher bist, baue die MQTT-Seite in ein paar Minuten mit dem Online-MQTT-Client und einem öffentlichen Test-Broker als Prototyp, bevor du dich festlegst.

Häufig gestellte Fragen