MQTT vs CoAP : pub/sub sur TCP contre requête/réponse sur UDP

MQTT vs CoAP, c'est un choix entre deux protocoles conçus pour le même type de matériel, de petits appareils sur batterie reliés à des réseaux avec pertes, qui fonctionnent pourtant de manière opposée. MQTT, c'est du publish/subscribe sur TCP via un broker ; CoAP, c'est du requête/réponse RESTful sur UDP, directement entre points de terminaison. Ce guide compare transports, en-têtes, sécurité, multicast et flux de données pour vous aider à déterminer lequel convient à vos appareils et à votre backend.

La version courte

Si vos appareils peuvent maintenir une connexion TCP et que vos données doivent atteindre plusieurs consommateurs dans le cloud, MQTT avec un broker est généralement la voie la plus simple. Si vos appareils se trouvent sur un réseau IPv6 contraint comme 6LoWPAN ou Thread, dorment la plupart du temps et sont adressés comme de minuscules serveurs web, CoAP est un choix naturel. De nombreux grands déploiements utilisent CoAP sur le réseau local contraint et MQTT entre une passerelle et le cloud.

Comment fonctionne CoAP

CoAP (Constrained Application Protocol, RFC 7252) apporte le modèle REST aux microcontrôleurs. Chaque appareil expose des ressources comme /sensors/temp, et les clients utilisent GET, POST, PUT et DELETE sur celles-ci, exactement comme en HTTP, mais dans un format binaire compact sur UDP. Les réponses portent des codes calqués sur les codes de statut HTTP, par exemple 2.05 Content ou 4.04 Not Found.

Comme UDP n'offre aucune garantie de livraison, CoAP ajoute sa propre fiabilité légère : un message peut être Confirmable (CON), que le destinataire doit acquitter, ou Non-confirmable (NON), envoyé sans attendre de retour. Les retransmissions utilisent un backoff exponentiel.

CoAP dispose aussi d'une option Observe (RFC 7641). Un client signale son intérêt pour une ressource et le serveur envoie une notification à chaque changement. C'est ce qui se rapproche le plus du subscribe de MQTT dans CoAP, mais en point à point entre un client et un seul serveur.

Comment fonctionne MQTT

Les clients MQTT ouvrent une connexion TCP (éventuellement TLS) vers un broker, puis publient des messages sur des topics et s'abonnent à des topic filters. Les appareils ne communiquent jamais directement entre eux ; le broker gère la diffusion, les dernières valeurs connues retenues, les sessions persistantes pour les abonnés hors ligne et les messages Last Will en cas de déconnexion brutale. Si la notion de broker est nouvelle pour vous, commencez par ce qu'est un broker MQTT, et pour une introduction pas à pas, consultez le tutoriel MQTT.

MQTT vs CoAP en un coup d'œil

Transport : TCP vs UDP

Le transport est à l'origine de la plupart des différences. TCP fournit à MQTT des flux d'octets ordonnés et fiables, mais il exige une poignée de main en trois temps pour se connecter et conserve un état aux deux extrémités. Sur une liaison radio avec pertes, les retransmissions TCP et le blocage en tête de file peuvent ajouter de la latence. Pour en savoir plus sur la question du transport, consultez MQTT utilise-t-il TCP ou UDP.

UDP permet à CoAP d'envoyer une mesure dans un seul datagramme sans établir de connexion, ce qui convient aux appareils qui se réveillent brièvement, transmettent puis se rendorment. La contrepartie : l'application, ici CoAP, doit gérer elle-même la fiabilité, la déduplication et le contrôle de congestion, et les appareils derrière un NAT deviennent difficiles à joindre, car les correspondances UDP expirent rapidement.

Taille des en-têtes et surcoût

Les deux protocoles sont compacts. Un PUBLISH MQTT peut être très petit, mais la chaîne du topic accompagne chaque message, sauf si vous utilisez les topic aliases de MQTT 5. CoAP utilise un en-tête de 4 octets, un token court et des options encodées en deltas, si bien que le chemin URI reste lui aussi compact. En pratique, le surcoût par message se situe dans la même petite fourchette pour les deux ; la différence la plus importante concerne le surcoût de connexion (TCP et TLS pour MQTT, contre rien ou DTLS pour CoAP).

Sécurité : TLS vs DTLS

MQTT utilise TLS sur TCP, la même pile éprouvée qui protège HTTPS, avec une prise en charge mature dans les SDK d'appareils, les passerelles et les brokers cloud. Un broker MQTT managé gère généralement les certificats pour vous ; ConnectMQ, par exemple, sert un certificat Let's Encrypt sur le port 8883 pour TLS et sur le port 8084 pour WebSocket sécurisé.

CoAP utilise DTLS, la version datagramme de TLS. Cela fonctionne, mais l'état de session, la retransmission du handshake sur des liaisons avec pertes et le rebinding NAT ajoutent de la complexité, et l'outillage est moins répandu. OSCORE (RFC 8613) offre une sécurité de bout en bout au niveau objet qui survit aux proxys, ce qui est intéressant dans les réseaux contraints multi-sauts, mais ajoute sa propre gestion des clés.

Pour l'un comme pour l'autre protocole, la règle pratique est la même : chiffrez chaque tronçon qui quitte l'appareil, et ne vous fiez jamais à la seule isolation réseau. Le guide des bonnes pratiques de sécurité MQTT couvre les identifiants, TLS et la conception des topics pour les déploiements MQTT.

Observe vs subscribe

CoAP Observe et le subscribe de MQTT livrent tous deux des mises à jour sans polling, mais leur topologie diffère. Avec Observe, chaque client intéressé s'enregistre auprès de l'appareil lui-même. Dix tableaux de bord signifient dix observateurs sur un microcontrôleur qui ne dispose parfois que de quelques kilo-octets de RAM. Avec MQTT, l'appareil publie une seule fois vers le broker, et c'est le broker qui gère n'importe quel nombre d'abonnés. C'est pourquoi MQTT passe mieux à l'échelle lorsque les données ont de nombreux consommateurs, tandis que CoAP fonctionne bien lorsqu'un contrôleur dialogue avec de nombreux petits appareils.

Multicast et découverte locale

C'est l'avantage net de CoAP. Un client peut envoyer une seule requête à un groupe multicast IP, par exemple pour éteindre toutes les lumières d'un étage, et chaque membre répond. Combiné à la découverte de ressources via /.well-known/core, CoAP convient aux réseaux locaux de gestion de bâtiment et de domotique dans lesquels les appareils se trouvent mutuellement sans serveur central. MQTT n'a pas de multicast ; chaque message passe par le broker.

Un schéma hybride courant

Les réseaux maillés contraints et le cloud ont des besoins différents ; de nombreux systèmes placent donc une passerelle entre les deux :

1. Les capteurs d'un maillage Thread ou 6LoWPAN exposent des ressources CoAP.
2. Une passerelle de bordure observe ces ressources ou reçoit des POST CoAP.
3. La passerelle publie chaque mise à jour en MQTT sur TLS vers un broker MQTT cloud, par exemple sur site1/floor2/room14/temperature.
4. Les tableaux de bord, historiens et services d'alerte s'abonnent au broker.

Voici le côté cloud de cette passerelle en Python. La gestion de CoAP dépend de votre bibliothèque ; elle est donc représentée par une fonction qui reçoit une mesure ; la partie MQTT, elle, est complète.

import json
import ssl
import time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set("site1/gateway1/status", "offline", qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish("site1/gateway1/status", "online", qos=1, retain=True)

client.on_connect = on_connect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_start()

def forward_coap_reading(resource_path, value):
    """À appeler depuis votre callback CoAP Observe."""
    topic = "site1/" + resource_path.strip("/").replace("sensors/", "")
    payload = json.dumps({"value": value, "ts": int(time.time())})
    client.publish(topic, payload, qos=1, retain=True)

# Exemple : une mesure observée depuis coap://[fd00::12]/sensors/floor2/room14/temperature
forward_coap_reading("/sensors/floor2/room14/temperature", 21.6)
time.sleep(2)

Pour expérimenter sans compte, remplacez la connexion par client.connect("broker.connectmq.com", 1883) avec n'importe quel client ID unique et un préfixe de topic comme connectmq/demo/<random-id>/, mais gardez à l'esprit que le serveur MQTT public gratuit est lisible par tous et réservé aux tests.

Lequel choisir, et quand

Choisissez MQTT lorsque :

• Les appareils sont en Wi-Fi, Ethernet ou cellulaire et peuvent maintenir une connexion TCP sortante.
• Les données doivent atteindre plusieurs consommateurs dans le cloud.
• Vous voulez un état retenu, un statut en ligne via le Last Will et une mise en mémoire tampon pour les abonnés hors ligne.
• Vous préférez des bibliothèques clientes matures et largement disponibles, ainsi qu'un hébergement managé.

Choisissez CoAP lorsque :

• Les appareils fonctionnent sur des maillages IPv6 contraints, avec très peu de RAM et d'énergie.
• Vous avez besoin de commandes multicast ou d'une découverte locale sans serveur central.
• L'interaction relève naturellement du requête/réponse, comme la lecture ou l'écriture d'un paramètre d'appareil.

Si votre projet penche plutôt du côté de MQTT mais que vos appareils sont extrêmement contraints ou dépourvus de TCP, intéressez-vous aussi à MQTT-SN, qui apporte la sémantique MQTT à UDP et à d'autres transports de datagrammes.

Démarrez avec ConnectMQ

Que vos appareils parlent MQTT nativement ou via une passerelle CoAP, le côté cloud a besoin d'un broker fiable. ConnectMQ est un broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS sur le port 8883 et un explorateur de topics en direct pour vérifier chaque passerelle dès sa mise en ligne. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez votre première passerelle en quelques minutes.

Questions fréquentes

CoAP est-il meilleur que MQTT pour les appareils sur batterie ?

Il peut l'être pour les appareils qui se réveillent rarement et envoient un seul datagramme, car UDP évite l'établissement d'une connexion. Pour les appareils qui remontent souvent des données ou doivent recevoir des commandes, la connexion persistante de MQTT est généralement tout aussi efficace et plus simple à exploiter.

CoAP a-t-il besoin d'un broker ?

Non. Les clients CoAP dialoguent directement avec les points de terminaison des appareils. Des proxys peuvent ajouter de la mise en cache et de la traduction de protocole, mais il n'existe pas de broker central comme dans MQTT.

CoAP et MQTT peuvent-ils fonctionner ensemble ?

Oui. Une passerelle observe couramment les ressources CoAP d'un maillage local et publie les valeurs vers un broker MQTT dans le cloud, ce qui vous offre l'efficacité locale et la diffusion dans le cloud.

MQTT prend-il en charge UDP ?

Le MQTT standard fonctionne sur TCP ou WebSocket. MQTT-SN est un protocole apparenté conçu pour UDP et d'autres réseaux de datagrammes, généralement relié à un broker MQTT classique par l'intermédiaire d'une passerelle.