Die Grenzen öffentlicher MQTT-Broker lassen sich in der ersten begeisterten Stunde eines Projekts leicht übersehen und sind schmerzhaft, wenn man sie erst vor einem Kunden entdeckt. Dieser Artikel erklärt die vier wichtigsten Einschränkungen eines öffentlichen MQTT-Brokers am konkreten Beispiel von broker.connectmq.com, zeigt, wie Sie Ihre Tests innerhalb dieser Grenzen gestalten, und nennt die klaren Signale, dass es Zeit für einen privaten Broker ist.
Warum öffentliche Broker überhaupt Limits haben
Ein öffentlicher Broker ist ein geteilter, anonymer Dienst. Jeder im Internet kann sich ohne Konto verbinden, veröffentlichen und abonnieren. Genau diese Offenheit macht ihn für Tutorials und schnelle Tests nützlich, und genau deshalb braucht er Limits: Ohne sie könnte ein einziges fehlerhaftes Skript den Broker fluten und ihn für alle anderen unbrauchbar machen.
Die Limits sind kein Mangel. Sie halten einen kostenlosen Community-Dienst nutzbar. ConnectMQ betreibt broker.connectmq.com genau zu diesem Zweck: als Ort ohne Einrichtung, um MQTT zu lernen, eine Bibliothek zu testen oder eine Demo zu zeigen, parallel zu privaten Brokern für echte Workloads. Der Artikel zum kostenlosen öffentlichen MQTT-Broker beschreibt, wie Sie broker.connectmq.com effektiv nutzen; dieser Artikel konzentriert sich darauf, was er nicht leisten kann.
Einschränkung 1: Kein Datenschutz
Auf einem öffentlichen Broker kann jeder Client jedes Topic lesen. Ein Abonnent von # erhält alles, was veröffentlicht wird, vorbehaltlich der Schutzmechanismen des Brokers. Topic-Namen sind keine Geheimnisse, und ausgefallene Präfixe verringern nur zufällige Kollisionen.
Was das in der Praxis bedeutet:
- Veröffentlichen Sie niemals personenbezogene Daten, Standortverläufe, Kamera-Schnappschüsse oder irgendetwas, das eine Person oder Wohnung identifiziert.
- Veröffentlichen Sie niemals Zugangsdaten, API-Schlüssel oder WLAN-Passwörter, auch nicht „vorübergehend".
- Steuern Sie niemals reale Anlagen über ein öffentliches Topic. Jeder kann in Ihr Befehls-Topic veröffentlichen, nicht nur mitlesen.
- Gehen Sie davon aus, dass Payloads irgendwo von irgendwem protokolliert werden.
Verwenden Sie ein zufälliges Präfix wie connectmq/demo/9b2e7/, damit Ihr Testverkehr nicht mit dem anderer kollidiert. Das ist Höflichkeit und Komfort, keine Sicherheitsmaßnahme.
Einschränkung 2: Keine Dienstgarantien
Öffentliche Broker werden nach bestem Bemühen angeboten. Es gibt kein SLA, keine garantierte Verfügbarkeit und keine Support-Zusage. Der Broker kann für Wartungsarbeiten neu starten, Limits können sich ändern, und Sessions überdauern das Ablauffenster nicht. Auf broker.connectmq.com ist der Session-Ablauf auf 30 Minuten begrenzt; ein Gerät, das länger offline ist, beginnt also neu.
Für eine Demo oder einen Workshop ist das in Ordnung. Für ein Produkt, ein Pilotprojekt oder alles, worauf sich ein Kunde verlässt, nicht.
Mit Funkstille rechnen
Da es keine Garantien gibt, schreiben Sie Ihre Test-Clients so, dass sie Unterbrechungen verkraften. Aktivieren Sie automatisches Reconnect, abonnieren Sie im Connect-Callback erneut statt nur einmal beim Start, und halten Sie eine fehlende Nachricht erst dann für einen Fehler in Ihrem eigenen Code, wenn Sie einen Broker-Neustart ausgeschlossen haben. Diese Gewohnheiten sind auf jedem Broker gute Praxis und erleichtern später den Weg in die Produktion.
Einschränkung 3: Ein geteilter Topic-Bereich
Alle öffentlichen Nutzer teilen sich einen Topic-Baum. Die Folgen:
- Kollisionen. Beliebte Namen wie
test,sensor/tempoderhome/livingroomwerden von vielen genutzt. Sie erhalten deren Nachrichten und die anderen Ihre. - Überraschungen durch Retained Messages. Die Retained Message eines anderen auf einem generischen Topic erscheint, sobald Sie abonnieren.
- Wildcard-Rauschen. Breite Abonnements liefern Verkehr, den Sie nie angefordert haben, und verbrauchen Ihr Ratenbudget.
Versehen Sie Topics immer mit einem eindeutigen Präfix und abonnieren Sie möglichst eng.
Einschränkung 4: Limits für Rate, Größe und Abonnements
Der öffentliche MQTT-Broker begrenzt die Ressourcen pro Client, damit alle fairen Zugang haben. Auf broker.connectmq.com gelten folgende Limits:
| Limit | Wert beim öffentlichen MQTT-Broker | Warum es existiert |
|---|---|---|
| Nachrichtengröße | 64 KB pro Nachricht | Verhindert, dass große Payloads die Bandbreite dominieren |
| Publish-Rate | 10 Nachrichten pro Sekunde und Client | Hindert Skripte daran, den Broker zu fluten |
| Abonnements | 10 pro Client | Begrenzt die Fan-out-Kosten pro Client |
| Topic-Tiefe | 8 Topic-Ebenen | Hält das Topic-Matching effizient |
| QoS | 0, 1 und 2 | Volles Protokollverhalten zum Lernen |
| Session-Ablauf | Bis 30 Minuten | Gibt Ressourcen verwaister Sessions frei |
| Authentifizierung | Anonym, beliebige nicht leere, eindeutige Client-ID | Keine Einrichtung für Lernende |
Das Überschreiten eines Limits kann zu abgelehnten Operationen oder einer Trennung führen. Wenn Sie sich mit MQTT 5 verbinden, protokollieren Sie die Reason Codes, die Ihr Client erhält; sie verraten weit mehr als ein generisches „Verbindung verloren".
Tests gestalten, die die Limits respektieren
Hier ein Python-Publisher (paho-mqtt 2.x), der deutlich innerhalb der öffentlichen Limits bleibt: eindeutige Client-ID, eindeutiges Präfix, flache Topics, eine Ratenbegrenzung und kompakte Payloads.
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN_ID = uuid.uuid4().hex[:6]
PREFIX = f"connectmq/demo/{RUN_ID}" # 3 Ebenen, lässt Platz darunter
MAX_RATE = 5 # Nachrichten pro Sekunde, unter dem Limit von 10/s
INTERVAL = 1.0 / MAX_RATE
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code, "prefix:", PREFIX)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Disconnected:", reason_code)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=f"limits-demo-{RUN_ID}",
protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
try:
for i in range(50):
payload = json.dumps({"i": i, "t": round(20 + random.random() * 2, 2)})
assert len(payload.encode()) < 64 * 1024
client.publish(f"{PREFIX}/sensor/temp", payload, qos=1)
time.sleep(INTERVAL)
finally:
client.loop_stop()
client.disconnect()
Beobachten Sie das Ganze in einem zweiten Terminal und abonnieren Sie dabei eng nur Ihr eigenes Präfix:
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-RUNID -t "connectmq/demo/RUNID/#" -v
Ersetzen Sie RUNID durch das vom Skript ausgegebene Präfix.
Häufige Stolperfallen
- Leere Client-ID. Der öffentliche Broker verlangt eine nicht leere Client-ID. Erzeugen Sie für jeden Lauf eine eindeutige.
- Zwei Skripte mit derselben Client-ID. Jede Verbindung wirft die andere hinaus, was eine Reconnect-Schleife erzeugt.
- Enge Publish-Schleifen. Eine
while True-Schleife ohne Pause überschreitet das Ratenlimit innerhalb einer Sekunde. - Tiefe Topic-Bäume.
connectmq/demo/abc/site/area/line/cell/machine/sensorhat 9 Ebenen und überschreitet das Limit von 8 Ebenen. Halten Sie Test-Topics flach. Gerade Industrie-4.0-Projekte stoßen hier schnell an: Ein vollständiger Unified Namespace (UNS) bildet die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) als Topic-Pfad ab, etwaacme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und braucht samt Testpräfix mehr Ebenen, als der öffentliche MQTT-Broker erlaubt. Testen Sie dort nur einen gekürzten Ausschnitt und entwerfen Sie die volle Struktur auf einem privaten Broker. - Großes JSON oder Bilder. Alles in der Nähe von 64 KB gehört auf einen privaten Broker, und Bilder gehören ohnehin selten in MQTT.
Anzeichen, dass es Zeit für einen privaten Broker ist
Verlassen Sie den öffentlichen Broker, sobald Ihnen einer dieser Punkte auffällt:
- Die Daten würden jemanden bloßstellen oder ihm schaden, wenn ein Fremder sie liest.
- Ein Gerät führt empfangene Befehle aus.
- Ein Kunde, eine Kollegin oder ein Lehrer ist darauf angewiesen, dass das System morgen funktioniert.
- Sie brauchen mehr als 10 Abonnements pro Client, größere Nachrichten oder tiefere Topic-Hierarchien.
- Sie möchten sehen, wer verbunden ist, und Zugangsdaten pro Gerät verwalten.
Der Vergleich öffentlicher vs. privater MQTT-Broker führt durch den Wechsel, und vom Prototyp zur Produktion deckt den Rest des Weges ab.
Was sich mit einem privaten Tarif ändert
Ein privater ConnectMQ-Broker behält dasselbe Protokoll und denselben Client-Code bei, ändert aber die Regeln:
- Authentifizierung mit generiertem Benutzernamen, Passwort und einer an diese Zugangsdaten gebundenen Client-ID.
- Isolation von anderen Mandanten, sodass Ihr Topic-Bereich Ihnen gehört.
- TLS auf 8883 und Secure WebSocket auf 8084 mit einem Let's-Encrypt-Zertifikat.
- Tarifbasierte Limits: Der kostenlose Serverless-Tarif erlaubt bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB; der kostenpflichtige Serverless-Tarif erhöht dies auf bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions.
- Portal-Tools wie ein Browser-Client, ein Live-Topic-Explorer, ein Dashboard und Schwellwert-Alarme.
Kostenlos zu einem privaten ConnectMQ-Broker wechseln
Wenn der öffentliche Broker seinen Zweck erfüllt hat, erstellen Sie Ihren kostenlosen privaten Broker im Serverless-Tarif, ohne Kreditkarte, und richten Sie dasselbe Skript mit Ihren neuen Zugangsdaten auf Port 8883 aus. Lesen Sie den Leitfaden zum Cloud-MQTT-Broker, um die nächsten Schritte zu planen, erfahren Sie, warum ein verwalteter MQTT-Broker Betriebsaufwand spart, oder besuchen Sie connectmq.com, um die Tarife zu vergleichen.
Häufig gestellte Fragen
Ist es sicher, einen öffentlichen MQTT-Broker zu nutzen?
Zum Lernen und für Demos mit harmlosen Daten ist es sicher. Für personenbezogene Daten, Zugangsdaten oder die Steuerung realer Anlagen ist es nicht sicher, weil jeder jedes Topic lesen und darin veröffentlichen kann.
Was passiert, wenn ich das Ratenlimit des öffentlichen Brokers überschreite?
Operationen können abgelehnt oder der Client getrennt werden. Bleiben Sie beim Veröffentlichen unter 10 Nachrichten pro Sekunde und Client und prüfen Sie beim Debuggen die MQTT-5-Reason-Codes.
Warum erhalte ich Nachrichten, die ich nicht veröffentlicht habe?
Andere Nutzer veröffentlichen auf denselben Topic-Namen. Verwenden Sie ein eindeutiges Präfix wie connectmq/demo/<random-id>/ und abonnieren Sie nur dieses Präfix.
Behält der öffentliche Broker meine Session, wenn mein Gerät offline geht?
Nur innerhalb des Session-Ablauffensters, das auf broker.connectmq.com auf 30 Minuten begrenzt ist. Danach beginnt das Gerät eine neue Session.
