WebSocket vs. MQTT — Transportkanal oder Messaging-Protokoll?

WebSocket: gut geeignet für

• ✓Für Live-Daten, die der Server von sich aus schicken soll, weil WebSocket genau dafür gebaut ist und der Browser nicht ständig nachfragen muss.
• ✓Für beidseitigen Austausch in Echtzeit, weil beide Seiten über dieselbe offene Leitung jederzeit senden können, auch gleichzeitig (der Fachbegriff dafür ist Vollduplex).
• ✓Für viele kleine, häufige Nachrichten, weil die Daten als schlanke Frames (kleine Datenpakete mit sehr wenig Verpackung drumherum) fliessen und so fast kein unnötiger Ballast mitgeschickt wird.
• ✓Für Anwendungen, die durch Firmen-Schutzsysteme müssen, weil WebSocket über die normalen Web-Zugänge läuft (Ports 80 und 443, dieselben, die auch jede Webseite nutzt) und dort meist ohne Sonderfreigabe durch Firewalls durchkommt.
• ✓Für Web- und App-Oberflächen direkt, weil WebSocket fest in jeden modernen Browser eingebaut ist und keine zusätzliche Software beim Nutzer braucht.

WebSocket: weniger geeignet für

• ✗Für einfache, seltene Abfragen ist WebSocket überdimensioniert, weil das Offenhalten der Leitung unnötig Ressourcen bindet. Hier reicht ein klassischer HTTP- beziehungsweise REST-Aufruf (Anfrage und Antwort über HTTP).
• ✗Für reines Datenabholen ohne Server-Push lohnt sich der Aufwand nicht, weil du die Live-Fähigkeit gar nicht nutzt. Besser ist ein normaler HTTP-Aufruf, bei Bedarf ergänzt um Server-Sent Events (eine einfachere Einweg-Technik, bei der nur der Server sendet).
• ✗Für die Vernetzung von Maschinen in der Fertigung ist WebSocket nicht gedacht, weil es das taktgenaue, garantierte Timing nicht bietet, das Maschinen brauchen (dass ein Signal zum Beispiel verlässlich innerhalb weniger Millisekunden ankommt). Dafür gibt es spezielle Industrie-Protokolle wie PROFINET.
• ✗Für Netze aus sehr vielen Geräten, die nach dem Muster Publish/Subscribe arbeiten, ist WebSocket allein umständlich. Publish/Subscribe funktioniert wie ein Zeitungs-Abo: Ein Sender veröffentlicht zu einem Thema, viele Empfänger, die dieses Thema abonniert haben, bekommen es automatisch. Dafür passt oft MQTT besser (ein schlankes Protokoll für genau diesen Fall), das seinerseits teils über WebSocket transportiert wird.

MQTT: gut geeignet für

• ✓Viele Geräte, kleine Nachrichten: Ein Broker verteilt mühelos Messwerte von Tausenden Sensoren gleichzeitig.
• ✓Schmale Bandbreite: Der Verwaltungsanteil pro Nachricht (Overhead) ist extrem klein, eine komplette Datennachricht kommt mit wenigen Bytes plus Topic-Name aus, ein Bruchteil eines HTTP-Requests.
• ✓Instabile Verbindungen: Quittungsmechanismen (QoS) und die Abschiedsnachricht Last Will fangen Verbindungsabbrüche sauber ab.
• ✓Entkopplung: Sender und Empfänger kennen sich nicht, dadurch lassen sich neue Abonnenten jederzeit ergänzen, ohne die Sender anzufassen.
• ✓Firewall-freundlich: Der Client (so heisst jedes angeschlossene Gerät oder Programm) baut die Verbindung immer selbst nach aussen zum Broker auf. Auf der Geräteseite muss keine Tür in der Firewall (ein sogenannter Port) von aussen geöffnet werden; erreichbar sein muss nur der Broker.

MQTT: weniger geeignet für

• ✗Harte Echtzeit im Maschinentakt: Wenn jede Millisekunde zählt, etwa bei der Steuerung von Maschinenachsen, sind spezialisierte Maschinen-Netzwerke die richtige Wahl (Fachbegriffe: Feldbusse oder Industrial Ethernet, etwa PROFINET und EtherCAT).
• ✗Grosse Dateien: MQTT ist für kurze Meldungen gebaut, für Firmware-Updates, Bilder oder Videos eignet sich ein Dateitransfer über HTTP oder ein spezialisiertes Protokoll besser.
• ✗Klassisches Frage-Antwort-Muster: Wer gezielt eine Antwort auf eine Anfrage braucht, etwa eine App, die auf Knopfdruck Daten abruft, fährt mit HTTP, der gewohnten Web-Technik, meist einfacher.
• ✗Direktverbindungen ohne Infrastruktur: MQTT braucht immer einen Broker, für eine simple Punkt-zu-Punkt-Verbindung zwischen zwei Geräten ist das zu viel des Guten.