Knowledge Base Wiki

MQTT^[1] (initialement Message Queuing Telemetry Transport^[2],[3]) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP.

Il a été initialement développé par Andy Stanford-Clark (IBM) et Arlen Nipper (EuroTech). Il est conçu pour les connexions avec des sites distants où la bande passante du réseau est limitée.

MQTT 3.1.1 est un standard OASIS, la version 5 de la spécification est maintenant publiée depuis le 7 mars 2019^[4].

Depuis 2013, le terme MQTT n'est plus un acronyme^[3] car contrairement au nom "Message Queuing Telemetry Transport" aucun mécanisme de file n'est mis en place dans le protocole.

Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom, Eurotech et Cirrus Link) sont les auteurs de la première version du protocole en 1999 qui a servi à surveiller un oléoduc dans le désert. L'objectif était d'avoir un protocole efficace en bande passante, léger et utilisant peu d'énergie de batterie, car la liaison satellite qu'ils utilisaient était très coûteuse à cette époque.

Les agents MQTT sont des logiciels ou des composants qui fonctionnent en tant que clients MQTT ou brokers MQTT dans une architecture MQTT. Voici une explication des deux types d'agents MQTT :

1. Client MQTT : Un client MQTT est un agent qui se connecte à un broker MQTT pour publier des messages, s'abonner à des sujets et recevoir des messages publiés par d'autres clients. Les clients MQTT peuvent être des dispositifs IoT, des applications web, des applications mobiles ou tout autre logiciel capable de communiquer via le protocole MQTT. Ils sont souvent déployés dans des environnements où la communication à faible bande passante et la fiabilité sont essentielles, tels que les réseaux IoT.
2. Broker MQTT : Un broker MQTT est un agent qui reçoit les messages publiés par les clients MQTT et les transmet aux clients abonnés aux sujets correspondants. Il agit comme un serveur centralisé qui facilite la communication entre les clients MQTT. Les brokers MQTT peuvent être déployés dans le cloud, sur des serveurs locaux ou sur des dispositifs IoT eux-mêmes. Ils sont responsables de la gestion des connexions des clients, de la distribution des messages et de la mise en œuvre des politiques de sécurité.

Il est important de noter que dans une architecture MQTT typique, il peut y avoir plusieurs clients MQTT et un ou plusieurs brokers MQTT. Les clients peuvent publier des messages sur différents sujets, et les brokers sont responsables de la distribution de ces messages aux clients abonnés aux sujets correspondants. Cette architecture distribuée et légère fait de MQTT un choix populaire pour les applications IoT et les systèmes de messagerie en temps réel.

Les principaux agents open-source sont :

• ActiveMQ (en)
• ejabberd
• JoramMQ, OW2 JORAM
• Mosquitto

De très nombreuses bibliothèques sont disponibles pour programmer des clients MQTT, pour la plupart des langages (C, C++, Java, JavaScript, PHP, Python…) et sur la plupart des plates-formes (GNU/Linux, Windows, iOS, Android, Arduino…).

Les projets Eclipse Paho (en) ainsi que wolfSSL offrent des implémentations libres et open-source des protocoles de messagerie ouverts et standards destinés aux applications nouvelles et émergentes du M2M (machine-to-machine) et de l'Internet des objets.

De nombreux projets mettent en œuvre MQTT :

• Facebook Messenger : Facebook a utilisé des aspects de MQTT dans Facebook Messenger, cependant on ne connaît pas exactement ce qui est utilisé de MQTT dans Facebook Messenger ni pourquoi^[5].
• La dernière version du système de contrôle de signalisation de IECC Scalable DeltaRail utilise MQTT pour les communications entre les différentes parties du système et les composants du système de signalisation^[6].
• Home Assistant, logiciel serveur domotique open source, est compatible MQTT et fonctionne avec le serveur Mosquitto^[7].

Dans un livre rouge intitulé Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry et paru en 2012, IBM décrit plusieurs exemples d'applications dans le domaine de la santé et de l'énergie^[8].

Le protocole MQTT utilise par défaut le port TCP 1883 pour communiquer de manière non chiffrée.

Cependant, il est possible de chiffrer la communication à l'aide de SSL/TLS. Dans ce cas le port par défaut sera TCP 8883.

Il est important de noter que les brokers MQTT peuvent être configurés pour utiliser d'autres ports en fonction des besoins spécifiques de l'infrastructure et des politiques de sécurité. Par exemple, certains déploiements MQTT peuvent utiliser des ports non standard pour des raisons de sécurité ou de compatibilité avec d'autres systèmes. Dans de tels cas, il est essentiel de consulter la documentation spécifique du broker MQTT pour connaître les ports configurés sur le système.

Il est possible d'encapsuler le protocole MQTT dans HTTPS (HTTP sécurisé). Cela implique généralement d'utiliser une passerelle ou un proxy qui agit en tant que pont entre les clients MQTT et le serveur MQTT, en utilisant HTTPS comme protocole de transport sécurisé.

Voici un exemple d'application :

1. Client MQTT : Le client MQTT établit une connexion HTTPS avec une passerelle ou un proxy.
2. Passerelle ou proxy : La passerelle ou le proxy reçoit les messages MQTT via la connexion HTTPS sécurisée. Il décode ensuite ces messages et les retransmet vers le serveur MQTT en utilisant le protocole MQTT standard sur le port MQTT approprié (généralement le port TCP 1883 ou 8883 pour MQTT sécurisé).
3. Serveur MQTT : Le serveur MQTT reçoit les messages MQTT du proxy comme s'il s'agissait de connexions MQTT normales.

De même, les réponses du serveur MQTT peuvent être encapsulées dans des messages HTTPS et renvoyées au client MQTT via la même passerelle ou le même proxy.

Cette approche peut être utile dans les cas où une communication sécurisée est requise entre les clients MQTT et le serveur MQTT, par exemple lorsque les messages MQTT sont envoyés via Internet et qu'une couche de sécurité supplémentaire est nécessaire pour protéger les données sensibles contre les interceptions ou les manipulations. Cependant, il convient de noter que l'encapsulation de MQTT dans HTTPS peut ajouter un surcoût en termes de latence et de charge de traitement, en raison du processus de décodage et de retransmission des messages.

• (en) Site officiel
• Notices d'autorité :

  • GND

• Portail d’Internet
• Portail de la programmation informatique