MQTT vs NATS : choisir un système de messagerie pour l'IoT

La comparaison MQTT vs NATS revient souvent lorsqu'une équipe apprécie la simplicité de NATS pour ses microservices et se demande s'il pourrait aussi servir ses appareils. Ce sont deux systèmes publish/subscribe légers, avec abonnements à jokers et faible latence, mais ils ont été façonnés par des clients très différents. Ce guide compare le support des appareils, les garanties de livraison, la persistance et l'écosystème, et explique où un broker MQTT managé trouve sa place à côté de NATS.

Deux systèmes pub/sub légers

MQTT est un protocole standard ouvert de l'OASIS. Tout client conforme peut dialoguer avec tout broker conforme, et il existe de nombreuses implémentations des deux côtés. Il a été conçu pour la télémétrie d'appareils contraints sur des réseaux peu fiables, d'où des fonctionnalités comme le Last Will, les retained messages et les sessions persistantes.

NATS est un système et un protocole de messagerie open source issu de l'écosystème CNCF, avec une implémentation serveur principale. Il a été conçu pour la communication cloud native entre services : requête/réponse rapide, diffusion et répartition de charge du travail à l'intérieur des data centers et entre eux. Core NATS est volontairement « fire-and-forget » ; JetStream, intégré au serveur NATS, ajoute la persistance, le rejeu et des garanties de livraison plus fortes.

Chacun excelle dans ce pour quoi il a été conçu. La vraie question est : quels clients connectez-vous ?

MQTT vs NATS en un coup d'œil

Le support des appareils fait la différence

Pour l'IoT, la différence la plus concrète tient à la disponibilité des clients. Il existe des clients MQTT pour pratiquement toutes les plateformes qu'un ingénieur embarqué rencontre : bibliothèques ESP32 et Arduino comme PubSubClient, bibliothèques C embarquées pour cibles RTOS, modules cellulaires intégrant MQTT dans le firmware du modem, PLC et passerelles industrielles avec MQTT natif, logiciels SCADA et historians qui parlent Sparkplug B. Les capteurs et passerelles du commerce proposent souvent MQTT comme simple option de configuration.

Les clients NATS sont excellents en Go, Rust, Java, .NET, JavaScript, Python et C sur du matériel de classe Linux. Un Raspberry Pi ou un PC industriel les fait tourner sans difficulté. Sur les microcontrôleurs et dans les firmwares constructeurs, le support de NATS est rare. Si un appareil commercial doit envoyer des données sans que vous écriviez de firmware, il parlera presque certainement MQTT, pas NATS.

Garanties de livraison et persistance

MQTT intègre les garanties de livraison dans chaque message. Un appareil peut publier une alarme en QoS 1 et une mesure de vibration à haute fréquence en QoS 0 sur la même connexion. Les sessions persistantes conservent les messages QoS 1 et 2 pour un abonné qui se déconnecte, et les retained messages conservent la dernière valeur par topic, de sorte qu'un tableau de bord ouvert plus tard voit immédiatement l'état actuel. Pour les détails, consultez les niveaux de QoS MQTT expliqués et les retained messages MQTT.

Core NATS livre aux clients connectés à cet instant, et rien de plus. C'est rapide et simple, et c'est le bon modèle pour de nombreux appels de services. Lorsque vous avez besoin de durabilité, JetStream stocke les messages dans des streams dotés de politiques de rétention, permet aux consommateurs d'accuser réception et de rejouer, et peut dédupliquer par identifiant de message. JetStream est plus puissant que les sessions MQTT pour l'historique et le rejeu, mais il introduit un ensemble distinct de concepts (streams, consumers, politiques d'acquittement) que quelqu'un doit concevoir et exploiter.

Présence et état des appareils

Les systèmes IoT doivent constamment répondre à la question « cet appareil est-il en ligne, et quelle était sa dernière mesure ? ». MQTT répond nativement aux deux. Un appareil définit un Last Will tel que offline sur site1/pump7/status avec le flag retain, publie online après connexion, et le broker publie le will si la connexion tombe de façon non propre. Consultez le guide MQTT Last Will and Testament pour le modèle complet.

Avec NATS, on construit généralement la présence avec des heartbeats envoyés par chaque appareil, ou en surveillant les événements de connexion du compte système du serveur, et on stocke les dernières valeurs dans un bucket clé-valeur JetStream. Cela fonctionne, mais vous assemblez la solution au lieu de simplement la configurer.

Subjects vs topics

Les modèles de nommage sont suffisamment proches pour se traduire. Un topic MQTT factory1/line2/cnc1/temperature correspond naturellement à un subject NATS factory1.line2.cnc1.temperature. Le + de MQTT correspond à un niveau, comme le * de NATS, et le # de MQTT correspond au reste, comme le > de NATS. Le serveur NATS propose même une interface MQTT qui mappe ainsi les topics vers les subjects et accepte des clients MQTT 3.1.1, ce qui est utile lorsque NATS constitue déjà l'épine dorsale. Elle ne prend pas en charge les fonctionnalités de MQTT 5 : vérifiez donc la documentation NATS au regard des fonctionnalités dont dépendent vos appareils.

Une architecture hybride pragmatique

De nombreuses équipes utilisent les deux, chacun à la couche qui lui convient :

1. Les appareils, passerelles PLC et IHM se connectent à un broker MQTT via TLS.
2. Un service de pont s'abonne aux topics des appareils et republie sur des subjects NATS pour les microservices backend.
3. Les services utilisent en interne la requête/réponse et les queue groups de NATS, et JetStream lorsqu'ils ont besoin de streams durables.
4. Les commandes repassent par le pont et sont publiées sur le topic de commande MQTT de l'appareil.

Un pont unidirectionnel minimal en Go ressemble à ceci, avec le client Go Eclipse Paho et le client NATS officiel.

package main

import (
	"crypto/tls"
	"log"
	"strings"

	mqtt "github.com/eclipse/paho.mqtt.golang"
	"github.com/nats-io/nats.go"
)

func main() {
	nc, err := nats.Connect(nats.DefaultURL)
	if err != nil {
		log.Fatal(err)
	}
	defer nc.Drain()

	opts := mqtt.NewClientOptions().
		AddBroker("tls://broker.connectmq.com:8883").
		SetClientID("YOUR_CLIENT_ID").
		SetUsername("YOUR_USERNAME").
		SetPassword("YOUR_PASSWORD").
		SetTLSConfig(&tls.Config{MinVersion: tls.VersionTLS12}).
		SetAutoReconnect(true)

	opts.SetOnConnectHandler(func(c mqtt.Client) {
		// S'abonner dans le handler de connexion pour restaurer l'abonnement après les reconnexions
		c.Subscribe("factory1/+/+/telemetry", 1, func(_ mqtt.Client, m mqtt.Message) {
			subject := strings.ReplaceAll(m.Topic(), "/", ".")
			if err := nc.Publish(subject, m.Payload()); err != nil {
				log.Printf("nats publish failed: %v", err)
			}
		})
	})

	client := mqtt.NewClient(opts)
	if token := client.Connect(); token.Wait() && token.Error() != nil {
		log.Fatal(token.Error())
	}
	log.Println("bridging MQTT to NATS")
	select {}
}

Le client Go paho utilise MQTT 3.1.1, que ConnectMQ accepte aux côtés de MQTT 5. Pour l'essayer sans identifiants, utilisez tcp://broker.connectmq.com:1883, un client ID unique et un préfixe de topic comme connectmq/demo/<random-id>/ sur le serveur MQTT public gratuit, réservé aux tests. Méfiez-vous des caractères autorisés dans les topics MQTT mais spéciaux dans les subjects NATS, comme . ou les espaces, et assainissez-les dans le pont.

Quand choisir l'un ou l'autre

Choisissez MQTT lorsque vos clients sont des appareils, des passerelles, des PLC ou du matériel tiers, lorsque la connectivité est peu fiable, ou lorsque vous avez besoin de présence, d'état retained et de conventions industrielles comme Sparkplug B et un Unified Namespace.

Choisissez NATS lorsque vos clients sont des services que vous développez, tournant sur des réseaux fiables, et que vous voulez une requête/réponse rapide, des queue groups et une persistance JetStream optionnelle avec un minimum d'infrastructure.

Choisissez les deux lorsque vous avez une flotte d'appareils et un backend de microservices déjà standardisé sur NATS.

Pour la couche appareils, un broker MQTT managé vous évite d'exploiter et de sécuriser un service exposé sur Internet. ConnectMQ propose MQTT 3.1.1 et 5.0, TLS, les abonnements partagés sur le plan Serverless payant, des quotas par plan et l'isolation multi-tenant, sans pont NATS intégré : le pont reste donc votre propre petit service, comme montré ci-dessus. Si vous comparez aussi d'autres backends, consultez MQTT vs Kafka, et pour les bases, le tutoriel MQTT.

Démarrer avec ConnectMQ

Offrez à vos appareils un point d'accès MQTT standard et largement supporté, et gardez NATS pour vos services. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, connectez un appareil et votre pont, et observez les deux côtés dans l'explorateur de topics en direct.

Questions fréquentes

NATS est-il plus rapide que MQTT ?

Les deux offrent une faible latence, et la vitesse réelle dépend davantage du serveur, du réseau et des paramètres de livraison que du protocole. Choisissez en fonction des clients et des fonctionnalités plutôt que de la vitesse brute.

Les appareils IoT peuvent-ils se connecter directement à NATS ?

Les appareils de classe Linux peuvent utiliser des clients NATS. Les microcontrôleurs et les capteurs du commerce prennent rarement en charge NATS, ce qui explique la domination de MQTT au niveau des appareils.

NATS prend-il en charge les clients MQTT ?

Le serveur NATS fournit une interface MQTT 3.1.1 adossée à JetStream. Elle ne couvre pas les fonctionnalités de MQTT 5 : un broker MQTT dédié convient donc généralement mieux aux grandes flottes hétérogènes.

Quel est l'équivalent NATS d'un retained message MQTT ?

Les équivalents les plus proches sont un stream JetStream configuré pour conserver le dernier message par subject, ou un bucket clé-valeur JetStream. Les deux doivent être configurés explicitement.