MQTT-Bandbreitennutzung: Overhead pro Nachricht berechnen

Die MQTT-Bandbreitennutzung lässt sich leicht abschätzen, sobald Sie wissen, woher jedes Byte stammt: aus dem MQTT-Paket selbst, aus den TCP/IP-Headern, die es transportieren, aus der TLS-Verschlüsselung darum herum und aus dem Hintergrundverkehr von Verbindungsaufbau und Keep Alive. Dieser Leitfaden berechnet jede Schicht für eine realistische Telemetrienachricht mit QoS 0, 1 und 2 und macht aus den Zahlen eine monatliche Datenschätzung, die Sie bei der Wahl eines Mobilfunktarifs für Ihre Geräte nutzen können.

Warum MQTT schlank ist und wohin die Bytes trotzdem gehen

Der Fixed Header von MQTT ist nur zwei Byte groß, es gibt keine Text-Header wie bei HTTP, und eine langlebige Verbindung ersetzt den Handshake pro Anfrage. Dadurch ist der Protokoll-Overhead pro Nachricht winzig. Auf einer volumenbasierten Verbindung bezahlen Sie aber IP-Bytes, nicht MQTT-Bytes, und bei kleinen Payloads dominieren die unteren Schichten. Ein nützliches Denkmodell hat vier Schichten:

Hinzu kommen zwei Hintergrundkosten, die nicht pro Nachricht anfallen: der Verbindungsaufbau (TCP, TLS-Handshake, CONNECT) und Keep-Alive-Pings im Leerlauf. Beide werden unten behandelt. Den Aufbau der MQTT-Schicht auf Byte-Ebene finden Sie im Leitfaden zur MQTT-Paketstruktur.

MQTT-Overhead pro Nachricht nach QoS

Nehmen Sie ein typisches Beispiel: MQTT 3.1.1, das Topic plant1/line2/pump3/telemetry (28 Zeichen) und einen JSON-Payload von 48 Byte wie {"t":1760601600,"flow":12.4,"p":3.1,"temp":41.7}.

Das PUBLISH-Paket mit QoS 0 besteht aus:

• Fixed Header: 2 Byte (Typ und Flags, ein Byte Remaining Length)
• Topic: 2 Byte Längenpräfix + 28 Byte = 30 Byte
• Payload: 48 Byte
• Gesamt: 80 Byte

Bei QoS 1 und 2 erhält das PUBLISH einen Packet Identifier von 2 Byte, und es kommen Bestätigungspakete von je 4 Byte hinzu:

Bei MQTT 5 kommt im PUBLISH ein Byte für die leere Properties-Länge hinzu; Erfolgsbestätigungen ohne Properties bleiben bei 4 Byte. Auf MQTT-Ebene verändert die Wahl des QoS die Kosten also nur moderat. Der echte Unterschied zeigt sich auf der Transportschicht, denn jedes zusätzliche Paket bedeutet meist ein zusätzliches TCP-Segment. Der Leitfaden zu MQTT-QoS-Stufen erklärt, wann sich die zusätzlichen Zustellgarantien lohnen.

Der Topic-Name ist oft der größte MQTT-Kostenfaktor

Im obigen Beispiel macht das Topic 30 der 32 Byte Overhead bei QoS 0 aus. In Industrie-4.0-Projekten folgt der Topic-Baum meist einem Unified Namespace (UNS), dessen Ebenen die ISA-95-Hierarchie Enterprise → Site → Area → Line → Cell abbilden. Solche Topics wie acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur überschreiten leicht 50 Zeichen. Die sprechende UNS-Struktur müssen Sie deshalb nicht aufgeben. Zwei Abhilfen: Halten Sie geräteseitige Topics knapp, oder nutzen Sie Topic Aliases von MQTT 5, die das Topic nach dem ersten Publish durch eine Zwei-Byte-Zahl ersetzen. Der Leitfaden zum MQTT Topic Alias zeigt die Ersparnis im Detail.

TCP/IP und TLS hinzurechnen

Jedes einzeln gesendete MQTT-Paket wird in einem TCP-Segment mit mindestens 40 Byte IPv4- und TCP-Headern übertragen. Der Empfänger bestätigt Daten mit TCP-ACKs, die ebenfalls Segmente von 40 Byte sind, sofern sie nicht an Daten in Gegenrichtung angehängt werden können. Das Verhalten bei verzögerten ACKs unterscheidet sich je nach Betriebssystem und Netzwerk-Stack; betrachten Sie die ACK-Kosten daher als Näherung.

TLS verpackt jeden Schreibvorgang in einen Record. Mit TLS 1.3 und einem AES-GCM-Cipher fügt jeder Record 5 Byte Header, 1 Byte inneren Content Type und ein Authentifizierungs-Tag von 16 Byte hinzu: 22 Byte. TLS 1.2 mit AES-GCM fügt wegen einer expliziten Nonce von 8 Byte 29 Byte hinzu.

Zusammengerechnet für eine Telemetrienachricht, IPv4 ohne TCP-Optionen, TLS 1.3, mit einem reinen TCP-ACK pro Datensegment:

Bei einem Payload von 48 Byte betragen die Kosten auf der Leitung etwa das Vier- bis Achtfache der Daten. Dieses Verhältnis schrumpft mit wachsenden Payloads: Ein Payload von 1 KB hat nahezu denselben absoluten Overhead, der dann nur noch einen kleinen Anteil ausmacht. Deshalb ist das Bündeln von Messwerten, etwa eine Nachricht mit zehn Messungen statt zehn Nachrichten, die mit Abstand wirksamste Bandbreitenoptimierung.

TLS ist für echte Deployments nicht optional, und wie die Tabelle zeigt, sind seine Kosten pro Nachricht moderat. Größer sind die Kosten des Handshakes.

Kosten des Verbindungsaufbaus

Jede neue Verbindung bezahlt für:

1. TCP-Handshake: drei Segmente, etwa 120 bis 180 Byte.
2. TLS-Handshake: typischerweise einige Kilobyte, überwiegend die Zertifikatskette des Servers. Die TLS-1.3-Session-Resumption, sofern Ihre Bibliothek sie unterstützt, reduziert das erheblich.
3. CONNECT und CONNACK: Ein CONNECT mit einer Client ID von 20 Zeichen, Benutzername und Passwort umfasst etwa 80 Byte; CONNACK hat in MQTT 3.1.1 4 Byte.
4. SUBSCRIBE und SUBACK für jede Subscription, sofern Sie keine persistente Session verwenden.

Ein einziger Reconnect kann also so viel kosten wie Dutzende Telemetrienachrichten. Geräte, die sich jede Minute verbinden, einmal veröffentlichen und wieder trennen, verschwenden den Großteil ihrer Daten für Handshakes. Halten Sie die Verbindung offen, sofern das Gerät nicht lange schläft, und nutzen Sie eine persistente Session, damit Sie nicht nach jedem Reconnect neu abonnieren müssen. Der Leitfaden zu persistenten Sessions erklärt, wie das geht.

Kosten des Keep Alive

Hat ein Client während des Keep-Alive-Intervalls nichts zu senden, schickt er PINGREQ (2 Byte), und der Broker antwortet mit PINGRESP (2 Byte). Mit TLS 1.3 und TCP/IP kostet ein Ping-Austausch etwa 64 + 64 Byte plus ein ACK: rund 170 Byte.

Pings werden nur gesendet, wenn die Verbindung ansonsten inaktiv ist. Ein Gerät, das alle 30 Sekunden mit einem Keep Alive von 60 Sekunden veröffentlicht, sendet also überhaupt keine Pings. Längere Intervalle sparen Daten, riskieren aber NAT-Timeouts in Mobilfunknetzen, die inaktive Verbindungen verwerfen und einen teuren Reconnect erzwingen. Stimmen Sie den Wert mit den Hinweisen im Artikel zum MQTT-Keep-Alive-Intervall ab.

Monatliches Datenvolumen für ein Mobilfunkgerät schätzen

Typische Fälle sind Maschinen beim Kunden, die ein Maschinenbauer per Mobilfunk für Fernwartung und Zustandsüberwachung anbindet, oder verteilte Anlagen wie Pumpstationen. Dieser Python-Rechner kombiniert die Einzelteile. Passen Sie die Eingaben an Ihr Gerät an:

def mqtt_monthly_bytes(
    payload=48, topic_len=28, qos=1, msgs_per_day=1440,
    tls=True, reconnects_per_day=2, handshake_bytes=5000,
    keepalive_s=120, idle_seconds_per_day=0,
):
    ip_tcp = 40
    tls_rec = 22 if tls else 0
    publish = 2 + 2 + topic_len + payload + (2 if qos else 0)

    def seg(mqtt_bytes):
        return mqtt_bytes + tls_rec + ip_tcp

    if qos == 0:
        per_msg = seg(publish) + ip_tcp
    elif qos == 1:
        per_msg = seg(publish) + seg(4) + ip_tcp
    else:
        per_msg = seg(publish) + 3 * seg(4) + 2 * ip_tcp

    pings = idle_seconds_per_day / keepalive_s if keepalive_s else 0
    ping_bytes = pings * (2 * seg(2) + ip_tcp)
    connect_bytes = reconnects_per_day * (handshake_bytes if tls else 300)

    per_day = msgs_per_day * per_msg + ping_bytes + connect_bytes
    return per_day * 30

for qos in (0, 1, 2):
    mb = mqtt_monthly_bytes(qos=qos) / 1_000_000
    print(f"QoS {qos}: {mb:.1f} MB per month")

Bei einer Nachricht pro Minute mit QoS 1 über TLS ergeben sich rund 11 MB pro Monat und Gerät, wobei nur ein kleiner Teil auf die zwei angenommenen Reconnects entfällt. Setzen Sie msgs_per_day auf 144 (alle zehn Minuten), mit einem Keep Alive von 300 Sekunden und hinzugerechneter Leerlaufzeit, sinkt die Summe deutlich. Dies sind berechnete Schätzungen, keine Messungen; überprüfen Sie sie anhand des tatsächlichen Verbrauchs einer Test-SIM oder indem Sie einen Tag lang den Verkehr mit tcpdump mitschneiden und die Bytes summieren.

Checkliste zur Bandbreitenreduzierung

1. Bündeln Sie Messwerte zu weniger, größeren Nachrichten, wo die Latenz es zulässt.
2. Verwenden Sie kompakte Payloads: kurze JSON-Schlüssel, CBOR oder Protobuf. Siehe MQTT-Payload-Format.
3. Kürzen Sie Geräte-Topics oder nutzen Sie Topic Aliases mit MQTT 5.
4. Wählen Sie den QoS pro Topic: QoS 0 für häufige Telemetrie, bei der gelegentlicher Verlust akzeptabel ist, QoS 1 für Ereignisse und Befehle.
5. Halten Sie Verbindungen offen und nutzen Sie persistente Sessions, statt sich für jede Nachricht neu zu verbinden.
6. Stimmen Sie den Keep Alive auf den längsten Wert ab, den der NAT-Timeout Ihres Netzwerks zulässt.
7. Veröffentlichen Sie bei Änderungen statt in fester Rate, wenn Werte stabil sind.
8. Vermeiden Sie unnötige Subscriptions: Eine Wildcard-Subscription auf einem Gerät empfängt jede passende Nachricht, was Downlink-Daten kostet.

Effiziente Geräte mit ConnectMQ betreiben

ConnectMQ unterstützt MQTT 3.1.1 und 5.0, einschließlich Topic Aliases und Session Expiry, über TLS auf Port 8883 mit einem Let's-Encrypt-Zertifikat, sodass die obigen Optimierungen ohne besondere Konfiguration funktionieren. Erstellen Sie Prototypen auf dem kostenlosen öffentlichen MQTT-Broker und messen Sie dann den echten Verkehr gegen einen privaten Broker. Das MQTT-Tutorial behandelt die Grundlagen, falls das Protokoll neu für Sie ist.

Starten Sie mit ConnectMQ

Mit einem verwalteten MQTT-Broker konzentrieren Sie sich auf die Effizienz Ihrer Geräte statt auf den Serverbetrieb. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und sehen Sie mit dem Live-Topic-Explorer genau, was Ihre Geräte senden. Für einen breiteren Vergleich lesen Sie unseren Leitfaden zur Wahl eines Cloud-MQTT-Brokers.

Häufig gestellte Fragen

Wie viel Overhead fügt MQTT pro Nachricht hinzu?

Auf MQTT-Ebene fügt ein PUBLISH bei QoS 0 4 Byte plus den Topic-Namen hinzu, bei QoS 1 und 2 6 Byte plus das Topic, noch ohne Bestätigungen. TCP/IP und TLS kommen mit rund 60 oder mehr Byte pro Paket obendrauf.

Macht TLS MQTT deutlich teurer?

Pro Nachricht fügt TLS 1.3 etwa 22 Byte pro Record hinzu, was moderat ist. Größer sind die Kosten des Handshakes von einigen Kilobyte pro neuer Verbindung. Halten Sie Verbindungen daher offen, statt häufig neu zu verbinden.

Wie viele Daten verbraucht der MQTT Keep Alive?

Ein Ping-Austausch kostet auf MQTT-Ebene wenige Bytes, mit TCP, IP und TLS aber rund 170 Byte. Bei einem Intervall von 60 Sekunden auf einer inaktiven Verbindung sind das etwa 240 KB pro Tag.

Ist QoS 0 immer am günstigsten?

In Bytes ja, weil keine Bestätigungspakete gesendet werden. Zwingen verlorene Nachrichten Ihre Anwendung jedoch dazu, Daten erneut zu senden oder abzufragen, kann QoS 1 insgesamt günstiger sein.