BROWSER MQTT-ANLEITUNG

MQTT, WebSocket oder MQTT über WSS? Wählen Sie nach Verantwortung

Wählen Sie MQTT, wenn Clients Broker-vermittelte Topics, QoS und Session-Verhalten benötigen. Nutzen Sie natives WebSocket für einen anwendungsspezifischen Browser-zu-Server-Kanal. Verwenden Sie MQTT über WSS, wenn Browser am selben MQTT-Topic- und Richtlinienmodell wie Ihre Geräte teilnehmen sollen.

Wählen Sie das kleinste Komplettmodell

Entscheiden Sie sich für die Messaging-Verantwortung, die das Produkt benötigt, und nicht für die Tatsache, dass jede Option eine Verbindung offen halten kann.

Wählen Sie MQTT

Verwenden Sie MQTT, wenn Geräte und Dienste Broker-vermittelte Topics, Fan-out, QoS, Retained Messages oder Session-Verhalten benötigen. Native Clients nutzen MQTT in der Regel über TLS/TCP.

Wählen Sie natives WebSocket

Verwenden Sie den nativen WebSocket, wenn ein Browser und ein Anwendungsserver einen benutzerdefinierten Live-Kanal benötigen und die Anwendung für Routing, Autorisierung, Bestätigung und Wiederherstellung zuständig ist.

MQTT über WSS verwenden

Verwenden Sie MQTT über WSS, wenn Browsercode über einen browserkompatiblen sicheren Transport an den MQTT-Topics, QoS, Identität und Richtlinienmodell des Brokers teilnehmen muss.

Protokollebenen und Zuständigkeiten klar trennen

MQTT über WSS kombiniert Protokolle; Es ersetzt MQTT nicht durch WebSocket und überträgt die Anwendungsverantwortung nicht auf den Transport.

MQTT über TLS/TCP

Für native Geräte und Dienste, die TCP-Sockets öffnen können.

  1. Anwendungs-Payload
  2. MQTT-Topics, QoS, Sitzung
  3. TLS → TCP

Nativer WebSocket

Für einen benutzerdefinierten Browser-zu-Anwendungsserver-Kanal.

  1. Anwendungsdefinierte Nachrichten und Wiederherstellung
  2. WebSocket-Rahmen
  3. TLS → TCP

MQTT über WSS

Für Browser-MQTT-Clients, die eine Verbindung zu einem Broker-Listener herstellen.

  1. Anwendungs-Payload
  2. MQTT-Topics, QoS, Sitzung
  3. WebSocket-Rahmen
  4. TLS → TCP
Verantwortung
VerantwortungMQTTWebSocketMQTT over WSS
NachrichtensemantikBroker-Topics, QoS, aufbewahrte Nachrichten und SitzungenDie Anwendung definiert Routing, Bestätigungen, Wiedergabe und NachrichtenbedeutungDie Semantik von MQTT bleibt innerhalb von WebSocket-Frames unverändert
Identität und AutorisierungBroker Clientidentität und Publish/Subscribe-RichtlinieAnwendungssitzung plus Autorisierung für jede benutzerdefinierte NachrichtenaktionTLS schützt den Transport; Es gelten weiterhin die Brokeridentitäts- und Topic-Richtlinien
Wiederherstellung trennenClient-Wiederverbindung plus explizites sauberes oder dauerhaftes MQTT-SitzungsverhaltenDie Anwendung stellt den Status, die Abonnements und die Behandlung verpasster Nachrichten neu herStellen Sie zuerst WSS wieder her, verbinden Sie dann MQTT erneut und setzen Sie die Abonnements fort oder erstellen Sie sie neu

Führen Sie einen MQTT.js-Loopback mit fester Sandbox aus

Dieses Beispiel ist bewusst an die öffentliche RunMQTT-Sandbox gebunden. Ersetzen Sie nur die beiden Sandbox-Platzhalter durch die aktuellen Zugangsdaten auf der Seite „Public Broker“.

MQTT.js · fester WSS-Endpunkt · nur synthetische Daten
import mqtt from "mqtt";

const endpoint = "wss://public.runmqtt.com/mqtt";
const suffix = crypto.randomUUID().replaceAll("-", "");
const topic = `runmqtt/sandbox/${suffix}/loopback`;
const payload = JSON.stringify({
  source: "runmqtt-wss-guide",
  value: 42,
});

const client = mqtt.connect(endpoint, {
  clientId: `runmqtt-guide-${suffix}`,
  username: "<PUBLIC_SANDBOX_USERNAME>",
  password: "<PUBLIC_SANDBOX_PASSWORD>",
  clean: true,
  connectTimeout: 10_000,
  reconnectPeriod: 3_000,
  protocolVersion: 4,
});

client.on("connect", async () => {
  await client.subscribeAsync(topic, { qos: 1 });
  await client.publishAsync(topic, payload, { qos: 1 });
});

client.on("message", (_topic, _payload) => {
  console.info("Synthetic QoS 1 loopback received");
});

client.on("reconnect", () => console.info("Reconnecting"));
client.on("close", () => console.info("Disconnected"));
client.on("error", () => console.error("MQTT connection failed"));

export async function disconnect() {
  await client.endAsync();
}

window.addEventListener("pagehide", () => client.end(true));
Der Endpunkt ist festgelegt; Es gibt keine willkürlichen Eingaben des Brokers.
Topic, Client-ID und JSON-Payload sind synthetisch und für jeden Seitenaufruf eindeutig.
Die Zugangsdaten der öffentlichen Sandbox sind für einmalige Tests gedacht, nicht für den Produktivbetrieb.
Ein zufälliges Topic reduziert versehentliche Kollisionen, schafft jedoch keine Privatsphäre auf einem gemeinsam genutzten Broker.
Verwenden Sie den No-Input-Browsertester

Behandeln Sie die Verbindung, die erneute Verbindung und den MQTT-Status separat

Ein erfolgreiches WebSocket-Upgrade ist lediglich die Transportvoraussetzung. Der Client führt weiterhin MQTT CONNECT aus und stellt den beabsichtigten Abonnementstatus wieder her.

  1. 01

    Verbinden Sie WSS und dann MQTT

    Validieren Sie das öffentliche Zertifikat TLS, aktualisieren Sie /mqtt auf WebSocket, authentifizieren Sie MQTT und warten Sie auf das Verbindungsereignis MQTT, bevor Sie ein Abonnement oder eine Veröffentlichung durchführen.

  2. 02

    Verbindung und gewünschten Zustand wiederherstellen

    Nach einem unerwarteten Abschluss öffnet MQTT.js einen neuen WSS-Kanal und sendet erneut MQTT CONNECT. Mit „clean: true“ erneut vom Connect-Handler abonnieren.

  3. 03

    Trennen Sie die Verbindung absichtlich

    Beenden Sie den MQTT-Client, wenn die Seite verlassen wird oder der Benutzer die Sitzung beendet. Lassen Sie keine Reconnect-Timer oder versteckten Abonnements laufen.

Reproduzierbare RunMQTT-Sandbox-Beweise

Verifiziert am 10.08.2026 mit MQTT.js 5.15.2 unter Verwendung von MQTT 3.1.1 und aktivierter Zertifikatsvalidierung. Diese Prüfungen stellen die Kompatibilität für die dokumentierte Sandbox her; Sie stellen kein Leistungsergebnis oder SLA dar.

Verifizierungsprüfung
VerifizierungsprüfungErgebnisUmfang
Browser WSS geöffnetChromium 142, Firefox 150 und WebKit 26.4 öffneten den festen WSS-Endpunkt, ohne die TLS-Validierung zu umgehen.wss://public.runmqtt.com/mqtt
MQTT-QoS-1-RoundtripVeröffentlichen und abonnieren Sie Loopbacks, die über einfache MQTT 1883, MQTT TLS 8883 und WSS 443 abgeschlossen wurden.Aktuelle Zugangsdaten des öffentlichen Brokers und zufällige synthetische Topics
IntegritätsprüfungFür die fünfminütige Integritätsprüfung müssen Cloudflare und Google DoH den öffentlichen Hostnamen in die Relay-IP auflösen. Anschließend werden Zertifikatsnamen, Relay-Listener, Hostnamensübereinstimmung und ein echtes /mqtt WebSocket-Upgrade validiert.Bereitstellungsprüfung alle fünf Minuten
Wiederholen Sie die Überprüfung der festen Sandbox

Wählen Sie Transport nach Laufzeit und Nachrichtenvertrag

Das gleiche Produkt kann MQTT über TLS für Geräte, MQTT über WSS für eine Browserkonsole und natives WebSocket für eine separate anwendungsspezifische Live-Benutzeroberfläche verwenden.

Szenario
SzenarioBevorzugenGrundProduktionsgrenze
Browser MQTT-KonsoleMQTT über WSSDer Browser verknüpft dieselben Topics, QoS, und dasselbe Broker-Richtlinienmodell wie MQTT-Clients.Verwenden Sie benutzerbezogene oder kurzlebige Anmeldeinformationen. Versenden Sie niemals ein gemeinsames Produktionsgeheimnis im Frontend-Code.
Mobilfunk-ClientMQTT über TLS für native Apps; MQTT über WSS für Browser-LaufzeitenWählen Sie den Transport aus, den die Laufzeit unterstützt, und behalten Sie dabei das MQTT-Wiederverbindungs- und Topic-Verhalten bei.Testen Sie echte Netzwerkübergänge und definieren Sie explizit Backoff-, Sitzungs- und Duplikatbehandlung.
GerätetelemetrieMQTT über TLS/TCPNative Geräte benötigen normalerweise nicht die WebSocket-Framing-Schicht, um vom Broker weitergeleitete Telemetriedaten zu veröffentlichen.Geben Sie jedem Gerät eine eindeutige Identität und eine Veröffentlichungsrichtlinie mit der geringsten Berechtigung.
Command-DownlinkMQTTBroker-Abonnements, QoS und Sitzungsoptionen drücken die Bereitstellung von Gerätebefehlen direkter aus als ein benutzerdefinierter Socket-Kanal.Autorisieren Sie Befehls-Topics separat und entwerfen Sie eine idempotente Befehlsverarbeitung.

MQTT vs. WebSocket FAQ

Handelt es sich bei MQTT und WebSocket um denselben Protokolltyp?

Nein. MQTT definiert die Messaging-Semantik auf Anwendungsebene. WebSocket stellt einen dauerhaften bidirektionalen Kanal bereit. MQTT kann WebSocket als einen seiner Transporte verwenden.

Kann ein Browser eine direkte Verbindung zu MQTT herstellen?

Ein Browser kann keinen beliebigen rohen TCP-Socket öffnen. Ein Browser-MQTT-Client stellt eine Verbindung zu einem Broker-WebSocket-Listener her, normalerweise über WSS, und tauscht MQTT-Pakete innerhalb von WebSocket-Frames aus.

Stellt die erneute Verbindung von WSS MQTT-Abonnements automatisch wieder her?

Nicht von alleine. WebSocket stellt nur den Kanal wieder her. Der MQTT-Client muss die Verbindung wiederherstellen und sich dann auf eine wiederaufgenommene MQTT-Sitzung verlassen oder sich erneut anmelden. Das Sandbox-Beispiel verwendet eine saubere Sitzung und abonniert bei jeder Verbindung.

Ist WebSocket schneller als MQTT?

Es gibt keine verantwortungsvolle, universelle Antwort. Vergleichen Sie den gesamten Anwendungspfad, einschließlich Routing, Autorisierung, Zustellung, Wiederherstellung und das Netzwerk, in dem die Anwendung ausgeführt wird. Dieser Leitfaden erhebt keinen Anspruch auf Leistung oder SLA.