Dans la spécification, la taille maximale d'un message MQTT est d'environ 256 Mo par paquet, mais la limite qui compte réellement est celle fixée par votre broker, votre bibliothèque cliente et la mémoire de votre appareil, généralement bien plus basse. Ce guide explique chacune de ces limites, ce qui se passe quand un message est trop gros, et trois stratégies pour transférer de gros payloads comme des images, des journaux ou des firmwares sans casser vos connexions MQTT.
Le plafond du protocole : 256 Mo
MQTT encode la longueur de l'en-tête variable et du payload de chaque paquet dans un champ « remaining length » de quatre octets maximum, avec sept bits utiles chacun. La plus grande valeur possible est 268 435 455 octets, soit environ 256 Mo. Retirez le nom du topic et les en-têtes, et vous obtenez le payload maximum théorique. L'encodage est expliqué octet par octet dans le guide de la structure des paquets MQTT.
Personne n'exploite de système de production à proximité de ce plafond. Un broker qui accepterait des messages de 256 Mo de n'importe quel client serait facile à épuiser : il doit mettre le paquet en mémoire tampon, éventuellement le stocker pour des sessions hors ligne ou comme valeur retenue, et le copier vers chaque subscriber. MQTT a été conçu pour de nombreux petits messages, et chaque couche d'un déploiement réel le reflète.
Où se trouvent les vraies limites
| Couche | Limite typique | Ce qui la fixe |
|---|---|---|
| Spécification MQTT | 268 435 455 octets par paquet | Encodage de la remaining length |
| Broker | Taille maximale de message ou de paquet configurée | Configuration du broker ou offre |
| Négociation MQTT 5 | Propriété Maximum Packet Size | Le client et le broker annoncent chacun ce qu'ils acceptent |
| Bibliothèque cliente | Taille du buffer interne | Valeurs par défaut de la bibliothèque, par ex. 256 octets dans PubSubClient pour Arduino |
| Appareil | RAM libre | Un microcontrôleur peut ne disposer que de quelques dizaines de Ko |
| Réseau | Débit et stabilité | Les gros messages prennent plus de temps et échouent plus souvent sur les liens faibles |
C'est la plus petite limite de la chaîne qui l'emporte. Un broker qui accepte 1 Mo ne sert à rien si un subscriber ESP8266 ne peut mettre en tampon que quelques kilo-octets. Si vous travaillez avec du matériel de classe Arduino, le guide de la taille du buffer PubSubClient traite de ce piège particulier.
Taille maximale des messages MQTT sur ConnectMQ
Voici les limites actuelles par type de broker :
| Broker | Taille maximale de message |
|---|---|
| Serveur MQTT public gratuit (broker.connectmq.com, tests uniquement) | 64 Ko |
| Offre Serverless (Free) | 256 Ko |
| Offre Serverless (Paid) | 1 Mo |
| Dedicated, BYOC et Self Managed Enterprise | Dépend du déploiement |
Pour la plupart des télémétries, alarmes et commandes, même 64 Ko est généreux : une mesure de capteur en JSON pèse généralement bien moins de 1 Ko. Si vous approchez régulièrement de ces limites, c'est généralement le signe que le payload a sa place ailleurs, comme décrit ci-dessous.
Le Maximum Packet Size de MQTT 5
MQTT 5 a rendu les limites de taille explicites avec la propriété Maximum Packet Size (0x27) :
- Dans le CONNECT, le client indique au broker le plus gros paquet qu'il accepte de recevoir. Le broker ne doit rien envoyer de plus gros ; il supprime alors ces messages pour ce client.
- Dans le CONNACK, le broker indique au client le plus gros paquet qu'il accepte. Un client qui envoie davantage enfreint le protocole.
Notez qu'il s'agit de la taille du paquet entier, en-tête fixe, topic et propriétés compris, pas seulement du payload. Gardez de la marge.
Lire la limite du broker avec MQTT.js :
const mqtt = require("mqtt");
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
clientId: "size-check-8b4d",
protocolVersion: 5,
properties: { maximumPacketSize: 64 * 1024 }, // ce que ce client accepte
});
client.on("connect", (connack) => {
const max = connack.properties?.maximumPacketSize;
console.log("Broker maximum packet size:", max ?? "not announced");
client.end();
});
Si la propriété est absente, le broker n'a pas annoncé de limite dans le CONNACK, mais il peut tout de même en appliquer une. Connaissez toujours la limite documentée de votre broker.
Que se passe-t-il quand un message est trop gros
Le comportement dépend de la version du protocole et du sens :
- Du client vers le broker, en MQTT 5. Le broker déconnecte généralement le client avec le reason code
0x95 Packet too large. - Du client vers le broker, en MQTT 3.1.1. Il n'y a pas de reason code ; le broker ferme la connexion. Le client constate une perte de connexion générique.
- Du broker vers le client. Si un subscriber a annoncé un Maximum Packet Size inférieur, le broker supprime le message pour ce subscriber. En 3.1.1, la bibliothèque du subscriber peut échouer à l'analyser ou se déconnecter.
- Dans le client. Certaines bibliothèques refusent d'envoyer et renvoient une erreur ; PubSubClient pour Arduino renvoie simplement
falsedepuispublish().
Le schéma dangereux est celui d'un client qui met en file d'attente le message surdimensionné, se reconnecte et le renvoie immédiatement. Résultat : une boucle de déconnexion, l'une des raisons classiques pour lesquelles un client MQTT se déconnecte sans cesse. Validez la taille avant de publier, et supprimez ou redirigez les messages trop gros.
Stratégies pour les gros payloads
1. Réduire le payload
Avant de découper quoi que ce soit, réduisez. Les noms de champs JSON sont répétés dans chaque message ; des clés courtes, des encodages binaires comme CBOR ou Protobuf et la compression gzip réduisent souvent les payloads de façon spectaculaire. N'envoyer que les valeurs modifiées plutôt que l'état complet aide aussi. Le guide du format de payload MQTT compare les options.
2. Découper le message
Lorsqu'un payload est modérément gros, par exemple quelques centaines de kilo-octets de journaux, vous pouvez le découper en morceaux numérotés et le réassembler côté réception. Ce publisher Python découpe un fichier en morceaux de 32 Ko avec un petit en-tête JSON par morceau :
import base64, hashlib, json, math, time, uuid
import paho.mqtt.client as mqtt
CHUNK = 32 * 1024
TOPIC = "connectmq/demo/8b4d/files"
def send_file(client, path):
data = open(path, "rb").read()
transfer_id = uuid.uuid4().hex[:8]
total = math.ceil(len(data) / CHUNK)
sha = hashlib.sha256(data).hexdigest()
for i in range(total):
part = data[i * CHUNK:(i + 1) * CHUNK]
msg = {"id": transfer_id, "seq": i, "total": total, "sha256": sha,
"data": base64.b64encode(part).decode()}
client.publish(f"{TOPIC}/{transfer_id}", json.dumps(msg), qos=1).wait_for_publish()
time.sleep(0.15) # respecter les limites de débit par client
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="chunker-8b4d")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
send_file(client, "report.csv")
client.loop_stop()
client.disconnect()
Base64 augmente la taille d'environ un tiers : 32 Ko de binaire deviennent donc environ 43 Ko sur le réseau, confortablement sous la limite de 64 Ko du serveur public. Le subscriber regroupe les morceaux par id, les ordonne par seq et vérifie le SHA-256 une fois les total parties arrivées. Utilisez la QoS 1 pour ne pas perdre silencieusement de morceaux, et prévoyez les doublons et les parties manquantes avec un timeout. Sur le serveur public, gardez à l'esprit la limite de 10 messages par seconde, que gère la pause.
Le découpage ajoute de la complexité : réservez-le aux payloads trop gros pour un seul message, mais assez petits pour que MQTT reste le bon transport.
3. Envoyer le fichier hors bande
Pour les images, la vidéo, les images de firmware et les gros exports, le modèle le plus robuste consiste à garder entièrement les octets hors de MQTT. Téléversez le fichier vers un stockage objet ou un serveur web en HTTPS, puis publiez un petit message MQTT qui pointe vers lui :
{
"type": "firmware",
"version": "2.4.1",
"url": "https://files.example.com/fw/sensor-2.4.1.bin",
"sha256": "9f2c...e81a",
"size": 1048576
}
Les appareils récupèrent le fichier avec des requêtes HTTP range et la reprise des téléchargements, vérifient le hash et rendent compte de leur progression via MQTT. Vous conservez les atouts de MQTT, notification instantanée et diffusion vers de nombreux appareils, tandis que HTTP et les services de stockage gèrent le transfert en volume.
Check-list de décision selon la taille
- Moins de 10 Ko : envoyez en un seul message, sans traitement particulier.
- De 10 Ko jusqu'à la limite de votre broker : compressez ou utilisez un encodage compact, et vérifiez que chaque subscriber peut le mettre en tampon.
- Au-delà de la limite, mais seulement occasionnellement : découpez avec des numéros de séquence et des sommes de contrôle.
- Gros fichiers binaires ou transferts en volume réguliers : téléversez hors bande et publiez une référence.
- Dans tous les cas : vérifiez la taille dans le code avant d'appeler publish.
Envoyer des messages sur ConnectMQ
ConnectMQ vous offre des limites claires selon l'offre, des messages de 256 Ko sur l'offre Serverless gratuite à 1 Mo sur l'offre Serverless payante, avec les options Dedicated, BYOC et Self Managed Enterprise pour les déploiements plus importants. Expérimentez d'abord sur le serveur MQTT public gratuit, puis passez à un broker MQTT managé lorsque vous avez besoin d'identifiants privés et de limites plus élevées. Le tutoriel MQTT couvre les fondamentaux si vous débutez.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et obtenez un nom d'utilisateur, un mot de passe et un client ID en quelques minutes. Pour comparer les options d'hébergement, lisez notre guide pour choisir un broker MQTT cloud.
Questions fréquentes
Quelle est la taille maximale d'un message MQTT ?
Le protocole autorise des paquets jusqu'à 268 435 455 octets, soit environ 256 Mo. En pratique, les brokers fixent des limites bien plus basses ; sur ConnectMQ, c'est 64 Ko sur le serveur MQTT public gratuit, 256 Ko sur l'offre gratuite et 1 Mo sur l'offre Serverless payante.
Que se passe-t-il si je publie un message trop gros ?
Le broker le rejette, généralement en fermant la connexion. Les clients MQTT 5 reçoivent le reason code 0x95 Packet too large, tandis que les clients MQTT 3.1.1 voient simplement la connexion tomber.
Faut-il envoyer des fichiers via MQTT ?
Les petits fichiers peuvent être envoyés directement ou en morceaux. Pour les gros fichiers, téléversez-les en HTTPS vers un stockage et publiez un petit message MQTT contenant l'URL et la somme de contrôle.
La limite de taille inclut-elle le nom du topic ?
Les limites des brokers sont souvent exprimées par message ou par paquet, et le Maximum Packet Size de MQTT 5 compte le paquet entier, topic et propriétés compris. Gardez de la marge au-delà de la taille de votre payload.
