MQTT

O MQTT (Message Queuing Telemetry Transport) é um protocolo de mensagens leve e amplamente adotado, projetado para dispositivos restritos. O suporte a AWS IoT Core para MQTT é baseado na especificação MQTT v3.1.1 e na especificação MQTT v5.0, com algumas diferenças, conforme documentado em Diferenças de AWS IoT das especificações do MQTT. Como a versão mais recente do padrão, o MQTT 5 apresenta vários recursos principais que tornam um sistema baseado em MQTT mais robusto, incluindo novos aprimoramentos de escalabilidade, relatório de erros aprimorado com respostas de código de motivo, temporizadores de expiração de mensagens e sessões e cabeçalhos de mensagens de usuário personalizados. Para obter mais informações sobre os recursos do MQTT 5 compatíveis com o AWS IoT Core, consulte Recursos compatíveis com MQTT 5. O AWS IoT Core também dá suporte para comunicação entre versões MQTT (MQTT 3 e MQTT 5). Um publicador do MQTT 3 pode enviar uma mensagem do MQTT 3 para um assinante do MQTT 5 que receberá uma mensagem de publicação do MQTT 5 e vice-versa.

O AWS IoT Core dá suporte a conexões de dispositivos que usam o protocolo MQTT sobre WSS e que são identificadas por uma ID de cliente. O SDKs de dispositivo da AWS IoT dá suporte a ambos os protocolos e são as formas recomendadas de conectar dispositivos a AWS IoT Core. Os SDKs do Dispositivo AWS IoT dão suporte às funções necessárias para dispositivos e clientes se conectarem e acessarem os serviços AWS IoT. Os Device SDKs oferecem suporte aos protocolos de autenticação exigidos pelos serviços AWS IoT e aos requisitos de ID de conexão exigidos pelos protocolos MQTT e MQTT sobre WSS. Para obter informações sobre como se conectar ao AWS IoT usando os SDKs do Dispositivo AWS e links para exemplos de AWS IoT nos idiomas com suporte, confira Conectar-se ao MQTT usando os SDKs do Dispositivo AWS IoT. Para obter mais informações sobre métodos de autenticação e os mapeamentos de porta para mensagens MQTT, consulte Protocolos, mapeamentos de porta e autenticação.

Embora seja recomendável usar os SDKs do Dispositivo AWS IoT para se conectar ao AWS IoT, eles não são obrigatórios. Porém, se você não usar os SDKs do Dispositivo AWS IoT, deverá fornecer a segurança necessária de conexão e comunicação. Os clientes devem enviar a extensão TLS de Server Name Indication (SNI) na solicitação de conexão. As tentativas de conexão que não incluem o SNI são recusadas. Para obter mais informações, consulte Segurança de transporte no AWS IoT. Clientes que usam usuários do IAM e credenciais do AWS para autenticar clientes devem fornecer a autenticação correta do Signature versão 4.

Conectar-se ao MQTT usando os SDKs do Dispositivo AWS IoT

Esta seção contém links para os SDKs do Dispositivo AWS IoT e para o código-fonte de programas de amostra que ilustram como conectar um dispositivo a AWS IoT. Os aplicativos de amostra vinculados aqui mostram como se conectar ao AWS IoT usando o protocolo MQTT e o MQTT pelo WSS.

Opções de Qualidade de serviço (QoS) do MQTT

AWS IoT e os SDKs de Dispositivo AWS IoT dão suporte aos níveis de Qualidade de Serviço (QoS) do MQTT 0 e 1. O protocolo MQTT define um terceiro nível de QoS, o nível 2, mas AWS IoT não dá suporte a ele. Apenas o protocolo MQTT dá suporte ao atributo de QoS. HTTPS dá suporte a QoS passando um parâmetro de string de consulta ?qos=qos em que o valor pode ser 0 ou 1.

Essa tabela descreve como cada nível de QoS afeta as mensagens publicadas para e pelo agente de mensagens.

Sessões persistentes do MQTT

As sessões persistentes armazenam as assinaturas e mensagens de um cliente, com uma Qualidade de Serviço (QoS) de 1, que não foram reconhecidas pelo cliente. Quando o dispositivo se reconecta a uma sessão persistente, a sessão é retomada, as assinaturas são restabelecidas e as mensagens assinadas não confirmadas que são recebidas e armazenadas antes da reconexão são enviadas ao cliente.

O processamento das mensagens armazenadas é registrado no CloudWatch e no CloudWatch Logs. Para informações sobre as entradas gravadas no CloudWatch e no CloudWatch Logs, consulte Métricas do agente de mensagens e Entrada de log em fila.

Criar uma sessão persistente

No MQTT 3, você cria uma sessão persistente do MQTT enviando uma mensagem CONNECT e definindo o sinalizador cleanSession como 0. Se nenhuma sessão existir para o cliente enviar a mensagem CONNECT, uma nova sessão persistente será criada. Se já existir uma sessão para o cliente, o cliente retomará a sessão existente. Para criar uma sessão limpa, você envia uma mensagem CONNECT e define o sinalizador cleanSession como 1, e o broker não armazenará nenhum estado da sessão quando o cliente se desconectar.

No MQTT 5, você lida com sessões persistentes definindo o sinalizador Clean Start e Session Expiry Interval. O Clean Start controla o início da sessão de conexão e o final da sessão anterior. Quando você define Clean Start =1, uma nova sessão é criada e uma sessão anterior é encerrada, se existir. Quando você define Clean Start =0, a sessão de conexão retoma uma sessão anterior, se ela existir. O intervalo de expiração da sessão controla o final da sessão de conexão. O intervalo de expiração da sessão especifica o tempo, em segundos (número inteiro de 4 bytes), em que uma sessão persistirá após a desconexão. Configuração Session Expiry interval = 0 faz com que a sessão seja encerrada imediatamente após a desconexão. Se o intervalo de expiração da sessão não for especificado na mensagem CONNECT, o padrão será 0.

No MQTT 5, se você define Clean Start = 1 e Session Expiry Interval =0, isso equivale a uma sessão limpa do MQTT 3. Se você define Clean Start = 0 e Session Expiry Interval> 0, isso equivale a uma sessão persistente do MQTT 3.

Operações durante uma sessão persistente

Os clientes usam o atributo sessionPresent na mensagem de conexão confirmada (CONNACK) para determinar se uma sessão persistente está presente. Se sessionPresent for 1, uma sessão persistente estará presente e todas as mensagens armazenadas para o cliente serão entregues ao cliente após o cliente receber a CONNACK, conforme descrito em Tráfego de mensagens após a reconexão com uma sessão persistente. Se sessionPresent for 1, o cliente não precisará se inscrever novamente. Porém, se sessionPresent for 0, nenhuma sessão persistente estará presente, e o cliente deverá se inscrever novamente nos filtros de tópico.

Depois que o cliente ingressa em uma sessão persistente, ele pode publicar mensagens e assinar filtros de tópico sem quaisquer sinalizadores adicionais em cada operação.

Tráfego de mensagens após a reconexão com uma sessão persistente

Uma sessão persistente representa uma conexão contínua entre um cliente e um agente de mensagens MQTT. Quando um cliente se conecta ao agente de mensagens usando uma sessão persistente, o agente de mensagens salva todas as inscrições que o cliente faz durante a conexão. Quando o cliente se desconecta, o agente de mensagens armazena mensagens de QoS não confirmadas e novas mensagens de QoS 1 publicadas em tópicos nos quais o cliente está inscrito. As mensagens são armazenadas conforme o limite da conta. As mensagens que excedem o limite serão descartadas. Para obter mais informações sobre os limites de mensagem persistente, consulte endpoints e cotas do AWS IoT Core. Quando o cliente se conecta novamente à sua sessão persistente, todas as inscrições são restabelecidas e todas as mensagens armazenadas são enviadas para o cliente com uma taxa máxima de 10 mensagens por segundo. No MQTT 5, se uma QoS1 de saída com o intervalo de expiração da mensagem expirar quando um cliente estiver offline, depois que a conexão for retomada, o cliente não receberá a mensagem expirada.

Após a reconexão, as mensagens armazenadas são enviadas ao cliente, a uma taxa limitada a 10 mensagens armazenadas por segundo, junto com qualquer tráfego de mensagens atual até que o limite Publish requests per second per connection seja atingido. Como a taxa de entrega das mensagens armazenadas é limitada, serão necessários vários segundos para entregar todas as mensagens armazenadas se uma sessão tiver mais de 10 mensagens armazenadas para entregar após a reconexão.

Encerrar uma sessão persistente

As sessões persistentes podem terminar das seguintes maneiras:

No MQTT 3, o valor padrão do tempo de expiração das sessões persistentes é de uma hora, e isso se aplica a todas as sessões na conta.

No MQTT 5, você pode definir o intervalo de expiração da sessão para cada sessão nos pacotes CONNECT e DISCONNECT.

Para o intervalo de expiração da sessão no pacote DISCONNECT:

Reconexão após a expiração de uma sessão persistente

Se um cliente não se reconectar à sessão persistente antes que ela expire, a sessão terminará e as mensagens armazenadas serão descartadas. Quando um cliente se reconecta depois que a sessão expira com um sinalizador cleanSession para 0, o serviço cria uma nova sessão persistente. As assinaturas ou mensagens da sessão anterior não estão disponíveis para esta sessão porque foram descartadas quando a sessão anterior expirou.

Cobranças persistentes de mensagens de sessão

As mensagens são cobradas de seu Conta da AWS quando o agente de mensagens envia uma mensagem para um cliente ou para uma sessão persistente off-line. Quando um dispositivo offline com uma sessão persistente se reconecta e retoma a sessão, as mensagens armazenadas são entregues ao dispositivo e cobradas novamente em sua conta. Para obter mais informações sobre a definição de preço de mensagem, consulte Preços do AWS IoT Core – Mensagens.

O tempo de expiração padrão da sessão persistente de uma hora pode ser aumentado usando o processo padrão de aumento de limite. Observe que aumentar o tempo de expiração da sessão pode aumentar suas cobranças de mensagens, pois o tempo adicional pode permitir que mais mensagens sejam armazenadas no dispositivo off-line e essas mensagens adicionais seriam cobradas em sua conta conforme a taxa de mensagens padrão. O tempo de expiração da sessão é aproximado e uma sessão pode persistir por até 30 minutos a mais do que o limite da conta; porém, uma sessão não será menor que o limite da conta. Para obter mais informações sobre limites de sessão, consulte AWS Service Quotas.

Mensagens retidas do MQTT

AWS IoT Core dá suporte ao sinalizador RETAIN descrito no protocolo MQTT. Quando um cliente define o sinalizador RETAIN em uma mensagem MQTT que ele publica, o AWS IoT Core salva a mensagem. Em seguida, ele pode ser enviado para novos assinantes, recuperado chamando a operação GetRetainedMessage e visualizado no console do AWS IoT.

Tarefas comuns com mensagens retidas pelo MQTT em AWS IoT Core

O AWS IoT Core salva mensagens MQTT com o sinalizador RETAIN definido. Essas mensagens retidas são enviadas a todos os clientes que se inscreveram no tópico, como uma mensagem MQTT normal, e também são armazenadas para serem enviadas aos novos assinantes do tópico.

As mensagens retidas pelo MQTT exigem ações políticas específicas para autorizar os clientes a acessá-las. Para obter exemplos de uso de políticas de mensagens retidas, consulte Exemplos de políticas de mensagens retidas.

Esta seção descreve operações comuns que envolvem mensagens retidas.

Faturamento e mensagens retidas

A publicação de mensagens com a bandeira RETAIN definida por um cliente, usando o console do AWS IoT ou chamando Publish gera cobranças adicionais de mensagens descritas em AWS IoT CorePreços – Mensagens.

A recuperação de mensagens retidas por um cliente, usando o console do AWS IoT ou chamando GetRetainedMessagegera cobranças de mensagens, além das cobranças normais de uso da API. As cobranças adicionais estão descritas em AWS IoT CorePreços – Mensagens.

As mensagens de Testamento do MQTT publicadas quando um dispositivo se desconecta inesperadamente geram cobranças de mensagens descritas em AWS IoT CorePreços - Mensagens.

Para obter mais informações sobre custos de mensagens, consulte Preços do AWS IoT Core – Mensagens.

Comparar mensagens retidas do MQTT e sessões persistentes do MQTT

Mensagens retidas e sessões persistentes são recursos padrão do MQTT que possibilitam que os dispositivos recebam mensagens publicadas enquanto eles estavam off-line. As mensagens retidas podem ser publicadas de sessões persistentes. Esta seção descreve os principais aspectos desses recursos e como eles funcionam juntos.

Para obter mais informações sobre sessões persistentes, consulte Sessões persistentes do MQTT.

Com as mensagens retidas, o cliente de publicação determina se uma mensagem deve ser retida e entregue a um dispositivo após a conexão, independentemente de ter tido uma sessão anterior ou não. A escolha de armazenar uma mensagem é feita pelo publicador e a mensagem armazenada é entregue a todos os clientes atuais e futuros que assinam com assinaturas de QoS 0 ou QoS 1. As mensagens retidas mantêm apenas uma mensagem sobre um determinado tópico por vez.

Quando uma conta armazena o número máximo de mensagens retidas, AWS IoT Core retorna uma resposta limitada às mensagens publicadas com RETAIN definido e cargas superiores a 0 bytes até que algumas mensagens retidas sejam excluídas e a contagem de mensagens retidas fique abaixo do limite.

O MQTT reteve mensagens e sombras do dispositivo AWS IoT

Tanto as mensagens retidas quanto as sombras do dispositivo retêm dados de um dispositivo, mas se comportam de maneira diferente e servem a propósitos diferentes. Esta seção descreve suas semelhanças e diferenças.

Mensagens de Último testamento e Testamento (LWT, Last Will and Testament) do MQTT

Último testamento e Testamento (LWT, Last Will and Testament) é um atributo do MQTT. Com o LWT, os clientes podem especificar uma mensagem que o corretor publicará em um tópico definido pelo cliente e enviará a todos os clientes que se inscreveram no tópico quando ocorrer uma desconexão não iniciada. A mensagem que os clientes especificam é chamada de mensagem LWT ou Mensagem de testamento, e o tópico que os clientes definem é chamado de Tópico de testamento. Você pode especificar uma mensagem LWT quando um dispositivo se conecta ao agente. Essas mensagens podem ser retidas definindo o sinalizador Will Retain no campo Connect Flag bits durante a conexão. Por exemplo, se o sinalizador Will Retain estiver definido como 1, uma mensagem de testamento será armazenada no corretor no tópico de testamento associado. Para obter mais informações, consulte Mensagens de Will.

O corretor armazenará as mensagens de testamento até que ocorra uma desconexão não iniciada. Quando isso acontecer, o corretor publicará as mensagens para todos os clientes que se inscreveram no Tópico de testamento para notificar a desconexão. Se o cliente se desconectar do agente com uma desconexão iniciada pelo cliente usando a mensagem MQTT DISCONNECT, o broker não publicará as mensagens LWT armazenadas. Em todos os outros casos, as mensagens LWT serão enviadas. Para obter uma lista completa dos cenários de desconexão em que o agente enviará as mensagens LWT, confira Eventos de conexão/desconexão.

Uso do ConnectAttributes

O ConnectAttributes permite que você especifique quais atributos deseja usar na mensagem de conexão em suas políticas do IAM, como PersistentConnect e LastWill. Com o ConnectAttributes, você pode criar políticas que não dão aos dispositivos acesso a novos recursos por padrão, o que pode ser útil se um dispositivo for comprometido.

O connectAttributes oferece suporte aos seguintes recursos:

Por padrão, Sua política tem uma conexão não persistente e não há atributos passados para essa conexão. Você deve especificar uma conexão persistente em sua política do IAM se quiser ter uma.

Para exemplos de ConnectAttributes, consulte Exemplos da política de conexão.

Recursos compatíveis com o MQTT 5

O suporte do AWS IoT Core para o MQTT 5 é baseado na especificação MQTT v5.0, com algumas diferenças, conforme documentado em Diferenças de AWS IoT das especificações do MQTT.

Assinaturas compartilhadas

O AWS IoT Core é compatível com assinaturas compartilhadas para MQTT 3 e MQTT 5. As assinaturas compartilhadas permitem que vários clientes compartilhem uma assinatura de um tópico e somente um cliente receberá mensagens publicadas nesse tópico usando uma distribuição randomizada. As assinaturas compartilhadas podem efetivamente balancear a carga das mensagens MQTT entre vários assinantes. Por exemplo, digamos que você tenha 1.000 dispositivos publicando no mesmo tópico e 10 aplicativos de back-end processando essas mensagens. Nesse caso, os aplicativos de back-end podem se inscrever no mesmo tópico e cada um receberá mensagens publicadas aleatoriamente pelos dispositivos no tópico compartilhado. Isso é efetivamente “compartilhar” a carga dessas mensagens. As assinaturas compartilhadas também permitem uma melhor resiliência. Quando qualquer aplicativo de back-end é desconectado, o agente distribui a carga para os assinantes restantes no grupo.

Para usar assinaturas compartilhadas, os clientes assinam um filtro de tópicos de uma assinatura compartilhada da seguinte maneira:

$share/{ShareName}/{TopicFilter}

As assinaturas que têm o mesmo {ShareName}/{TopicFilter} pertencem ao mesmo grupo de assinaturas compartilhadas. Você pode criar vários grupos de assinaturas compartilhadas e não exceder o limite de assinaturas compartilhadas por grupo. Para obter mais informações, consulte Endpoints e cotas do AWS IoT Core na Referência geral da AWS.

As tabelas a seguir comparam assinaturas não compartilhadas e as assinaturas compartilhadas:

sports/tennis
sports/#

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

Fluxo de assinaturas não compartilhadas	Fluxo de assinaturas compartilhadas

Observações importantes sobre o uso de assinaturas compartilhadas

Para obter mais informações sobre limites de Assinatura compartilhada, consulte Endpoints e cotas do AWS IoT Core na Referência geral da AWS. Para testar assinaturas compartilhadas usando o cliente MQTT AWS IoT no console do AWS IoT, confira Testar assinaturas compartilhadas no cliente MQTT. Para obter mais informações sobre assinaturas compartilhadas, confira Assinaturas compartilhadas da especificação MQTtv5.0.

Início limpo e expiração da sessão

Você pode usar o Clean Start e o Session Expiry para lidar com suas sessões persistentes com mais flexibilidade. Um sinalizador Clean Start indica se a sessão deve começar sem usar uma sessão existente. O intervalo de expiração da sessão indica por quanto tempo manter a sessão após uma desconexão. O intervalo de expiração da sessão pode ser modificado na desconexão. Para obter mais informações, consulte Sessões persistentes do MQTT.

Código de motivo em todos os ACKs

Você pode depurar ou processar mensagens de erro com mais facilidade usando os códigos de motivo. Os códigos de motivo são retornados pelo agente de mensagens com base no tipo de interação com o corretor (Assinar, Publicar, Confirmar). Para obter mais informações, consulte Códigos de motivo do MQTT. Para obter uma lista completa dos códigos de motivo do MQTT, consulte a especificação do MQTT v5.

Aliases de tópicos

Você pode substituir o nome de um tópico por um alias de tópico, que é um número inteiro de dois bytes. O uso de aliases de tópicos pode otimizar a transmissão de nomes de tópicos para reduzir potencialmente os custos de dados em serviços de dados medidos. AWS IoT Core tem um limite padrão de 8 aliases de tópicos. Para obter mais informações, consulte Endpoints e cotas do AWS IoT Core na Referência geral da AWS.

Expiração da mensagem

Você pode adicionar valores de expiração de mensagens às mensagens publicadas. Esses valores representam o intervalo de expiração da mensagem em segundos. Se as mensagens não tiverem sido enviadas aos assinantes dentro desse intervalo, a mensagem expirará e será removida. Se você não definir o valor de expiração da mensagem, ela não expirará.

Na saída, o assinante receberá uma mensagem com o tempo restante no intervalo de expiração. Por exemplo, se uma mensagem de publicação de entrada tiver uma expiração de 30 segundos e for encaminhada para o assinante após 20 segundos, o campo de expiração da mensagem será atualizado para 10. É possível que a mensagem recebida pelo assinante tenha um MEI atualizado de 0. Isso porque, assim que o tempo restante for de 999 ms ou menos, ele será atualizado para 0.

No AWS IoT Core, o intervalo mínimo de expiração da mensagem é 1. Se o intervalo for definido como 0 do lado do cliente, ele será ajustado para 1. O intervalo máximo de expiração da mensagem é 604800 (7 dias). Qualquer valor maior que isso será ajustado para o valor máximo.

Na comunicação entre versões, o comportamento da expiração da mensagem é decidido pela versão MQTT da mensagem de publicação de entrada. Por exemplo, uma mensagem com expiração de mensagem enviada por uma sessão conectada via MQTT5 pode expirar para dispositivos inscritos com sessões MQTT3. A tabela abaixo mostra como a expiração de mensagens oferece suporte aos seguintes tipos de mensagens publicadas:

Outros recursos do MQTT 5

Desconexão do servidor

Quando ocorre uma desconexão, o servidor pode enviar proativamente ao cliente um DISCONNECT para notificar o encerramento da conexão com um código de motivo para a desconexão.

Resposta/solicitação

Os editores podem solicitar que uma resposta seja enviada pelo destinatário para um tópico especificado pelo publicador no momento do recebimento.

Tamanho máximo do pacote

O cliente e o servidor podem especificar de modo independente o tamanho máximo do pacote ao qual eles dão suporte.

Formato de carga útil e tipo de conteúdo

Você pode especificar o formato da carga útil (binário, texto) e o tipo de conteúdo quando uma mensagem é publicada. Eles são encaminhados para o destinatário da mensagem.

Propriedades do MQTT 5

As propriedades do MQTT 5 são adições importantes ao padrão MQTT para oferecer suporte aos novos recursos do MQTT 5, como a expiração da sessão e o padrão de solicitação/resposta. No AWS IoT Core, você pode criar regras que podem encaminhar as propriedades em mensagens de saída ou usar HTTP Publish para publicar mensagens MQTT com algumas das novas propriedades.

A tabela a seguir lista todas as propriedades do MQTT 5 compatíveis com AWS IoT Core.

Códigos de motivo do MQTT

O MQTT 5 introduz relatório de erros aprimorado com respostas de código de motivo. O AWS IoT Core pode retornar códigos de motivo, incluindo, entre outros, os seguintes, agrupados por pacotes. Para obter uma lista completa dos códigos de motivo com suporte no MQTT 5, confira especificações do MQTT v5.

Diferenças de AWS IoT das especificações do MQTT

A implementação do agente de mensagens é baseada na especificação MQTT v3.1.1 e na Especificação MQTT v5.0, mas difere das especificações das seguintes maneiras: