MQTT

Le MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger et largement adopté, conçu pour les appareils restreints. AWS IoT Core le soutient pour MQTT est basé sur les spécifications MQTT v3.1.1 et MQTT v5.0, avec quelques différences, comme indiqué dans. AWS IoT différences par rapport aux spécifications MQTT Dernière version de la norme, MQTT 5 introduit plusieurs fonctionnalités clés qui renforcent la robustesse du MQTT-based système, notamment de nouvelles améliorations en termes d'évolutivité, un meilleur signalement des erreurs avec des réponses au code de motif, des 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 fonctionnalités prises en charge par MQTT 5, voir Fonctionnalités prises AWS IoT Core en charge par MQTT 5. AWS IoT Core prend également en charge la communication entre les versions MQTT (MQTT 3 et MQTT 5). Un diffuseur de publication MQTT 3 peut envoyer un message MQTT 3 à un abonné MQTT 5 qui recevra un message de publication MQTT 5, et vice versa.

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

Bien que nous vous recommandions d'utiliser les SDK de l' AWS IoT appareil pour vous y connecter AWS IoT, ils ne sont pas obligatoires. Si vous n'utilisez pas les SDK de l' AWS IoT appareil, vous devez toutefois fournir la sécurité de connexion et de communication nécessaire. Les clients doivent envoyer l’extension TLS SNI (Server Name Indication) 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 des utilisateurs et des AWS informations d'identification IAM pour authentifier les clients doivent fournir l'authentification Signature Version 4 correcte.

Une fois que vos clients sont connectés, vous pouvez surveiller et gérer leurs connexions client MQTT à l'aide de la console ou des API. Pour de plus amples informations, veuillez consulter Gestion des connexions MQTT.

Connexion à MQTT à l'aide du AWS IoT SDK pour appareils

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

Options de qualité de service (QoS) MQTT

AWS IoT et les SDK pour AWS IoT appareils prennent en charge les niveaux de qualité de service (QoS) MQTT et. 0 1 Le protocole MQTT définit un troisième niveau de QoS, le 2 niveau, AWS IoT mais ne le supporte pas. Seul le protocole MQTT prend en charge la fonctionnalité QoS. HTTPS prend 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.

Sessions permanentes MQTT

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 stockés est enregistré dans CloudWatch les métriques et les CloudWatch journaux. 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 permanente MQTT en envoyant un message CONNECT et en définissant l’indicateur cleanSession sur 0. 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 permanentes en définissant l’indicateur Clean Start et Session 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 message CONNECT, la valeur par défaut est 0.

Dans MQTT 5, si vous définissez Clean Start = 1 et Session Expiry Interval =0, cela équivaut à une session propre de MQTT 3. Si vous définissez Clean Start = 0 et Session Expiry Interval >0, cela équivaut à une session permanente 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 permanente représente une connexion continue entre un client et un agent de messages MQTT. 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 QoS 1 sortant avec l'intervalle d'expiration des messages expire lorsqu'un client est hors ligne, une fois la connexion rétablie, le client ne recevra pas le message expiré.

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.

Pour les abonnés partagés, les messages seront mis en file d'attente si au moins un abonné d'un groupe utilise une session permanente et qu'aucun abonné n'est en ligne pour recevoir le message QoS 1. La mise en file d'attente des messages s'effectue à une vitesse maximale de 20 messages par seconde par abonné actif dans un groupe. Pour plus d'informations, consultez la section Mise en file d'attente des messages relatifs aux abonnements partagés.

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 permanentes 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 sur les paquets CONNECT et DISCONNECT.

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

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.

MQTT a retenu les messages

AWS IoT Core supporte le RETAIN drapeau décrit dans le protocole MQTT. Lorsqu'un client place l'RETAINindicateur sur un message MQTT 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 conservés au format MQTT dans AWS IoT Core

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

Les messages retenus au format MQTT nécessitent des actions 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 d'utilisation habituels de l'API. Les frais supplémentaires sont décrits dans la section AWS IoT Core Tarification - Messagerie.

Les messages MQTT Will publiés lorsqu’un appareil se déconnecte de façon inattendue entraînent 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 retenus et des sessions permanentes MQTT

Les messages retenus et les sessions permanentes sont des fonctionnalités standard de 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 Sessions permanentes MQTT.

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 l'éditeur et le message stocké est remis à tous les clients actuels et futurs abonnés aux abonnements 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 retenus, AWS IoT Core renvoie une réponse limitée aux messages publiés avec l’option RETAIN définie et à des charges utiles supérieures à 0 octet jusqu’à ce que certains messages retenus soient supprimés et que le nombre de messages retenus tombe en dessous de la limite.

MQTT a conservé les messages et AWS IoT Clichés instantanés d’appareil

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.

Messages MQTT Last Will and Testament (LWT)

Last Will and Testament (LWT) est une fonctionnalité de MQTT. Grâce LWT, les clients peuvent spécifier un message que l’agent publiera sur un rubrique défini par le client et enverra à tous les clients abonnés au rubrique en cas de déconnexion non initiée. Le message spécifié par les clients est appelé message LWT ou message Will, et la rubrique définie par les clients est appelé rubrique Will. Vous pouvez spécifier un message LWT lorsqu’un appareil se connecte à l’agent. 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.

Lorsque vous gérez les connexions client, vous pouvez contrôler si les messages LWT sont publiés lorsque vous déconnectez un client. Pour de plus amples informations, veuillez consulter Gestion des connexions MQTT.

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 de l’agent avec une déconnexion initiée par le client à l’aide du message MQTT DISCONNECT, l’agent ne publiera pas les messages LWT enregistrés. Dans tous les autres cas, les messages LWT seront envoyés. En raison de la nature asynchrone du traitement des déconnexions, il n'est pas garanti que les messages LWT seront envoyés dans l'ordre lors de la reconnexion. Nous vous recommandons d'utiliser les événements du cycle de vie pour améliorer la précision de la détection de l'état de connectivité, car ces événements fournissent des attributs tels que les horodatages et les numéros de version pour gérer les événements de rupture de service. Pour une liste complète des scénarios de déconnexion dans lesquels le courtier enverra les messages LWT, consultez la section Connect/Disconnect événements.

Utilisation de ConnectAttributes

ConnectAttributes vous permettent de spécifier les attributs que vous souhaitez utiliser dans votre message de connexion dans vos politiques IAM telles que PersistentConnect et LastWill. 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 politique IAM si vous souhaitez en avoir une.

Lorsque vous gérez les connexions client via la console ou les API, vous pouvez consulter les attributs de connexion et la configuration de session pour les clients connectés. Pour de plus amples informations, veuillez consulter Gestion des connexions MQTT.

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

Fonctionnalités prises en charge par MQTT 5

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

Abonnements partagés

AWS IoT Core prend en charge les abonnements partagés pour MQTT 3.1.1 et MQTT 5. Les abonnements partagés permettent à plusieurs clients de partager un abonnement à un sujet et un seul client recevra les messages publiés sur ce sujet selon une distribution aléatoire. Les abonnements partagés peuvent équilibrer efficacement la charge des messages MQTT 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 au même sujet, et chacune recevra aléatoirement des messages publiés par les appareils sur le sujet 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. Lorsque tous les abonnés se déconnectent, les messages sont mis en file d'attente.

Des fonctionnalités de mise en file d'attente de messages sont disponibles pour les abonnements partagés sur les connexions MQTT 3.1.1 et MQTT 5 afin d'améliorer la fiabilité de la livraison des messages.

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é. 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/#

Non-shared flux d'abonnements	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 référence AWS générale. Pour tester les abonnements partagés à l'aide du client AWS IoT MQTT dans la AWS IoT console, consultezTest des abonnements partagés dans le client MQTT. Vous pouvez également consulter les sujets auxquels les clients connectés sont abonnés, y compris les abonnements partagés, à l'aide des fonctionnalités de gestion des connexions client. Pour de plus amples informations, veuillez consulter Gestion des connexions MQTT. Pour plus d'informations sur les abonnements partagés, consultez la section Abonnements partagés de la MQTTv5.0 spécification.

Abonnements partagés, mise en file d'attente des messages

Pour améliorer la fiabilité de la diffusion des messages, les abonnements partagés incluent des fonctionnalités de mise en file d'attente des messages qui stockent les messages lorsqu'aucun abonné en ligne n'est disponible. Lorsqu'un groupe d'abonnement partagé contient au moins un membre disposant d'une session permanente, la fonctionnalité de mise en file d'attente est activée pour le groupe. Lors de la distribution de messages, les membres en ligne sont sélectionnés comme destinataires. Les messages QoS 1 sont mis en file d'attente lorsqu'aucun membre n'est trouvé en ligne ou lorsque le nombre d'abonnés dépasse la limite. Publish requests per second per connection Les messages en file d'attente sont remis soit lorsque les membres existants reprennent leurs sessions permanentes, soit lorsque de nouveaux membres rejoignent le groupe. Les messages en file d'attente sont distribués à un maximum de 20 messages par seconde par abonné du groupe actif, ainsi que tout autre message délivré à l'abonné conformément aux abonnements.

Par défaut, la rétention des messages en file d'attente respecte le Persistent Session expiry periodquota. Toutefois, si un intervalle d'expiration des messages (MEI) est défini dans le message de publication entrant, le MEI a priorité. Lorsque le MEI est présent, il détermine la période de rétention des messages, quelle que soit la période d'expiration de la session persistante.

Le débit des files d'attente de messages est limité en fonction du Queued messages per second per accountquota, et le nombre de messages est limité par le Maximum number of queued messages per shared subscription groupquota. Pour consulter et gérer vos quotas, accédez à la console Service Quotas.

Vous pouvez surveiller la file d'attente CloudWatch en effectuant une recherche ApproximateQueueDepth dans l'AWS/Usageespace de noms, ou vous pouvez utiliser la commande CLI suivante pour répertorier les métriques associées à la profondeur de file d'attente de chaque groupe d'abonnement partagé.

aws cloudwatch list-metrics --namespace "AWS/Usage" --dimensions Name=Resource,Value='ApproximateQueueDepth'

Lorsque ces limites sont dépassées, seuls les messages qui étaient déjà en file d'attente avant d'atteindre la limite sont conservés. Les nouveaux messages entrants qui dépasseraient les limites sont supprimés. Le système ne remplace pas les anciens messages en file d'attente par des messages plus récents.

La mise en file d'attente des messages est enregistrée dans CloudWatch les métriques et CloudWatch les journaux. 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. Les messages en file d'attente sont toujours facturés au tarif de messagerie standard. Pour plus d’informations sur la tarification des messages, consultez AWS IoT Core Tarification.

Cycle de vie des sessions dans un groupe d'abonnement partagé

Lorsqu'une session propre s'abonne à un groupe, elle devient membre en ligne du groupe. Lorsqu'elle se désabonne ou se déconnecte, la session nettoyée quitte le groupe.

Lorsqu'une session permanente s'abonne à un groupe, elle devient membre en ligne du groupe. Lorsqu'il se déconnecte, il reste dans le groupe, mais en devient un membre hors ligne. Lorsqu'il se reconnecte, il redevient membre en ligne. La session permanente quitte le groupe lorsqu'il se désabonne explicitement ou lorsqu'il expire après une déconnexion.

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 Sessions permanentes MQTT.

Code de motif sur tous les ACK

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 Codes de motif MQTT. Pour une liste complète des codes de motif MQTT, consultez la spécification MQTT v5.

Alias de sujets

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 (MEI) 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é ait un MEI mis à jour de 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, le MEI minimum 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 la communication entre versions, le comportement d’expiration du message est déterminé par la version MQTT du message de publication entrant. Par exemple, un message d’expiration envoyé par une session connectée via MQTT5 peut expirer pour les appareils abonnés à des sessions MQTT3. Le tableau ci-dessous indique comment l’expiration des messages prend en charge les types de messages de publication suivants :

Autres fonctionnalités de MQTT 5

Déconnexion du serveur

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

Request/Response

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.

Propriétés du MQTT 5

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

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

Codes de motif MQTT

MQTT 5 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 motif pris en charge par MQTT 5, consultez les spécifications du MQTT 5.

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

L’implémentation de l’agent de messages est basée sur les spécifications MQTT v3.1.1 et MQTT v5.0, mais elle diffère des spécifications de la manière suivante :

Gestion des connexions MQTT

AWS IoT Core fournit des API et des fonctionnalités de console pour vous aider à gérer les connexions MQTT, notamment la possibilité de déconnecter les clients, d'afficher les détails des connexions et de gérer leurs sessions. Ces fonctionnalités vous permettent de mieux contrôler votre parc de AWS IoT clients et de résoudre les problèmes de connexion.

Déconnexion des clients MQTT

Utilisez l'DeleteConnectionAPI pour déconnecter les appareils MQTT AWS IoT Core en spécifiant leurs identifiants clients. Lorsque vous déconnectez un client, vous le AWS IoT Core déconnectez du courtier de AWS IoT Core messages et vous pouvez éventuellement nettoyer l'état de la session et supprimer le message LWT (LWT).

Lorsque vous appelez l'DeleteConnectionAPI, AWS IoT Core exécute plusieurs actions pour garantir une déconnexion correcte. AWS IoT Core envoie d'abord un message de déconnexion MQTT au client pour mettre fin à la session MQTT. Le service ferme ensuite le TCP/TLS socket sous-jacent.

Le courtier de messages envoie un DISCONNECT paquet à l'appareil et publie un événement du cycle de vie avec la raison de la déconnexionAPI_INITIATED_DISCONNECT. Cela vous permet d'identifier le moment où une déconnexion a été initiée via l'API plutôt que par le client ou en raison de problèmes réseau. Vous pouvez surveiller ces événements à des fins de visibilité, de résolution des problèmes et d'audit. Par exemple, vous pouvez utiliser des AWS IoT règles pour traiter ces événements afin de savoir quand et pourquoi les clients ont été déconnectés.

Si vous définissez le cleanSession paramètre surtrue, AWS IoT Core supprime l'état de session du client, y compris tous les abonnements et les messages en file d'attente. Si vous nettoyez une session, la session persistante est interrompue. Si le client était une session persistante et que le preventWillMessage paramètre est défini surfalse, le service envoie le message LWT s'il est disponible, ce qui est utile lors des opérations de maintenance planifiées.

Lorsque vous appelez l'DeleteConnectionAPI, le processus de déconnexion commence immédiatement, mais le moment exact auquel le client reconnaît la déconnexion peut varier en fonction des conditions du réseau et de l'implémentation du client. La plupart des clients détectent la déconnexion en quelques secondes, mais dans certains cas, en cas de mauvaise connectivité réseau, le client peut mettre plus de temps à reconnaître qu'il a été déconnecté.

Pour plus d’informations sur la tarification, consultez Tarification AWS IoT Core.

Cas d’utilisation

L'DeleteConnectionAPI est utile pour gérer les clients qui se comportent mal ou consomment des ressources excessives. En forçant une déconnexion, vous pouvez vous assurer que les clients rétablissent leurs connexions avec une authentification et une autorisation appropriées, ce qui peut aider à résoudre les problèmes de consommation de ressources.

Les scénarios de redirection de clients bénéficient également de cette API. Lorsque vous devez rediriger des clients vers différents points de terminaison ou Régions AWS que vous pouvez les déconnecter par programme et les reconnecter à un autre AWS IoT Core point de terminaison en modifiant les paramètres DNS. Cette API peut aider à résoudre les connexions bloquées ou à éliminer les états de session problématiques susceptibles d'empêcher le fonctionnement normal.

Paramètres d'API

L'DeleteConnectionAPI accepte les paramètres suivants :

Syntaxe de l'API

L'DeleteConnectionAPI utilise le format de requête HTTP suivant :

DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Exemples de demandes :

// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Les requêtes réussies renvoient HTTP 200 OK sans aucun corps de réponse.

Autorisations requises

Pour utiliser l'DeleteConnectionAPI, vous devez disposer de l'autorisation IAM suivante :

iot:DeleteConnection

Vous pouvez étendre cette autorisation à des ID clients spécifiques à l'aide de politiques basées sur les ressources. Par exemple :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Considérations importantes

Les clients déconnectés peuvent immédiatement tenter de se reconnecter, sauf si vous avez implémenté une logique supplémentaire pour empêcher la reconnexion. L'opération de déconnexion met uniquement fin à la connexion en cours et n'empêche pas la reconnexion d'une connexion. Si vous devez empêcher la reconnexion, envisagez d'implémenter une logique côté client ou de désactiver les informations d'identification d'un appareil.

Les limites de débit s'appliquent à l'API dans le cadre de la limitation de débit standard de AWS IoT Core l'API. Lorsque vous planifiez des opérations de déconnexion en masse, assurez-vous de tenir compte de ces limites et de mettre en œuvre une logique de nouvelle tentative et des stratégies de traitement par lots appropriées pour éviter les ralentissements. Pour plus d’informations, consultez Points de terminaison et quotas AWS IoT Core.

Réponses d'erreur

L'DeleteConnectionAPI peut renvoyer les réponses d'erreur suivantes :

Affichage des informations de connexion

Utilisez l'GetConnectionAPI pour récupérer des informations détaillées sur les connexions clientes MQTT actives, notamment l'état de la connexion, les détails des sessions et les informations réseau.

L'GetConnectionAPI renvoie des métadonnées de connexion complètes qui aident à résoudre les problèmes de connectivité, à surveiller le comportement des clients et à auditer les modèles de connexion. Vous pouvez utiliser ces informations pour comprendre le cycle de vie des connexions client et diagnostiquer les problèmes liés aux sessions MQTT. Les informations de connexion sont disponibles pendant 30 minutes après la déconnexion, que le client ait utilisé une session propre ou persistante. Pour les métadonnées déconnectées au-delà de 30 minutes, utilisez l'GetThingConnectivityDataAPI qui nécessite l'activation de l'indexation du parc.

Cas d’utilisation

L'GetConnectionAPI est utile pour résoudre les problèmes de connexion et surveiller le comportement des clients. Vous pouvez vérifier l'état de connectivité du client, vérifier les paramètres de session permanente et consulter les horodatages des connexions pour comprendre les modèles de connectivité des clients.

Les diagnostics réseau bénéficient également de cette API. Les détails de connexion incluent les adresses IP et les ports source et cible, qui permettent d'identifier les problèmes de routage réseau ou les problèmes de point de terminaison de connexion. Ces informations sont précieuses pour résoudre les problèmes de connectivité ou optimiser les configurations réseau.

Paramètres d'API

L'GetConnectionAPI accepte les paramètres suivants :

Syntaxe de l'API

L'GetConnectionAPI utilise le format de requête HTTP suivant :

GET /connections/<client-id>?includeSocketInformation=false HTTP/1.1

Exemples de demandes :

GET /connections/myDevice123?includeSocketInformation=false HTTP/1.1

// Get connection details for a client with special characters (URL encoded)
// Original client ID: "my device/123"
GET /connections/my%20device%2F123?includeSocketInformation=true HTTP/1.1

Exemple de réponse pour un client connecté :

{
    "clientId": "abcd12345fvgbh",
    "connected": true,
    "cleanSession": false,
    "connectedSince": 1573002340451,
    "thingName": "deviceABC",
    "sourceIp": "203.0.113.1",
    "sourcePort": 8883,
    "targetIp": "198.51.100.1",
    "targetPort": 8883,
    "keepAliveDuration": 60,
    "disconnectReason": null,
    "sessionExpiry": 3600
}

Champs de réponse :

Autorisations requises

Pour utiliser l'GetConnectionAPI, vous devez disposer de l'autorisation IAM suivante :

iot:GetConnection

Vous pouvez étendre cette autorisation à des ID clients spécifiques à l'aide de politiques basées sur les ressources.

Exemples de politiques d'autorisation

Exemple 1 : Autoriser GetConnection avec des informations de socket pour tous les clients

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/*"
        }
    ]
}

Avec cette politique, l'appel d'API suivant renvoie les détails de connexion, y compris les informations du socket :

GET /connections/myDevice123?includeSocketInformation=true HTTP/1.1

Résultat : l'API renvoie tous les champs de connexionsourceIp, y comprissourcePort,targetIp, ettargetPort.

Exemple 2 : autoriser GetConnection mais refuser les informations de socket pour des clients spécifiques

Vous pouvez utiliser une approche basée sur les conditions ou une approche de refus explicite :

Condition-based approche :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*",
            "Condition": {
                "Bool": {
                    "iot:IncludeSocketInformation": "false"
                }
            }
        }
    ]
}

Approche de refus explicite :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*",
            "Condition": {
                "Bool": {
                    "iot:IncludeSocketInformation": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": ["iot:GetConnection"],
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Quelle que soit la politique, l'appel d'API suivant est refusé :

GET /connections/myDevice123?includeSocketInformation=true HTTP/1.1

Résultat : L'API renvoie une erreur 403 Forbidden car l'accès aux informations du socket est restreint pour ces clients.

Réponses d'erreur

L'GetConnectionAPI peut renvoyer les réponses d'erreur suivantes :

Gestion des abonnements des clients

Utilisez l'ListSubscriptionsAPI pour récupérer tous les abonnements aux rubriques d'une session client MQTT. Cette API renvoie les abonnements aux clients connectés et aux clients hors ligne avec des sessions persistantes, offrant ainsi une visibilité sur les modèles d'abonnement des clients et aidant à résoudre les problèmes liés aux abonnements.

L'ListSubscriptionsAPI fournit des informations complètes sur les abonnements qui permettent d'auditer le comportement des clients, de résoudre les problèmes de livraison des messages et de comprendre les modèles d'abonnement sur l'ensemble de votre parc d'appareils. Vous pouvez utiliser ces informations pour vérifier que les clients sont abonnés aux rubriques attendues et identifier les conflits d'abonnement potentiels.

Cas d’utilisation

L'ListSubscriptionsAPI vous aide à résoudre les problèmes de livraison des messages et à vérifier le comportement des clients en matière d'abonnement. Utilisez cette API pour vérifier les sujets auxquels un client est abonné, valider les niveaux de QoS et identifier les abonnements qui se chevauchent ou les cartes whildcards trop permissives.

Les scénarios de gestion des abonnements bénéficient également de cette API. Lorsque des clients signalent des messages manquants ou une livraison inattendue, vous pouvez utiliser cette API pour vérifier leurs abonnements actuels et vous assurer qu'ils correspondent à la configuration attendue. Cela est particulièrement utile pour le débogage de hiérarchies d'abonnement complexes et de configurations d'abonnement partagées.

Paramètres d'API

L'ListSubscriptionsAPI accepte les paramètres suivants :

Syntaxe de l'API

L'ListSubscriptionsAPI utilise le format de requête HTTP suivant :

GET /connections/<client-id>/subscriptions?nextToken=token&maxResults=max HTTP/1.1

Exemples de demandes :

// Get subscriptions for a specific client
GET /connections/myDevice123/subscriptions HTTP/1.1

// Get subscriptions with custom page size
GET /connections/myDevice123/subscriptions?maxResults=50 HTTP/1.1

// Get next page of results using pagination token
GET /connections/myDevice123/subscriptions?nextToken=eyJhbGciOiJIUzI1NiJ9&maxResults=50 HTTP/1.1

Exemple de réponse :

{
    "subscriptions": [
        {"topicFilter": "device/myDevice123/commands", "qos": 1},
        {"topicFilter": "device/myDevice123/shadow", "qos": 0}
    ],
    "nextToken": "eyJhbGciOiJIUzI1NiJ9"
}

Champs de réponse :

Autorisations requises

Pour utiliser l'ListSubscriptionsAPI, vous devez disposer de l'autorisation IAM suivante :

iot:ListSubscriptions

Vous pouvez étendre cette autorisation à des ID clients spécifiques à l'aide de politiques basées sur les ressources. Par exemple :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:ListSubscriptions",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Réponses d'erreur

L'ListSubscriptionsAPI peut renvoyer les réponses d'erreur suivantes :

Gestion des connexions MQTT à l'aide de la console

Vous pouvez utiliser la AWS IoT console pour déconnecter les appareils MQTT et gérer leurs connexions. La console fournit une interface intuitive permettant de visualiser les appareils connectés et d'effectuer des opérations de déconnexion.

Afficher les clients MQTT connectés

Cette procédure explique comment afficher les périphériques MQTT actuellement connectés dans la AWS IoT console.

Afficher les abonnements aux clients MQTT

Cette procédure explique comment afficher les abonnements aux rubriques pour un client MQTT spécifique à l'aide de la AWS IoT console.

Déconnecter un appareil MQTT

Cette procédure explique comment déconnecter un périphérique MQTT spécifique à l'aide de la AWS IoT console.

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

L’implémentation de l’agent de messages est basée sur les spécifications MQTT v3.1.1 et MQTT v5.0, mais elle diffère des spécifications de la manière suivante :

CloudWatch Journaux AWS IoT entrées du journal

Le courtier de AWS IoT messages génère une entrée de journal avec un « eventType of » Connect lorsqu'un client MQTT se connecte.

Exemple d'entrée dans le journal Connect

{
    "timestamp": "2017-08-10 15:37:23.476",
    "logLevel": "INFO",
    "traceId": "20b23f3f-d7f1-feae-169f-82263394fbdb",
    "accountId": "123456789012",
    "status": "Success",
    "eventType": "Connect",
    "protocol": "MQTT",
    "clientId": "abf27092886e49a8a5c1922749736453",
    "thingName": "myDevice",
    "principalId": "145179c40e2219e18a909d896a5340b74cf97a39641beec2fc3eeafc5a932167",
    "sourceIp": "205.251.233.181",
    "sourcePort": 13490,
    "keepAliveDuration": 60,
    "sessionExpiry": 3600,
    "cleanSession": boolean
}

Outre les attributs courants des CloudWatch journaux, les entrées du journal Connect contiennent les attributs suivants :