MQTT

Architecture de MQTT

MQTT fonctionne au-dessus de TCP/IP en utilisant une topologie PUSH/SUBSCRIBE. Dans l'architecture MQTT, il existe deux types de systèmes : les clients et les courtiers. Le courtier est le serveur avec lequel les clients communiquent. Il reçoit les communications des clients et les transmet à d'autres clients. Les clients ne communiquent pas directement entre eux, mais se connectent au courtier. Chaque client peut être soit un éditeur, soit un abonné, soit les deux.

MQTT est un protocole événementiel. Il n'y a pas de transmission de données périodique ou continue. Cela permet de réduire la transmission au minimum. Un client ne publie que lorsqu'il y a des informations à envoyer, et un courtier n'envoie des informations aux abonnés que lorsque de nouvelles données arrivent.

Architecture des messages

Une autre façon pour MQTT de minimiser ses transmissions est d'utiliser une construction de messages restreinte et étroitement définie. Chaque message a un en-tête fixe de seulement 2 octets. Un en-tête optionnel peut être utilisé, mais il augmente la taille du message. La charge utile du message est limitée à 256 Mo. Trois niveaux différents de qualité de service (QoS) permettent aux concepteurs de réseaux de choisir entre la minimisation de la transmission des données et la maximisation de la fiabilité.

• QoS 0 - Offre la quantité minimale de transmission de données. Avec ce niveau, chaque message est délivré à un abonné une seule fois, sans confirmation. Il n'y a aucun moyen de savoir si les abonnés ont reçu le message. Cette méthode est parfois appelée "fire and forget" ou "at most once delivery" Comme ce niveau suppose que la livraison est complète, les messages ne sont pas stockés pour être livrés à des clients déconnectés qui se reconnectent par la suite.
• QoS 1 - Le courtier tente de délivrer le message et attend une réponse de confirmation de l'abonné. Si aucune confirmation n'est reçue dans un délai donné, le message est envoyé à nouveau. Avec cette méthode, l'abonné peut recevoir le message plus d'une fois si le courtier ne reçoit pas l'accusé de réception de l'abonné à temps. Cette méthode est parfois appelée "livraison au moins une fois".
• QoS 2 - Le client et le courtier utilisent une poignée de main en quatre étapes pour s'assurer que le message est reçu, et qu'il n'est reçu qu'une seule fois. C'est ce que l'on appelle parfois la "livraison une seule fois".
  
  

Dans les cas où les communications sont fiables mais limitées, la qualité de service 0 peut être la meilleure option. Dans les situations où les communications ne sont pas fiables, mais où les connexions ne sont pas aussi limitées en ressources, la qualité de service 2 serait la meilleure option. La qualité de service 1 offre une sorte de solution optimale, mais exige que l'application qui reçoit les données sache comment gérer les doublons.

Pour QoS 1 et QoS 2, les messages sont sauvegardés ou mis en file d'attente pour les clients qui ne sont pas en ligne et qui ont une session persistante établie. Ces messages sont renvoyés (selon le niveau de qualité de service approprié) une fois que le client est de nouveau en ligne.

Sujets

Les messages dans MQTT sont publiés en tant que sujets. Les sujets sont structurés dans une hiérarchie utilisant la barre oblique (/) comme délimiteur. Cette structure ressemble à l'arborescence d'un système de fichiers d'un ordinateur. Une structure telle que sensors/OilandGas/Pressure/ permet à un abonné de spécifier qu'il ne doit recevoir que les données des clients qui publient dans le sujet Pression, ou pour une vue plus large, peut-être toutes les données des clients qui publient dans n'importe quel sujet sensors/OilandGas. Les sujets ne sont pas explicitement créés dans MQTT. Si un courtier reçoit des données publiées sur un sujet qui n'existe pas encore, le sujet est simplement créé et les clients peuvent s'abonner au nouveau sujet.

Messages conservés

Pour que l'empreinte reste faible, les messages reçus ne sont pas stockés dans le courtier, sauf s'ils sont marqués d'un drapeau de conservation. C'est ce qu'on appelle un message conservé. Les utilisateurs qui souhaitent stocker les messages reçus devront les stocker ailleurs, en dehors du protocole MQTT. Il y a une exception.

En tant que protocole événementiel, il est possible, voire probable, qu'un abonné reçoive très peu de messages pour un sujet donné, même sur une longue période. Dans la structure thématique mentionnée précédemment, il se peut que les messages relatifs à la rubrique Pression ne soient envoyés que lorsqu'un capteur détecte que la pression a dépassé un certain niveau. En supposant que le capteur supervisé ne tombe pas souvent en panne, il peut s'écouler des mois, voire des années, avant qu'un client ne publie un message à ce sujet.

Pour s'assurer qu'un nouvel abonné reçoit les messages d'un thème, les courtiers peuvent conserver le dernier message envoyé à chaque thème. C'est ce qu'on appelle un message conservé. Chaque fois qu'un nouveau client s'abonne à un thème ou qu'un client existant revient en ligne, le message conservé est envoyé aux abonnés, garantissant ainsi que l'abonnement est actif et qu'il contient les informations les plus récentes.

Dernières volontés et testament

Lorsque les communications ne sont pas fiables, il est possible qu'un éditeur se déconnecte du réseau sans avertissement. Un éditeur peut enregistrer un message à envoyer aux abonnés au cas où il se déconnecte de manière inattendue, c'est ce qu'on appelle un testament. Ce message est caché dans le courtier et envoyé aux abonnés si l'éditeur se déconnecte de manière inappropriée. En règle générale, ce message contient des informations permettant d'identifier l'éditeur déconnecté afin que les mesures appropriées puissent être prises.

Messages MQTT

Pour que le protocole reste petit, il n'y a que quatre actions possibles pour toute communication : publier, s'abonner, se désabonner ou faire un ping.

• Publier - Envoie un bloc de données contenant le message à envoyer. Ces données sont spécifiques à chaque implémentation mais pourraient être quelque chose d'aussi simple qu'une indication marche/arrêt, ou une valeur d'un certain capteur, comme la température, la pression, etc. Si le sujet sur lequel le message est publié n'existe pas, il est créé par le courtier.
• Subscribe - Transforme un client en abonné d'une rubrique. Les sujets peuvent faire l'objet d'un abonnement spécifique ou de caractères génériques qui permettent de s'abonner à toute une branche de sujet ou à une partie de n'importe quelle branche de sujet. Pour s'abonner, un client envoie un paquet SUBSCRIBE et reçoit en retour un paquet SUBACK. S'il existe un message retenu pour le sujet, le nouvel abonné reçoit également ce message.
• PING - Un client peut envoyer un ping au courtier. Un paquet PINGREQ est envoyé par l'abonné et un paquet PINGRESP est envoyé en réponse. Les pings peuvent être utilisés pour s'assurer que la connexion fonctionne toujours et que la session TCP n'a pas été fermée inopinément par un autre équipement de réseau tel qu'un routeur ou une passerelle.
• DISCONNECT - Un abonné ou un éditeur peut envoyer un message DISCONNECT au courtier. Ce message informe le courtier qu'il n'aura plus besoin d'envoyer ou de mettre en file d'attente des messages pour un abonné et qu'il ne recevra plus de données d'un éditeur. Ce type d'arrêt permet au client de se reconnecter en utilisant la même identité qu'auparavant. Lorsqu'un client se déconnecte sans envoyer de message de déconnexion, ses dernières volontés sont envoyées aux abonnés

Sécurité

L'objectif initial du protocole MQTT était de réaliser la transmission de données la plus petite et la plus efficace possible sur des lignes de communication coûteuses et peu fiables. À ce titre, la sécurité n'était pas une préoccupation majeure lors de la conception et de la mise en œuvre de MQTT.

Cependant, certaines options de sécurité sont disponibles au prix d'une transmission de données plus importante et d'un encombrement plus grand.

• Sécurité du réseau - Si le réseau lui-même peut être sécurisé, la transmission de données MQTT non sécurisées n'a pas lieu d'être. Dans ce cas, les problèmes de sécurité devraient provenir de l'intérieur du réseau lui-même, peut-être par l'intermédiaire d'un acteur malveillant ou d'une autre forme de pénétration du réseau.
• Nom d'utilisateur et mot de passe - MQTT autorise les noms d'utilisateur et les mots de passe pour permettre à un client d'établir une connexion avec un broker. Malheureusement, pour ne pas alourdir la note, les noms d'utilisateur et les mots de passe sont transmis en texte clair. En 1999, cela était plus que suffisant, car il aurait été extrêmement difficile d'intercepter une communication satellite pour ce qui était essentiellement une lecture de capteur sans importance. Cependant, aujourd'hui, l'interception de nombreux types de communications de réseaux sans fil est triviale, ce qui rend ce type d'authentification pratiquement inutile.
  De nombreux cas d'utilisation requièrent un nom d'utilisateur et un mot de passe non pas comme protection contre les acteurs de mauvaise foi, mais comme moyen d'éviter les connexions involontaires.
• SSL/TLS - La solution la plus évidente pour sécuriser les transmissions entre les clients et les courtiers est la mise en œuvre de SSL/TLS, qui s'exécute au-dessus de TCP/IP. Malheureusement, cela ajoute un surcoût substantiel à des communications par ailleurs légères.