La latence d'un broker MQTT par région compte, car la distance physique entre vos appareils et le broker fixe un plancher qu'aucun réglage ne peut supprimer. Ce guide explique d'où vient la latence MQTT, vous montre comment mesurer les temps d'aller-retour depuis vos propres sites avec un court script, et propose une méthode pratique pour choisir où votre broker doit tourner.
D'où vient la latence MQTT
La latence de bout en bout d'un message MQTT, de la publication par un capteur à sa réception par un abonné, est la somme de plusieurs composantes :
| Composante | De quoi il s'agit | Influencée par |
|---|---|---|
| Réseau d'accès | De l'appareil à Internet : Wi-Fi, Ethernet, cellulaire, satellite | Conditions radio, opérateur, matériel de passerelle |
| Propagation | La lumière qui parcourt la fibre jusqu'au broker et retour | Distance physique et chemin de routage |
| Routage et peering | Sauts entre réseaux | Interconnexions des FAI et des fournisseurs cloud |
| Traitement par le broker | Analyse, autorisation, correspondance des abonnements, livraison | Charge du broker, offre, diffusion |
| Chemin vers l'abonné | Du broker à l'application consommatrice | Emplacement de l'abonné |
| Comportement du client | Mise en tampon, regroupement, acquittements QoS | Paramètres de la bibliothèque et votre code |
Le choix de la région influe surtout sur la propagation et le routage. Dans une fibre optique, la lumière se déplace à environ deux tiers de sa vitesse dans le vide, ce qui représente environ 1 milliseconde de temps d'aller-retour par tranche de 100 kilomètres de fibre, avant tout détour de routage. Les chemins réseau réels sont rarement des lignes droites : les temps mesurés sont donc plus élevés. Un appareil situé sur un continent qui communique avec un broker sur un autre paiera toujours cette distance à chaque aller-retour.
L'établissement de la connexion multiplie les allers-retours
La latence pèse surtout au moment de la connexion. Avant que le premier message ne circule, un client MQTT protégé par TLS a besoin d'une poignée de main TCP, d'une poignée de main TLS et d'un échange MQTT CONNECT/CONNACK. TLS 1.3 nécessite un aller-retour pour sa poignée de main, TLS 1.2 généralement deux. Cela représente plusieurs allers-retours avant la première publication, ce qui se remarque pour les appareils qui sortent d'un sommeil profond, se connectent, publient et se déconnectent. Pour les appareils connectés en permanence, le coût d'établissement est payé une fois et c'est le temps d'aller-retour en régime établi qui compte le plus.
La QoS ajoute des allers-retours d'acquittement
Une publication en QoS 0 est envoyée sans attendre de retour. La QoS 1 attend un PUBACK, et la QoS 2 nécessite un échange en quatre étapes. Le message atteint les abonnés à peu près au même moment, mais l'éditeur attend plus longtemps, ce qui compte pour les clients dont la fenêtre de messages en vol est limitée. Notre article sur les niveaux de QoS MQTT détaille ces compromis.
Comment mesurer la latence MQTT depuis vos sites
Les cartes de latence génériques sont un point de départ utile, mais ce sont vos propres mesures depuis vos propres sites qui comptent. Mesurez à trois niveaux.
Niveau 1 : temps d'aller-retour réseau
Depuis une machine située sur le site des appareils, exécutez :
# Aller-retour ICMP (peut être bloqué par certains réseaux)
ping -c 20 broker.connectmq.com
# Vue par saut du chemin, utile pour repérer les détours
mtr --report --report-cycles 20 broker.connectmq.com
# Temps de connexion TCP au port MQTT TLS
time nc -z -w 5 broker.connectmq.com 8883
La ligne nc ne mesure qu'une connexion TCP brute ; le script au niveau MQTT ci-dessous fournit des chiffres TLS et protocolaires plus utiles.
Niveau 2 : connexion MQTT et aller-retour de publication
Ce script Python, basé sur paho-mqtt 2.x, mesure le temps jusqu'au CONNACK sur TLS, puis l'aller-retour de messages publiés et reçus par le même client. Exécutez-le depuis chaque site qui vous intéresse.
# mqtt_rtt.py - mesure le temps de connexion MQTT et l'aller-retour publication/réception
import statistics
import sys
import threading
import time
import uuid
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "broker.connectmq.com"
PORT = 8883
SAMPLES = 30
run_id = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{run_id}/rtt"
connected = threading.Event()
received = threading.Event()
rtts = []
sent_at = 0.0
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=0)
def on_subscribe(client, userdata, mid, reason_codes, properties):
connected.set()
def on_message(client, userdata, msg):
rtts.append((time.perf_counter() - sent_at) * 1000)
received.set()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"rtt-{run_id}", protocol=mqtt.MQTTv5)
# Pour un broker privé, ajoutez les identifiants :
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
if not connected.wait(15):
sys.exit("could not connect and subscribe")
print(f"connect + TLS + subscribe: {(time.perf_counter() - t0) * 1000:.0f} ms")
for i in range(SAMPLES):
received.clear()
sent_at = time.perf_counter()
client.publish(TOPIC, str(i), qos=0)
if not received.wait(5):
print("timeout on sample", i)
time.sleep(0.2) # rester bien en dessous de 10 msg/s sur le broker public
client.loop_stop()
client.disconnect()
if rtts:
rtts.sort()
print(f"publish->receive RTT over {len(rtts)} samples: "
f"median {statistics.median(rtts):.1f} ms, "
f"p90 {rtts[int(len(rtts) * 0.9) - 1]:.1f} ms, max {rtts[-1]:.1f} ms")
Comme le même client publie et reçoit, le résultat correspond à un aller-retour complet via le broker, ce qui donne une bonne approximation de la latence appareil-backend lorsque votre backend se trouve à proximité du broker. Le script utilise le serveur MQTT public gratuit avec un topic aléatoire : il fonctionne donc sans compte. Ce serveur sert aux tests et aux prototypes, pas aux données de production.
Niveau 3 : les régions candidates que vous contrôlez
Pour comparer des emplacements avant de vous engager, démarrez une petite machine virtuelle dans chaque région cloud candidate, installez Mosquitto avec TLS et exécutez le même script contre chacune depuis chaque site. Vous obtenez ainsi une matrice de chiffres réels plutôt que des hypothèses.
Transformer les mesures en décision
Rassemblez les résultats dans un tableau comme celui-ci, en utilisant des médianes et un percentile élevé plutôt que des pings isolés :
| Site | Région A médiane / p90 | Région B médiane / p90 | Région C médiane / p90 | Nombre d'appareils |
|---|---|---|---|---|
| Usine 1 | ... | ... | ... | ... |
| Usine 2 | ... | ... | ... | ... |
| Entrepôt | ... | ... | ... | ... |
| Services backend | ... | ... | ... | n/a |
Appliquez ensuite ces règles :
- Pondérez par importance, pas seulement par nombre d'appareils. Une boucle de régulation sur un site peut compter davantage que des centaines de tableaux de bord ailleurs.
- Incluez votre backend. Si vos bases de données et services tournent dans une région cloud donnée, un broker éloigné ajoute de la latence à chaque message consommé.
- Regardez le p90 et le maximum, pas seulement la médiane. La gigue compte pour tout ce qui est interactif.
- Vérifiez les exigences de résidence. Les règles de protection des données peuvent imposer la région avant même la latence ; voir la résidence des données MQTT.
- Envisagez le partitionnement. Si vos sites sont répartis sur plusieurs continents et ont besoin d'une faible latence, des brokers distincts par région peuvent être préférables à un broker central unique.
- Gardez à l'esprit que la latence est rarement le seul critère. Le coût, la résidence des données et la simplicité d'exploitation l'emportent souvent sur quelques millisecondes pour une télémétrie lue par des humains.
Choisir l'emplacement d'un déploiement ConnectMQ
ConnectMQ propose plusieurs modèles de déploiement, et l'emplacement fonctionne différemment dans chacun :
- Serverless (Free et Paid) : votre broker tourne sur le cluster partagé de ConnectMQ. Exécutez le script de mesure depuis vos sites contre ce broker pour vérifier si le temps d'aller-retour répond à vos besoins.
- Dedicated : un cluster isolé pour votre charge de travail. Discutez des options d'emplacement avec l'équipe, tableau de mesures à l'appui.
- BYOC : le broker tourne dans votre propre compte cloud, et peut donc se trouver dans la région où vivent déjà vos autres systèmes. Confirmez avec l'équipe les fournisseurs et régions pris en charge lors de la planification ; notre guide sur le broker MQTT BYOC présente ce modèle.
- Self Managed Enterprise : vous le placez là où vous exploitez votre propre infrastructure.
Pour la plupart des charges de télémétrie et de supervision, un broker bien placé dans la même zone géographique que les appareils suffit. Pour les boucles de régulation serrées, gardez-les en local, en périphérie, et utilisez le broker cloud pour la supervision, le reporting et l'intégration. Notre article sur la latence des jumeaux numériques temps réel approfondit ce partage des rôles.
Les pièges courants en matière de latence
- Mesurer une seule fois depuis le bureau. Mesurez depuis les réseaux réels des appareils, en particulier les sites en cellulaire.
- Accuser le broker pour le Wi-Fi. Lancez d'abord les tests réseau ; les réseaux d'accès ajoutent souvent plus de délai que la distance.
- Se reconnecter pour chaque message. Les appareils en sommeil profond paient plusieurs allers-retours à chaque réveil ; gardez les sessions ouvertes lorsque l'alimentation le permet.
- Placer les abonnés loin du broker. Un backend situé dans une autre région double la distance parcourue par chaque message.
- Ignorer le DNS. Des résolveurs lents ajoutent du délai à chaque nouvelle connexion ; mettez les résultats en cache sur les passerelles.
Mesurez votre latence sur ConnectMQ
ConnectMQ est un broker MQTT managé avec des options de déploiement Serverless, Dedicated et BYOC, pour adapter l'emplacement à vos sites et à vos systèmes. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, exécutez le script depuis vos sites et servez-vous des résultats pour choisir votre configuration de production. Le guide sur le broker MQTT cloud couvre le reste de la décision d'hébergement, et comment faire évoluer un broker MQTT traite de la capacité.
Questions fréquentes
Dans quelle mesure le choix de la région influe-t-il sur la latence MQTT ?
La distance impose un temps d'aller-retour minimal d'environ 1 milliseconde par tranche de 100 kilomètres de fibre, et les chemins réels en ajoutent. Pour des appareils situés sur un autre continent, le choix de la région domine généralement la part réseau de la latence.
Quelle est la meilleure façon de mesurer la latence d'un broker MQTT ?
Lancez depuis le site des appareils un test au niveau MQTT qui chronomètre la connexion, le TLS et un aller-retour publication-réception, et collectez médianes et percentiles élevés sur de nombreux échantillons.
Le TLS ralentit-il MQTT ?
Le TLS ajoute des allers-retours à la connexion, mais très peu de coût par message ensuite. Gardez les connexions ouvertes lorsque c'est possible pour ne payer la poignée de main qu'une seule fois.
Puis-je choisir où tourne mon broker ConnectMQ ?
Avec BYOC, le broker tourne dans votre propre compte cloud : vous choisissez donc la région parmi les options prises en charge par l'équipe. Pour les déploiements Dedicated, discutez de l'emplacement avec l'équipe.
