MQTT vs. HTTP für IoT: Das richtige Protokoll

Bei der Entwicklung von IoT-Systemen ist die Protokollwahl eine der grundlegendsten Architekturentscheidungen. MQTT und HTTP sind die beiden häufigsten Optionen — und sie haben sehr unterschiedliche Eigenschaften, die sie für verschiedene Szenarien mehr oder weniger geeignet machen.

MQTT: Leichtgewichtig und Publish-Subscribe

MQTT (Message Queuing Telemetry Transport) wurde in den späten 1990ern für die Überwachung von Ölpipelines entwickelt — ein Szenario mit wenig Bandbreite, hoher Latenz und vielen Geräten. Diese Ursprünge prägen das Protokoll bis heute.

MQTT-Grundkonzepte

Broker: Zentraler Server, der alle Nachrichten verwaltet (Mosquitto, HiveMQ, AWS IoT Core)

Publisher: Gerät, das Daten sendet (z.B. Temperatursensor)

Subscriber: Empfänger von Nachrichten (z.B. Dashboard-Backend)

Topic: Hierarchischer Kanal für Nachrichten (z.B. factory/hall1/machine3/temperature)

Sensor → PUBLISH auf Topic → MQTT Broker → SUBSCRIBE Clients

Quality of Service (QoS)

MQTT bietet drei Zuverlässigkeitsstufen:

• QoS 0 (At most once): Fire-and-forget. Nachricht kann verloren gehen. Schnellste Option.
• QoS 1 (At least once): Mindestens einmal zugestellt. Duplikate möglich.
• QoS 2 (Exactly once): Genau einmal. Langsamste, zuverlässigste Option.

Technische Eigenschaften

• Protokoll-Header: 2 Bytes (minimal)
• Verbindungstyp: Persistent TCP-Verbindung
• Kommunikationsmuster: Pub/Sub
• Port: 1883 (unverschlüsselt), 8883 (TLS)
• Payload: Beliebiges Binärformat (JSON, Protobuf, MessagePack)

MQTT-Implementierung

# MicroPython auf ESP32 (Sensor-Seite)
from umqtt.simple import MQTTClient
import ujson

client = MQTTClient(
    client_id="sensor_hall1_machine3",
    server="mqtt.example.com",
    port=8883,
    ssl=True,
    user="sensor_user",
    password="secret"
)

client.connect()

# Daten publizieren
def publish_reading(temperature, humidity):
    payload = ujson.dumps({
        "temperature": temperature,
        "humidity": humidity,
        "timestamp": time.time()
    })
    client.publish(
        b"factory/hall1/machine3/sensors",
        payload.encode(),
        qos=1
    )

// Node.js Backend (Subscriber)
import mqtt from 'mqtt';

const client = mqtt.connect('mqtts://mqtt.example.com:8883', {
  username: process.env.MQTT_USER,
  password: process.env.MQTT_PASS,
});

client.subscribe('factory/+/+/sensors'); // Wildcard für alle Hallen und Maschinen

client.on('message', async (topic, message) => {
  const data = JSON.parse(message.toString());
  const [_, hall, machine, _type] = topic.split('/');

  await db.sensor_readings.create({
    data: { hall, machine, ...data }
  });

  // WebSocket Push an Dashboard
  io.to(`machine:${machine}`).emit('reading', { hall, machine, ...data });
});

HTTP: Universal und zustandslos

HTTP ist das Protokoll des Webs. Es ist Request-Response-basiert, zustandslos und weit bekannt.

HTTP für IoT

# MicroPython auf ESP32 mit HTTP POST
import urequests
import ujson

def send_reading(temperature, humidity):
    payload = {
        "device_id": "sensor_hall1_machine3",
        "temperature": temperature,
        "humidity": humidity
    }

    response = urequests.post(
        "https://api.example.com/readings",
        json=payload,
        headers={"Authorization": "Bearer " + API_KEY}
    )

    return response.status_code == 201

Direkter Vergleich

Wann MQTT wählen

MQTT ist die richtige Wahl wenn:

• Viele Geräte gleichzeitig senden (100+)
• Daten kontinuierlich und hochfrequent übertragen werden (> 1/s)
• Geräte mit Batterien betrieben werden (niedriger Energieverbrauch kritisch)
• Echtzeit-Reaktion auf Geräte-Events benötigt wird
• Netzwerkverbindung unzuverlässig ist (QoS-Mechanismus)
• Bidirektionale Kommunikation (Server → Gerät) häufig benötigt wird

Typische Anwendungen: Produktionsüberwachung, Smart Home, Fahrzeugtelemetrie, Energiezähler.

Wann HTTP wählen

HTTP ist die richtige Wahl wenn:

• Wenige Geräte mit seltenen Updates (< 1/min)
• Einfachheit und Debugging-Freundlichkeit Priorität haben
• Geräte hinter restriktiven Firewalls stehen (Port 443 immer offen)
• Vorhandene HTTP-Infrastruktur (API Gateways, Auth-Services) genutzt werden soll
• Gerät nur gelegentlich Daten sendet (z.B. täglicher Bericht)
• Entwicklungsteam keine MQTT-Erfahrung hat

Typische Anwendungen: Gelegentliche Statusmeldungen, tägliche Zusammenfassungen, Firmware-Update-Checks.

Der Hybrid-Ansatz

Viele produktionsreife IoT-Systeme nutzen beide Protokolle:

Sensoren (hochfrequent) → MQTT → Backend-Broker → TimescaleDB
Aktoren (Kommandos) → MQTT → Geräte
Geräte-Konfiguration → HTTPS REST API → Gerät
Firmware-Updates → HTTPS → Gerät
Dashboard-Daten → HTTPS REST API → Frontend

Die Regel: MQTT für Gerät-zu-Backend-Datenstrom (hochfrequent, Push), HTTP für alles andere (Konfiguration, Firmware, Dashboard).

MQTT Security Best Practices

# Mosquitto-Konfiguration (mosquitto.conf)
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

# Anonymen Zugang sperren
allow_anonymous false
password_file /etc/mosquitto/passwd

# Client-Zertifikate für mTLS
require_certificate true
use_identity_as_username true

# ACL: Jedes Gerät darf nur auf eigenes Topic schreiben
acl_file /etc/mosquitto/acl

Protokollentscheidungen im IoT haben langfristige Konsequenzen — beide zu wechseln ist aufwendig, wenn Hardware bereits im Feld ist. Wenn Sie ein IoT-System aufbauen und die richtige Architektur definieren wollen, sprechen Sie mit uns.