MQTT

MQTT(Message Queuing Telemetry Transport) est un protocole de messagerie léger et largement adopté, conçu pour les appareils limités. AWS IoT Core le support de MQTT est basé sur les spécifications MQTT v3.1.1 et MQTTv5.0, avec quelques différences, comme indiqué dans. AWS IoT différences par rapport MQTT aux spécifications En tant que dernière version de la norme, la version MQTT 5 introduit plusieurs fonctionnalités clés qui renforcent la robustesse d'un système MQTT basé, notamment de nouvelles améliorations en termes d'évolutivité, un meilleur signalement des erreurs avec les réponses au code de motif, les délais d'expiration des messages et des sessions, et des en-têtes de message utilisateur personnalisés. Pour plus d'informations sur les MQTT 5 fonctionnalités prises AWS IoT Core en charge, voir MQTT5 fonctionnalités prises en charge. AWS IoT Core prend également en charge MQTT la communication entre versions (MQTT3 et MQTT 5). Un éditeur MQTT 3 peut envoyer un message MQTT 3 à un abonné MQTT 5 qui recevra un message MQTT 5 publications, et vice versa.

AWS IoT Core prend en charge les connexions de périphériques qui utilisent le MQTT WSS protocole et le MQTT surprotocole et qui sont identifiées par un identifiant client. Les AWS IoT Appareil SDKs prennent en charge les deux protocoles et sont les méthodes recommandées pour connecter les appareils AWS IoT Core. L' AWS IoT appareil SDKs prend en charge les fonctions nécessaires aux appareils et aux clients pour se connecter aux AWS IoT services et y accéder. L'appareil SDKs prend en charge les protocoles d'authentification requis par les AWS IoT services et les exigences d'identification de connexion requises par le MQTT protocole et MQTT WSS les protocoles supplémentaires. Pour plus d'informations sur la façon de se connecter AWS IoT à l' AWS appareil SDKs et pour obtenir des liens vers des exemples de AWS IoT langues prises en charge, consultezConnexion à l'MQTTutilisation de l' AWS IoT appareil SDKs. Pour plus d'informations sur les méthodes d'authentification et les mappages de ports pour les MQTT messages, consultezProtocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).

Bien que nous vous recommandions d'utiliser l' AWS IoT appareil SDKs pour vous y connecter AWS IoT, ils ne sont pas obligatoires. Si vous n'utilisez pas l' AWS IoT appareilSDKs, vous devez toutefois fournir la sécurité de connexion et de communication nécessaire. Les clients doivent envoyer l'TLSextension Server Name Indication (SNI) dans la demande de connexion. Les tentatives de connexion qui n'incluent pas le SNI sont refusées. Pour plus d'informations, voir Sécurité du transport dans AWS IoT. Les clients qui utilisent IAM des utilisateurs et des AWS informations d'identification pour authentifier les clients doivent fournir l'authentification Signature Version 4 correcte.

Connexion à l'MQTTutilisation de l' AWS IoT appareil SDKs

Cette section contient des liens vers le AWS IoT périphérique SDKs et vers le code source d'exemples de programmes illustrant comment connecter un appareil à celui-ci AWS IoT. Les exemples d'applications liés ici montrent comment se connecter à AWS IoT l'aide du MQTT protocole et MQTT plus encoreWSS.

MQTTOptions de qualité de service (QoS)

AWS IoT et l' AWS IoT appareil SDKs prend en charge les niveaux 0 de MQTT qualité de service (QoS) et. 1 Le MQTT protocole définit un troisième niveau de QoS, le niveau 12, mais AWS IoT ne le prend pas en charge. Seul le MQTT protocole prend en charge la fonctionnalité QoS. HTTPSprend en charge la QoS en transmettant un paramètre de chaîne de requête ?qos=qos dont la valeur peut être 0 ou 1.

Ce tableau décrit comment chaque niveau de QoS affecte les messages publiés par et vers l’agent de messages.

MQTTsessions persistantes

Les sessions permanentes stockent les abonnements et les messages d’un client, avec une qualité de service (QoS) de 1, qui n’ont pas été reconnus par le client. Lorsque l’appareil se reconnecte à une session permanente, la session reprend, les abonnements sont rétablis et les messages d’abonnement reçus et stockés sans accusé de réception avant la reconnexion sont envoyés au client.

Le traitement des messages enregistrés est enregistré dans CloudWatch et CloudWatch Logs. Pour plus d'informations sur les entrées écrites dans CloudWatch et les CloudWatch journaux, reportez-vous aux Métriques d'agent de messages sections etEntrée de journal en file d'attente.

Création d’une session permanente

Dans MQTT 3, vous créez une session MQTT persistante en envoyant un CONNECT message et en réglant le cleanSession drapeau sur0. Si aucune session n’existe pour le client qui envoie le message CONNECT, une nouvelle session permanente est créée. Si une session existe déjà pour le client, celui-ci la reprend. Pour créer une session propre, vous envoyez un message CONNECT et vous définissez l’indicateur cleanSession sur 1, et l’agent ne stockera aucun état de session lorsque le client se déconnecte.

Dans MQTT 5, vous gérez les sessions persistantes en réglant le Clean Start drapeau etSession Expiry Interval. Le démarrage propre contrôle le début de la session de connexion et la fin de la session précédente. Lorsque vous définissez Clean Start =1, une nouvelle session est créée et une session précédente est interrompue si elle existe. Lorsque vous définissez Clean Start =0, la session de connexion reprend une session précédente si elle existe. L’intervalle d’expiration de session contrôle la fin de la session de connexion. L’intervalle d’expiration de session indique le temps, en secondes (entier de 4 octets), pendant lequel une session persistera après la déconnexion. Le paramètre Session Expiry interval = 0 entraîne la fin de la session immédiatement après la déconnexion. Si l'intervalle d'expiration de session n'est pas spécifié dans le CONNECT message, la valeur par défaut est 0.

En MQTT 5, si vous définissez Clean Start = 1 et Session Expiry Interval =0, cela équivaut à une session nettoyée à MQTT 3 reprises. Si vous définissez Clean Start = 0 et Session Expiry Interval >0, cela équivaut à une session persistante de MQTT 3.

Opérations au cours d’une session permanente

Les clients utilisent l’attribut sessionPresent dans le message de connexion reconnue (CONNACK), afin de déterminer si une session permanente est présente. Si sessionPresent est 1, une session permanente est présente et tous les messages stockés pour le client sont remis au client une fois que celui-ci a reçu CONNACK, comme décrit dans Trafic de messages après reconnexion à une session permanente. Si sessionPresent est 1, le client n’a pas besoin de se réabonner. Toutefois, si sessionPresent est défini sur 0, aucune session permanente n’est présente et le client doit se réabonner à ses filtres de rubrique.

Une fois que le client rejoint la session permanente, il peut publier des messages et à s’abonner aux filtres de rubrique sans aucun indicateur supplémentaire sur chaque opération.

Trafic de messages après reconnexion à une session permanente

Une session persistante représente une connexion permanente entre un client et un courtier de MQTT messages. Lorsqu’un client se connecte à l’agent de messages à l’aide d’une session permanente, ce dernier enregistre tous les abonnements souscrits par le client pendant la connexion. Lorsque le client se déconnecte, le courtier de messages conserve les messages d'une QoS 1 et les nouveaux messages d'une QoS 1 publiés sur les rubriques auxquelles le client s'est abonné. Les messages sont stockés conformément à la limite du compte. Les messages dépassant cette limite seront supprimés. Pour plus d’informations sur les limites de messages permanents, veuilelz consulter AWS IoT Core quotas de point de terminaison. Lorsque le client se reconnecte à sa session permanente, tous les abonnements sont réactivés et tous les messages stockés sont envoyés au client à un rythme maximum de 10 messages par seconde. Dans MQTT 5, si un QoS1 sortant avec un intervalle d'expiration des messages expire alors qu'un client est hors ligne, le client ne recevra pas le message expiré une fois la connexion rétablie.

Après la reconnexion, les messages stockés sont envoyés au client, à un débit limité à 10 messages stockés par seconde, ainsi que tout le trafic de messages en cours jusqu’à ce que la limite Publish requests per second per connection soit atteinte. Le taux de livraison des messages stockés étant limité, la remise de tous les messages stockés prendra plusieurs secondes si une session comporte plus de 10 messages stockés à remettre après la reconnexion.

Fin d’une session permanente

Les sessions permanentes peuvent prendre fin de différentes manières :

Dans MQTT 3, la valeur par défaut du délai d'expiration des sessions persistantes est d'une heure, et cela s'applique à toutes les sessions du compte.

Dans MQTT 5, vous pouvez définir l'intervalle d'expiration de session pour chaque session ouverte CONNECT et pour chaque DISCONNECT paquet.

Pour l'intervalle d'expiration de session sur le DISCONNECT paquet :

Reconnexion après expiration d’une session permanente

Si un client ne se reconnecte pas à sa session permanente avant son expiration, celle-ci se termine et les messages enregistrés sont supprimés. Lorsqu’un client se reconnecte après l’expiration de la session et définit un indicateur cleanSession sur 0, le service crée une nouvelle session persistante. Les abonnements ou messages de la session précédente ne sont pas disponibles pour cette session car ils ont été supprimés à l’expiration de la session précédente.

Frais liés aux messages de session persistants

Les messages vous sont facturés Compte AWS lorsque le courtier de messages envoie un message à un client ou lors d'une session permanente hors ligne. Lorsqu’un appareil hors ligne doté d’une session permanente se reconnecte et reprend sa session, les messages enregistrés sont transmis à l’appareil et débités de nouveau sur votre compte. Pour plus d’informations sur la tarification des messages, consultez la section AWS IoT Core Tarification - Messagerie.

Le délai d’expiration des sessions permanentes par défaut d’une heure peut être augmenté en utilisant le processus d’augmentation de limite standard. Notez que l’augmentation du délai d’expiration de la session peut augmenter le coût de vos messages, car ce délai supplémentaire pourrait permettre de stocker davantage de messages sur l’appareil hors ligne et ces messages supplémentaires seraient débités de votre compte au tarif de messagerie standard. L’heure d’expiration de la session est approximative et une session peut persister jusqu’à 30 minutes de plus que la limite du compte ; toutefois, une session ne sera pas inférieure à la limite du compte. Pour de plus amples informations sur les limites de sessions, veuillez consulter AWS Service Quotas.

MQTTmessages conservés

AWS IoT Core supporte le RETAIN drapeau décrit dans le MQTT protocole. Lorsqu'un client place l'RETAINindicateur sur un MQTT message qu'il publie, il AWS IoT Core enregistre le message. Il peut ensuite être envoyé aux nouveaux abonnés, récupéré en appelant l’opération GetRetainedMessage et visualisé dans la AWS IoT console.

Tâches courantes avec des messages MQTT conservés dans AWS IoT Core

AWS IoT Core enregistre MQTT les messages avec le RETAIN drapeau défini. Ces messages conservés sont envoyés à tous les clients abonnés au sujet, sous forme de MQTT message normal, et ils sont également stockés pour être envoyés aux nouveaux abonnés au sujet.

MQTTles messages conservés nécessitent des mesures politiques spécifiques pour autoriser les clients à y accéder. Pour des exemples d’utilisation des politiques relatives aux messages retenus, consultez Exemples de stratégies de messages conservés.

Cette section décrit les opérations courantes impliquant les messages retenus.

Facturation et messages retenus

La publication de messages avec l'RETAINindicateur défini par un client, à l'aide de AWS IoT la console ou par appel Publishentraîne des frais de messagerie supplémentaires décrits dans la section AWS IoT Core Tarification - Messagerie.

La récupération des messages conservés par un client, en utilisant AWS IoT la console ou en appelant GetRetainedMessageentraîne des frais de messagerie en plus des frais API d'utilisation normaux. Les frais supplémentaires sont décrits dans la section AWS IoT Core Tarification - Messagerie.

MQTTLes messages publiés lorsqu'un appareil se déconnecte de façon inattendue entraîneront-ils des frais de messagerie décrits dans la section AWS IoT Core Tarification - Messagerie.

Pour plus d’informations sur les coûts de messagerie, consultez la section AWS IoT Core Tarification - Messagerie.

Comparaison des messages MQTT conservés et des sessions MQTT persistantes

Les messages conservés et les sessions persistantes sont des fonctionnalités standard MQTT qui permettent aux appareils de recevoir des messages publiés alors qu'ils étaient hors ligne. Les messages retenus peuvent être publiés à partir de sessions permanentes. Cette section décrit les principaux aspects de ces fonctionnalités et explique comment elles fonctionnent ensemble.

Pour plus d'informations sur les sessions permanentes, consultez MQTTsessions persistantes.

Avec les messages retenus, le client de publication détermine si un message doit être retenu et remis à un appareil après sa connexion, qu’il ait déjà eu une session ou non. Le choix de stocker un message est fait par le diffuseur de publication et le message stocké est remis à tous les clients actuels et futurs qui s’abonnent avec un abonnement QoS 0 ou QoS 1. Les messages retenus ne contiennent qu’un seul message à la fois sur une rubrique donnée.

Lorsqu'un compte a stocké le nombre maximum de messages conservés, AWS IoT Core renvoie une réponse limitée aux messages publiés avec un paramètre RETAIN défini et à une charge utile supérieure à 0 octet, jusqu'à ce que certains messages conservés soient supprimés et que le nombre de messages conservés tombe en dessous de la limite.

MQTTmessages conservés et AWS IoT Device Shadows

Les messages retenus et les Device Shadows retiennent les données d’un appareil, mais ils se comportent différemment et répondent à des objectifs différents. Cette section décrit leurs similitudes et leurs différences.

MQTTMessages du dernier testament (LWT)

Last Will and Testament (LWT) est une fonctionnalité deMQTT. Les clients peuvent ainsi spécifier un message que le courtier publiera sur un sujet défini par le client et enverra à tous les clients abonnés au sujet en cas de déconnexion non initiée. LWT Le message spécifié par les clients est appelé LWT message ou message testamentaire, et le sujet défini par les clients est appelé sujet testamentaire. Vous pouvez spécifier un LWT message lorsqu'un appareil se connecte au broker. Ces messages peuvent être retenus en plaçant l’indicateur Will Retain dans le champ Connect Flag bits pendant la connexion. Par exemple, si l’indicateur Will Retain est défini sur 1, un message Will sera stocké dans l’agent dans le rubrique Will associée. Pour plus d’informations, consultez Messages volontaires.

L’agent retiendra les messages Will jusqu’à ce qu’une déconnexion non initiée se produise. Lorsque cela se produit, le courtier publiera les messages à tous les clients abonnés à la rubrique Will pour notifier la déconnexion. Si le client se déconnecte du courtier avec une déconnexion initiée par le client à l'aide du MQTT DISCONNECT message, le courtier ne publiera pas les messages stockés. LWT Dans tous les autres cas, les LWT messages seront envoyés. Pour une liste complète des scénarios de déconnexion dans lesquels le courtier enverra les LWT messages, consultez la section Événements de connexion/déconnexion.

En utilisant connectAttributes

ConnectAttributesvous permettent de spécifier les attributs que vous souhaitez utiliser dans votre message de connexion dans vos IAM politiques, tels que PersistentConnect etLastWill. Grâce à ConnectAttributes, vous pouvez ainsi créer des politiques qui n’autorisent pas les appareils à accéder aux nouvelles fonctionnalités par défaut, ce qui peut être utile si un appareil est compromis.

connectAttributes prend en charge les fonctions suivantes :

Par défaut, votre politique prévoit une connexion non permanente et aucun attribut n’est transmis pour cette connexion. Vous devez spécifier une connexion permanente dans votre IAM politique si vous souhaitez en avoir une.

Pour des exemples ConnectAttributes, consultez la section Exemples de politiques de connexion.

MQTT5 fonctionnalités prises en charge

AWS IoT Core le support pour MQTT 5 est basé sur la spécification MQTT v5.0 avec quelques différences, comme indiqué dansAWS IoT différences par rapport MQTT aux spécifications.

Abonnements partagés

AWS IoT Core prend en charge les abonnements partagés pour MQTT 3 et MQTT 5. Les abonnements partagés permettent à plusieurs clients de partager un abonnement à une rubrique et un seul client recevra les messages publiés sur cette rubrique selon une distribution aléatoire. Les abonnements partagés peuvent équilibrer efficacement la charge MQTT des messages entre un certain nombre d'abonnés. Supposons, par exemple, que 1000 appareils publient sur le même rubrique et que 10 applications principales traitent ces messages. Dans ce cas, les applications principales peuvent s’abonner à la même rubrique et chacune recevra aléatoirement des messages publiés par les appareils sur le rubrique partagé. Cela revient à « partager » efficacement la charge de ces messages. Les abonnements partagés permettent également une meilleure résilience. Lorsqu’une application principale se déconnecte, l’agent répartit la charge entre les abonnés restants du groupe.

Pour utiliser les abonnements partagés, les clients s’abonnent au filtre de rubrique d’un abonnement partagé comme suit :

$share/{ShareName}/{TopicFilter}

Les abonnements identiques {ShareName}/{TopicFilter} appartiennent au même groupe d’abonnements partagés. Vous pouvez créer plusieurs groupes d’abonnements partagés et ne pas dépasser la limite d’abonnements partagés par groupe. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .

Les tableaux suivants comparent les abonnements non partagés et les abonnements partagés :

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Flux d’abonnements non partagés	Flux d’abonnements partagés

Remarques importantes concernant l’utilisation des abonnements partagés

Pour plus d’informations sur les limites des abonnements partagés, consultez la section AWS IoT Core Points de terminaison et quotas de la AWS référence générale. Pour tester les abonnements partagés à l'aide du AWS IoT MQTT client dans la AWS IoT console, consultezTest des abonnements partagés dans le MQTT client. Pour plus d'informations sur les abonnements partagés, consultez la section Abonnements partagés de la spécification MQTTv5 .0.

Démarrage correct et expiration de session

Vous pouvez utiliser Clean Start et Session Expiration pour gérer vos sessions permanentes avec plus de flexibilité. Un indicateur Clean Start indique si la session doit démarrer sans utiliser une session existante. Un intervalle d’expiration de session indique la durée pendant laquelle la session doit être retenue après une déconnexion. L’intervalle d’expiration des sessions peut être modifié lors de la déconnexion. Pour de plus amples informations, veuillez consulter MQTTsessions persistantes.

Code de raison sur tous ACKs

Vous pouvez déboguer ou traiter les messages d’erreur plus facilement à l’aide des codes de motif. Les codes de motif sont renvoyés par l’agent de messages en fonction du type d’interaction avec l’agent (s’abonner, publier, accuser réception). Pour plus d'informations, consultez la section Codes de MQTT motif. Pour une liste complète des codes de MQTT raison, voir la spécification MQTT v5.

Alias de rubrique

Vous pouvez remplacer le nom d’une rubrique par un alias de rubrique, qui est un entier de deux octets. L'utilisation d'alias de rubrique permet d'optimiser la transmission des noms de rubriques afin de réduire potentiellement les coûts de données sur les services de données mesurés. AWS IoT Core a une limite par défaut de 8 alias de rubrique. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .

Expiration du message

Vous pouvez ajouter des valeurs d’expiration aux messages publiés. Ces valeurs représentent l’intervalle d’expiration des messages en secondes. Si un message n’a pas été envoyé aux abonnés dans cet intervalle, il expirera et sera supprimé. Si vous ne définissez pas la valeur d’expiration du message, celui-ci n’expirera pas.

À l’aller, l’abonné recevra un message indiquant le temps restant dans l’intervalle d’expiration. Par exemple, si un message de publication entrant expire 30 secondes et qu’il est acheminé vers l’abonné au bout de 20 secondes, le champ d’expiration du message sera mis à jour à 10. Il est possible que le message reçu par l'abonné soit actualisé à MEI 0. En effet, dès que le temps restant est inférieur ou égal à 999 ms, il sera mis à jour à 0.

Dans AWS IoT Core, l'intervalle d'expiration minimal des messages est de 1. Si l’intervalle est défini sur 0 du côté client, il sera ajusté à 1. L’intervalle d’expiration maximal des messages est de 604 800 (7 jours). Toute valeur supérieure à cette valeur sera ajustée à la valeur maximale.

Dans les communications entre versions, le comportement relatif à l'expiration du message est déterminé par la MQTT version du message de publication entrant. Par exemple, un message expirant envoyé par une session connectée via MQTT5 peut expirer pour les appareils abonnés à des MQTT3 sessions. Le tableau ci-dessous indique comment l’expiration des messages prend en charge les types de messages de publication suivants :

MQTT5 autres fonctionnalités

Déconnexion du serveur

Lorsqu'une déconnexion se produit, le serveur peut envoyer de manière proactive au client un message DISCONNECT pour notifier la fermeture de la connexion avec un code de motif de déconnexion.

Requête/réponse

Les éditeurs peuvent demander qu’une réponse soit envoyée par le destinataire à un rubrique spécifié par le diffuseur de publication lors de la réception.

Taille maximale du paquet

Le client et le serveur peuvent spécifier indépendamment la taille de paquet maximale qu’ils prennent en charge.

Format de charge utile et type de contenu

Vous pouvez spécifier le format de charge utile (binaire, texte) et le type de contenu lorsqu’un message est publié. Ils sont transmis au destinataire du message.

MQTT5 propriétés

MQTTLes 5 propriétés sont des ajouts importants à la MQTT norme pour prendre en charge les MQTT 5 nouvelles fonctionnalités telles que l'expiration de session et le modèle Request/Response. Dans AWS IoT Core, vous pouvez créer des règles permettant de transférer les propriétés des messages sortants, ou utiliser HTTPPublier pour publier MQTT des messages contenant certaines des nouvelles propriétés.

Le tableau suivant répertorie les MQTT 5 propriétés prises en AWS IoT Core charge.

MQTTcodes de raison

MQTT5 introduit un meilleur signalement des erreurs avec les réponses au code de raison. AWS IoT Core peut renvoyer des codes de motif, y compris, mais sans s'y limiter, les suivants regroupés par paquets. Pour une liste complète des codes de raison pris en charge par MQTT 5, consultez les spécifications MQTT 5.

AWS IoT différences par rapport MQTT aux spécifications

L'implémentation du courtier de messages est basée sur les spécifications MQTT v3.1.1 et MQTTv5.0, mais elle diffère des spécifications de la manière suivante :