MQTT-Latenz erklärt: Was die Round-Trip-Zeit beeinflusst und wie Sie sie messen

MQTT-Latenz ist die Zeit zwischen dem Senden einer Nachricht durch einen Publisher und ihrem Empfang durch einen Subscriber, und in den meisten IoT-Systemen wird sie von Faktoren außerhalb des Protokolls selbst bestimmt. Dieser Leitfaden zerlegt jede Komponente der Round-Trip-Zeit, erklärt, welche Stellschrauben wirklich zählen, und liefert ein kleines Python-Skript, mit dem Sie die Latenz aus Ihrem eigenen Netzwerk gegen einen echten Broker messen.

Was „Latenz“ bei MQTT bedeutet

Der Begriff wird für mehrere unterschiedliche Messungen verwendet, seien Sie also präzise, bevor Sie optimieren:

• One-Way-Latenz: vom Publisher zum Subscriber. Schwer exakt zu messen, weil die beiden Uhren auf verschiedenen Maschinen laufen.
• Round-Trip-Zeit (RTT): Ein Client publiziert auf ein Topic, das er selbst abonniert hat, und misst, wie lange es dauert, bis die Nachricht zurückkommt. Eine Uhr, daher ist der Wert verlässlich. Genau das misst das Skript weiter unten.
• Verbindungslatenz: Zeit vom Öffnen eines Sockets bis zum Empfang des CONNACK. Relevant für Geräte, die aufwachen, sich verbinden, publizieren und wieder schlafen.
• Bestätigungslatenz: Zeit vom PUBLISH bis zum PUBACK bei QoS 1. Sie zeigt, wann der Broker die Verantwortung für die Nachricht übernommen hat.

Für Geräte, die eine Verbindung offen halten (das übliche MQTT-Muster), ist die Round-Trip-Zeit die nützlichste Einzelkennzahl.

Die Komponenten der MQTT-Latenz

Eine Nachricht vom Sensor zum Dashboard durchläuft mehrere Stationen. Jede fügt Verzögerung hinzu:

Netzwerkdistanz

Licht in Glasfasern ist schnell, aber nicht unendlich schnell, und reale Routen sind keine geraden Linien. Ein Gerät in einem Werk bei Stuttgart, das mit einem Broker auf einem anderen Kontinent spricht, sieht immer eine höhere Grundlatenz als eines, das mit einem Broker in seiner eigenen Region spricht. Keine Protokolleinstellung kann das beseitigen; nur die Platzierung des Brokers.

TLS-Overhead

Der TLS-Handshake fügt beim Öffnen der Verbindung Round-Trips hinzu. Danach kostet symmetrische Verschlüsselung auf modernen CPUs sehr wenig und auf Chips wie dem ESP32 nur moderat. Da MQTT-Clients normalerweise stunden- oder tagelang verbunden bleiben, beeinflusst TLS vor allem die Verbindungslatenz, nicht die Nachrichtenlatenz im laufenden Betrieb. Deshalb ist „TLS ist langsam“ selten ein guter Grund für Port 1883; die Abwägungen finden Sie in MQTT-Ports erklärt.

QoS-Stufe

Das ist der am häufigsten missverstandene Teil. Bei QoS 0 leitet der Broker sofort weiter. Bei QoS 1 leitet der Broker ebenfalls sofort nach Empfang weiter, und das PUBACK läuft parallel zurück, sodass die Zustelllatenz auf einer gesunden Verbindung ähnlich wie bei QoS 0 ist. QoS 2 fügt einen vierstufigen Handshake hinzu; je nach Broker-Implementierung erfolgt die Weiterleitung nach dem ersten oder zweiten Schritt. Der größere Effekt höherer QoS betrifft den Durchsatz und das Verhalten bei Paketverlust: Neuübertragungen erhöhen die Latenz, wenn das Netzwerk Probleme macht. Der Leitfaden zu MQTT-QoS-Stufen behandelt die Abläufe im Detail.

Nagle, Pufferung und die Client-Loop

Manche Stacks verzögern kleine Schreibvorgänge, um sie zusammenzufassen. Viele MQTT-Bibliotheken deaktivieren den Nagle-Algorithmus, Embedded-Stacks und eigene Sockets aber möglicherweise nicht. Auf Mikrocontrollern fügt eine Hauptschleife, die client.loop() nur einmal pro Sekunde aufruft, eingehenden Nachrichten bis zu einer Sekunde Latenz hinzu, egal wie schnell das Netzwerk ist.

Keep-Alive und Reconnects

Keep-Alive beeinflusst die Latenz auf einer gesunden Verbindung nicht, entscheidet aber, wie schnell eine tote Verbindung erkannt wird. Eine stillschweigend abgebrochene Verbindung mit 300 Sekunden Keep-Alive kann Minuten bedeuten, bis der Client sich neu verbindet, und jede Nachricht in diesem Zeitfenster kommt zu spät.

MQTT-Latenz selbst messen

Das folgende Skript verbindet sich mit dem öffentlichen MQTT-Broker unter broker.connectmq.com, der für Tests und Prototypen gedacht ist, abonniert ein eindeutiges Topic, publiziert Nachrichten mit Zeitstempel darauf und berechnet Round-Trip-Statistiken. Mit zwei Nachrichten pro Sekunde bleibt es unter dem Limit des öffentlichen MQTT-Brokers von 10 Nachrichten pro Sekunde und Client.

# mqtt_rtt.py - MQTT-Round-Trip-Latenz messen
# pip install "paho-mqtt>=2.0"
import json
import statistics
import sys
import threading
import time
import uuid

import paho.mqtt.client as mqtt

HOST = "broker.connectmq.com"
USE_TLS = "--tls" in sys.argv
PORT = 8883 if USE_TLS else 1883
QOS = 1
SAMPLES = 50
INTERVAL = 0.5  # Sekunden zwischen Publishes (2 Nachrichten/s)

run_id = uuid.uuid4().hex[:8]
topic = f"connectmq/demo/{run_id}/rtt"
rtts = []
subscribed = threading.Event()
done = threading.Event()


def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected to {HOST}:{PORT} -> {reason_code}")
    client.subscribe(topic, qos=QOS)


def on_subscribe(client, userdata, mid, reason_code_list, properties):
    subscribed.set()


def on_message(client, userdata, msg):
    received = time.perf_counter()
    data = json.loads(msg.payload)
    rtts.append((received - data["t"]) * 1000.0)
    if len(rtts) >= SAMPLES:
        done.set()


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"rtt-{run_id}")
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
if USE_TLS:
    client.tls_set()  # nutzt den CA-Speicher des Systems

t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=60)
client.loop_start()
if not subscribed.wait(10):
    sys.exit("Subscribe timed out")
print(f"Connect + subscribe took {(time.perf_counter() - t0) * 1000:.1f} ms")

for seq in range(SAMPLES):
    payload = json.dumps({"seq": seq, "t": time.perf_counter()})
    client.publish(topic, payload, qos=QOS)
    time.sleep(INTERVAL)

done.wait(10)
client.loop_stop()
client.disconnect()

if not rtts:
    sys.exit("No messages received")

rtts.sort()
p95 = rtts[int(len(rtts) * 0.95) - 1]
print(f"samples={len(rtts)} lost={SAMPLES - len(rtts)}")
print(f"min={rtts[0]:.1f} ms  median={statistics.median(rtts):.1f} ms  "
      f"p95={p95:.1f} ms  max={rtts[-1]:.1f} ms")

Führen Sie es zweimal aus und vergleichen Sie:

python mqtt_rtt.py         # reines TCP auf 1883
python mqtt_rtt.py --tls   # TLS auf 8883

Die Ergebnisse lesen

1. Minimum entspricht ungefähr dem bestmöglichen Pfad: Netzwerk plus Broker ohne Hindernisse. Das ist Ihre Untergrenze.
2. Median ist das, was Nutzer typischerweise erleben.
3. p95 und Maximum zeigen Jitter durch WLAN-Wiederholungen, Mobilfunk-Scheduling oder überlastete Verbindungen. Für Regelkreise und Alarme sind diese Werte wichtiger als der Median.
4. Connect + Subscribe zeigt die Kosten des TLS-Handshakes. Mit --tls ist dieser Wert spürbar höher, während der Median pro Nachricht nahe am reinen TCP-Lauf bleibt.
5. Verlorene Samples bei QoS 1 bedeuten meist, dass das Skript endete, bevor verspätete Nachrichten eintrafen, oder dass die Verbindung abbrach. Prüfen Sie die Konsole auf Disconnects.

Führen Sie den Test dort aus, wo Ihre Geräte tatsächlich arbeiten (im Werksnetz, über ein Mobilfunkmodem, an einem Heimrouter), nicht nur in Ihrem Büro. Der Unterschied ist oft die wertvollste Erkenntnis.

Ein Wort zur Einordnung in der Industrieautomation: MQTT ist kein Ersatz für harte Echtzeit. Regelkreise mit festen Zykluszeiten bleiben in der SPS und im Feldbus. MQTT transportiert Maschinendaten, Zustände und Alarme in den Unified Namespace (UNS), aus dem MES, SCADA, OEE-Dashboards und Predictive-Maintenance-Anwendungen lesen. Für diese Anwendungsfälle sind Median und p95 im Bereich typischer Netzwerklatenzen fast immer ausreichend.

Praktische Wege, die MQTT-Latenz zu senken

1. Verbindungen offen halten. Einmal verbinden, viele Male publizieren. Wer pro Nachricht neu verbindet, zahlt jedes Mal den TCP- und TLS-Handshake.
2. Eine Broker-Region nahe Ihren Geräten wählen. Die Distanz bestimmt die Untergrenze.
3. QoS pro Datentyp wählen. Hochfrequente Telemetrie, bei der der nächste Messwert den letzten ersetzt, kann QoS 0 nutzen; Befehle und Alarme verdienen QoS 1.
4. Payloads kompakt halten. Große JSON-Dokumente brauchen auf langsamen Verbindungen länger. Erwägen Sie binäre Kodierungen für hochfrequente Daten und Topic Aliases aus MQTT 5, um wiederholte Topic-Namen zu verkürzen.
5. Die Client-Loop häufig bedienen. Rufen Sie auf Arduino oder ESP32 loop() in jeder Iteration auf und vermeiden Sie blockierende Verzögerungen.
6. Keep-Alive abstimmen, um tote Verbindungen schnell zu erkennen (30 bis 60 Sekunden sind üblich), ohne Bandbreite zu verschwenden.
7. Unnötige Hops vermeiden. Jede Bridge, jedes Gateway und jedes Node-RED-Relay im Pfad bringt eigene Verarbeitung und Warteschlangen mit.
8. Subscriber-Callbacks schnell machen. Übergeben Sie aufwendige Arbeit an einen Worker-Thread oder eine Queue, damit die Netzwerk-Loop nicht blockiert.

Fehlerbehebung bei hoher oder schwankender Latenz

Von der Messung zur Produktion

Der öffentliche MQTT-Broker wird gemeinsam genutzt, betrachten Sie seine Werte also als Hinweis auf Ihren Netzwerkpfad und nicht als Benchmark. Für Produktionsverkehr bietet Ihnen ein verwalteter MQTT-Broker wie ConnectMQ einen privaten, authentifizierten Endpunkt auf 8883 und 8084 ohne die öffentlichen Ratenlimits; Details zu den Plänen finden Sie im Leitfaden zu Cloud-MQTT-Brokern. Um den Test gegen Ihren eigenen ConnectMQ-Broker zu wiederholen, ergänzen Sie client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"), setzen die Client-ID auf YOUR_CLIENT_ID und starten mit --tls. Für weiteren Protokollhintergrund lesen Sie das MQTT-Tutorial und wie MQTT funktioniert.

Starten Sie mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, und richten Sie das Latenzskript mit zwei Zeilen darauf aus. Der Browser-Client und der Live-Topic-Explorer von ConnectMQ zeigen Ihnen genau, wann jede Nachricht ankommt.

Häufig gestellte Fragen

Was ist eine gute MQTT-Latenz?

Das hängt von der Distanz und dem Zugangsnetz ab. Vergleichen Sie Ihre minimale RTT mit einem einfachen Netzwerk-Ping zum Broker-Host; fügt MQTT nur wenig hinzu, ist der Broker nicht Ihr Engpass.

Macht QoS 1 MQTT langsamer als QoS 0?

Auf einer gesunden Verbindung ist die Zustelllatenz ähnlich, weil der Broker weiterleitet, bevor das PUBACK abgeschlossen ist. QoS 1 verursacht vor allem dann Overhead, wenn Pakete verloren gehen und erneut gesendet werden müssen.

Erhöht TLS die MQTT-Latenz?

TLS verlängert den Verbindungsaufbau um den Handshake, doch auf einer langlebigen Verbindung ist der Overhead pro Nachricht gering. Verbindungen offen zu halten ist der beste Weg, die Auswirkung zu minimieren.

Warum Round-Trip- statt One-Way-Latenz messen?

Round-Trip nutzt eine einzige Uhr und vermeidet so Fehler durch nicht synchronisierte Uhren auf Publisher- und Subscriber-Maschinen.