Ist MQTT TCP oder UDP? Die Transportschicht erklärt

Ist MQTT TCP oder UDP? MQTT läuft über TCP: entweder direkt, in TLS verpackt oder in einer WebSocket-Verbindung, die ihrerseits über TCP läuft. Dieser Artikel erklärt, warum MQTT auf die Garantien von TCP angewiesen ist, wo UDP-basierte Varianten wie MQTT-SN und das experimentelle MQTT über QUIC ins Bild passen und welche Ports Sie für einen Cloud-Broker genau in Ihrer Firewall öffnen müssen.

Ist MQTT TCP oder UDP? Die kurze Antwort

Die Spezifikationen von MQTT 3.1.1 und 5.0 verlangen einen zugrunde liegenden Transport, der einen geordneten, verlustfreien, bidirektionalen Bytestrom liefert. TCP/IP bietet genau das und ist daher der Standardtransport. TLS über TCP und WebSocket über TCP erfüllen die Anforderungen ebenfalls, weil sie diese Eigenschaften bewahren. Reines UDP tut das nicht, daher läuft Standard-MQTT nie direkt über UDP.

Transport	Zugrunde liegendes Protokoll	Typischer Port	Standard-MQTT?
MQTT über TCP	TCP	1883	Ja
MQTT über TLS	TLS über TCP	8883	Ja
MQTT über WebSocket	HTTP-Upgrade über TCP	8083 (`ws`)	Ja
MQTT über sicheres WebSocket	TLS über TCP	8084 (`wss`)	Ja
MQTT-SN	UDP oder andere Datagramm-Netze	Gateway-spezifisch	Eigenes Protokoll
MQTT über QUIC	QUIC über UDP	Broker-spezifisch	Nicht Teil des OASIS-Standards

Wo MQTT im Netzwerkstack sitzt

MQTT ist ein Protokoll der Anwendungsschicht. Stellen Sie sich den Stack von oben vor:

Anwendung: Ihr Sensorcode, Dashboard oder Backend-Dienst.
MQTT: CONNECT-, PUBLISH-, SUBSCRIBE- und Bestätigungspakete.
Optionales WebSocket-Framing: genutzt von Browsern und manchen Umgebungen hinter Proxys.
Optionales TLS: Verschlüsselung und Authentifizierung des Brokers.
TCP: zuverlässige, geordnete Zustellung mit Neuübertragung und Flusskontrolle.
IP und Sicherungsschicht: WLAN, Ethernet, Mobilfunk.

Weil MQTT über TCP sitzt, kann es einfach bleiben. Es braucht keine eigenen Sequenznummern für die Reihenfolge und keine eigenen Retransmission-Timer für verlorene Segmente; TCP erledigt das auf der Strecke zwischen Client und Broker.

Warum MQTT sich für TCP entschieden hat

Reihenfolge und Vollständigkeit

MQTT-Pakete haben einen Header variabler Länge und können über mehrere TCP-Segmente verteilt sein. Der Parser erwartet, dass die Bytes vollständig und in Reihenfolge ankommen. Bei UDP können Pakete ungeordnet, doppelt oder gar nicht ankommen, und das Protokoll müsste das Zusammensetzen neu erfinden.

Verbindungszustand

MQTT ist verbindungsorientiert. Der Austausch von CONNECT/CONNACK authentifiziert den Client, und der Broker verknüpft die offene Verbindung mit einer Session. Keep-Alive, Last Will und Session-Übernahme hängen alle von einer klaren Vorstellung ab, ob „diese Verbindung offen ist“ oder „diese Verbindung abgebrochen ist“, und genau die liefert TCP.

QoS baut auf einer zuverlässigen Verbindung auf

QoS 1 und 2 ergänzen Garantien über Verbindungsabbrüche hinweg und zwischen Client und Broker, nicht Zuverlässigkeit auf Paketebene. Sie setzen voraus, dass die Verbindung zuverlässig ist, solange sie besteht, und behandeln nur, was passiert, wenn sie abbricht. Der Leitfaden zu MQTT-QoS-Stufen zeigt diese Abläufe.

Firewalls und NAT

Von einem Gerät ausgehend aufgebaute TCP-Verbindungen verstehen Router und Firewalls gut. Der Broker kann Nachrichten über dieselbe Verbindung zurückschicken, sodass Geräte nie einen offenen eingehenden Port brauchen.

Die Kosten von TCP

TCP gibt es nicht umsonst, und es ist fair, die Abwägungen zu kennen:

Verbindungsaufbau: TCP braucht einen Drei-Wege-Handshake, und TLS fügt seinen eigenen hinzu. Geräte, die aufwachen, sich verbinden, publizieren und wieder schlafen, zahlen das jedes Mal.
Head-of-Line-Blocking: Ein verlorenes Segment verzögert alles dahinter auf derselben Verbindung, bis es neu übertragen wurde.
Speicher: Ein TCP/IP-Stack und eine TLS-Bibliothek belegen RAM und Flash, die die kleinsten Mikrocontroller nicht haben.
Leerlauf-Timeouts: NAT-Geräte verwerfen inaktive TCP-Zuordnungen, daher muss das MQTT-Keep-Alive kürzer sein als diese Timeouts.

Für die meisten WLAN-, Ethernet- und Mobilfunkgeräte sind diese Kosten im Vergleich zum Nutzen gering, besonders wenn Verbindungen stundenlang offen bleiben. Der Leitfaden zur MQTT-Latenz zeigt, wie Sie den Effekt in Ihrem eigenen Netzwerk messen.

Wo UDP ins Spiel kommt: MQTT-SN

Für Geräte ohne TCP, etwa Zigbee-Knoten oder Sensoren in einfachen Funknetzen, gibt es MQTT-SN (MQTT for Sensor Networks). Es behält das Publish/Subscribe-Modell bei, nutzt aber kompakte Pakete, numerische Topic-IDs und Unterstützung für schlafende Clients, und es läuft über UDP oder andere Datagramm-Transporte. MQTT-SN-Clients sprechen mit einem Gateway, das ihren Verkehr für den Broker in normales MQTT über TCP umwandelt. Lesen Sie MQTT-SN erklärt zur Gateway-Einrichtung und zu Topic-IDs.

Der wichtige Punkt: MQTT-SN ist ein anderes Leitungsprotokoll. Ein Standard-Broker akzeptiert es nur über ein Gateway.

Und MQTT über QUIC?

QUIC ist ein moderner Transport auf Basis von UDP, der zuverlässige, verschlüsselte Streams mit schnellerem Verbindungsaufbau und weniger Head-of-Line-Blocking als TCP plus TLS bietet. Einige Broker-Hersteller haben mit MQTT über QUIC experimentiert, was mobilen Clients helfen kann, die häufig das Netz wechseln. Stand heute ist es nicht Teil des OASIS-MQTT-Standards, die Unterstützung in Client-Bibliotheken ist begrenzt, und Sie sollten keine Geräteflotte darauf planen, sofern Ihr Broker und Ihre Bibliotheken es nicht ausdrücklich unterstützen. Beachten Sie, dass MQTT selbst hier auf einem zuverlässigen, geordneten Stream sitzt; QUIC stellt diesen Stream lediglich auf Basis von UDP bereit.

Welche Ports Sie für Ihren Broker öffnen müssen

Da jeder Standard-MQTT-Transport TCP ist, sind alle Firewall-Regeln ausgehendes TCP. Für broker.connectmq.com und private ConnectMQ-Broker:

TCP 8883 für Geräte, Gateways und Dienste mit MQTT über TLS. Diesen Port sollten Sie zuerst beantragen.
TCP 8084 für Browser und Web-Apps mit sicherem WebSocket unter dem Pfad /mqtt.
TCP 1883 nur für Tests oder isolierte Netze; er ist unverschlüsselt.
TCP 8083 nur für lokale WebSocket-Experimente.
Keine UDP-Ports sind für Standard-MQTT nötig.

Gerade in Werksnetzen ist das ein Vorteil: Ein Edge-Gateway neben der SPS baut nur eine ausgehende TCP-Verbindung durch die IT/OT-Firewall auf, und es muss kein eingehender Port in die Produktionszone geöffnet werden. Wie sich das mit einer DMZ kombinieren lässt, zeigt MQTT in der DMZ. Details und Fehlerbehebung finden Sie in MQTT-Ports erklärt.

Prüfen Sie es selbst

Mit den Werkzeugen, die Sie bereits haben, können Sie bestätigen, dass MQTT TCP ist. Prüfen Sie zuerst die TCP-Erreichbarkeit:

nc -vz broker.connectmq.com 8883

Öffnen Sie dann eine MQTT-Session über TLS auf dem öffentlichen MQTT-Broker, der nur für Tests gedacht ist, mit Debug-Ausgabe, die jedes über die TCP-Verbindung gesendete MQTT-Paket ausgibt:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i tcp-check-62ab -t "connectmq/demo/62ab/#" -v -d

Während der Befehl läuft, listen Sie die Verbindung in einem anderen Terminal auf:

# Linux
ss -tnp | grep 8883
# macOS
netstat -an -p tcp | grep 8883

Sie sehen eine TCP-Verbindung im Zustand ESTABLISHED zu Port 8883 und in jedem Keep-Alive-Intervall PINGREQ und PINGRESP in der Debug-Ausgabe. Wenn Sie den Verkehr in Wireshark mitschneiden, erscheinen die Pakete als TCP, dann TLS, mit MQTT darin.

Im Code ist die Wahl des Transports nur ein URL-Schema. In MQTT.js verwendet mqtts://broker.connectmq.com:8883 TLS über TCP und wss://broker.connectmq.com:8084/mqtt sicheres WebSocket über TCP; der Rest Ihres Codes ist identisch.

const mqtt = require("mqtt");

// Gleiche MQTT-Session-Semantik, zwei TCP-basierte Transporte
const url = process.env.USE_WSS
  ? "wss://broker.connectmq.com:8084/mqtt"
  : "mqtts://broker.connectmq.com:8883";

const client = mqtt.connect(url, { clientId: "tcp-js-62ab", protocolVersion: 5 });

client.on("connect", () => {
  console.log("Connected via", url);
  client.publish("connectmq/demo/62ab/transport", url, { qos: 1 }, () => client.end());
});

Überlegungen für die Produktion

Wenn Sie über den öffentlichen MQTT-Broker hinausgehen, der für Prototypen und nicht für Produktionsdaten gedacht ist, bleibt die Wahl des Transports gleich, aber die Sicherheit wird strenger: TLS überall, eindeutige Zugangsdaten pro Gerät und ein auf Ihr Netzwerk abgestimmtes Keep-Alive. Ein verwalteter MQTT-Broker wie ConnectMQ stellt genau diese TCP-Endpunkte mit einem bereits eingerichteten Let's-Encrypt-Zertifikat bereit, sodass Ihre Geräte nur ausgehenden Zugriff auf 8883 (und 8084 für Web-Clients) benötigen. Einen vollständigen Rundgang durch das Protokoll bietet das MQTT-Tutorial.

Starten Sie mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, öffnen Sie ausgehendes TCP 8883 in Ihrem Netzwerk und verbinden Sie sich mit den generierten Zugangsdaten. Mit dem Browser-Client von ConnectMQ prüfen Sie die Konnektivität, bevor Sie ein einziges Gerät ausrollen.

Häufig gestellte Fragen