MQTT TCP ou UDP ? La couche transport expliquée

MQTT utilise-t-il TCP ou UDP ? MQTT fonctionne sur TCP : directement, encapsulé dans TLS, ou transporté dans une connexion WebSocket qui repose elle-même sur TCP. Cet article explique pourquoi MQTT dépend des garanties de TCP, quelle place occupent les variantes basées sur UDP comme MQTT-SN et le MQTT sur QUIC expérimental, et précisément quels ports ouvrir dans votre pare-feu pour un broker cloud.

MQTT utilise-t-il TCP ou UDP ? La réponse courte

Les spécifications MQTT 3.1.1 et 5.0 exigent un transport sous-jacent qui fournit un flux d'octets ordonné, sans perte et bidirectionnel. TCP/IP fournit exactement cela : c'est donc le transport standard. TLS sur TCP et WebSocket sur TCP conviennent aussi, car ils préservent ces propriétés. L'UDP brut, lui, ne les offre pas : le MQTT standard ne fonctionne donc jamais directement sur UDP.

Transport	Protocole sous-jacent	Port typique	MQTT standard ?
MQTT sur TCP	TCP	1883	Oui
MQTT sur TLS	TLS sur TCP	8883	Oui
MQTT sur WebSocket	Upgrade HTTP sur TCP	8083 (`ws`)	Oui
MQTT sur WebSocket sécurisé	TLS sur TCP	8084 (`wss`)	Oui
MQTT-SN	UDP ou autres réseaux de datagrammes	Selon la passerelle	Protocole distinct
MQTT sur QUIC	QUIC sur UDP	Selon le broker	Ne fait pas partie du standard OASIS

La place de MQTT dans la pile réseau

MQTT est un protocole de la couche application. Représentez-vous la pile en partant du haut :

Application : le code de votre capteur, votre tableau de bord ou votre service backend.
MQTT : les paquets CONNECT, PUBLISH, SUBSCRIBE et les acquittements.
Tramage WebSocket optionnel : utilisé par les navigateurs et certains environnements derrière proxy.
TLS optionnel : chiffrement et authentification du broker.
TCP : livraison fiable et ordonnée, avec retransmission et contrôle de flux.
IP et couche liaison : Wi-Fi, Ethernet, cellulaire.

Comme MQTT se situe au-dessus de TCP, il peut rester simple. Il n'a besoin ni de ses propres numéros de séquence pour l'ordre, ni de ses propres temporisations de retransmission pour les segments perdus ; TCP s'en charge sur chaque tronçon entre le client et le broker.

Pourquoi MQTT a choisi TCP

Ordre et intégrité

Les paquets MQTT ont un en-tête de longueur variable et peuvent être découpés sur plusieurs segments TCP. L'analyseur s'attend à recevoir les octets complets et dans l'ordre. Avec UDP, les paquets peuvent arriver dans le désordre, en double ou pas du tout, et le protocole devrait réinventer le réassemblage.

État de connexion

MQTT est orienté connexion. L'échange CONNECT/CONNACK authentifie le client, et le broker associe la connexion ouverte à une session. Le keep-alive, le Last Will et la reprise de session dépendent tous d'une notion claire de « cette connexion est ouverte » ou « cette connexion est rompue », que TCP fournit.

La QoS s'appuie sur une liaison fiable

Les QoS 1 et 2 ajoutent des garanties qui tiennent à travers les coupures de connexion et entre le client et le broker ; elles n'assurent pas la fiabilité au niveau des paquets. Elles supposent que la liaison est fiable tant qu'elle est active et ne gèrent que ce qui se passe lorsqu'elle se rompt. Le guide des niveaux de QoS MQTT présente ces flux.

Pare-feu et NAT

Les connexions TCP initiées en sortie par un appareil sont bien gérées par les routeurs et les pare-feu. Le broker peut renvoyer des messages sur la même connexion : les appareils n'ont donc jamais besoin d'un port entrant ouvert.

Le coût de TCP

TCP n'est pas gratuit, et il est juste d'en connaître les compromis :

Établissement de la connexion : TCP nécessite une poignée de main en trois temps, et TLS ajoute la sienne par-dessus. Les appareils qui se réveillent, se connectent, publient puis se rendorment paient ce coût à chaque fois.
Blocage en tête de file : un segment perdu retarde tout ce qui le suit sur la même connexion jusqu'à sa retransmission.
Mémoire : une pile TCP/IP et une bibliothèque TLS occupent de la RAM et de la flash que les plus petits microcontrôleurs n'ont pas.
Délais d'inactivité : les équipements NAT suppriment les correspondances TCP inactives ; le keep-alive MQTT doit donc être plus court que ces délais.

Pour la plupart des appareils Wi-Fi, Ethernet et cellulaires, ces coûts sont faibles par rapport aux bénéfices, surtout lorsque les connexions restent ouvertes pendant des heures. Le guide de la latence MQTT montre comment en mesurer l'effet sur votre propre réseau.

La place d'UDP : MQTT-SN

Pour les appareils sans TCP, comme les nœuds Zigbee ou les capteurs sur des réseaux radio simples, il existe MQTT-SN (MQTT for Sensor Networks). Il conserve le modèle publish/subscribe mais utilise des paquets compacts, des topic IDs numériques et la prise en charge des clients en veille, et il fonctionne sur UDP ou d'autres transports de datagrammes. Les clients MQTT-SN dialoguent avec une passerelle, qui convertit leur trafic en MQTT classique sur TCP pour le broker. Lisez MQTT-SN expliqué pour la configuration de la passerelle et les topic IDs.

Point important : MQTT-SN est un protocole filaire différent. Un broker standard ne l'accepte que par l'intermédiaire d'une passerelle.

Et le MQTT sur QUIC ?

QUIC est un transport moderne construit sur UDP qui fournit des flux fiables et chiffrés, avec un établissement de connexion plus rapide et moins de blocage en tête de file que TCP plus TLS. Certains éditeurs de brokers ont expérimenté le transport de MQTT sur QUIC, ce qui peut aider les clients mobiles qui changent souvent de réseau. À ce jour, il ne fait pas partie du standard MQTT d'OASIS, la prise en charge par les bibliothèques clientes est limitée, et il ne faut pas bâtir un parc autour de lui à moins que votre broker et vos bibliothèques ne le prennent explicitement en charge. Remarquez que, même dans ce cas, MQTT repose sur un flux fiable et ordonné ; QUIC fournit simplement ce flux au-dessus d'UDP.

Quels ports ouvrir pour votre broker

Puisque tous les transports MQTT standard reposent sur TCP, les règles de pare-feu sont toutes en TCP sortant. Pour broker.connectmq.com et les brokers ConnectMQ privés :

TCP 8883 pour les appareils, passerelles et services utilisant MQTT sur TLS. C'est le premier à demander.
TCP 8084 pour les navigateurs et les applications web utilisant WebSocket sécurisé sur le chemin /mqtt.
TCP 1883 uniquement pour les tests ou les réseaux isolés ; il n'est pas chiffré.
TCP 8083 uniquement pour les expérimentations WebSocket locales.
Aucun port UDP n'est nécessaire pour le MQTT standard.

Les détails et le dépannage se trouvent dans les ports MQTT expliqués.

Vérifiez-le vous-même

Vous pouvez confirmer que MQTT repose sur TCP avec les outils dont vous disposez déjà. Vérifiez d'abord l'accessibilité TCP :

nc -vz broker.connectmq.com 8883

Ouvrez ensuite une session MQTT sur TLS sur le serveur MQTT public gratuit, réservé aux tests, avec la sortie de débogage, qui affiche chaque paquet MQTT envoyé sur la connexion TCP :

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

Pendant son exécution, listez la connexion depuis un autre terminal :

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

Vous verrez une connexion TCP ESTABLISHED vers le port 8883 et, à chaque intervalle de keep-alive, PINGREQ et PINGRESP dans la sortie de débogage. Si vous capturez le trafic dans Wireshark, les paquets apparaissent comme du TCP, puis du TLS, avec MQTT à l'intérieur.

Dans le code, le choix du transport se résume à un schéma d'URL. Avec MQTT.js, mqtts://broker.connectmq.com:8883 utilise TLS sur TCP et wss://broker.connectmq.com:8084/mqtt utilise WebSocket sécurisé sur TCP ; le reste de votre code est identique.

const mqtt = require("mqtt");

// Même sémantique de session MQTT, deux transports basés sur TCP
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());
});

Considérations pour la production

Lorsque vous dépassez le stade du serveur MQTT public gratuit, le choix du transport reste le même mais la sécurité se renforce : TLS partout, identifiants uniques par appareil et keep-alive ajusté à votre réseau. Un broker MQTT managé comme ConnectMQ expose exactement ces points d'accès TCP avec un certificat Let's Encrypt déjà en place : vos appareils n'ont besoin que d'un accès sortant au port 8883 (et 8084 pour les clients web). Pour un parcours complet du protocole, consultez le tutoriel MQTT.

Démarrez avec ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, ouvrez le port TCP 8883 en sortie sur votre réseau et connectez-vous avec les identifiants générés. Le client intégré au navigateur de ConnectMQ vous permet de confirmer la connectivité avant de déployer le moindre appareil.

Questions fréquentes

MQTT utilise-t-il TCP ou UDP ?

Le MQTT standard utilise TCP, directement ou via TLS ou WebSocket. UDP n'est utilisé que par le protocole distinct MQTT-SN et par le MQTT sur QUIC expérimental.

Puis-je envoyer du MQTT sur UDP pour économiser de l'énergie ?

Pas vers un broker standard. Utilisez MQTT-SN avec une passerelle, ou maintenez une connexion TCP de longue durée et ne publiez que lorsque les valeurs changent.

Le MQTT sur WebSocket utilise-t-il toujours TCP ?

Oui. WebSocket commence par une requête HTTP sur TCP, puis transporte les paquets MQTT sur cette même connexion TCP.

À quelle couche du modèle OSI appartient MQTT ?

MQTT est un protocole de la couche application qui s'appuie sur TCP au niveau de la couche transport.

MQTT utilise-t-il TCP ou UDP ? La couche transport de MQTT expliquée