Verbindungslimits von MQTT-Brokern: Verbindungen, Nachrichtenraten und Payload-Grenzen

Die Verbindungslimits eines MQTT-Brokers legen fest, wie viele Clients Sie anbinden können, wie schnell diese publizieren dürfen und wie groß jede Nachricht sein darf. Dieser Leitfaden erklärt alle gängigen Kontingente eines verwalteten MQTT-Brokers, wie Broker mit MQTT 3.1.1 und MQTT 5 signalisieren, dass Sie eines erreicht haben, und wie Sie Clients schreiben, die bequem innerhalb der Limits Ihres Plans bleiben.

Warum verwaltete MQTT-Broker Kontingente durchsetzen

Ein verwalteter MQTT-Broker ist geteilte Infrastruktur, selbst wenn Sie einen dedizierten Cluster haben. Arbeitsspeicher, CPU, Netzwerkbandbreite und Dateideskriptoren sind endlich, und ein einziger fehlerhafter Client, etwa eine Firmware, die in einer engen Publish-Schleife hängt, oder ein Reconnect-Sturm nach einem WLAN-Ausfall, kann den Dienst für alle anderen auf denselben Maschinen beeinträchtigen. Kontingente verwandeln diese endlichen Ressourcen in explizite, vorhersehbare Limits.

Bei einem mandantenfähigen Dienst sind Kontingente auch das, wodurch Isolation in der Praxis funktioniert. ConnectMQ wendet zum Beispiel Kontingente pro Plan, Flood-Schutz und IP-Sperren nach wiederholt fehlgeschlagenen Anmeldungen an, damit das Problem eines Mandanten auch das Problem dieses Mandanten bleibt. Wenn Sie neu in diesem Modell sind, erklärt unser Beitrag dazu, was ein MQTT-Broker macht, die Grundlagen des Zusammenspiels von Clients und Brokern.

Die gängigen Kontingente von MQTT-Brokern

Die meisten Anbieter setzen eine Kombination der folgenden Limits durch. Die Namen unterscheiden sich, die Konzepte sind überall gleich.

Echte Planlimits als Beispiel

So legt ConnectMQ seine Limits pro Plan fest:

• Serverless (Free): bis zu 25 Verbindungen, QoS bis 1, Nachrichten bis 256 KB.
• Serverless (Paid): bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB, Shared Subscriptions.
• Dedicated, BYOC und Self Managed Enterprise: isolierte Bereitstellungen, dimensioniert für Ihren Workload.
• Öffentlicher MQTT-Broker (broker.connectmq.com, nur für Tests und Prototypen): 64 KB pro Nachricht, 10 Nachrichten pro Sekunde und Client, 10 Subscriptions pro Client, 8 Topic-Ebenen, QoS 0 bis 2 und Session Expiry bis zu 30 Minuten.

Wie Broker signalisieren, dass Sie ein Kontingent erreicht haben

Hier spielt die Protokollversion eine große Rolle.

MQTT 3.1.1: Raten anhand von Verbindungsabbrüchen

MQTT 3.1.1 kennt nur eine Handvoll CONNACK-Rückgabecodes und bietet dem Broker keine Möglichkeit, einen Verbindungsabbruch zu begründen. Überschreitet ein 3.1.1-Client ein Limit, schließt der Broker meist einfach die TCP-Verbindung. Der Client sieht ein allgemeines „Verbindung verloren“ und verbindet sich neu, wobei er oft erneut an dasselbe Limit stößt. Die Diagnose von Kontingentproblemen unter 3.1.1 bedeutet, Client-Logs mit dem abzugleichen, was die Konsole des Anbieters anzeigt.

MQTT 5: explizite Reason Codes

MQTT 5 hat Reason Codes für CONNACK, PUBACK, SUBACK und DISCONNECT eingeführt, wodurch Kontingentprobleme für den Client sichtbar werden. Die häufigsten sind in der OASIS-Spezifikation MQTT 5.0 definiert:

ConnectMQ unterstützt MQTT-5-Reason-Codes, einschließlich 0x97 Quota exceeded, sodass ein Client mit MQTT 5 eine genaue Ursache protokollieren kann statt eines vagen Verbindungsabbruchs. Schon das ist ein starker Grund, für neue Projekte MQTT 5 zu verwenden; den Rest finden Sie unter MQTT-5-Funktionen.

MQTT-5-Broker können Limits außerdem vorab in CONNACK-Properties wie Maximum Packet Size, Receive Maximum, Topic Alias Maximum und Maximum QoS bekannt geben. Ein gut geschriebener Client liest sie aus und passt sich an.

Clients entwerfen, die innerhalb ihrer Kontingente bleiben

Die beste Kontingentstrategie ist ein Client, der nie in die Nähe des Limits kommt. Diese Praktiken verhindern die meisten Kontingentvorfälle.

Die Broker-Limits beim Verbindungsaufbau auslesen

Das folgende Python-Beispiel verbindet sich mit paho-mqtt 2.x über TLS, gibt die vom Broker angekündigten Limits aus und protokolliert Reason Codes beim Verbindungsabbruch.

import paho.mqtt.client as mqtt

LIMIT_PROPS = ("MaximumPacketSize", "ReceiveMaximum",
               "TopicAliasMaximum", "MaximumQoS", "SharedSubscriptionAvailable")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect refused:", reason_code)
        return
    print("connected")
    for name in LIMIT_PROPS:
        value = getattr(properties, name, None)
        if value is not None:
            print(f"  broker limit {name} = {value}")

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)
    if reason_code == "Quota exceeded":
        print("plan quota hit; back off and alert an operator")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Wenn Sie zunächst ohne Konto experimentieren möchten, richten Sie dasselbe Skript auf den kostenlosen öffentlichen MQTT-Broker auf Port 1883, mit einer eindeutigen Client ID und ohne Zugangsdaten.

Publishes auf dem Client begrenzen

Verlassen Sie sich nie darauf, dass der Broker Sie drosselt. Ein kleiner Token Bucket hält Lastspitzen unter Kontrolle, was vor allem dann zählt, wenn sich ein Gerät neu verbindet und versucht, einen Rückstau nachzusenden.

const mqtt = require("mqtt");

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "YOUR_CLIENT_ID",
  username: "YOUR_USERNAME",
  password: "YOUR_PASSWORD",
  protocolVersion: 5,
  reconnectPeriod: 5000,
});

// Token Bucket: höchstens RATE Nachrichten pro Sekunde, Burst bis BURST.
const RATE = 5;
const BURST = 10;
let tokens = BURST;
setInterval(() => { tokens = Math.min(BURST, tokens + RATE); }, 1000);

const queue = [];
function enqueue(topic, payload) { queue.push({ topic, payload }); }

setInterval(() => {
  while (tokens >= 1 && queue.length > 0 && client.connected) {
    const { topic, payload } = queue.shift();
    client.publish(topic, payload, { qos: 1 });
    tokens -= 1;
  }
}, 100);

client.on("connect", () => console.log("connected"));
client.on("disconnect", (packet) => console.log("broker disconnect, reason", packet.reasonCode));

// Nachsenden eines Rückstaus nach einem Ausfall simulieren.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));

Beim Reconnect mit Jitter zurückweichen

Wenn ein Standort die Konnektivität verliert, verbinden sich womöglich Hunderte Geräte in derselben Sekunde neu. Ohne zufälliges Backoff erreichen sie gemeinsam das Kontingent für die Verbindungsrate, scheitern gemeinsam und versuchen es gemeinsam erneut. Fügen Sie jeder Reconnect-Verzögerung zufälligen Jitter hinzu und begrenzen Sie die maximale Verzögerung auf ein bis zwei Minuten.

Client IDs eindeutig und stabil halten

Bei verwalteten MQTT-Brokern, die Client IDs an ausgegebene Zugangsdaten binden, wie es ConnectMQ tut, sind Duplikate eine häufige Falle. Kopieren Sie einen Satz Zugangsdaten auf zwei Geräte, wirft jede Verbindung die andere hinaus, was MQTT 5 als 0x8E Session taken over meldet. Das Ergebnis sieht aus wie eine flatternde Verbindung und verbraucht schnell die Limits für die Verbindungsrate. Geben Sie einen Satz Zugangsdaten pro Gerät oder Dienst aus.

Kleine Messwerte bündeln

Zehn Sensorwerte in einer JSON-Nachricht kosten einen Publish statt zehn. Bündeln hält die Nachrichtenraten niedrig und reduziert meist die Bandbreite, sofern das Bündel deutlich unter dem Payload-Limit Ihres Plans bleibt.

Weniger, breitere Subscriptions verwenden

Eine einzelne Wildcard wie site1/+/telemetry ist einfacher zu verwalten als Dutzende exakter Subscriptions und hält Sie von den Obergrenzen für Subscriptions pro Client fern. Besonders gut funktioniert das mit einem Unified Namespace (UNS), dessen Topic-Struktur der ISA-95-Hierarchie folgt: Ein MES-Dienst für eine Linie abonniert dann etwa acme/werk-stuttgart/montage/linie-1/# statt jeder Zelle einzeln. Achten Sie dabei auf die Topic-Tiefe; Enterprise, Site, Area, Line, Cell und Messwert ergeben bereits sechs Ebenen. Hintergründe liefert der Beitrag Sparkplug B und Unified Namespace.

Checkliste zur Kontingent-Bereitschaft

Gehen Sie vor dem Rollout diese Liste für jeden Client-Typ durch:

1. Gleichzeitige Verbindungen zählen, einschließlich Dashboards, Skripten und Integrationen.
2. Maximale Publishes pro Sekunde und Client berechnen, nicht nur den Durchschnitt.
3. Den größten Payload messen, einschließlich nachgesendeter Rückstaus und Fehler-Dumps.
4. Das für jedes Topic benötigte QoS-Level bestätigen und prüfen, ob der Plan es unterstützt.
5. Sicherstellen, dass jedes Gerät eine eigene Client ID und eigene Zugangsdaten hat.
6. Exponentielles Backoff mit Jitter für Reconnects implementieren.
7. MQTT-5-Reason-Codes protokollieren und an einen durchsuchbaren Ort senden.
8. Reserven einplanen: etwa die doppelte erwartete Last ansetzen, damit Wachstum Sie nicht überrascht.

Die Dimensionierungsrechnung hinter den Punkten 2 und 3 finden Sie unter MQTT-Nachrichten pro Sekunde abschätzen. Wenn Sie Einstiegsoptionen vergleichen, zeigt unser Leitfaden zum kostenlosen MQTT-Broker-Tarif, wie sich Kontingente zwischen Gratisplänen unterscheiden, und der Grundlagenartikel zum Cloud-MQTT-Broker behandelt Hosting-Entscheidungen umfassender.

Fehlerbehebung bei Kontingentproblemen

• Verbindungen brechen alle paar Sekunden ab: Prüfen Sie vor allem anderen auf doppelte Client IDs.
• Große Nachrichten verschwinden: Vergleichen Sie die Payload-Größe mit dem Planlimit und der Maximum-Packet-Size-Property des Brokers.
• Subscriptions empfangen stillschweigend nichts: Prüfen Sie die SUBACK-Reason-Codes; ein Fehlercode bedeutet, dass der Filter nicht akzeptiert wurde.
• Nach einem standortweiten Ausfall, etwa einem Netzausfall im Werk, scheitert alles: Ihrer Reconnect-Logik fehlt Jitter, und Sie lösen den Schutz der Verbindungsrate aus.
• Unerklärliche Verbindungsabbrüche unter MQTT 3.1.1: Stellen Sie den Client vorübergehend auf MQTT 5 um, um einen Reason Code zu erhalten.

Starten Sie mit einem verwalteten MQTT-Broker

ConnectMQ veröffentlicht seine Planlimits klar und meldet Kontingentprobleme mit MQTT-5-Reason-Codes, sodass Sie vom ersten Tag an darauf hin entwerfen können. Starten Sie mit dem kostenlosen Serverless-Plan unter app.connectmq.com ohne Kreditkarte und steigen Sie mit wachsender Flotte auf Serverless (Paid), Dedicated oder BYOC um. Wenn Sie den Betrieb der Infrastruktur vollständig abgeben möchten, übernimmt ein verwalteter MQTT-Broker Patches, TLS und Kapazität für Sie.

Häufig gestellte Fragen

Was bedeutet der MQTT-Reason-Code 0x97?

0x97 steht in MQTT 5 für „Quota exceeded“. Der Broker teilt dem Client mit, dass ein Implementierungs- oder Planlimit erreicht wurde, daher sollte der Client zurückweichen statt es sofort erneut zu versuchen.

Zählen Dashboards und Skripte zu den Verbindungslimits?

Ja. Jeder MQTT-Client mit einer offenen Sitzung zählt als eine Verbindung, ob Sensor, Node-RED-Flow oder Browser-Tab.

Woher weiß ich, welche maximale Nachrichtengröße mein Broker akzeptiert?

Prüfen Sie die Plandokumentation und lesen Sie unter MQTT 5 die Property Maximum Packet Size im CONNACK aus. Der kostenlose Serverless-Plan von ConnectMQ erlaubt 256 KB, der kostenpflichtige Serverless-Plan 1 MB.

Warum verbindet sich mein Gerät in einer Schleife immer wieder neu?

Die häufigste Ursache sind zwei Clients, die sich eine Client ID teilen, wodurch der Broker jedes Mal die ältere Sitzung trennt. Geben Sie jedem Gerät eigene Zugangsdaten und eine eigene Client ID.