Quotas de connexion d'un broker MQTT : connexions, débits de messages et limites de payload

Les quotas de connexion d'un broker MQTT déterminent combien de clients vous pouvez connecter, à quelle vitesse ils peuvent publier et quelle taille peut atteindre chaque message. Ce guide explique chaque quota courant sur un broker MQTT managé, la façon dont les brokers MQTT 3.1.1 et MQTT 5 signalent que vous en avez atteint un, et comment écrire des clients qui restent confortablement dans les limites de votre offre.

Pourquoi les brokers MQTT managés appliquent des quotas

Un broker MQTT managé est une infrastructure partagée, même lorsque vous disposez d'un cluster dédié. La mémoire, le CPU, la bande passante réseau et les descripteurs de fichiers sont limités, et un seul client défaillant, comme un firmware coincé dans une boucle de publication serrée ou une tempête de reconnexions après une coupure Wi-Fi, peut dégrader le service pour tous les autres utilisateurs des mêmes machines. Les quotas transforment ces ressources limitées en limites explicites et prévisibles.

Sur un service multi-tenant, les quotas sont aussi la manière dont l'isolation fonctionne concrètement. ConnectMQ, par exemple, applique des quotas par offre, une protection contre les inondations de messages et un blocage d'IP après des échecs de connexion répétés, afin que le problème d'un tenant reste le problème de ce tenant. Si ce modèle est nouveau pour vous, notre article sur ce que fait un broker MQTT couvre les bases des interactions entre clients et brokers.

Les quotas courants d'un broker MQTT

La plupart des fournisseurs appliquent une combinaison des quotas suivants. Les noms diffèrent, mais les concepts sont partout les mêmes.

Des limites d'offres réelles en exemple

Voici comment ConnectMQ fixe ses limites selon l'offre :

• Serverless (Free) : jusqu'à 25 connexions, QoS jusqu'à 1, messages jusqu'à 256 Ko.
• Serverless (Paid) : jusqu'à 1 000 connexions, QoS 2, messages jusqu'à 1 Mo, abonnements partagés.
• Dedicated, BYOC et Self Managed Enterprise : déploiements isolés dimensionnés pour votre charge de travail.
• Serveur MQTT public gratuit (broker.connectmq.com, pour les tests uniquement) : 64 Ko par message, 10 messages par seconde par client, 10 abonnements par client, 8 niveaux de topic, QoS 0 à 2 et expiration de session jusqu'à 30 minutes.

Comment les brokers signalent qu'un quota est atteint

C'est là que la version du protocole fait toute la différence.

MQTT 3.1.1 : deviner à partir des déconnexions

MQTT 3.1.1 ne dispose que d'une poignée de codes de retour CONNACK et n'offre aucun moyen au broker d'expliquer une déconnexion. Lorsqu'un client 3.1.1 dépasse une limite, le broker se contente généralement de fermer la connexion TCP. Le client voit une « perte de connexion » générique et se reconnecte, atteignant souvent de nouveau la même limite. Diagnostiquer des problèmes de quota en 3.1.1 suppose de croiser les journaux du client avec ce qu'affiche la console du fournisseur.

MQTT 5 : des codes de raison explicites

MQTT 5 a ajouté des codes de raison à CONNACK, PUBACK, SUBACK et DISCONNECT, ce qui rend les problèmes de quota visibles côté client. Ceux que vous rencontrerez le plus souvent sont définis dans la spécification OASIS MQTT 5.0 :

ConnectMQ prend en charge les codes de raison MQTT 5, dont 0x97 (quota dépassé), si bien qu'un client en MQTT 5 peut journaliser une cause précise au lieu d'une déconnexion floue. Cela suffit à justifier l'usage de MQTT 5 pour les nouveaux projets ; consultez les fonctionnalités de MQTT 5 pour le reste.

Les brokers MQTT 5 peuvent aussi annoncer leurs limites dès la connexion, dans des propriétés CONNACK comme Maximum Packet Size, Receive Maximum, Topic Alias Maximum et Maximum QoS. Un client bien écrit les lit et s'y adapte.

Concevoir des clients qui restent dans leurs quotas

La meilleure stratégie en matière de quotas, c'est un client qui n'approche jamais de la limite. Ces pratiques préviennent la plupart des incidents liés aux quotas.

Lire les limites du broker à la connexion

L'exemple Python ci-dessous se connecte avec paho-mqtt 2.x sur TLS, affiche les limites annoncées par le broker et journalise les codes de raison à la déconnexion.

import paho.mqtt.client as mqtt

LIMIT_PROPS = ("MaximumPacketSize", "ReceiveMaximum",
               "TopicAliasMaximum", "MaximumQoS", "SharedSubscriptionAvailable")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect refused:", reason_code)
        return
    print("connected")
    for name in LIMIT_PROPS:
        value = getattr(properties, name, None)
        if value is not None:
            print(f"  broker limit {name} = {value}")

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)
    if reason_code == "Quota exceeded":
        print("plan quota hit; back off and alert an operator")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Si vous voulez d'abord expérimenter sans compte, pointez le même script vers le serveur MQTT public gratuit sur le port 1883, avec un client ID unique et sans identifiants.

Limiter le débit de publication côté client

Ne comptez jamais sur le broker pour vous freiner. Un petit seau à jetons (token bucket) maîtrise les rafales, ce qui compte surtout lorsqu'un appareil se reconnecte et tente de vider un arriéré.

const mqtt = require("mqtt");

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "YOUR_CLIENT_ID",
  username: "YOUR_USERNAME",
  password: "YOUR_PASSWORD",
  protocolVersion: 5,
  reconnectPeriod: 5000,
});

// Seau à jetons : au plus RATE messages par seconde, rafale jusqu'à BURST.
const RATE = 5;
const BURST = 10;
let tokens = BURST;
setInterval(() => { tokens = Math.min(BURST, tokens + RATE); }, 1000);

const queue = [];
function enqueue(topic, payload) { queue.push({ topic, payload }); }

setInterval(() => {
  while (tokens >= 1 && queue.length > 0 && client.connected) {
    const { topic, payload } = queue.shift();
    client.publish(topic, payload, { qos: 1 });
    tokens -= 1;
  }
}, 100);

client.on("connect", () => console.log("connected"));
client.on("disconnect", (packet) => console.log("broker disconnect, reason", packet.reasonCode));

// Simule la purge d'un arriéré après une panne.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));

Temporiser avec une gigue aléatoire à la reconnexion

Lorsqu'un site perd sa connectivité, des centaines d'appareils peuvent se reconnecter dans la même seconde. Sans temporisation aléatoire, ils atteignent ensemble le quota de taux de connexion, échouent ensemble et réessaient ensemble. Ajoutez une gigue aléatoire à chaque délai de reconnexion et plafonnez le délai maximal à une ou deux minutes.

Garder des client ID uniques et stables

Sur les brokers MQTT managés qui lient les client ID aux identifiants émis, comme le fait ConnectMQ, les doublons sont un piège fréquent. Si vous copiez un même jeu d'identifiants sur deux appareils, chaque connexion éjecte l'autre, ce que MQTT 5 signale par 0x8E (session reprise). Le résultat ressemble à une connexion instable et épuise rapidement les limites de taux de connexion. Émettez un jeu d'identifiants par appareil ou service.

Regrouper les petites mesures

Dix valeurs de capteur dans un seul message JSON coûtent une publication au lieu de dix. Le regroupement réduit le débit de messages et généralement la bande passante, à condition que le lot reste bien en deçà de la limite de payload de votre offre.

Utiliser des abonnements moins nombreux et plus larges

Un seul joker comme site1/+/telemetry est plus simple à gérer que des dizaines d'abonnements exacts, et vous tient à l'écart des plafonds d'abonnements par client.

Checklist de préparation aux quotas

Avant le déploiement, passez en revue cette liste pour chaque type de client :

1. Comptez les connexions simultanées, y compris les tableaux de bord, scripts et intégrations.
2. Calculez le pic de publications par seconde et par client, pas seulement la moyenne.
3. Mesurez le plus gros payload, y compris les purges d'arriérés et les vidages d'erreurs.
4. Confirmez le niveau de QoS nécessaire à chaque topic et sa prise en charge par l'offre.
5. Vérifiez que chaque appareil a son propre client ID et ses propres identifiants.
6. Implémentez une temporisation exponentielle avec gigue pour les reconnexions.
7. Journalisez les codes de raison MQTT 5 et envoyez-les vers un outil où vous pouvez les rechercher.
8. Gardez de la marge : prévoyez environ le double de la charge attendue pour que la croissance ne vous prenne pas de court.

Pour les calculs de dimensionnement des points 2 et 3, lisez estimer les messages MQTT par seconde. Si vous comparez des options d'entrée de gamme, notre guide sur l'offre gratuite d'un broker MQTT montre comment les quotas diffèrent entre offres gratuites, et notre dossier sur le broker MQTT cloud couvre plus largement les choix d'hébergement.

Résoudre les problèmes de quota

• Les connexions tombent toutes les quelques secondes : cherchez avant tout des client ID en double.
• Les gros messages disparaissent : comparez la taille du payload à la limite de l'offre et à la propriété Maximum Packet Size du broker.
• Des abonnements ne reçoivent rien, sans erreur visible : examinez les codes de raison du SUBACK ; un code d'échec signifie que le filtre n'a pas été accepté.
• Tout échoue après une panne générale du site : votre logique de reconnexion manque de gigue et vous déclenchez la protection sur le taux de connexion.
• Déconnexions inexpliquées en MQTT 3.1.1 : passez temporairement le client en MQTT 5 pour obtenir un code de raison.

Démarrer avec un broker MQTT managé

ConnectMQ publie clairement les limites de ses offres et signale les problèmes de quota par des codes de raison MQTT 5, pour que vous puissiez concevoir en conséquence dès le premier jour. Commencez avec l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, puis passez à Serverless payant, Dedicated ou BYOC à mesure que votre flotte grandit. Si vous préférez confier entièrement l'infrastructure à quelqu'un d'autre, un broker MQTT managé gère pour vous les correctifs, le TLS et la capacité.

Questions fréquentes

Que signifie le code de raison MQTT 0x97 ?

0x97 correspond à « Quota exceeded » (quota dépassé) en MQTT 5. Le broker indique au client qu'une limite de l'implémentation ou de l'offre a été atteinte : le client doit donc temporiser plutôt que réessayer immédiatement.

Les tableaux de bord et les scripts comptent-ils dans les quotas de connexion ?

Oui. Chaque client MQTT qui maintient une session ouverte compte pour une connexion, qu'il s'agisse d'un capteur, d'un flux Node-RED ou d'un onglet de navigateur.

Comment connaître la taille maximale de message acceptée par mon broker ?

Consultez la documentation de l'offre et, en MQTT 5, lisez la propriété Maximum Packet Size dans le CONNACK. L'offre Serverless gratuite de ConnectMQ autorise 256 Ko et l'offre Serverless payante 1 Mo.

Pourquoi mon appareil se reconnecte-t-il en boucle ?

La cause la plus fréquente est le partage d'un même client ID par deux clients, ce qui conduit le broker à déconnecter l'ancienne session à chaque fois. Attribuez à chaque appareil ses propres identifiants et son propre client ID.