MQTT 5 vs. MQTT 3.1.1: Was hat sich geändert und lohnt sich das Upgrade?

MQTT 3.1.1 wurde 2014 zum OASIS-Standard und später zum ISO-Standard (ISO/IEC 20922). MQTT 5 folgte 2019 als OASIS-Standard. Das Kernmodell – Publish/Subscribe über Topics mit drei QoS-Stufen – ist unverändert, aber MQTT 5 bringt die Features mit, für die alle ständig Workarounds gebaut haben: ordentliche Fehlermeldungen, Ablaufzeiten, Metadaten, lastverteilte Subscriptions und Flow Control. Hier erfährst du, was sich tatsächlich unterscheidet und wann es darauf ankommt.

Übersichtstabelle

Reason Codes überall

In 3.1.1 liefert ein fehlgeschlagenes CONNECT einen von sechs Codes zurück, und die meisten anderen Fehler bleiben stumm: Ist ein Publish nicht autorisiert, verwirft der Broker es womöglich einfach oder schließt die Verbindung. MQTT 5 ergänzt CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT und AUTH um einen Reason Code, optional mit einem menschenlesbaren Reason String. Der Broker kann außerdem ein DISCONNECT senden, um zu erklären, warum er eine Verbindung schließt, etwa 0x8E Session taken over. Die vollständige Liste gängiger Codes findest du in unserem Guide zu MQTT-Verbindungsfehlern.

Session Expiry und Message Expiry

Session Expiry Interval

MQTT 3.1.1 bietet genau einen Schalter: Clean Session. Mit cleanSession=false behält der Broker deine Subscriptions und gepufferten Nachrichten für immer, was sich bei Geräten, die nie zurückkommen, anhäufen kann. MQTT 5 teilt das auf in Clean Start (bestehende Session beim Verbinden verwerfen?) und Session Expiry Interval (wie viele Sekunden die Session nach dem Trennen erhalten bleibt). Ein Gerät kann jetzt sagen: Behalte meine Session eine Stunde lang, dann räum auf.

Message Expiry Interval

Ein Publisher kann für jede Nachricht eine Lebensdauer in Sekunden festlegen. Wurde sie bis dahin nicht zugestellt – zum Beispiel, weil der Subscriber offline war –, verwirft der Broker sie. So bekommt ein Offline-Aktor nicht Stunden später noch einen veralteten Befehl, und das gilt auch für Retained Messages.

User Properties und Content-Metadaten

MQTT-5-Pakete können User Properties enthalten: beliebige UTF-8-Schlüssel/Wert-Paare, ähnlich wie HTTP-Header. Nutze sie für Trace-IDs, Schema-Versionen oder Quellkennungen, ohne die Payload in einen Umschlag zu packen. Zwei verwandte Properties beschreiben die Payload selbst: Payload Format Indicator (binär oder UTF-8) und Content Type (zum Beispiel application/json).

client.publish('factory/line-1/temp', JSON.stringify({ c: 21.4 }), {
  qos: 1,
  properties: {
    messageExpiryInterval: 60,
    contentType: 'application/json',
    userProperties: { traceId: 'a1b2c3', schema: 'v2' },
  },
});

Shared Subscriptions

Normalerweise erhält jeder Subscriber jede passende Nachricht. Eine Shared Subscription verteilt Nachrichten stattdessen auf eine Gruppe, sodass du ein Backend horizontal skalieren kannst. Abonnieren drei Instanzen $share/workers/orders/#, geht jede Nachricht nur an eine von ihnen. Mehrere 3.1.1-Broker boten das als proprietäre Erweiterung an; MQTT 5 standardisiert die Syntax. Mehr zu Filtern erfährst du in MQTT-Topics und Wildcards.

Topic Aliases

Lange Topic-Namen werden mit jedem Publish übertragen. Mit Topic Aliases ordnet ein Client einem Topic einmalig eine kleine Ganzzahl zu und sendet danach nur noch diese Zahl. Jede Seite teilt über Topic Alias Maximum mit, wie viele Aliase sie akzeptiert. Das spart Bandbreite bei Geräten, die häufig an lange Topics über volumenbasierte Verbindungen publishen.

Request/Response

MQTT ist von Haus aus einseitig, aber viele Anwendungen brauchen Antworten. MQTT 5 ergänzt das Publish-Paket um ein Response Topic (wohin die Antwort gehen soll) und Correlation Data (zu welcher Anfrage die Antwort gehört). Ein Responder liest beides und publisht seine Antwort entsprechend – du musst also kein eigenes Umschlagformat mehr erfinden.

Flow Control und Limits

• Receive Maximum: wie viele unbestätigte QoS-1- und QoS-2-Nachrichten eine Seite gleichzeitig verarbeiten will. Das verhindert, dass ein schneller Broker ein langsames Gerät überrollt. Siehe MQTT-QoS-Stufen.
• Maximum Packet Size: Jede Seite kann Pakete ablehnen, die größer sind als ein von ihr angegebener Wert.
• Server Keep Alive: Der Broker kann den Keep-Alive-Wert des Clients überschreiben.
• Assigned Client Identifier: Verbindest du dich mit leerer Client-ID, teilt dir der Broker die von ihm erzeugte mit.

Enhanced Authentication

Die Authentifizierung in MQTT 3.1.1 beschränkt sich auf Benutzername und Passwort im CONNECT (plus TLS-Client-Zertifikate auf Transportebene). MQTT 5 ergänzt ein AUTH-Paket und die Properties Authentication Method und Authentication Data. Damit werden Challenge/Response-Verfahren wie SCRAM oder Kerberos möglich, ebenso eine erneute Authentifizierung auf einer laufenden Verbindung ohne Disconnect. Die Unterstützung durch Broker variiert, also prüfe sie, bevor du dich darauf verlässt.

Kleinere, aber nützliche Ergänzungen

• Subscription-Optionen: No Local (meine eigenen Nachrichten nicht zurückspiegeln), Retain As Published und Retain Handling.
• Subscription Identifiers: zeigen an, welche Subscription auf eine zugestellte Nachricht gepasst hat.
• Will Delay Interval: verzögert den Last Will, damit ein schneller Reconnect ihn nicht auslöst.

Solltest du upgraden?

Für neue Projekte ist MQTT 5 die richtige Standardwahl: Allein die besseren Fehlermeldungen sparen Stunden beim Debuggen. Bleib bei 3.1.1, wo sich Firmware oder Bibliotheken nicht aktualisieren lassen; nichts zwingt dich zur Migration, und beide Versionen koexistieren auf demselben Broker. Wenn du upgradest, aktiviere die Version in deinem Client (bei MQTT.js protocolVersion: 5) und prüfe, ob der Broker sie akzeptiert.

Im Browser mit MQTT 5 verbinden

Ganz neu im Protokoll? Fang mit Was ist MQTT? an oder probier beide Versionen direkt im Online-MQTT-Client aus.

Häufig gestellte Fragen