MQTT vs. WebSocket: Protokoll oder Transport?

MQTT vs. WebSocket klingt nach einer Entscheidung zwischen zwei konkurrierenden Protokollen, ist in Wahrheit aber eine Frage der Schichten. WebSocket ist ein Transport, der einem Browser eine Vollduplex-Leitung zu einem Server verschafft; MQTT ist ein Messaging-Protokoll, das Topics, Subscriptions, Zustellgarantien und Sitzungszustand definiert – und es kann über genau diese Leitung laufen. Dieser Leitfaden erklärt den Unterschied, zeigt, was eine reine WebSocket-App von Hand bauen muss, und führt Sie durch die Verbindung eines Browsers mit einem MQTT-Broker über Secure WebSocket.

Was WebSocket eigentlich ist

WebSocket (RFC 6455) beginnt als HTTP-Anfrage mit einem Upgrade: websocket-Header. Sobald der Server zustimmt, wechselt die Verbindung in ein schlankes Framing-Format, in dem beide Seiten jederzeit Text- oder Binärnachrichten senden können. Es löst ein ganz bestimmtes Problem: Vor WebSocket konnten Browser keine offene, bidirektionale Verbindung zu einem Server halten.

Genauso wichtig ist, was WebSocket nicht definiert. Es gibt keine Topics, keine Subscriptions, keine Bestätigungen über TCP hinaus, keine Vorstellung davon, wer eine Nachricht erhalten soll, kein Reconnect-Verhalten und keinen Zustand, der einen Verbindungsabbruch überdauert. Jede Anwendung auf einem rohen WebSocket erfindet ihr eigenes Nachrichtenformat und ihre eigene Semantik.

Was MQTT hinzufügt

MQTT ist ein Anwendungsprotokoll mit einem klar definierten Paketsatz: CONNECT, PUBLISH, SUBSCRIBE, Bestätigungen und so weiter. Es bietet Ihnen:

• Topic-basiertes Routing über einen Broker, mit den Wildcards + und #.
• QoS 0, 1 und 2 als Zustellgarantien pro Nachricht.
• Retained Messages, damit ein neuer Client sofort den letzten bekannten Wert erhält.
• Persistente Sessions, die Nachrichten puffern, während ein Client offline ist.
• Keep Alive und Last Will zur Online-/Offline-Erkennung.
• MQTT-5-Extras wie Message Expiry, Response Topics für Request/Response, User Properties und Reason Codes.

MQTT läuft normalerweise über reines TCP oder TLS, die Spezifikation definiert aber auch, wie es über WebSocket mit dem Subprotokoll mqtt transportiert wird. Genau das ermöglicht es einem Browser, dasselbe Protokoll zu sprechen wie ein ESP32. Hintergründe dazu, wie der Broker all das routet, finden Sie unter So funktioniert MQTT.

MQTT vs. WebSocket im Vergleich

Was eine reine WebSocket-App selbst bauen muss

So sieht ein realistisches Backend für ein reines WebSocket-Dashboard aus: Der Server führt eine Map der verbundenen Browser. Geräte senden Messwerte per HTTP oder über einen eigenen Socket. Trifft ein Messwert ein, entscheidet der Server, wer ihn bekommen soll, iteriert über die passenden Sockets und sendet JSON. Dann kommen die Anforderungen:

1. Browser sollen nur Daten der Standorte erhalten, die sie gerade anzeigen – also ergänzen Sie einen „subscribe“-Nachrichtentyp und ein Filterschema.
2. Ein frisch geöffnetes Dashboard soll aktuelle Werte sofort zeigen – also ergänzen Sie einen Cache der letzten Werte.
3. Mobile Clients fallen oft weg – also ergänzen Sie Heartbeats und Reconnect-Logik im Browser.
4. Befehle brauchen eine Bestätigung – also ergänzen Sie Nachrichten-IDs und Acknowledgments.
5. Sie brauchen wegen der Last einen zweiten Server – also ergänzen Sie eine Pub/Sub-Schicht zwischen den Servern, damit ein Messwert auf dem einen auch Browser auf dem anderen erreicht.

An diesem Punkt haben Sie einen Broker nachgebaut, nur ohne die Interoperabilität. Mit MQTT über WebSocket existiert jede dieser Funktionen bereits, und Geräte wie Browser teilen sich ein System.

Reines WebSocket bleibt für manche Aufgaben die richtige Wahl: eine Chatfunktion in einer bestehenden Web-App, kollaboratives Bearbeiten, ein Spieleserver oder jeder Fall, in dem beide Enden Ihr eigener Code sind und die Nachrichtensemantik einzigartig für Ihre Anwendung ist.

Einen Browser per WebSocket mit MQTT verbinden

ConnectMQ stellt MQTT über WebSocket auf Port 8083 und über Secure WebSocket auf Port 8084 bereit, jeweils unter dem Pfad /mqtt. Über HTTPS ausgelieferte Seiten müssen die sichere Variante verwenden. Das folgende Beispiel nutzt MQTT.js von einem CDN und den kostenlosen öffentlichen MQTT-Broker, sodass Sie es als HTML-Datei speichern und direkt öffnen können. Der öffentliche MQTT-Broker ist für Tests gedacht, nicht für Produktionsdaten.

// Load MQTT.js first, for example:
// <script src="https://unpkg.com/mqtt@5.10.1/dist/mqtt.min.js"></script>

const prefix = "connectmq/demo/" + Math.random().toString(16).slice(2, 10);
const clientId = "browser-" + Math.random().toString(16).slice(2, 10);

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId,
  protocolVersion: 5,
  clean: true,
  keepalive: 30,
  reconnectPeriod: 2000,
});

client.on("connect", () => {
  console.log("connected as", clientId);
  client.subscribe(prefix + "/sensors/+/temperature", { qos: 1 });

  // Publish a retained reading so late joiners see it immediately
  client.publish(
    prefix + "/sensors/room1/temperature",
    JSON.stringify({ value: 22.3, ts: Date.now() }),
    { qos: 1, retain: true }
  );
});

client.on("message", (topic, payload, packet) => {
  console.log(topic, payload.toString(), "retain:", packet.retain);
});

client.on("reconnect", () => console.log("reconnecting..."));
client.on("error", (err) => console.error("mqtt error:", err.message));

console.log("Publish test data with:");
console.log(`mosquitto_pub -h broker.connectmq.com -p 1883 -i cli-${clientId} -t "${prefix}/sensors/room2/temperature" -m '{"value":19.8}'`);

Führen Sie den ausgegebenen mosquitto_pub-Befehl in einem Terminal aus, und die Browserkonsole zeigt die Nachricht eines reinen TCP-Clients an. Genau darum geht es bei MQTT über WebSocket: Der Transport unterscheidet sich, Topics und Semantik sind dieselben.

Für einen privaten Broker ersetzen Sie den Host in der URL durch Ihre Broker-Adresse und ergänzen die Optionen um username: "YOUR_USERNAME" und password: "YOUR_PASSWORD" sowie clientId: "YOUR_CLIENT_ID". Denken Sie daran, dass alles, was an einen Browser ausgeliefert wird, für dessen Nutzer sichtbar ist. Geben Sie Browser-Clients daher eigene, eingeschränkte Zugangsdaten, statt Geräte- oder Backend-Zugangsdaten wiederzuverwenden. Der Leitfaden MQTT über WebSocket behandelt Ports, Proxys und Fehlersuche ausführlicher, und MQTT im Browser mit JavaScript baut ein komplettes Dashboard.

Performance und Overhead

MQTT über WebSocket fügt jedem MQTT-Paket einen kleinen WebSocket-Frame-Header hinzu, dazu kommt das anfängliche HTTP-Upgrade. Für Dashboard-Traffic sind diese Kosten vernachlässigbar. Für ressourcenbeschränkte Geräte gibt es überhaupt keinen Grund, WebSocket zu verwenden; verbinden Sie sich über TCP auf 1883 oder TLS auf 8883 und sparen Sie die Bytes. Eine gängige Aufteilung: Geräte auf 8883, Browser auf 8084, beide am selben Broker.

Häufige Fallstricke

• Falscher Pfad. Viele Broker, darunter ConnectMQ, erwarten /mqtt. Eine Verbindung zum Root-Pfad scheitert mit einem Handshake-Fehler.
• Mixed Content. Eine über HTTPS ausgelieferte Seite kann keine ws://-Verbindung öffnen. Verwenden Sie wss:// und Port 8084.
• Geteilte Client IDs. Zwei Browser-Tabs mit derselben fest codierten Client ID werfen sich gegenseitig immer wieder hinaus. Erzeugen Sie eine pro Tab.
• Unternehmens-Proxys. Manche Proxys stören WebSocket-Upgrades auf Nicht-Standard-Ports. Testen Sie aus den Netzwerken, die Ihre Nutzer tatsächlich verwenden.
• Durchsickernde Geheimnisse. Betten Sie niemals Backend- oder Gerätezugangsdaten in Frontend-Code ein.

Was sollten Sie wählen?

Wenn Sie eine Echtzeitfunktion bauen, bei der beide Enden Ihr eigener Webcode sind und die Semantik einzigartig ist, ist reines WebSocket in Ordnung. Wenn Browser Daten von Geräten sehen müssen, wenn mehrere Clients dieselben Daten teilen oder wenn Sie Garantien, gespeicherten Zustand und Präsenz brauchen, wählen Sie MQTT und nutzen WebSocket im Browser als dessen Transport. Ein typisches Beispiel aus der Fertigung ist ein browserbasiertes Shopfloor- oder Leitstand-Dashboard, das Maschinenzustände direkt aus dem Unified Namespace (UNS) abonniert, dessen Topics der ISA-95-Hierarchie folgen, etwa acme/werk-stuttgart/montage/+/+/zustand. Ein verwalteter MQTT-Broker liefert Ihnen beide Endpunkte – TCP für Geräte und WSS für Browser –, ohne dass Sie die Infrastruktur selbst betreiben. Für eine vollständige Einführung in das Protokoll beginnen Sie mit dem MQTT-Tutorial.

Echtzeit-Dashboards auf ConnectMQ bauen

ConnectMQ stellt MQTT auf 1883 und 8883 sowie MQTT über WebSocket auf 8083 und 8084 mit einem Let's-Encrypt-Zertifikat bereit, sodass sich Geräte und Browser mit demselben Broker verbinden. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und testen Sie ihn mit dem browserbasierten MQTT-Client des Portals, bevor Sie eine einzige Zeile Frontend-Code schreiben.

Häufig gestellte Fragen

Ist MQTT besser als WebSocket?

Die beiden sind keine Alternativen auf derselben Schicht. WebSocket ist ein Transport, MQTT ein Messaging-Protokoll, das über WebSocket laufen kann. Nutzen Sie MQTT, wenn Sie Topics, Fan-out und Zustellgarantien brauchen.

Kann sich ein Browser direkt mit einem MQTT-Broker verbinden?

Ja, sofern der Broker MQTT über WebSocket unterstützt. Bei ConnectMQ verwenden Sie wss://broker.connectmq.com:8084/mqtt und eine Bibliothek wie MQTT.js.

Warum scheitert meine MQTT-WebSocket-Verbindung auf einer HTTPS-Seite?

Browser blockieren unsichere ws://-Verbindungen von HTTPS-Seiten. Wechseln Sie zu wss:// auf Port 8084 und prüfen Sie, ob der Pfad /mqtt lautet.

Sollten IoT-Geräte MQTT über WebSocket verwenden?

In der Regel nicht. Geräte sollten MQTT direkt über TCP oder TLS nutzen, was weniger Overhead hat. WebSocket ist vor allem für Browser und Netzwerke gedacht, die nur Web-Traffic zulassen.