Recursos MQTT suportados pelo agente MQTT da Grade de Eventos do Azure

O Transporte de Telemetria de Enfileiramento de Mensagens (MQTT) é um protocolo de transporte de mensagens de publicação-assinatura projetado para ambientes restritos. O MQTT é eficiente, escalável e confiável, o que o torna popular para comunicação em cenários de Internet das Coisas (IoT). O broker MQTT suporta clientes que publicam e assinam mensagens sobre MQTT v3.1.1, MQTT v3.1.1 sobre WebSocket, MQTT v5 e MQTT v5 sobre WebSocket. O broker MQTT também suporta comunicação entre versões MQTT (MQTT 3.1.1 e MQTT 5).

O agente MQTT na Grade de Eventos do Azure também oferece suporte a dispositivos e serviços que enviam mensagens MQTT por HTTPS, simplificando a integração com clientes não MQTT. O Event Grid permite enviar mensagens MQTT para a nuvem para análise de dados, armazenamento e visualizações, entre outros casos de uso. Esta funcionalidade está atualmente em pré-visualização.

O MQTT v5 introduziu muitas melhorias em relação ao MQTT v3.1.1 para oferecer uma comunicação mais perfeita, transparente e eficiente. E acrescentou:

• Melhor relatório de erros.
• Comunicação mais transparente com os clientes por meio de recursos como propriedades do usuário e tipo de conteúdo.
• Mais controlo para os clientes sobre a comunicação através de funcionalidades como a mensagem e a expiração da sessão.
• Padrões importantes padrão, como o padrão solicitação-resposta.

Fluxo de conexão

Seus clientes MQTT devem se conectar através do Transport Layer Security (TLS) 1.2 ou TLS 1.3. As tentativas de ignorar esta etapa falham com a conexão.

Quando você se conectar ao broker MQTT, use as seguintes portas durante a comunicação pelo MQTT:

• MQTT v3.1.1 e MQTT v5 na porta TCP 8883
• MQTT v3.1.1 sobre WebSocket e MQTT v5 sobre WebSocket na porta TCP 443

O pacote CONNECT deve incluir as seguintes propriedades:

• O ClientId campo é obrigatório e deve incluir o nome da sessão do cliente. O nome da sessão precisa ser exclusivo em todo o namespace. Você pode usar o nome de autenticação do cliente como o nome da sessão se cada cliente estiver usando uma sessão por cliente. Se um cliente estiver usando várias sessões, ele precisará usar valores diferentes para ClientId cada uma de suas sessões.
• O Username campo é obrigatório se você não selecionou um valor durante a criação do alternativeAuthenticationNameSources namespace. Nesse caso, você precisa fornecer o Username nome de autenticação do seu cliente no campo. Esse nome precisa corresponder ao nome de autenticação fornecido e ao valor no campo de certificado do cliente especificado durante a criação do recurso do cliente.

Saiba mais sobre a autenticação de cliente.

Suporte a várias sessões

O suporte a várias sessões permite que seus clientes MQTT de aplicativos tenham uma implementação mais escalável e confiável, conectando-se ao broker MQTT com várias sessões ativas ao mesmo tempo.

Configuração do namespace

Antes de usar esse recurso, você precisa configurar o namespace para permitir várias sessões por cliente. Para configurar várias sessões por cliente no portal do Azure, siga estas etapas:

1. Vá para seu namespace no portal do Azure.
2. Em Configuração, altere o valor de Máximo de sessões de cliente por nome de autenticação para o número de sessões por cliente que pretende.
3. Selecione Aplicar.

Fluxo de conexão

Os pacotes CONNECT para cada sessão devem incluir as seguintes propriedades:

• Forneça a propriedade no pacote CONNECT para indicar o nome de Username autenticação do cliente.
• Forneça a ClientID propriedade no pacote CONNECT para significar o nome da sessão, como se houver um ou mais valores para a ID do cliente para cada nome de usuário.

Por exemplo, as seguintes combinações de Username e ClientId no pacote CONNECT permitem que o cliente Mgmt-application se conecte ao broker MQTT em três sessões independentes:

• Primeira sessão:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session1
• Segunda sessão:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session2
• Terceira sessão:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session3

Para obter mais informações, consulte Estabelecer várias sessões para um único cliente.

Manipular sessões

• Se um cliente tentar assumir a sessão ativa de outro cliente apresentando seu nome de sessão com um nome de autenticação diferente, sua solicitação de conexão será rejeitada com um erro não autorizado. Por exemplo, se o cliente B tentar se conectar à sessão 123 atribuída naquele momento para o cliente A, a solicitação de conexão do cliente B será rejeitada. No entanto, se o mesmo cliente tentar se reconectar com os mesmos nomes de sessão e o mesmo nome de autenticação, ele poderá assumir a sessão existente.
• Se um recurso de cliente for excluído sem encerrar sua sessão, outros clientes não poderão usar seu nome de sessão até que a sessão expire. Por exemplo, se o cliente B cria uma sessão com o nome de sessão 123 e, em seguida, o cliente B é excluído, o cliente A não pode se conectar à sessão 123 até que ela expire.
• O limite para o número de sessões por cliente aplica-se a sessões online e offline em qualquer momento. Por exemplo, considere um namespace com o máximo de sessões de cliente por nome de autenticação definido como 1. O cliente A se conecta com uma sessão persistente 123 e, em seguida, é desconectado. O cliente A não pode se conectar a uma nova sessão 456 porque sua sessão 123 ainda está ativa, mesmo que esteja offline. Assim, recomendamos que o mesmo cliente sempre se reconecte com os mesmos nomes de sessão estática, em vez de gerar um novo nome de sessão a cada reconexão.

Recursos do MQTT

O agente MQTT Event Grid suporta os seguintes recursos MQTT.

Quality of Service

O broker MQTT suporta os níveis 0 e 1 de Qualidade de Serviço (QoS), que definem a garantia de entrega de mensagens em pacotes PUBLISH e SUBSCRIBE entre clientes e o broker MQTT.

• QoS 0 garante entrega no máximo uma vez: o assinante não reconhece mensagens com QoS 0 e o editor não as retransmite.
• A QoS 1 garante a entrega pelo menos uma vez: o assinante reconhece as mensagens e o editor as retransmite se elas não forem reconhecidas.

A QoS permite que seus clientes controlem a eficiência e a confiabilidade da comunicação.

Sessões persistentes

O broker MQTT suporta sessões persistentes para MQTT v3.1.1 para que o broker MQTT preserve informações sobre a sessão de um cliente quando ele é desconectado para garantir a confiabilidade da comunicação. Estas informações incluem as subscrições do cliente e mensagens QoS 1 perdidas ou não reconhecidas. Os clientes podem configurar uma sessão persistente definindo o cleanSession sinalizador no pacote CONNECT como false.

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

O MQTT v5 introduziu os recursos de início limpo e expiração da sessão como uma melhoria em relação ao MQTT v3.1.1 no tratamento da persistência da sessão. O início limpo permite que um cliente inicie uma nova sessão com o broker MQTT depois de descartar quaisquer dados da sessão anterior. A expiração da sessão permite que um cliente informe o broker MQTT quando uma sessão inativa for considerada expirada e removida automaticamente.

No pacote CONNECT, um cliente pode definir o sinalizador Clean Start como true. Um cliente também pode definir um curto intervalo de expiração da sessão por motivos de segurança ou para evitar possíveis conflitos de dados que possam ter ocorrido durante a sessão anterior. Um cliente também pode definir o Clean Start sinalizador como false ou um intervalo de expiração de sessão longo para garantir a confiabilidade e a eficiência das sessões persistentes.

Configuração do intervalo máximo de expiração da sessão

Você pode configurar o intervalo máximo de expiração de sessão permitido para todos os clientes que se conectam ao namespace Grade de Eventos. Para clientes MQTT v3.1.1, o limite configurado é aplicado como o intervalo de expiração de sessão padrão para todas as sessões persistentes. Para clientes MQTT v5, o limite configurado é aplicado como o valor máximo para a propriedade de intervalo de expiração de sessão no pacote CONNECT. Qualquer valor que exceda o limite é ajustado. O valor padrão para essa propriedade de namespace é uma hora e pode se estender por até oito horas. Para configurar o intervalo máximo de expiração da sessão no portal do Azure, siga estas etapas:

1. Vá para seu namespace no portal do Azure.
2. Em Configuração, altere o valor de Intervalo máximo de expiração da sessão em horas para o limite desejado.
3. Selecione Aplicar.

Estouro de sessão

O broker MQTT mantém uma fila de mensagens para cada sessão MQTT ativa que não está conectada, até que o cliente se conecte com o broker MQTT novamente para receber as mensagens na fila. Se um cliente não se conectar para receber as mensagens de QoS 1 enfileiradas, a fila de sessões acumulará mensagens até atingir seu limite de 100 mensagens ou 1 MB. Depois que a fila atingir seu limite durante a vida útil da sessão, a sessão será encerrada.

Mensagens da Última Vontade e do Testamento

O Last Will and Testament (LWT) notifica seus clientes MQTT com as desconexões abruptas de outros clientes MQTT. Você pode usar o LWT para garantir um fluxo previsível e confiável de comunicação entre clientes MQTT durante desconexões inesperadas. Esse recurso é valioso para cenários em que a comunicação em tempo real, a confiabilidade do sistema e as ações coordenadas são críticas. Os clientes que colaboram para executar tarefas complexas podem reagir a mensagens LWT uns dos outros, ajustando seu comportamento, redistribuindo tarefas ou assumindo certas responsabilidades para manter o desempenho e a estabilidade do sistema.

Para usar LWT, um cliente pode especificar a mensagem Will, o tópico Will e o restante das propriedades Will no pacote CONNECT durante a conexão. Quando o cliente se desconecta abruptamente, o broker MQTT publica a mensagem Will para todos os clientes que se inscreveram no tópico Will. Para reduzir o ruído de desconexões flutuantes, o cliente pode definir o intervalo de atraso para um valor maior que zero. Nesse caso, se o cliente se desconectar abruptamente, mas restaurar a conexão antes que o intervalo de atraso expire, a mensagem Will não será publicada.

Propriedades do utilizador

O broker MQTT suporta propriedades de usuário em pacotes MQTT v5 PUBLISH que você pode usar para adicionar pares de chave/valor personalizados no cabeçalho da mensagem para fornecer mais contexto sobre a mensagem. Os casos de uso para propriedades de usuário são versáteis. Você pode usar esse recurso para incluir a finalidade ou a origem da mensagem para que o recetor possa lidar com a mensagem sem analisar a carga útil, o que economiza recursos de computação. Por exemplo, uma mensagem com uma propriedade de usuário que indica sua finalidade como um "aviso" pode acionar uma lógica de manipulação diferente daquela com a finalidade de "informações".

Padrão de solicitação-resposta

O MQTT v5 introduziu campos no cabeçalho do pacote MQTT PUBLISH que fornecem contexto para a mensagem de resposta no padrão solicitação-resposta. Esses campos incluem um tópico de resposta e uma ID de correlação que o respondente pode usar na resposta sem configuração prévia. As informações de resposta permitem uma comunicação mais eficiente para o padrão padrão solicitação-resposta usado em cenários de comando e controle.

Intervalo de expiração da mensagem

No MQTT v5, o intervalo de expiração das mensagens permite que as mensagens tenham uma vida útil configurável. O intervalo de expiração da mensagem é definido como o intervalo de tempo entre o momento em que uma mensagem é publicada no broker MQTT e o momento em que o broker precisa descartar a mensagem não entregue. Esse recurso é útil em cenários em que as mensagens são válidas por apenas um determinado período de tempo, como comandos sensíveis ao tempo, streaming de dados em tempo real ou alertas de segurança. Ao definir um intervalo de expiração de mensagens, o broker MQTT pode remover automaticamente mensagens desatualizadas. Esta etapa garante que apenas informações relevantes estejam disponíveis para os assinantes. Se o intervalo de expiração de uma mensagem estiver definido como zero, isso significa que a mensagem nunca deve expirar.

Aliases de tópico

No MQTT v5, os aliases de tópico permitem que um cliente use um alias mais curto no lugar do nome completo do tópico na mensagem publicada. O broker MQTT mantém um mapeamento entre o alias do tópico e o nome do tópico real. Esse recurso pode economizar largura de banda de rede e reduzir o tamanho do cabeçalho da mensagem, especialmente para tópicos com nomes longos. É útil em cenários em que o mesmo tópico é repetidamente publicado em várias mensagens, como em redes de sensores. O broker MQTT suporta até 10 aliases de tópico. Um cliente pode usar um Topic Alias campo no pacote PUBLISH para substituir o nome completo do tópico pelo alias correspondente.

Controlo de fluxo

No MQTT v5, controle de fluxo refere-se ao mecanismo para gerenciar a taxa e o tamanho das mensagens que um cliente pode manipular. Para configurar o controle de fluxo, defina os Maximum Packet Size parâmetros e Receive Maximum no pacote CONNECT. O Receive Maximum parâmetro permite que o cliente limite o número de mensagens enviadas pelo broker ao número de mensagens que o cliente pode manipular. O Maximum Packet Size parâmetro define o tamanho máximo de pacotes que o cliente pode receber. O broker MQTT tem um limite de tamanho de mensagem de 512 KiB. Esse recurso garante a confiabilidade e a estabilidade da comunicação para dispositivos restritos com velocidade de processamento ou recursos de armazenamento limitados.

Confirmações negativas e pacote de desconexão iniciado pelo servidor

Para MQTT v5, o broker MQTT pode enviar confirmações negativas e pacotes de desconexão iniciados pelo servidor que fornecem ao cliente mais informações sobre falhas para entrega de mensagens ou conexão. Esses recursos ajudam o cliente a diagnosticar o motivo por trás de uma falha e tomar as ações mitigadoras apropriadas. O broker MQTT usa os códigos de motivo definidos na especificação MQTT v5.

Encomenda de mensagens

O MQTT v5 garante a entrega de mensagens em ordem dentro de cada tópico e de cada cliente quando o nível 1 de QoS é usado, o que é crucial para fluxos de trabalho que exigem integridade de sequência. É ideal para cenários como telemetria, execução de comandos e dados de séries cronológicas.

No entanto, não garante a ordenação em diferentes tópicos ou quando as mensagens são enviadas com diferentes níveis de QoS. Para saber mais, contacte-nos em askmqtt@microsoft.com.

Identificadores de cliente atribuídos

O MQTT v5 introduz suporte para identificadores de cliente atribuídos, o que permite que o broker MQTT gere e retorne um ID de cliente exclusivo quando o cliente não fornece um. O suporte do broker MQTT para esse recurso garante a integração perfeita do cliente e reduz a necessidade de os clientes gerenciarem seus próprios identificadores. É especialmente útil em cenários em que o provisionamento de clientes é dinâmico ou quando os dispositivos não têm identidade pré-configurada. Os IDs de cliente atribuídos podem ser recuperados da resposta do CONNACK e reutilizados em sessões futuras para manter uma identificação consistente.

Gerenciar o identificador do cliente e os limites de sessão no MQTT

• Os identificadores de cliente atribuídos permitem que os clientes se conectem sem especificar identificadores predefinidos, permitindo sessões temporárias ou persistentes.
• Os clientes podem evitar ser bloqueados usando intervalos de expiração de sessão curtos durante a primeira conexão e salvando o identificador de cliente atribuído para uso futuro.
• Para atualizações ou redefinições de firmware, os clientes devem manter seu identificador de cliente conhecido ou usar intervalos de expiração de sessão modestos para evitar bloqueios prolongados.
• A configuração do namespace pode aumentar os limites de sessão por cliente para minimizar interrupções durante atualizações ou reversões.

Limitações atuais

O broker MQTT está adicionando mais recursos MQTT v5 e MQTT v3.1.1 no futuro para se alinhar mais com as especificações MQTT. A lista a seguir detalha as diferenças atuais entre os recursos suportados pelo broker MQTT e as especificações MQTT.

Limitações atuais do MQTT v5

Atualmente, o MQTT v5 difere da especificação MQTT v5 das seguintes maneiras:

• As subscrições partilhadas ainda não são suportadas.
• O intervalo máximo de atraso é de 300 segundos.
• QoS máximo é 1.
• O tamanho máximo do pacote é de 512 KiB.
• Não há suporte para identificadores de assinatura.
• O alias máximo do tópico é 10. O servidor não atribui nenhum aliases de tópico para mensagens de saída no momento. Os clientes podem atribuir e usar aliases de tópico dentro do limite definido.
• CONNACK não retorna a Response Information propriedade mesmo se a solicitação CONNECT contiver a Request Response Information propriedade.
• As propriedades do usuário nos pacotes CONNECT, SUBSCRIBE, DISCONNECT, PUBACK e AUTH não são usadas pelo serviço, portanto, não são suportadas. Se qualquer uma dessas solicitações incluir propriedades de usuário, a solicitação falhará.
• Se o servidor receber um pacote PUBACK de um cliente com um código de resposta sem êxito, a conexão será encerrada.
• O máximo de Keep Alive é de 1.160 segundos.

Limitações atuais do MQTTv3.1.1

Atualmente, o MQTT v5 difere da especificação MQTT v3.1.1 das seguintes maneiras:

• QoS 2 não é suportado. Uma solicitação de publicação com um RETAIN sinalizador ou com uma QoS 2 falha e fecha a conexão.
• O máximo de Keep Alive é de 1.160 segundos.

Exemplos de código

Este repositório contém exemplos de código C#, C e Python que mostram como enviar telemetria, enviar comandos e transmitir alertas. Os certificados criados através das amostras são adequados para testes, mas não são adequados para ambientes de produção.

Conteúdo relacionado

Para saber mais sobre MQTT, consulte a especificação MQTT v5. Para saber mais sobre o broker MQTT, consulte:

• Autenticação do cliente
• Estabeleça várias sessões para um único cliente