Die maximale MQTT-Nachrichtengröße liegt laut Spezifikation bei etwa 256 MB pro Paket. Entscheidend ist aber das Limit, das Ihr Broker, Ihre Client-Bibliothek und der Speicher Ihres Geräts vorgeben, und das ist meist weit niedriger. Dieser Leitfaden erklärt jedes dieser Limits, was passiert, wenn eine Nachricht zu groß ist, und drei Strategien, mit denen Sie große Payloads wie Bilder, Logs oder Firmware übertragen, ohne Ihre MQTT-Verbindungen zu gefährden.
Die Protokollgrenze: 256 MB
MQTT kodiert die Länge von Variable Header und Payload jedes Pakets in einem Feld „Remaining Length“ von bis zu vier Byte mit jeweils sieben nutzbaren Bits. Der größte Wert, der hineinpasst, sind 268.435.455 Byte, rund 256 MB. Abzüglich Topic-Name und Headern ist das der theoretisch maximale Payload. Die Kodierung wird im Leitfaden zur MQTT-Paketstruktur Byte für Byte erklärt.
Niemand betreibt Produktionssysteme in der Nähe dieser Grenze. Ein Broker, der von jedem Client Nachrichten mit 256 MB annimmt, ließe sich leicht in die Knie zwingen: Er muss das Paket puffern, es möglicherweise für Offline-Sessions oder als Retained-Wert speichern und an jeden Subscriber kopieren. MQTT wurde für viele kleine Nachrichten entworfen, und jede Schicht eines realen Deployments spiegelt das wider.
Wo die echten Limits liegen
| Schicht | Typisches Limit | Wodurch festgelegt |
|---|---|---|
| MQTT-Spezifikation | 268.435.455 Byte pro Paket | Kodierung der Remaining Length |
| Broker | Konfigurierte maximale Nachrichten- oder Paketgröße | Broker-Konfiguration oder Plan |
| Aushandlung in MQTT 5 | Property Maximum Packet Size | Client und Broker teilen jeweils mit, was sie akzeptieren |
| Client-Bibliothek | Interne Puffergröße | Bibliotheksstandards, z. B. 256 Byte in Arduino PubSubClient |
| Gerät | Freier RAM | Ein Mikrocontroller hat eventuell nur einige Dutzend KB frei |
| Netzwerk | Durchsatz und Stabilität | Große Nachrichten dauern länger und scheitern auf schwachen Verbindungen häufiger |
Das kleinste Limit in der Kette gewinnt. Ein Broker, der 1 MB akzeptiert, ist irrelevant, wenn ein ESP8266-Subscriber nur wenige Kilobyte puffern kann. Wenn Sie mit Hardware der Arduino-Klasse arbeiten, behandelt der Leitfaden zur Puffergröße von PubSubClient genau diese Falle.
Maximale MQTT-Nachrichtengröße bei ConnectMQ
Dies sind die aktuellen Limits pro Broker-Typ:
| Broker | Maximale Nachrichtengröße |
|---|---|
| Öffentlicher MQTT-Broker (broker.connectmq.com) | 64 KB |
| Serverless (Free) Plan | 256 KB |
| Serverless (Paid) Plan | 1 MB |
| Dedicated, BYOC und Self Managed Enterprise | Abhängig vom Deployment |
Für die meisten Telemetriedaten, Alarme und Befehle sind selbst 64 KB großzügig: Ein JSON-Sensorwert liegt typischerweise deutlich unter 1 KB, und auch ein SPS-Datenblock mit einigen Dutzend Prozesswerten bleibt meist im einstelligen Kilobyte-Bereich. Der öffentliche MQTT-Broker ist dabei nur für Tests und Prototypen gedacht, nicht für Produktionsdaten. Wenn Sie regelmäßig an diese Grenzen stoßen, ist das meist ein Zeichen, dass der Payload woanders hingehört, wie unten beschrieben.
Maximum Packet Size in MQTT 5
MQTT 5 hat Größenlimits mit der Property Maximum Packet Size (0x27) explizit gemacht:
- Im CONNECT teilt der Client dem Broker das größte Paket mit, das er empfangen will. Der Broker darf nichts Größeres senden; er verwirft solche Nachrichten für diesen Client stattdessen.
- Im CONNACK teilt der Broker dem Client das größte Paket mit, das er akzeptiert. Ein Client, der mehr sendet, verletzt das Protokoll.
Beachten Sie, dass dies die Größe des gesamten Pakets ist, einschließlich Fixed Header, Topic und Properties, nicht nur des Payloads. Lassen Sie etwas Spielraum.
Das Limit des Brokers in MQTT.js auslesen:
const mqtt = require("mqtt");
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
clientId: "size-check-8b4d",
protocolVersion: 5,
properties: { maximumPacketSize: 64 * 1024 }, // was dieser Client akzeptiert
});
client.on("connect", (connack) => {
const max = connack.properties?.maximumPacketSize;
console.log("Broker maximum packet size:", max ?? "not announced");
client.end();
});
Fehlt die Property, hat der Broker im CONNACK kein Limit angekündigt, kann aber dennoch eines durchsetzen. Kennen Sie immer das dokumentierte Limit Ihres Brokers.
Was passiert, wenn eine Nachricht zu groß ist
Das Verhalten hängt von Protokollversion und Richtung ab:
- Client zum Broker, MQTT 5. Der Broker trennt den Client typischerweise mit Reason Code
0x95 Packet too large. - Client zum Broker, MQTT 3.1.1. Es gibt keinen Reason Code; der Broker schließt die Verbindung. Der Client sieht einen allgemeinen Verbindungsverlust.
- Broker zum Client. Hat ein Subscriber eine kleinere Maximum Packet Size angekündigt, verwirft der Broker die Nachricht für diesen Subscriber. In 3.1.1 kann die Bibliothek des Subscribers beim Parsen scheitern oder die Verbindung trennen.
- Im Client. Manche Bibliotheken verweigern das Senden und geben einen Fehler zurück; Arduino PubSubClient liefert bei
publish()einfachfalse.
Gefährlich ist das Muster eines Clients, der die übergroße Nachricht in die Warteschlange stellt, sich neu verbindet und sie sofort erneut sendet. Das Ergebnis ist eine Trennungsschleife, einer der klassischen Gründe, warum ein MQTT-Client ständig die Verbindung trennt. Prüfen Sie die Größe vor dem Publish und verwerfen oder leiten Sie zu große Nachrichten um.
Strategien für große Payloads
1. Den Payload verkleinern
Bevor Sie etwas aufteilen, verkleinern Sie es. Feldnamen in JSON wiederholen sich in jeder Nachricht; kurze Schlüssel, binäre Kodierungen wie CBOR oder Protobuf und gzip-Kompression verkleinern Payloads oft drastisch. Auch nur geänderte Werte statt des vollständigen Zustands zu senden hilft. Der Leitfaden zum MQTT-Payload-Format vergleicht die Optionen.
2. Die Nachricht in Chunks aufteilen
Ist ein Payload mäßig groß, etwa einige Hundert Kilobyte Logdaten, können Sie ihn in nummerierte Chunks aufteilen und auf der Empfängerseite wieder zusammensetzen. Dieser Python-Publisher teilt eine Datei in Chunks von 32 KB mit einem kleinen JSON-Header pro Chunk:
import base64, hashlib, json, math, time, uuid
import paho.mqtt.client as mqtt
CHUNK = 32 * 1024
TOPIC = "connectmq/demo/8b4d/files"
def send_file(client, path):
data = open(path, "rb").read()
transfer_id = uuid.uuid4().hex[:8]
total = math.ceil(len(data) / CHUNK)
sha = hashlib.sha256(data).hexdigest()
for i in range(total):
part = data[i * CHUNK:(i + 1) * CHUNK]
msg = {"id": transfer_id, "seq": i, "total": total, "sha256": sha,
"data": base64.b64encode(part).decode()}
client.publish(f"{TOPIC}/{transfer_id}", json.dumps(msg), qos=1).wait_for_publish()
time.sleep(0.15) # Rate-Limits pro Client einhalten
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="chunker-8b4d")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
send_file(client, "report.csv")
client.loop_stop()
client.disconnect()
Base64 vergrößert die Daten um etwa ein Drittel, aus 32 KB Binärdaten werden auf der Leitung also rund 43 KB, bequem unter dem Limit von 64 KB des öffentlichen MQTT-Brokers. Der Subscriber sammelt die Chunks anhand von id, sortiert sie nach seq und prüft den SHA-256, sobald alle total Teile eingetroffen sind. Verwenden Sie QoS 1, damit Chunks nicht stillschweigend verloren gehen, und planen Sie für Duplikate und fehlende Teile einen Timeout ein. Beachten Sie auf dem öffentlichen MQTT-Broker das Limit von 10 Nachrichten pro Sekunde; genau dafür sorgt das Sleep.
Chunking erhöht die Komplexität. Reservieren Sie es daher für Payloads, die für eine Nachricht zu groß, aber klein genug sind, dass MQTT das richtige Transportmittel bleibt.
3. Die Datei out of band senden
Für Bilder, Videos, Firmware-Images und große Exporte ist es am robustesten, die Bytes komplett aus MQTT herauszuhalten. Laden Sie die Datei per HTTPS in einen Objektspeicher oder auf einen Webserver hoch und veröffentlichen Sie dann eine kleine MQTT-Nachricht, die darauf verweist:
{
"type": "firmware",
"version": "2.4.1",
"url": "https://files.example.com/fw/sensor-2.4.1.bin",
"sha256": "9f2c...e81a",
"size": 1048576
}
Die Geräte laden die Datei mit HTTP-Range-Requests und Fortsetzungsunterstützung herunter, prüfen den Hash und melden den Fortschritt per MQTT zurück. So behalten Sie die Stärken von MQTT, sofortige Benachrichtigung und Verteilung an viele Geräte, während HTTP und Speicherdienste den Massentransfer übernehmen. Ein typisches Beispiel aus der Fertigung ist eine Kamera-Prüfstation zur Qualitätskontrolle: Das Prüfbild landet im Objektspeicher, während eine kleine Nachricht mit Ergebnis, Bild-URL und Prüfsumme im Unified Namespace (UNS) unter dem Knoten der Zelle erscheint, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/qualitaet. MES und Qualitätsdashboards abonnieren dieses Topic, ohne je Megabytes über den Broker zu ziehen.
Checkliste zur Größenentscheidung
- Unter 10 KB: als eine Nachricht senden, keine besondere Behandlung.
- Von 10 KB bis zum Limit Ihres Brokers: komprimieren oder eine kompakte Kodierung verwenden und sicherstellen, dass jeder Subscriber die Nachricht puffern kann.
- Über dem Limit, aber nur gelegentlich: mit Sequenznummern und Prüfsummen in Chunks aufteilen.
- Große Binärdateien oder regelmäßige Massentransfers: out of band hochladen und einen Verweis veröffentlichen.
- In jedem Fall: die Größe im Code prüfen, bevor Sie publish aufrufen.
Nachrichten über ConnectMQ senden
ConnectMQ bietet Ihnen klare, planbasierte Limits, von Nachrichten mit 256 KB im kostenlosen Serverless-Plan bis zu 1 MB im kostenpflichtigen Serverless-Plan, mit den Optionen Dedicated, BYOC und Self Managed Enterprise für größere Deployments. Experimentieren Sie zuerst auf dem kostenlosen öffentlichen MQTT-Broker und wechseln Sie dann zu einem verwalteten MQTT-Broker, wenn Sie private Zugangsdaten und höhere Limits benötigen. Das MQTT-Tutorial behandelt die Grundlagen, falls Sie gerade erst anfangen.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und erhalten Sie in wenigen Minuten Benutzername, Passwort und Client ID. Um Hosting-Optionen zu vergleichen, lesen Sie unseren Leitfaden zur Wahl eines Cloud-MQTT-Brokers.
Häufig gestellte Fragen
Wie groß darf eine MQTT-Nachricht maximal sein?
Das Protokoll erlaubt Pakete bis 268.435.455 Byte, etwa 256 MB. In der Praxis setzen Broker deutlich niedrigere Limits; bei ConnectMQ sind es 64 KB auf dem öffentlichen MQTT-Broker, 256 KB im kostenlosen Plan und 1 MB im kostenpflichtigen Serverless-Plan.
Was passiert, wenn ich eine zu große Nachricht veröffentliche?
Der Broker lehnt sie ab, meist indem er die Verbindung schließt. MQTT-5-Clients erhalten den Reason Code 0x95 Packet too large, MQTT-3.1.1-Clients sehen nur, dass die Verbindung abbricht.
Sollte ich Dateien über MQTT senden?
Kleine Dateien lassen sich direkt oder in Chunks senden. Große Dateien laden Sie per HTTPS in einen Speicher hoch und veröffentlichen eine kleine MQTT-Nachricht mit URL und Prüfsumme.
Zählt der Topic-Name zum Größenlimit?
Broker-Limits werden oft pro Nachricht oder pro Paket angegeben, und die Maximum Packet Size in MQTT 5 zählt das gesamte Paket einschließlich Topic und Properties. Lassen Sie über Ihrer Payload-Größe etwas Spielraum.
