MQTT

MQTT (Message Queuing Telemetry Transport) è un protocollo di messaggistica leggero e ampiamente adottato, progettato per dispositivi vincolati. Il supporto AWS IoT Core per MQTT si basa sulla specifica MQTT v3.1.1 e la specifica MQTT v5.0, con alcune differenze come documentato in AWS IoT differenze rispetto alle specifiche MQTT. Essendo la versione più recente dello standard, MQTT 5 introduce diverse funzionalità chiave che rendono un sistema basato su MQTT più affidabile, inclusi nuovi miglioramenti della scalabilità, segnalazione degli errori migliorata con risposte codice motivo, timer di scadenza dei messaggi e delle sessioni e intestazioni messaggi utente personalizzate. Per ulteriori informazioni sulle funzionalità supportate da MQTT 5, consultate Funzionalità AWS IoT Core supportate da MQTT 5. AWS IoT Core supporta anche la comunicazione tra versioni MQTT (MQTT 3 e MQTT 5). Un autore MQTT 3 può inviare un messaggio MQTT 3 a un sottoscrittore MQTT 5 che riceverà un messaggio di pubblicazione MQTT 5, e viceversa.

AWS IoT Core supporta connessioni di dispositivi che utilizzano il protocollo MQTT e il protocollo MQTT over WSS e che sono identificate da un ID client. AWS IoT SDK per dispositivi supportano entrambi i protocolli e sono i modi consigliati per connettere i dispositivi a AWS IoT Core. I AWS IoT Device SDK supportano le funzioni necessarie per consentire a dispositivi e client di connettersi e accedere ai servizi. AWS IoT I Device SDK supportano i protocolli di autenticazione richiesti dai AWS IoT servizi e i requisiti di ID di connessione richiesti dal protocollo MQTT e dai protocolli MQTT su WSS. Per informazioni su come connettersi AWS IoT utilizzando gli SDK del AWS dispositivo e collegamenti ad esempi AWS IoT nelle lingue supportate, vedere. Connessione con MQTT utilizzando gli SDK del dispositivo AWS IoT Per ulteriori informazioni sull’autenticazione e sulla mappatura delle porte per i messaggi MQTT, consulta Protocolli, mappature delle porte e autenticazione.

Sebbene consigliamo di utilizzare gli SDK del AWS IoT dispositivo a cui connettersi AWS IoT, non sono necessari. Se non utilizzi gli SDK del AWS IoT dispositivo, tuttavia, devi fornire la necessaria sicurezza di connessione e comunicazione. I client devono inoltre inviare la Estensione TLS di Server Name Indication per impedire che le connessioni vengano rifiutate. I tentativi di connessione che non includono l'SNI vengono rifiutati. Per ulteriori informazioni, consulta Transport Security in AWS IoT. I client che utilizzano utenti e AWS credenziali IAM per autenticare i client devono fornire l'autenticazione Signature Version 4 corretta.

Connessione con MQTT utilizzando gli SDK del dispositivo AWS IoT

Questa sezione contiene collegamenti agli SDK del AWS IoT dispositivo e al codice sorgente di programmi di esempio che illustrano come collegare un dispositivo a. AWS IoT Le app di esempio collegate qui mostrano come connettersi AWS IoT utilizzando il protocollo MQTT e MQTT tramite WSS.

Opzioni di qualità del servizio MQTT (QoS)

AWS IoT e gli SDK del AWS IoT dispositivo supportano i livelli di qualità del servizio (QoS) MQTT e. 0 1 Il protocollo MQTT definisce un terzo livello di QoS, 2 livello, AWS IoT ma non lo supporta. Solo il protocollo MQTT supporta la caratteristica QoS. HTTPS supporta QoS passando un parametro di stringa di query ?qos=qos dove il valore può essere 0 o 1.

Questa tabella descrive come ogni livello QoS influisce sui messaggi pubblicati da e per il broker messaggi.

Sessioni persistenti MQTT

Le sessioni persistenti archiviano le sottoscrizioni e i messaggi di un client, con una qualità del servizio (QoS) pari a 1, che non sono stati riconosciuti dal client. Quando il dispositivo si riconnette a una sessione persistente, la sessione riprende, le relative sottoscrizioni vengono reintegrate e i messaggi sottoscritti non riconosciuti ricevuti e archiviati prima della riconnessione vengono inviati al client.

L'elaborazione dei messaggi archiviati viene registrata in and Logs. CloudWatch CloudWatch Per informazioni sulle voci scritte in CloudWatch and CloudWatch Logs, vedere Parametri del broker di messaggi e. Voce di log Queued

Creazione di una sessione persistente

In MQTT3, è possibile creare una sessione persistente MQTT inviando un messaggio CONNECT e impostando il flag cleanSession su 0. Se non esiste alcuna sessione per il client che invia il messaggio CONNECT, viene creata una nuova sessione persistente. Se esiste una sessione per il client, il client riprende la sessione esistente. Per creare una sessione pulita, è possibile inviare un messaggio CONNECT e impostare il flag cleanSession su 1. Il broker non memorizzerà alcuno stato della sessione quando il client si disconnette.

In MQTT 5, è possibile gestire le sessioni persistenti impostando il flag Clean Start e Session Expiry Interval. Avvio pulito controlla l'inizio della sessione di connessione e la fine della sessione precedente. Quando si imposta Clean Start = 1, viene creata una nuova sessione e una sessione precedente viene terminata, se esiste. Quando si imposta Clean Start= 0, la sessione di connessione riprende una sessione precedente, se esiste. L'intervallo di scadenza della sessione controlla la fine della sessione di connessione. L'intervallo di scadenza della sessione specifica il tempo, in secondi (numero intero a 4 byte), di persistenza di una sessione dopo la disconnessione. L'impostazione Session Expiry interval=0 causa la terminazione immediata della sessione dopo la disconnessione. Se l'intervallo di scadenza della sessione non è specificato nel messaggio CONNECT, il valore predefinito è 0.

In MQTT 5, se si imposta Clean Start = 1 e Session Expiry Interval = 0, questo è l'equivalente di una sessione pulita MQTT 3. Se si imposta Clean Start = 0 e Session Expiry Interval> 0, è l'equivalente di una sessione persistente MQTT 3.

Operazioni durante una sessione persistente

I dispositivi utilizzano l'attributo sessionPresent nel messaggio CONNACK (Connection Acknowledged) per determinare l'eventuale presenza di una sessione persistente. Se sessionPresent è 1, è presente una sessione persistente e tutti i messaggi archiviati per il client vengono distribuiti al client dopo che il client riceve il CONNACK, come descritto in Traffico dei messaggi dopo la riconnessione a una sessione persistente. Se sessionPresent è impostato su 1, non è necessario che il client esegua di nuovo la sottoscrizione. Se sessionPresent è impostato su 0, non è presente alcuna sessione persistente e il client deve eseguire nuovamente la sottoscrizione nei filtri degli argomenti.

Dopo che il client si unisce ad una sessione persistente, può pubblicare messaggi e sottoscrivere filtri argomento senza ulteriori flag in ogni operazione.

Traffico dei messaggi dopo la riconnessione a una sessione persistente

Una sessione persistente rappresenta una connessione continua tra un cliente e un broker di messaggi MQTT. Quando un client si connette a un broker di messaggi utilizzando una sessione persistente, il broker di messaggi salva tutte le sottoscrizioni che il client effettua durante la connessione. Quando il client si disconnette, il broker di messaggi archivia i messaggi QoS 1 non riconosciuti e i nuovi messaggi QoS 1 pubblicati in argomenti di cui il client ha eseguito la sottoscrizione. I messaggi vengono archiviati in base al limite dell'account. I messaggi che superano il limite verranno eliminati. Per ulteriori informazioni sui limiti dei messaggi persistenti, consulta Endpoint e quote di AWS IoT Core. Quando il client si riconnette alla sessione persistente, tutte le sottoscrizioni vengono ripristinate e tutti i messaggi archiviati vengono inviati al client a una velocità massima di 10 messaggi al secondo. In MQTT 5, se un QoS1 in uscita con l'Intervallo scadenza messaggio scade quando un client è offline, dopo che la connessione viene ripristinata, il client non riceverà il messaggio scaduto.

Dopo la riconnessione, i messaggi archiviati vengono inviati al client, a una velocità limitata di 10 messaggi archiviati al secondo, insieme a qualsiasi traffico di messaggi corrente fino a quando il limite di Publish requests per second per connection viene raggiunto. Poiché la velocità di distribuzione dei messaggi archiviati è limitata, ci vorranno alcuni secondi per distribuire tutti i messaggi archiviati se una sessione ha più di 10 messaggi archiviati da distribuire dopo la riconnessione.

Termine di una sessione persistente

Le sessioni persistenti possono terminare nei modi seguenti:

In MQTT 3, il valore predefinito del tempo di scadenza delle sessioni persistenti è un'ora e si applica a tutte le sessioni nell'account.

In MQTT 5, è possibile impostare Intervallo di scadenza della sessione per ogni sessione sui pacchetti CONNECT e DISCONNECT.

Per intervallo di scadenza della sessione sul pacchetto DISCONNECT:

Riconnessione dopo la scadenza di una sessione persistente

Se un client non si riconnette alla sessione persistente prima della scadenza, la sessione termina e i messaggi archiviati vengono eliminati. Quando un client si riconnette dopo la scadenza della sessione e imposta il flag cleanSession su 0, il servizio crea una nuova sessione persistente. Gli abbonamenti o i messaggi della sessione precedente non sono disponibili per questa sessione perché sono stati scartati alla scadenza della sessione precedente.

Addebito dei messaggi di sessione persistente

I messaggi vengono addebitati all'utente Account AWS quando il broker di messaggi invia un messaggio a un cliente o a una sessione persistente offline. Quando un dispositivo offline con una sessione persistente si riconnette e riprende la sessione, i messaggi archiviati vengono recapitati al dispositivo e vengono nuovamente addebitati sul tuo account. Per ulteriori informazioni sui prezzi dei messaggi, consulta AWS IoT Core pricing - Messagging (Prezzi di Amazon IoT Core - Messaggistica).

Si può aumentare il tempo di scadenza predefinito di un’ora della sessione persistente utilizzando il processo di aumento del limite standard. Si noti che l'aumento del tempo di scadenza della sessione potrebbe aumentare gli addebiti dei messaggi. Infatti, il tempo aggiuntivo potrebbe consentire l'archiviazione di più messaggi per il dispositivo offline e tali messaggi aggiuntivi verranno addebitati all'account alla tariffa di messaggistica standard. Il tempo di scadenza della sessione è approssimativo e una sessione potrebbe persistere fino a 30 minuti più a lungo rispetto al limite dell'account; tuttavia, una sessione non può essere inferiore al limite dell'account. Per ulteriori informazioni sui limiti di sessione, consulta Service Quotas di AWS.

Messaggi conservati da MQTT

AWS IoT Core supporta il flag RETAIN descritto nel protocollo MQTT. Quando un client imposta il flag RETAIN su un messaggio MQTT che pubblica, AWS IoT Core salva il messaggio. Può quindi essere inviato a nuovi sottoscrittori, recuperato chiamando l'operazione GetRetainedMessage e visualizzato nella console AWS IoT.

Attività comuni con MQTT ha conservato i messaggi in AWS IoT Core

AWS IoT Core salva i messaggi MQTT con il flag RETAIN impostato. Questi messaggi conservati vengono inviati a tutti i client che hanno sottoscritto l'argomento, come un normale messaggio MQTT, e vengono archiviati anche per essere inviati ai nuovi sottoscrittori all'argomento.

I messaggi conservati MQTT richiedono azioni di policy specifiche per autorizzare i client ad accedervi. Per esempi di utilizzo di policy dei messaggi conservati, consulta Esempi di policy per i messaggi conservati.

Questa sezione descrive le operazioni comuni che comportano messaggi conservati.

Messaggi di fatturazione e conservati

La pubblicazione di messaggi con il flag RETAIN impostato da un client, utilizzando la console AWS IoT o chiamando Publish comporta costi aggiuntivi di messaggistica descritti nella sezione Prezzi di AWS IoT Core - Messaggistica.

Il recupero dei messaggi conservati da un client, utilizzando la AWS IoT console o chiamando comporta costi di messaggistica oltre ai normali GetRetainedMessagecosti di utilizzo dell'API. I costi aggiuntivi sono descritti nella sezione Prezzi di AWS IoT Core - Messaggistica.

I messaggi Will MQTT che vengono pubblicati quando un dispositivo si disconnette inaspettatamente comportano i costi di messaggistica descritti in Prezzi di AWS IoT Core - Messaggistica.

Per ulteriori informazioni sui prezzi dei messaggi, consulta la sezione Prezzi di AWS IoT Core - Messaggistica.

Confronto tra i messaggi conservati MQTT e le sessioni persistenti MQTT

I messaggi conservati e le sessioni persistenti sono caratteristiche standard di MQTT che consentono ai dispositivi di ricevere messaggi pubblicati mentre erano offline. I messaggi conservati possono essere pubblicati da sessioni persistenti. In questa sezione vengono descritti gli aspetti chiave di queste caratteristiche e come funzionano insieme.

Per informazioni sulle sessioni persistenti, consulta Sessioni persistenti MQTT.

Con i messaggi mantenuti, il client di pubblicazione determina se un messaggio deve essere conservato e recapitato a un dispositivo dopo la connessione, indipendentemente dal fatto che abbia avuto una sessione precedente o meno. La scelta di archiviare un messaggio viene effettuata dall'editore e il messaggio archiviato viene recapitato a tutti i client attuali e futuri che si iscrivono con un abbonamento QoS 0 o QoS 1. I messaggi conservati conservano un solo messaggio su un determinato argomento alla volta.

Quando un account ha archiviato il numero massimo di messaggi conservati, AWS IoT Core restituisce una risposta limitata ai messaggi pubblicati con impostazione RETAIN e payload superiori a 0 byte fino a quando alcuni messaggi conservati non vengono eliminati e il conteggio dei messaggi conservati scende al di sotto del limite.

Messaggi e Device Shadow conservati da MQTT AWS IoT

I messaggi conservati e i Device Shadow conservano entrambi i dati da un dispositivo, ma si comportano in modo diverso e hanno scopi diversi. In questa sezione vengono descritti somiglianze e differenze.

Messaggi MQTT Last Will and Testament (LWT)

Last Will and Testament (LWT) è una funzionalità di MQTT. Con LWT, i clienti possono specificare un messaggio che il broker pubblicherà su un argomento definito dal client e invierà a tutti i client che hanno sottoscritto l'argomento quando si verifica una disconnessione non iniziata. Il messaggio specificato dai client è chiamato messaggio LWT o messaggio Will e l'argomento definito dai client viene definito argomento Will. Puoi specificare un messaggio LWT quando un dispositivo si connette al broker. Questi messaggi possono essere conservati impostando il flag Will Retain nel campo Connect Flag bits durante la connessione. Ad esempio, se il flag Will Retain è impostato su 1, un messaggio Will verrà archiviato nel broker nell’argomento Will associato. Per ulteriori informazioni, consulta Messaggi Will.

Il broker memorizzerà i messaggi Will fino a quando non si verificherà una disconnessione non avviata. Quando ciò accade, il broker pubblicherà i messaggi a tutti i clienti che si sono iscritti all’argomento Will per notificare la disconnessione. Se il client si disconnette dal broker con una disconnessione avviata dal client utilizzando il messaggio MQTT DISCONNECT, il broker non pubblicherà i messaggi LWT memorizzati. In tutti gli altri casi, i messaggi LWT verranno inviati. Per un elenco completo degli scenari di disconnessione in cui il broker invierà i messaggi LWT, vediEventi di connessione/disconnessione.

Utilizzo degli Attributi Connect

ConnectAttributes consentono di specificare quali attributi si desidera utilizzare nel messaggio di connessione delle policy IAM, ad esempio PersistentConnect e LastWill. Con ConnectAttributes, puoi creare criteri che non consentono ai dispositivi di accedere alle nuove funzionalità per impostazione predefinita, cosa che può essere utile in caso di compromissione di un dispositivo.

connectAttributes supporta le caratteristiche seguenti:

Per impostazione predefinita, la policy dispone di una connessione non persistente e non esistono attributi passati per questa connessione. È necessario specificare una connessione permanente nella policy IAM se si desidera averne una.

Per esempi di ConnectAttributes, consulta Esempi di policy di connessione.

Caratteristiche supportate da MQTT 5

AWS IoT Core il supporto per MQTT 5 si basa sulla specifica MQTT v5.0 con alcune differenze, come documentato in. AWS IoT differenze rispetto alle specifiche MQTT

Sottoscrizioni condivise

AWS IoT Core supporta sottoscrizioni condivise sia per MQTT 3 che per MQTT 5. Sottoscrizioni condivise consentono a più client di condividere una sottoscrizione a un argomento e solo un client riceverà i messaggi pubblicati su tale argomento utilizzando una distribuzione casuale. Sottoscrizioni condivise possono bilanciare efficacemente il carico di messaggi MQTT tra più abbonati. Ad esempio, si supponga di avere 1.000 dispositivi che pubblicano sullo stesso argomento e 10 applicazioni di back-end che elaborano tali messaggi. In tal caso, le applicazioni di back-end possono effettuare la sottoscrizione allo stesso argomento e ciascuna riceve in modo casuale i messaggi pubblicati dai dispositivi sull'argomento condiviso. Questo consente effettivamente di "condividere" il carico di tali messaggi. Sottoscrizioni condivise consentono anche una migliore resilienza. Quando un'applicazione di back-end si disconnette, il broker distribuisce il carico agli abbonati rimanenti nel gruppo.

Per utilizzare Sottoscrizioni condivise, i client effettuano la sottoscrizione al filtro di argomenti di una Sottoscrizione condivisa come illustrato di seguito:

$share/{ShareName}/{TopicFilter}

Le sottoscrizioni che hanno lo stesso {ShareName}/{TopicFilter} appartengono allo stesso gruppo di Sottoscrizioni condivise. È possibile creare più gruppi di Sottoscrizioni condivise e non superare il limite di Sottoscrizioni condivise per gruppo. Per ulteriori informazioni, consulta Endpoint e quote di AWS IoT Core nella Documentazione generale di riferimento di AWS .

Nelle tabelle seguenti vengono confrontate le Sottoscrizioni non condivise e le Sottoscrizioni condivise:

sports/tennis
sports/#

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

Flusso di sottoscrizioni non condivise	Flusso di sottoscrizioni condivise

Note importanti per l'utilizzo di sottoscrizioni condivise

Per ulteriori informazioni sui limiti di Sottoscrizioni condivise, consultare Endpoint e quote di AWS IoT Core nella Documentazione generale di riferimento di AWS . Per testare gli abbonamenti condivisi utilizzando il client AWS IoT MQTT nella console, vedere.AWS IoT Test delle sottoscrizioni condivise nel client MQTT Per ulteriori informazioni su Sottoscrizioni condivise, consultare Sottoscrizioni condivise nelle specifiche MQTTv5.0.

Avvio pulito e scadenza della sessione

È possibile utilizzare Avvio pulito e Scadenza della sessione per gestire le sessioni persistenti con maggiore flessibilità. Un flag Avvio pulito indica se la sessione deve iniziare senza utilizzare una sessione esistente. Un intervallo di scadenza della sessione indica per quanto tempo mantenere la sessione dopo una disconnessione. L'intervallo di scadenza della sessione può essere modificato al momento della disconnessione. Per ulteriori informazioni, consulta Sessioni persistenti MQTT.

Codice motivo su tutti gli ACK

È possibile eseguire il debug o elaborare i messaggi di errore più facilmente utilizzando i codici motivo. I codici motivo vengono restituiti dal broker di messaggi in base al tipo di interazione con il broker (sottoscrizione, pubblicazione, conferma). Per ulteriori informazioni, consulta Codici motivo MQTT. Per un elenco completo dei codici motivo MQTT, consulta Specifiche MQTT v5.

Alias argomento

È possibile sostituire un nome argomento con un alias argomento, che è un numero intero a due byte. L'utilizzo degli alias degli argomenti può ottimizzare la trasmissione dei nomi degli argomenti per ridurre potenzialmente i costi dei dati sui servizi di dati misurati. AWS IoT Core ha un limite predefinito di 8 alias tematici. Per ulteriori informazioni, consulta Endpoint e quote di AWS IoT Core nella Documentazione generale di riferimento di AWS .

Scadenza del messaggio

È possibile aggiungere valori di scadenza del messaggio ai messaggi pubblicati. Questi valori rappresentano l'intervallo di scadenza del messaggio in secondi. Se i messaggi non sono stati inviati ai sottoscrittori entro tale intervallo, il messaggio scadrà e verrà rimosso. Se non si imposta il valore di scadenza del messaggio, il messaggio non scadrà.

In uscita, il sottoscrittore riceverà un messaggio con il tempo rimanente nell'intervallo di scadenza. Ad esempio, se per un messaggio di pubblicazione in entrata è impostata una scadenza del messaggio di 30 secondi e il messaggio viene instradato al sottoscrittore dopo 20 secondi, il campo di scadenza del messaggio verrà aggiornato a 10. È possibile che il messaggio ricevuto dal sottoscrittore abbia un MEI aggiornato pari a 0. Questo perché non appena il tempo rimanente è pari o inferiore a 999 ms, verrà aggiornato a 0.

In AWS IoT Core, l'intervallo minimo di scadenza dei messaggi è 1. Se l'intervallo è impostato su 0 dal lato client, verrà modificato su 1. L'intervallo massimo di scadenza del messaggio è 604800 (7 giorni). Qualsiasi valore superiore a questo verrà modificato nel valore massimo.

Nella comunicazione tra versioni, il comportamento della scadenza del messaggio viene deciso dalla versione MQTT del messaggio di pubblicazione in entrata. Ad esempio, un messaggio con scadenza inviato da una sessione connessa tramite MQTT5 può scadere per i dispositivi che hanno effettuato la sottoscrizione con sessioni MQTT3. Nella tabella seguente viene elencato in che modo la scadenza del messaggio supporta i seguenti tipi di messaggi di pubblicazione:

Altre caratteristiche MQTT 5

Disconnessione server

Quando si verifica una disconnessione, il server può inviare in modo proattivo al client un messaggio DISCONNECT per segnalare la chiusura della connessione con un codice motivo della disconnessione.

Richiesta/Risposta

Gli autori possono richiedere che il destinatario invii una risposta a un argomento specificato dall'autore al momento della ricezione.

Dimensione massima del pacchetto

Client e server possono specificare in modo indipendente la dimensione massima dei pacchetti supportati.

Formato payload e tipo di contenuto

È possibile specificare il formato payload (binario, testo) e il tipo di contenuto quando viene pubblicato un messaggio. Questi dati vengono inoltrati al destinatario del messaggio.

Proprietà MQTT 5

Le proprietà MQTT 5 sono aggiunte importanti allo standard MQTT per supportare nuove caratteristiche MQTT 5 come Scadenza sessione e il modello Richiesta/Risposta. In AWS IoT Core, è possibile creare regole in grado di inoltrare le proprietà nei messaggi in uscita oppure utilizzare HTTP Publish per pubblicare messaggi MQTT con alcune delle nuove proprietà.

Nella tabella seguente sono elencate tutte le proprietà MQTT 5 supportate. AWS IoT Core

Codici motivo MQTT

MQTT 5 introduce una migliore segnalazione degli errori con risposte al codice motivo. AWS IoT Core può restituire codici di motivo inclusi, a titolo esemplificativo ma non esaustivo, i seguenti raggruppati per pacchetti. Per un elenco completo dei codici motivo supportati da MQTT 5, consulta Specifiche MQTT v5.

AWS IoT differenze rispetto alle specifiche MQTT

L'implementazione del broker di messaggi è basata sulla specifica MQTT v3.1.1 e la specifica MQTT v5.0 ma è diversa dalle specifiche per quanto riguarda le considerazioni seguenti: