MQTT vs. HTTP im IoT: Welches Protokoll sollten Sie verwenden?

MQTT vs HTTP ist meist die erste Protokollentscheidung in einem IoT-Projekt, und eine Fehlentscheidung zeigt sich später in leeren Akkus, trägen Dashboards oder einem Server, der unter Polling-Anfragen begraben ist. Dieser Leitfaden vergleicht beide hinsichtlich Overhead, Push gegenüber Polling, Energieverbrauch und Verbindungsmodell und liefert Ihnen ein Benchmark-Skript, damit Sie den Unterschied in Ihrem eigenen Netzwerk messen, statt sich auf die Aussagen anderer zu verlassen.

Zwei unterschiedliche Kommunikationsmodelle

HTTP ist ein Request/Response-Protokoll. Ein Client öffnet eine Verbindung, sendet eine Anfrage mit Methode, Pfad und Headern, und der Server antwortet. Der Server kann nicht von sich aus sprechen. Muss ein Gerät wissen, ob ein neuer Befehl wartet, muss es fragen, immer und immer wieder.

MQTT ist ein Publish/Subscribe-Protokoll. Jeder Client hält eine langlebige TCP-Verbindung zu einem Broker, publiziert Nachrichten auf Topics und abonniert die Topics, die ihn interessieren. Der Broker pusht passende Nachrichten in dem Moment, in dem sie eintreffen. Publisher und Subscriber adressieren einander nie direkt, und genau deshalb kann ein Sensormesswert gleichzeitig ein Dashboard, einen Datenbank-Writer und einen Alarmdienst erreichen. Wenn Sie sehen möchten, was in der Mitte sitzt, lesen Sie, was ein MQTT-Broker tut.

Dieser eine Unterschied, wer das Gespräch beginnt, bestimmt fast jede weitere Abwägung unten.

MQTT vs. HTTP im Überblick

Overhead: Bytes auf der Leitung

Jede HTTP-Anfrage enthält eine Request-Zeile, einen Host-Header und meist Content-Type, Content-Length, Authorization, User-Agent und mehr. All das ist Text und wird bei jeder Anfrage erneut gesendet. Bei einem 20 Byte großen Sensormesswert können die Header leicht zehnmal größer sein als die Daten.

Ein MQTT-PUBLISH-Paket hat einen festen Header von nur 2 Byte, den Topic-Namen und die Payload. Die Authentifizierung erfolgt einmal, beim CONNECT. Danach kostet jeder Messwert kaum mehr als sein Topic und seine Daten. MQTT 5 kann das mit Topic Aliases weiter verkleinern, die einen langen Topic-String durch eine kleine Ganzzahl ersetzen.

TLS verändert das Bild für beide. Der Handshake ist teuer, und HTTP-Clients, die pro Anfrage eine neue TLS-Verbindung öffnen, zahlen ihn jedes Mal. MQTT zahlt ihn einmal pro Verbindung. HTTP-Keep-Alive und HTTP/2 verringern den Abstand, doch viele eingeschränkte HTTP-Clients nutzen sie nicht.

Push vs. Polling

Muss die Cloud einen Befehl an ein Gerät senden, bietet HTTP drei Möglichkeiten: häufig pollen und Bandbreite verschwenden, selten pollen und Latenz akzeptieren oder einen zweiten Kanal wie WebSocket oder Server-Sent Events anflanschen. MQTT stellt einfach zu. Ein Gerät, das devices/pump-7/cmd abonniert hat, erhält einen Befehl, sobald er publiziert wird, typischerweise innerhalb eines Netzwerk-Round-Trips.

Polling skaliert auch auf dem Server schlecht. Tausend Geräte, die alle fünf Sekunden pollen, bedeuten Hunderte Anfragen pro Sekunde, egal ob sich etwas geändert hat. Mit MQTT ist der Broker untätig, bis es etwas zu sagen gibt. In der Fertigung zeigt sich das besonders deutlich: Fragen MES, OEE-Dashboard und Energiemonitoring jede Maschine einer Halle einzeln per REST ab, vervielfacht sich die Last mit jedem neuen System. In einem Unified Namespace (UNS) dagegen publiziert jede Maschine ihren Zustand einmal in eine ISA-95-Topic-Struktur wie acme/werk-stuttgart/montage/linie-1/zelle-3/zustand, und jedes System abonniert nur, was es braucht.

Auswirkungen auf Akku und Netzwerk

Bei batteriebetriebenen Geräten ist das Funkmodul meist der größte Energieverbraucher, und entscheidend ist, wie oft und wie lange es eingeschaltet ist. HTTP-Polling weckt das Funkmodul nach Zeitplan, öffnet eine Verbindung, handelt möglicherweise TLS aus, sendet Header und wartet auf eine Antwort. MQTT hält eine Verbindung mit kleinen PINGREQ-Paketen im Keep-Alive-Intervall offen und überträgt ansonsten nur echte Daten.

Das macht MQTT nicht automatisch für jedes batteriebetriebene Gerät besser. Ein Sensor, der einmal pro Stunde aufwacht, einen Messwert sendet und wieder schläft, profitiert nicht von einer dauerhaften Verbindung, und ein einzelner HTTP-POST kann einfacher sein. Das Modell der dauerhaften Verbindung zahlt sich aus, wenn Geräte häufig senden, Befehle empfangen müssen oder ihren Online-Status melden sollen. Bei Mobilfunkverbindungen, bei denen jedes Byte und jeder Verbindungsaufbau Geld kostet, summieren sich kleinere Pakete und weniger Handshakes schnell.

Führen Sie Ihren eigenen Benchmark MQTT vs. HTTP aus

Die Zahlen hängen von Ihrem Netzwerk, Ihren TLS-Einstellungen und Ihrer Bibliothek ab, also messen Sie. Das folgende Skript sendet 200 kleine JSON-Messwerte per MQTT an den kostenlosen öffentlichen MQTT-Broker und 200 per HTTP POST an einen lokalen Testserver und gibt anschließend die jeweils benötigte Zeit aus. Der öffentliche MQTT-Broker ist für solche Tests gedacht, nicht für Produktionsdaten. Installieren Sie zuerst die beiden Abhängigkeiten.

pip install "paho-mqtt>=2.0" requests

import json
import threading
import time
import uuid
from http.server import BaseHTTPRequestHandler, HTTPServer

import paho.mqtt.client as mqtt
import requests

N = 200
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}"
reading = json.dumps({"device": "bench-1", "temp": 21.7, "hum": 48})

# --- Minimaler lokaler HTTP-Endpunkt ---
class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers["Content-Length"]))
        self.send_response(204)
        self.end_headers()
    def log_message(self, *args):
        pass

server = HTTPServer(("127.0.0.1", 8080), Handler)
threading.Thread(target=server.serve_forever, daemon=True).start()

# --- HTTP: ein POST pro Messwert, jedes Mal neue Verbindung ---
start = time.perf_counter()
for _ in range(N):
    requests.post("http://127.0.0.1:8080/telemetry", data=reading,
                  headers={"Content-Type": "application/json"})
http_new = time.perf_counter() - start

# --- HTTP: eine Keep-Alive-Session wiederverwenden ---
session = requests.Session()
start = time.perf_counter()
for _ in range(N):
    session.post("http://127.0.0.1:8080/telemetry", data=reading,
                 headers={"Content-Type": "application/json"})
http_keepalive = time.perf_counter() - start

# --- MQTT: eine Verbindung, QoS 1, auf jedes PUBACK warten ---
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"bench-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

start = time.perf_counter()
for _ in range(N):
    info = client.publish(f"{PREFIX}/telemetry", reading, qos=1)
    info.wait_for_publish()
    time.sleep(0.11)  # unter dem Limit von 10 Nachrichten/s pro Client des öffentlichen Brokers bleiben
mqtt_elapsed = time.perf_counter() - start - N * 0.11

client.loop_stop()
client.disconnect()
server.shutdown()

print(f"HTTP new connection : {http_new:.2f}s")
print(f"HTTP keep-alive     : {http_keepalive:.2f}s")
print(f"MQTT QoS 1 (net)    : {mqtt_elapsed:.2f}s")

Zwei Einschränkungen halten den Vergleich fair. Der HTTP-Server läuft auf localhost und hat daher keinen Internet-Round-Trip, während der MQTT-Broker entfernt ist; richten Sie den HTTP-Test auf einen echten entfernten Endpunkt, wenn Sie einen gleichwertigen Latenztest möchten. Und der öffentliche MQTT-Broker begrenzt jeden Client auf 10 Nachrichten pro Sekunde, daher pausiert das Skript zwischen den Publishes und zieht diese Zeit ab. Möchten Sie Bytes statt Zeit vergleichen, führen Sie dasselbe Skript unter Wireshark aus und vergleichen Sie die Gesamtbytes pro Messwert. Dort ist der Unterschied meist am auffälligsten.

Wann HTTP die richtige Wahl ist

HTTP bleibt in mehreren Situationen das bessere Werkzeug:

• Seltene Uploads von Geräten, die lange schlafen und nie Befehle brauchen.
• Große Übertragungen wie Firmware-Images, Logs oder Kamera-Snapshots, bei denen HTTP-Range-Requests, CDNs und Caching glänzen.
• Öffentliche und Partner-APIs, bei denen jeder Entwickler und jedes Werkzeug bereits REST spricht.
• Restriktive Netzwerke, die nur ausgehendes HTTPS erlauben. Selbst hier ist MQTT über sicheres WebSocket oft zulässig, weil es als gewöhnliches HTTPS-Upgrade beginnt.

Viele reale Systeme nutzen beides: MQTT für Telemetrie, Befehle und Status, HTTP für Provisionierung, Firmware-Downloads und Backoffice-APIs. Ein kleiner Bridge-Dienst, der MQTT abonniert und einen REST-Endpunkt bereitstellt, ist ein verbreitetes Muster; der Leitfaden MQTT zu REST-API mit Flask zeigt eines.

Wann MQTT die richtige Wahl ist

Wählen Sie MQTT, wenn Geräte häufig melden, wenn die Cloud Geräte schnell erreichen muss, wenn mehrere Konsumenten dieselben Daten brauchen oder wenn Sie wissen müssen, welche Geräte online sind. Retained Messages liefern Nachzüglern den aktuellen Zustand, Last Will publiziert einen Offline-Status, wenn ein Gerät wegfällt, und QoS-Stufen erlauben, Overhead pro Nachricht gegen Zustellgarantien abzuwägen. Der Artikel zum MQTT-Publish/Subscribe-Modell erklärt, warum die Entkopplung von Produzenten und Konsumenten mit wachsendem System wichtig wird.

Der Preis von MQTT ist, dass Sie einen Broker brauchen, und ihn zuverlässig zu betreiben ist echte Betriebsarbeit, von TLS-Zertifikaten bis zu Verbindungslimits. ConnectMQ übernimmt diese Seite für Sie. Das ist der Hauptgrund, warum Teams einen verwalteten MQTT-Broker wählen, statt einen eigenen zu pflegen. Wenn Sie noch an den Grundlagen arbeiten, behandelt das MQTT-Tutorial Topics, QoS und Sessions Schritt für Schritt.

Entscheidungs-Checkliste

1. Muss der Server Daten oder Befehle an Geräte pushen? Wenn ja, tendieren Sie zu MQTT.
2. Senden Geräte mehr als ein paar Mal pro Stunde Daten? Wenn ja, tendieren Sie zu MQTT.
3. Konsumieren mehrere Dienste dieselben Daten? Wenn ja, tendieren Sie zu MQTT.
4. Ist die Payload groß oder der Austausch eine einmalige Dateiübertragung? Wenn ja, nutzen Sie HTTP.
5. Müssen Dritte sich mit Standard-Webwerkzeugen integrieren? Stellen Sie HTTP am Rand Ihres Systems bereit.
6. Ist der Online-/Offline-Status wichtig? MQTT liefert Ihnen Keep Alive und Last Will gratis.

Probieren Sie MQTT auf ConnectMQ aus

Am schnellsten klären Sie die Frage MQTT vs. HTTP für Ihr Projekt, indem Sie Ihr eigenes Gerät gegen einen echten Broker laufen lassen. ConnectMQ bietet Ihnen einen privaten, TLS-gesicherten Broker auf den Ports 8883 und 8084 mit generierten Zugangsdaten, einem MQTT-Client im Browser und einem Live-Topic-Explorer. Starten Sie mit dem kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und vergleichen Sie die Ergebnisse mit Ihrem aktuellen HTTP-Setup.

Häufig gestellte Fragen

Ist MQTT schneller als HTTP?

Bei häufigen kleinen Nachrichten meist ja, weil MQTT eine Verbindung wiederverwendet und weit kleinere Header sendet. Bei einer einzelnen großen Übertragung ist der Unterschied gering, und HTTP-Werkzeuge sind oft besser.

Kann MQTT eine REST-API ersetzen?

Es kann Polling-basierte Geräteendpunkte ersetzen, doch REST passt weiterhin besser für öffentliche APIs, CRUD-Operationen und Dateiübertragungen. Die meisten IoT-Plattformen nutzen beides.

Verbraucht MQTT weniger Akku als HTTP?

Wenn Geräte häufig kommunizieren oder Befehle empfangen müssen, in der Regel ja, da wiederholte Handshakes und Polling entfallen. Geräte, die selten aufwachen, um einen Messwert zu senden, profitieren kaum.

Können Browser MQTT nutzen wie HTTP?

Ja, über MQTT über WebSocket. Browser-Clients verbinden sich mit einer URL wie wss://broker.connectmq.com:8084/mqtt über eine Bibliothek wie MQTT.js.