MQTT

MQTT(Message Queuing Telemetry Transport) è un protocollo di messaggistica leggero e ampiamente utilizzato, progettato per dispositivi con limitazioni. AWS IoT Core il supporto per MQTT si basa sulle specifiche MQTT v3.1.1 e MQTTv5.0, con alcune differenze, come documentato in. AWS IoT differenze rispetto alle MQTT specifiche Essendo l'ultima versione dello standard, la MQTT 5 introduce diverse funzionalità chiave che rendono un sistema MQTT basato più robusto, tra cui nuovi miglioramenti della scalabilità, una migliore segnalazione degli errori con risposte al codice motivo, tempi di scadenza dei messaggi e delle sessioni e intestazioni dei messaggi utente personalizzate. Per ulteriori informazioni sulle MQTT 5 funzionalità supportate, consulta 5 funzionalità supportate AWS IoT Core . MQTT AWS IoT Core supporta anche la comunicazione tra MQTT versioni (MQTT3 e MQTT 5). Un editore di MQTT 3 pagine può inviare un messaggio di MQTT 3 messaggi a un utente con MQTT 5 abbonati che riceverà un messaggio di pubblicazione di MQTT 5 e viceversa.

AWS IoT Core supporta connessioni di dispositivi che utilizzano il MQTT protocollo e MQTT tramite WSS protocollo e che sono identificate da un ID client. AWS IoT Dispositivo SDKs supportano entrambi i protocolli e sono i modi consigliati per connettere i dispositivi a AWS IoT Core. Il AWS IoT dispositivo SDKs supporta le funzioni necessarie ai dispositivi e ai client per connettersi e accedere ai AWS IoT servizi. Il dispositivo SDKs supporta i protocolli di autenticazione richiesti AWS IoT dai servizi e i requisiti di ID di connessione richiesti dal MQTT protocollo e MQTT dai WSS protocolli aggiuntivi. Per informazioni su come connettersi AWS IoT utilizzando il AWS dispositivo SDKs e collegamenti ad esempi AWS IoT nelle lingue supportate, vedereConnessione MQTT tramite l'utilizzo del dispositivo AWS IoT SDKs. Per ulteriori informazioni sui metodi di autenticazione e sulle mappature delle porte per i MQTT messaggi, vedere. Protocolli, mappature delle porte e autenticazione

Sebbene consigliamo di utilizzare il AWS IoT dispositivo SDKs a cui connettersi AWS IoT, non sono necessari. Se non si utilizza il AWS IoT DispositivoSDKs, tuttavia, è necessario fornire la necessaria sicurezza di connessione e comunicazione. I client devono inviare l'TLSestensione Server Name Indication (SNI) nella richiesta di connessione. I tentativi di connessione che non includono il SNI vengono rifiutati. Per ulteriori informazioni, vedere Transport Security in AWS IoT. I client che utilizzano IAM utenti e AWS credenziali per autenticare i client devono fornire l'autenticazione Signature Version 4 corretta.

Connessione MQTT tramite l'utilizzo del dispositivo AWS IoT SDKs

Questa sezione contiene collegamenti al AWS IoT dispositivo SDKs 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 MQTT protocollo e MQTT oltreWSS.

MQTTOpzioni di qualità del servizio (QoS)

AWS IoT e il AWS IoT dispositivo SDKs supporta i livelli 0 di MQTT qualità del servizio (QoS) e. 1 Il MQTT protocollo definisce un terzo livello di QoS, livello2, ma AWS IoT non lo supporta. Solo il MQTT protocollo supporta la funzionalità QoS. HTTPSsupporta QoS passando un parametro di stringa di query ?qos=qos in cui il valore può essere 0 o 1.

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

MQTTsessioni persistenti

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 CloudWatch and CloudWatch Logs. 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 MQTT 3, si crea una sessione MQTT persistente inviando un CONNECT messaggio e impostando il cleanSession flag su0. 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, gestisci le sessioni persistenti impostando il Clean Start flag eSession 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 CONNECT messaggio, il valore predefinito è 0.

In MQTT 5, se imposti Clean Start = 1 e Session Expiry Interval =0, questo è l'equivalente di MQTT 3 sessioni pulite. Se imposti Clean Start = 0 e Session Expiry Interval >0, questo è l'equivalente di MQTT 3 sessioni persistenti.

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 client e un broker di MQTT messaggi. 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. Nella versione MQTT 5, se un QoS1 in uscita con Intervallo di scadenza dei messaggi scade quando un client è offline, dopo la ripresa della connessione, 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 questo vale per tutte le sessioni dell'account.

In MQTT 5, è possibile impostare l'intervallo di scadenza delle sessioni per ogni sessione su CONNECT e DISCONNECT pacchetti.

Per l'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 client 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.

MQTTmessaggi conservati

AWS IoT Core supporta il RETAIN flag descritto nel MQTT protocollo. Quando un client imposta il RETAIN flag su un MQTT messaggio 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 messaggi conservati in MQTT AWS IoT Core

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

MQTTI messaggi conservati richiedono azioni politiche 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 RETAIN flag impostato da un client, utilizzando la AWS IoT console o chiamando Publishcomporta costi di messaggistica aggiuntivi descritti in Prezzi - Messaggistica.AWS IoT Core

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

MQTTAi messaggi pubblicati quando un dispositivo si disconnette inaspettatamente verranno applicati i costi di messaggistica descritti in Pricing - Messaging?AWS IoT Core

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

Confronto tra messaggi conservati e sessioni MQTT persistenti MQTT

I messaggi conservati e le sessioni persistenti sono funzionalità standard 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 MQTTsessioni persistenti.

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 RETAIN set e payload superiori a 0 byte finché alcuni messaggi conservati non vengono eliminati e il numero di messaggi conservati non scende al di sotto del limite.

MQTTmessaggi conservati e Device Shadows 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.

MQTTMessaggi di Last Will and Testament (LWT)

Last Will and Testament (LWT) è una funzionalità di. MQTT ConLWT, i client 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 spontanea. Il messaggio specificato dai client si chiama LWT messaggio o messaggio di volontà e l'argomento definito dai client viene definito argomento di volontà. È possibile specificare un LWT messaggio 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 MQTT DISCONNECT messaggio, il broker non pubblicherà i messaggi memorizzati. LWT In tutti gli altri casi, i messaggi verranno inviati. LWT Per un elenco completo degli scenari di disconnessione in cui il broker invierà i LWT messaggi, consulta Eventi di connessione/disconnessione.

Usando connectAttributes

ConnectAttributesconsentono di specificare quali attributi si desidera utilizzare nel messaggio di connessione nelle IAM politiche, ad esempio PersistentConnect eLastWill. 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 persistente nella IAM politica se si desidera averne una.

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

MQTT5 funzionalità supportate

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 MQTT specifiche

Sottoscrizioni condivise

AWS IoT Core supporta gli abbonamenti condivisi 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. Le sottoscrizioni condivise possono bilanciare efficacemente il carico MQTT dei messaggi tra diversi 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 le sottoscrizioni condivise utilizzando il AWS IoT MQTT client nella AWS IoT console, consulta. Test degli MQTT abbonamenti condivisi nel client Per ulteriori informazioni sulle sottoscrizioni condivise, vedere Sottoscrizioni condivise della MQTTv5 specifica 2.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 MQTTsessioni persistenti.

Codice motivo su tutti ACKs

È 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 i codici dei MQTT motivi. Per un elenco completo dei codici MQTT motivo, vedere le specifiche della MQTT versione 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 dall'abbonato abbia un aggiornamento MEI pari a 0. Questo perché non appena il tempo rimanente è pari o inferiore a 999 ms, verrà aggiornato a 0.

Nel 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.

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

Altre 5 funzionalità MQTT

Disconnessione server

Quando si verifica una disconnessione, il server può inviare in modo proattivo DISCONNECT al client un messaggio di notifica della 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.

MQTT5 proprietà

MQTTLe 5 proprietà sono importanti aggiunte allo MQTT standard per supportare nuove MQTT 5 funzionalità come Session Expiry e il pattern Request/Response. In AWS IoT Core, puoi creare regole in grado di inoltrare le proprietà nei messaggi in uscita o utilizzare HTTPPublish per pubblicare MQTT messaggi con alcune delle nuove proprietà.

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

MQTTcodici di motivo

MQTT5 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 le specifiche di MQTT5.

AWS IoT differenze rispetto alle MQTT specifiche

L'implementazione del broker di messaggi si basa sulla specifica MQTTv3.1.1 e sulla specifica MQTT v5.0, ma differisce dalle specifiche nei seguenti modi: