Combien de connexions un broker MQTT peut-il supporter ? La réponse honnête est « cela dépend », mais cela dépend d'une liste courte et précise de ressources que vous pouvez mesurer et anticiper. Cet article explique ce qui limite les connexions MQTT simultanées, pourquoi les chiffres publiés correspondent rarement à votre charge, comment tester la capacité vous-même et comment les fournisseurs de brokers MQTT managés traduisent tout cela en limites d'offre.
Pourquoi il n'existe pas de chiffre unique
Vous trouverez des nombres de connexions impressionnants dans les supports marketing des éditeurs et les conférences. Ils sont généralement réels, mais mesurés dans des conditions particulières : clients inactifs, sans TLS ou avec reprise de session, payloads minuscules voire absents, matériel généreux et noyaux soigneusement réglés. Changez l'un de ces paramètres et le chiffre bouge.
Ce qui compte pour vous, ce n'est pas le maximum qu'un broker peut atteindre en laboratoire, mais le nombre de vos clients, avec vos keepalives, votre TLS, vos abonnements et vos schémas de messages, qu'un déploiement donné peut servir avec de la marge. Cela suppose de comprendre les goulots d'étranglement.
Ce qui limite les connexions MQTT simultanées
| Ressource | Pourquoi chaque connexion la consomme | Ce qui aggrave la situation |
|---|---|---|
| Mémoire | Tampons de socket, état TLS, objet de session, abonnements, messages en vol | Gros tampons, nombreux abonnements par client, messages QoS 1/2 en file |
| Descripteurs de fichiers | Chaque socket TCP est un fichier ouvert sur les systèmes de type Unix | ulimits par défaut trop bas, descripteurs supplémentaires pour les journaux et la persistance |
| CPU pour le TLS | Les poignées de main font appel à la cryptographie à clé publique | Tempêtes de reconnexions, absence de reprise de session, grandes tailles de clé |
| CPU pour les keepalives | PINGREQ et PINGRESP pour chaque client à chaque intervalle | Intervalles keepalive très courts sur de grandes flottes |
| Réseau et noyau | Tables de connexions, files d'acceptation, limites du load balancer | File d'acceptation réduite, tables conntrack, limites par IP |
| État des sessions | Les sessions persistantes survivent aux déconnexions | Expiration de session longue pour des clients qui ne reviennent jamais |
La mémoire
La mémoire est généralement la première limite stricte pour les grandes flottes d'appareils peu bavards. Chaque connexion embarque des tampons de socket du noyau, les structures propres au broker pour chaque client, l'état de session TLS et d'éventuels messages en file. Les abonnements en ajoutent, surtout avec de nombreux filtres à jokers. Les clients qui se déconnectent avec des sessions persistantes continuent de consommer de la mémoire jusqu'à l'expiration de la session.
Les descripteurs de fichiers
Sous Linux, chaque socket consomme un descripteur de fichier. La limite souple par défaut de nombreuses distributions est bien trop basse pour un broker, ce qui explique pourquoi « too many open files » est l'une des erreurs les plus courantes lors d'un premier auto-hébergement. Vous pouvez la consulter et l'augmenter :
# Limites actuelles du shell
ulimit -n
ulimit -Hn
# Limites d'un processus de broker en cours d'exécution (remplacez PID)
cat /proc/PID/limits | grep "open files"
# Nombre de sockets ouverts par le broker
ls /proc/PID/fd | wc -l
Pour un service systemd, augmentez la limite dans un fichier de surcharge :
# /etc/systemd/system/mosquitto.service.d/limits.conf
[Service]
LimitNOFILE=200000
Exécutez ensuite sudo systemctl daemon-reload && sudo systemctl restart mosquitto.
Le TLS
Le TLS protège chaque connexion de production, et il a un coût. Le chiffrement continu de petits messages MQTT est peu coûteux, mais la poignée de main l'est comparativement beaucoup plus. Cela compte surtout quand de nombreux clients se connectent en même temps, par exemple après une coupure de courant sur tout un site ou un redémarrage du broker. Un broker qui supporte confortablement sa flotte en régime établi peut tout de même peiner à toutes les accepter dans la même minute. Des délais de reconnexion avec gigue côté client sont la meilleure défense.
Les keepalives
Chaque client envoie un PINGREQ lorsqu'il n'a rien d'autre à envoyer pendant son intervalle keepalive. Sur une grande flotte, des keepalives très courts créent une charge de fond permanente. Un keepalive d'environ 30 à 60 secondes est un compromis courant entre détection rapide des pannes et surcoût ; les appareils sur batterie utilisent souvent des valeurs plus longues.
Le chemin réseau
Les load balancers, les passerelles NAT et les pare-feu conservent tous un état par connexion et ont leurs propres limites. Dans les configurations auto-hébergées, vérifiez la file d'acceptation du noyau (net.core.somaxconn) et la taille des tables de suivi de connexions si vous placez un pare-feu à état devant le broker.
Comment tester vous-même la capacité de connexion
Si vous exploitez votre propre broker, mesurez plutôt que de deviner. Le script ci-dessous ouvre de nombreuses connexions inactives depuis une machine vers un broker que vous contrôlez, comme une instance Mosquitto locale. N'effectuez pas de tests de connexion contre un broker partagé ou contre le serveur MQTT public gratuit, réservé aux tests fonctionnels et aux prototypes : vous déclencherez la protection contre les inondations et affecterez les autres utilisateurs.
# conn_test.py - ouvre N connexions MQTT inactives vers VOTRE PROPRE broker de test
import sys
import time
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "localhost"
COUNT = int(sys.argv[2]) if len(sys.argv) > 2 else 500
connected = 0
def on_connect(client, userdata, flags, reason_code, properties):
global connected
if not reason_code.is_failure:
connected += 1
clients = []
start = time.time()
for i in range(COUNT):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"conn-test-{i}")
c.on_connect = on_connect
try:
c.connect(HOST, 1883, keepalive=60)
c.loop_start()
clients.append(c)
except OSError as exc:
print(f"failed at {i}: {exc}")
break
if i % 100 == 0:
time.sleep(0.5) # cadencer la montée en charge
time.sleep(5)
print(f"{connected}/{COUNT} connected in {time.time() - start:.1f}s")
input("Press Enter to disconnect all clients...")
for c in clients:
c.disconnect()
c.loop_stop()
Lancez-le avec python conn_test.py localhost 2000 tout en surveillant la mémoire et le CPU du broker avec top ou htop. Notez que chaque client paho démarre son propre thread, si bien que la machine de test devient elle-même le goulot d'étranglement à un moment donné ; les outils de charge dédiés qui utilisent des boucles d'événements vont plus loin. Augmentez aussi ulimit -n sur la machine de test. Répétez le test avec le TLS activé et des abonnements réalistes, car les chiffres obtenus avec des clients inactifs en TCP simple sont les plus optimistes que vous verrez jamais.
Comment les brokers MQTT managés fixent les limites de connexions
Les fournisseurs de brokers MQTT managés sont soumis aux mêmes contraintes, mais ils les transforment en quotas d'offre pour vous éviter de régler des noyaux. Sur un cluster partagé, le quota protège aussi chaque tenant de tous les autres.
ConnectMQ publie les limites de connexions suivantes par offre :
| Offre | Limite de connexions | Autres limites clés |
|---|---|---|
| Serveur MQTT public gratuit | Usage raisonnable, limites par client | Messages de 64 Ko, 10 msg/s, 10 abonnements par client |
| Serverless (Free) | Jusqu'à 25 | QoS jusqu'à 1, messages de 256 Ko |
| Serverless (Paid) | Jusqu'à 1 000 | QoS 2, messages de 1 Mo, abonnements partagés |
| Dedicated | Dimensionnée pour votre charge sur un cluster isolé | À discuter avec l'équipe |
| BYOC | Dimensionnée pour votre charge dans votre propre compte cloud | À discuter avec l'équipe |
| Self Managed Enterprise | Vous l'exploitez et la dimensionnez | À discuter avec l'équipe |
Pour Dedicated et BYOC, le bon chiffre dépend des facteurs décrits dans cet article : votre keepalive, votre usage du TLS, votre débit de messages et le comportement de vos sessions. Partagez ces informations lors du cadrage du déploiement au lieu de demander un chiffre unique. Si vous dépassez un quota, les clients MQTT 5 reçoivent le code de raison 0x97 (quota dépassé) ; notre guide sur les quotas de connexion d'un broker MQTT explique comment le gérer.
Compter correctement les connexions
Les équipes sous-estiment fréquemment. Utilisez cette checklist pour vos estimations :
- Chaque appareil ou passerelle disposant de sa propre session MQTT.
- Chaque instance de service backend : enregistreurs en base, alertes, API.
- Chaque outil d'intégration comme Node-RED, Telegraf ou Home Assistant.
- Chaque tableau de bord ou onglet de navigateur exécutant un client MQTT sur WebSocket.
- Les outils de développement : explorateurs de bureau, sessions en ligne de commande, scripts de test.
- Le chevauchement temporaire pendant les déploiements, lorsque anciennes et nouvelles instances de service tournent ensemble.
- Une marge de croissance pour les six à douze prochains mois.
Les passerelles changent le calcul. Une passerelle industrielle qui agrège cinquante tags d'automates, ou une passerelle BLE qui relaie des dizaines de capteurs, utilise une seule connexion MQTT, pas cinquante. Si vous êtes proche d'une limite d'offre, agréger en périphérie revient souvent moins cher que de monter en gamme.
À retenir
- La capacité de connexion dépend de la mémoire, des descripteurs de fichiers, du coût du TLS, du trafic keepalive et de l'état des sessions ; ce n'est pas un chiffre fixe.
- La capacité en régime établi et la capacité face à une tempête de reconnexions sont différentes ; concevez des clients avec une temporisation à gigue.
- Testez votre propre charge sur un matériel que vous contrôlez, avec le TLS activé.
- Sur un broker MQTT managé, ce sont les quotas de l'offre qui comptent, et vous devez compter chaque client, pas seulement les appareils.
Pour le débit plutôt que les connexions, lisez estimer les messages MQTT par seconde, et pour les stratégies de croissance, consultez comment faire évoluer un broker MQTT. Le guide sur le broker MQTT cloud replace l'ensemble dans le contexte des choix d'hébergement.
Démarrer avec ConnectMQ
ConnectMQ est un broker MQTT managé avec des limites de connexions claires par offre, pour planifier votre capacité sans régler de serveurs. Créez un broker Serverless (Free) sur app.connectmq.com, sans carte bancaire, et passez à Serverless (Paid), Dedicated ou BYOC à mesure que votre flotte grandit.
Questions fréquentes
Combien de connexions un broker MQTT peut-il supporter sur un seul serveur ?
Cela dépend de la mémoire, des limites de descripteurs de fichiers, de l'usage du TLS, des intervalles keepalive et de l'état des sessions. Mesurez avec le comportement réel de vos clients et le TLS activé plutôt que de vous fier à un chiffre d'accroche.
Le TLS réduit-il le nombre de connexions MQTT qu'un broker peut supporter ?
Le TLS ajoute de la mémoire par connexion et rend les poignées de main gourmandes en CPU, ce qui compte surtout lors des tempêtes de reconnexions. Le trafic chiffré de petits messages en régime établi est comparativement peu coûteux.
Les clients MQTT inactifs consomment-ils quand même des ressources du broker ?
Oui. Un client inactif occupe toujours un socket, de la mémoire pour sa session et ses abonnements, et envoie des pings keepalive : les flottes silencieuses consomment donc elles aussi de la capacité.
Combien de connexions l'offre gratuite de ConnectMQ autorise-t-elle ?
L'offre Serverless (Free) autorise jusqu'à 25 connexions simultanées, et l'offre Serverless (Paid) jusqu'à 1 000. Les déploiements Dedicated et BYOC sont dimensionnés pour votre charge.
