Protocolo MQTT: imersão conceitual

O protocolo MQTT (Transporte de Telemetria de Enfileiramento de Mensagens) é usado há muitos anos, mas agora é especialmente relevante devido ao crescimento explosivo da IoT: dispositivos industriais e de consumidor implementam redes distribuídas e computação de borda, e dispositivos com transmissão contínua de dados estão se tornando parte do cotidiano da vida.

Isso significa que protocolos leves, abertos e acessíveis se tornarão ainda mais importantes ao longo do tempo. Este artigo fornece uma imersão conceitual no MQTT: como funciona, como é usado agora e como será usado no futuro.

Pequena introdução


O MQTT é um protocolo de mensagens com base em assinante do editor (pub / sub). A versão inicial em 1999 foi publicada por Andy Stanford-Clark, da IBM, e Arlene Nipper, da Cirrus Link. Eles visualizaram o MQTT como uma maneira de manter a comunicação entre máquinas em redes com largura de banda limitada ou comunicações imprevisíveis. Uma das primeiras opções para seu uso foi garantir que fragmentos do oleoduto estivessem em contato um com o outro e com os links centrais via satélites.

Dadas as condições operacionais adversas, o protocolo é pequeno e leve. É ideal para dispositivos de baixa potência e com autonomia limitada da bateria. Agora, eles incluem smartphones onipresentes e o número crescente de sensores e dispositivos conectados.

Assim, o MQTT tornou-se um protocolo para transmitir dados entre dispositivos com potência limitada da CPU e / ou duração da bateria, bem como para redes com largura de banda cara ou baixa, estabilidade imprevisível ou alta latência. É por isso que o MQTT é conhecido como o veículo ideal para a IoT. Ele é construído no protocolo TCP / IP, mas existe uma ramificação MQTT-SN para trabalhar via Bluetooth, UDP, ZigBee e outras redes de IoT que não sejam TCP / IP.

O MQTT não é o único protocolo de mensagens de pub / sub em tempo real de seu tipo, mas já se espalhou em vários ambientes que dependem das comunicações máquina a máquina. Entre seus colegas estão o Protocolo de Mensagens de Aplicativos da Web , o Protocolo de Mensagens Orientadas a Texto de Streaming e o Protocolo de Enfileiramento de Mensagens Alternativo .

O MQTT é a escolha lógica para desenvolvedores que desejam criar aplicativos com funcionalidade confiável e ampla compatibilidade com dispositivos e aplicativos conectados à Internet, incluindo navegadores, smartphones e dispositivos de IoT.

Como o MQTT funciona: o básico


O sistema de comunicação construído no MQTT consiste em um servidor publicador, um servidor intermediário e um ou mais clientes. O editor não exige nenhuma configuração para o número ou o local dos assinantes que recebem mensagens. Além disso, os assinantes não precisam ajustar para um editor específico. Pode haver vários intermediários de mensagens no sistema.



O MQTT fornece uma maneira de criar uma hierarquia de canais de comunicação - um tipo de ramificação com folhas. Sempre que o editor tiver novos dados para distribuir aos clientes, a mensagem será acompanhada de uma nota de controle de entrega. Clientes de nível superior podem receber cada mensagem, enquanto clientes de nível inferior podem receber mensagens relacionadas a apenas um ou dois canais básicos, "ramificações" na parte inferior da hierarquia. Isso facilita a troca de informações que variam em tamanho de dois bytes a 256 megabytes .

Um exemplo de como você pode configurar o cliente para conectar-se através do broker MQTT :

var options = { keepalive: 60, username: 'FIRST_HALF_OF_API_KEY', password: 'SECOND_HALF_OF_API_KEY', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); 

Quaisquer dados publicados ou recebidos pelo broker MQTT serão codificados em formato binário, pois o MQTT é um protocolo binário. Isso significa que, para obter o conteúdo original, você precisa interpretar a mensagem. Aqui está o que parece com Ably e JavaScript:

 var ably = new Ably.Realtime('REPLACE_WITH_YOUR_API_KEY'); var decoder = new TextDecoder(); var channel = ably.channels.get('input'); channel.subscribe(function(message) { var command = decoder.decode(message.data); }); 

Às vezes, os intermediários do MQTT podem acumular mensagens relacionadas a canais que não possuem assinantes atuais. Nesse caso, as mensagens serão descartadas ou salvas, dependendo das instruções na mensagem de controle. Isso é útil nos casos em que novos assinantes podem precisar do ponto de dados gravado mais recentemente, em vez de aguardar o próximo envio.

Vale ressaltar que o MQTT transmite credenciais de segurança em texto não criptografado, caso contrário, as funções de autenticação ou segurança não são suportadas. É aqui que a estrutura SSL entra em jogo , ajudando a proteger as informações transmitidas contra interceptação ou adulteração.

Além disso, no MQTT, você pode usar a autenticação Ably em tokens se não desejar divulgar sua chave de API para o cliente MQTT real (no caso de MQTT sem SSL, são necessários tokens para impedir a transferência de chaves de API em texto não criptografado). Exemplo de autenticação de token:

 var options = { keepalive: 60, username: INSERT_TOKEN_HERE, password: '', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); client.subscribe("[mqtt]tokenevents", { /* Create a new token called 'NEW_TOKEN' */ client.end(); options.username = NEW_TOKEN; client = mqtt.connect('mqtts:mqtt.ably.io', options); }); 

Funcionalidade MQTT: imersão mais profunda


De acordo com a IBM , o MQTT possui as seguintes propriedades:

  • Neutro no conteúdo da mensagem
  • Ideal para comunicações um-para-muitos distribuídas e aplicativos desconectados
  • Equipado com a função LWT (Last Will and Testament, “last will and testament”) para notificar as partes sobre uma desconexão anormal do cliente
  • Confia no TCP / IP para tarefas básicas de comunicação
  • Projetado para entregar mensagens usando os modelos "no máximo uma vez", "pelo menos uma vez" e "exatamente uma vez"

Um membro do sistema MQTT pode assumir a função de publicador, consumidor ou ambas as funções ao mesmo tempo.

Uma das características distintivas do MQTT é seu entendimento exclusivo dos canais: cada um deles é tratado como um caminho de arquivo, por exemplo:

 channel = "user/path/channel" 

Os canais garantem que todo cliente receba mensagens destinadas a ele. Ao tratar os canais como caminhos de arquivo, o MQTT executa todos os tipos de funções de comunicação úteis, incluindo a filtragem de mensagens com base em onde - em qual nível ou em qual filial - os clientes se inscrevem no caminho do arquivo.

Formato de mensagem MQTT


Veja os dois componentes que compõem cada mensagem do MQTT:

  • Byte 1 : contém o tipo de mensagem (solicitação de conexão do cliente, confirmação de assinatura, solicitação de ping etc.), um sinalizador de duplicação, instruções para salvar mensagens e informações sobre a qualidade de serviço (QoS).
  • Byte 2 : contém informações sobre o tamanho restante da mensagem, incluindo a carga útil e quaisquer dados no cabeçalho de uma variável opcional.

O sinalizador QoS no byte 1 merece atenção especial, pois está subjacente à funcionalidade variável suportada pelo MQTT. Os sinalizadores de QoS contêm os seguintes valores com base na intenção e urgência da mensagem:

  • 0 = não mais de uma vez: o servidor é acionado e esquece. As mensagens podem ser perdidas ou duplicadas.
  • 1 = pelo menos uma vez: o destinatário confirma a entrega. As mensagens podem ser duplicadas, mas a entrega é garantida
  • 2 = exatamente uma vez: o servidor fornece entrega. As mensagens chegam exatamente uma vez sem perda ou duplicação

Vejamos como usar os diferentes níveis de QoS em dispositivos de IoT e outros aplicativos.

Onde posso usar o MQTT?


Como os aplicativos de IoT estão sendo implementados em grande escala, o MQTT surgiu como uma maneira aberta, simples e escalável de implantar computação distribuída e funcionalidade de IoT para uma base de usuários mais ampla - tanto no mercado industrial quanto no consumidor.

Como mencionado acima, o MQTT é um protocolo de mensagens leve desenvolvido para redes e dispositivos não confiáveis ​​com restrições na fonte de alimentação e na CPU. No entanto, isso não significa que a conexão com a perda potencial de pacotes seja sua única aplicação. O MQTT fornece vários níveis de serviço para vários tipos de infraestrutura de IoT, desde a repetição da amostragem de dados até o gerenciamento de máquinas industriais:

  • Dados do sensor ambiental : Como já mencionado, o MQTT suporta o modelo de entrega de mensagens “não mais que uma vez”. Em redes com cobertura parcial ou alta latência, isso significa que as informações podem ser perdidas ou duplicadas . Nas áreas em que os sensores remotos registram e transmitem dados em intervalos especificados, isso não é um problema, pois novas leituras são recebidas regularmente. Os sensores em ambientes remotos geralmente são dispositivos de baixa energia, tornando o MQTT a solução ideal para sensores de IoT com uma prioridade de transferência de dados relativamente baixa.
  • Dados de desempenho da máquina : para responder rapidamente a problemas e evitar tempo de inatividade. Por exemplo, uma instalação de energia eólica precisa fornecer os indicadores atuais de desempenho às equipes locais, mesmo antes que essas informações cheguem ao data center. Em tais situações, a entrega de mensagens "pelo menos uma vez" garante que os especialistas apropriados sejam notados imediatamente pelos especialistas necessários, mesmo que cheguem como duplicados. Isso é importante para comunicações com máquinas de alta prioridade.
  • Sistemas de faturamento : existem ainda mais mensagens precisas e prioritárias que precisam ser processadas corretamente. Em situações de negócios em que a duplicação de registros é inaceitável, inclusive em sistemas de cobrança, o sinalizador de QoS "exatamente uma vez" é útil. Isso elimina a duplicação ou perda de pacotes nos sistemas de cobrança ou cobrança, reduz o número de anomalias e contradições desnecessárias, conforme combinado.

Quando não usar o MQTT?


Os desenvolvedores têm uma ampla seleção de protocolos para projetar e implantar canais de comunicação IoT bidirecional, incluindo MQTT, HTTP, CoAP , WebSockets (se a CPU / bateria permitir) e outros. Se o MQTT é a melhor opção depende do hardware e da tarefa do aplicativo.

Projetado para ambientes com largura de banda extremamente baixa, o protocolo MQTT pode ser bastante inflexível em sua busca para salvar todos os bytes. Por exemplo, a especificação define apenas cinco mensagens de erro com as quais o servidor pode rejeitar a conexão (por exemplo, um nome de usuário / senha inválido ou uma versão inaceitável do protocolo). Se o servidor quiser apontar para algum outro erro, está sem sorte. Pior ainda, se ocorrer um erro após o início da conexão, não há mecanismo para relatar um erro. O servidor pode apenas encolher os ombros e encerrar abruptamente a conexão TCP, deixando o cliente sem a menor idéia do motivo pelo qual ele foi descartado (e sem nenhuma maneira de distinguir uma desconexão deliberada de um problema temporário na rede). Para pessoas acostumadas aos protocolos pub / sub mais flexíveis e fáceis de depurar (embora menos econômicos em termos de largura de banda), essa abordagem espartana pode parecer um pouco primitiva.

O MQTT é frequentemente referido juntamente com o HTTP; portanto, o Google conduziu um estudo comparando-os em tempo de resposta, volume de tráfego e outros atributos importantes para os desenvolvedores. O MQTT ficou em primeiro lugar nos testes do Google, mas apenas nas condições em que a conexão pode ser reutilizada para enviar várias cargas úteis.

HTTP e MQTT são uma boa opção para aplicativos de IoT devido à quantidade relativamente pequena de tráfego, pouca bateria e requisitos de memória.

O CoAP é outro protocolo frequentemente comparado ao MQTT para o desenvolvimento de sistemas de IoT. Eles são semelhantes, mas existem diferenças visíveis. O MQTT é um protocolo muitos-para-muitos, enquanto o CoAP é basicamente um protocolo um-para-um para comunicação entre um servidor e um cliente. Ao mesmo tempo, o CoAP fornece recursos de metadados, descoberta e negociação de conteúdo que o MQTT não possui .

Nos casos em que os clientes devem receber apenas dados, os Eventos Enviados pelo Servidor também são uma opção adequada.

Como configurar rapidamente o MQTT


O repositório MQTT no GitHub possui uma extensa lista de bibliotecas MQTT de código aberto em vários idiomas. A seguir estão dois exemplos de customização usando o broker MQTT de código aberto, a biblioteca JavaScript e a biblioteca .NET.

Eclipse Mosquitto - broker MQTT de código aberto


O Eclipse Mosquitto é um broker de mensagens de código aberto (EPL / EDL) que implementa os protocolos MQTT versão 5.0, 3.1.1 e 3.1. O Mosquitto é leve e adequado para uso em todos os dispositivos: de computadores de placa única de baixo consumo a servidores de pleno direito.

MQTT.js


MQTT.js é uma biblioteca cliente para o protocolo MQTT, escrita em JavaScript para Node.js. e um navegador. Aqui está um exemplo de envio de uma mensagem usando o MQTT.js:

 var mqtt = require('mqtt') var client = mqtt.connect('mqtt://test.mosquitto.org') client.on('connect', function () { client.subscribe('presence', function (err) { if (!err) { client.publish('presence', 'Hello mqtt') } }) }) client.on('message', function (topic, message) { // message is Buffer console.log(message.toString()) client.end() }) 

MQTTnet


O MQTTnet é uma biblioteca .NET de alto desempenho que fornece o cliente e o servidor MQTT (broker).

Instalação do cliente MQTT:

 // Create a new MQTT client. var factory = new MqttFactory(); var mqttClient = factory.CreateMqttClient(); 

Depois de definir as configurações do cliente MQTT, é possível estabelecer uma conexão. O código a seguir mostra como se conectar ao servidor:

 // Use WebSocket connection. var options = new MqttClientOptionsBuilder() .WithWebSocketServer("broker.hivemq.com:8000/mqtt") .Build(); await client.ConnectAsync(options); 

Receba mensagens recebidas:

 client.UseApplicationMessageReceivedHandler(e => { Console.WriteLine("### RECEIVED APPLICATION MESSAGE ###"); Console.WriteLine($"+ Topic = {e.ApplicationMessage.Topic}"); Console.WriteLine($"+ Payload = {Encoding.UTF8.GetString(e.ApplicationMessage.Payload)}"); Console.WriteLine($"+ QoS = {e.ApplicationMessage.QualityOfServiceLevel}"); Console.WriteLine($"+ Retain = {e.ApplicationMessage.Retain}"); Console.WriteLine(); Task.Run(() => client.PublishAsync("hello/world")); }); 

Publicar publicação:

 var message = new MqttApplicationMessageBuilder() .WithTopic("MyTopic") .WithPayload("Hello World") .WithExactlyOnceQoS() .WithRetainFlag() .Build(); await client.PublishAsync(message); 

Consulte a documentação e o wiki do MQTTnet para obter mais exemplos .

Os provedores de nível corporativo possuem servidores MQTT prontos para troca de mensagens entre aplicativos móveis, máquinas industriais e uma ampla variedade de outros usos da IoT. Este guia explica como usar o MQTT por meio de um broker de nível corporativo.

E o dimensionamento?


Quando se trata de dimensionar o MQTT, há duas considerações a serem consideradas: 1) esse é o protocolo correto; 2) independentemente da escolha do protocolo, que infraestrutura e recursos de rede são necessários para lidar com o aumento do tráfego entre dispositivos usando o MQTT.

O LWM2M (Lightweight Machine to Machine) é outro protocolo que pode ser usado com o MQTT no nível corporativo. Comparado ao MQTT, às vezes é mais adequado para sistemas IoT de longo prazo . O MQTT é ideal para uma execução de avaliação da IoT sem esforço, enquanto o LWM2M fornece recursos para uma infraestrutura versátil e de longo prazo. O LWM2M também fornece ferramentas superiores de gerenciamento de dispositivos, como monitoramento de conexão, atualizações de firmware e ações de dispositivos remotos. Para empresas com um grande número de dispositivos não gerenciados que enviam grandes quantidades de dados para uma plataforma central, o LWM2M é a melhor opção. No entanto, estamos falando de implantações em larga escala da IoT; portanto, geralmente o MQTT é mais do que uma opção adequada. Além disso, o MQTT é mais comum e possui suporte mais amplo.

Agora, sobre as possibilidades de infraestrutura. Quando se trata de carregamento do servidor, o número de conexões simultâneas raramente é um gargalo. A maioria dos servidores / intermediários MQTT bons suporta milhares de conexões simultâneas, mas qual é a carga de trabalho necessária para processar e responder às mensagens após o servidor MQTT receber os dados reais? Como regra, existem todos os tipos de problemas em potencial, como leitura e gravação de e para o banco de dados, integração com o servidor, distribuição e gerenciamento de recursos para cada cliente, etc. Assim que uma máquina parar de lidar com a carga, você precisará adicionar servidores adicionais, ou seja, pense em balanceamento de carga, sincronização de mensagens entre clientes conectados a servidores diferentes, acesso generalizado ao estado do cliente, independentemente do tempo de conexão ou do servidor específico ao qual o cliente está conectado - a lista de produtos zhaetsya e continua.

Tais problemas merecem um artigo separado, e muitas informações podem ser encontradas na seção Engenharia do nosso blog . Em particular, consulte o artigo sobre algumas das complexidades de manutenção de uma infraestrutura de mensagens em tempo real em larga escala .

Qual é a situação atual com o MQTT?


Em abril de 2019, o OASIS lançou o MQTT v5.0 como um padrão oficial. O OASIS é um consórcio sem fins lucrativos de 600 organizações membros e 5.000 membros individuais .

A versão 5.0 apresenta uma série de novos recursos que devem ser de interesse dos desenvolvedores de sistemas em tempo real. Esses novos recursos são compatíveis com as versões atuais do MQTT. Entre eles estão:

  • Relatório de erros aprimorado : os códigos de retorno agora podem informar que os dados não estão sendo transmitidos por algum motivo. Sequências opcionais são suportadas para indicar o motivo. Eles ajudam a melhorar o diagnóstico de solução de problemas.
  • Compartilhamento de assinaturas : para ajudar a equilibrar a carga, as assinaturas podem ser compartilhadas entre vários clientes no lado de recebimento.
  • Propriedades da mensagem : a versão 5.0 introduz metadados como parte do cabeçalho da mensagem. Pode transmitir informações adicionais ao usuário final ou facilitar algumas das outras funções listadas abaixo.
  • Alias ​​do canal : os editores podem substituir os canais por identificadores numéricos para reduzir o número de bytes a transmitir.
  • Data de vencimento da mensagem : as mensagens podem ser marcadas para exclusão automática se o sistema não puder entregá-las dentro de um período de tempo especificado.

Para obter uma lista completa dos novos recursos do MQTT 5.0, consulte o Apêndice C do padrão oficial.

Além dos muitos dispositivos e serviços de consumo no mercado, o MQTT encontrou uso na infraestrutura corporativa de todas as formas e tamanhos . São smartphones e tablets, sistemas de monitoramento de energia, dispositivos médicos, plataformas e plataformas de petróleo, as indústrias automotiva e aeroespacial, bem como sensores e sistemas de visão de máquina usados ​​no manuseio de materiais, construção, cadeia de suprimentos, varejo e muito mais.

MQTT e Ably


O MQTT é um protocolo popular, amplamente suportado e relativamente maduro. É ótimo para muitos aplicativos em tempo real , e não apenas para implantar a IoT. No entanto, como a produção e o consumo de dados em tempo real continuam a crescer exponencialmente , o MQTT pode nem sempre ser o protocolo certo para atender às suas necessidades de streaming. Siga nossa seção Conceitos em tempo real para obter informações sobre outros protocolos e como eles se adaptam à sua situação.

A Ably fornece um broker e um adaptador de protocolo MQTT com tradução para o próprio protocolo da Ably nas duas direções, o que permite a integração com quaisquer sistemas e conexões existentes. WebSockets suportados, HTTP, SSE, gRPC (em desenvolvimento), STOMP, AMQP e outros protocolos para organizar uma infraestrutura de mensagens distribuídas em tempo real. Existem mais de 40 bibliotecas de clientes SDK e suporte para protocolos proprietários em tempo real.

Source: https://habr.com/ru/post/pt463669/


All Articles