Fundamentos do MQTT
O protocolo Message Queuing Telemetry Transport (MQTT) vem sendo utilizado há muitos anos, mas agora é especialmente relevante devido ao crescimento explosivo da IoT: tanto dispositivos de consumo quanto industriais estão implementando redes distribuídas e computação de borda, e dispositivos com transmissão de dados constante estão se tornando parte do cotidiano. Esse crescimento intensivo obriga a buscar formas de transferir dados de maneira eficiente.
O que é MQTT
Andy Stanford-Clark (IBM) e Arlen Nipper (na época trabalhando para a Eurotech, Inc.) foram os autores da primeira versão do protocolo em 1999. Ele foi usado para monitorar oleodutos dentro do framework SCADA. O objetivo era ter um protocolo que fosse eficiente em largura de banda, leve e que consumisse pouca bateria, porque os dispositivos estavam conectados via link de satélite que, naquela época, era extremamente caro. No momento, a maioria dos dispositivos usa a versão 5.0.
O Message Queuing Telemetry Transport (MQTT) é um protocolo de rede leve, baseado em publicação/assinatura, que transporta mensagens entre dispositivos. O protocolo geralmente opera sobre TCP/IP; entretanto, qualquer protocolo de rede que forneça conexões ordenadas, sem perda e bidirecionais pode suportar MQTT. Foi projetado para conexões com locais remotos onde é necessário um "pequeno footprint de código" ou onde a largura de banda da rede é limitada. O protocolo é um padrão aberto da OASIS e uma recomendação ISO (ISO/IEC 20922).
Dadas as condições operacionais, o protocolo foi feito pequeno e leve. É ideal para dispositivos com baixo consumo de energia e vida útil de bateria limitada. Agora, isso inclui smartphones, bem como um número cada vez maior de sensores e dispositivos conectados.
Assim, o MQTT se tornou um protocolo para streaming de dados entre dispositivos com poder de CPU e/ou vida útil de bateria limitados, bem como para redes com largura de banda cara ou baixa, estabilidade imprevisível ou alta latência. Por isso o MQTT é conhecido como o protocolo ideal para IoT. Ele é construído sobre o protocolo TCP/IP, mas existe um ramo MQTT-SN para trabalhar sobre Bluetooth, UDP, ZigBee e em outras redes IoT além do TCP/IP.
Como funciona
O modelo de publicar e assinar
Existem 2 definições principais no MQTT: MQTT Broker e cliente MQTT.
Um MQTT broker é um servidor que recebe todas as mensagens dos clientes e então encaminha as mensagens para os clientes de destino apropriados. Em palavras simples, o broker atua como um correio; o MQTT não usa o endereço do destinatário pretendido, mas usa a linha de assunto chamada “Topic”, e qualquer pessoa que quiser uma cópia dessa mensagem vai assinar (subscribe) esse topic. Múltiplos clientes podem receber a mensagem de um único broker (capacidades one-to-many). Similarmente, múltiplos publishers podem publicar tópicos para um único assinante (many-to-one).
Um cliente MQTT é qualquer dispositivo (de um microcontrolador até um servidor completo) que execute uma biblioteca MQTT e se conecte a um MQTT broker através de uma rede.
O cliente conecta-se ao broker. Ele pode assinar (subscribe) qualquer “topic” de mensagem no broker. Essa conexão pode ser uma conexão TCP/IP simples ou uma conexão TLS criptografada para mensagens sensíveis.
O cliente publica mensagens sob um topic enviando a mensagem e o topic ao broker.
O broker então encaminha a mensagem para todos os clientes que assinam esse topic.
Como as mensagens MQTT são organizadas por topics, o desenvolvedor da aplicação tem a flexibilidade de especificar que certos clientes só podem interagir com determinadas mensagens. Por exemplo, sensores publicarão suas leituras sob o topic “sensor_data” e assinarão o topic “config_change”. Aplicações de processamento de dados que salvam dados de sensores em um banco de dados de backend assinarão o topic “sensor_data”. Uma aplicação de console de administração poderia receber comandos do administrador do sistema para ajustar as configurações dos sensores, como sensibilidade e frequência de amostragem, e publicar essas alterações no topic “config_change”.
Tipos de mensagens MQTT
Uma sessão MQTT é dividida em quatro estágios: conexão, autenticação, comunicação e terminação. Um cliente inicia criando uma conexão Transmission Control Protocol/Internet Protocol (TCP/IP) com o broker usando ou uma porta padrão ou uma porta personalizada definida pelos operadores do broker. Ao criar a conexão, é importante reconhecer que o servidor pode continuar uma sessão antiga se for fornecida uma identidade de cliente reutilizada.
As portas padrão são 1883 para comunicação não criptografada e 8883 para comunicação criptografada -- utilizando Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Durante o handshake SSL/TLS, o cliente valida o certificado do servidor e autentica o servidor. O cliente também pode fornecer um certificado de cliente ao broker durante o handshake. O broker pode usar isso para autenticar o cliente. Embora não faça parte especificamente da especificação MQTT, tornou-se costume que brokers suportem autenticação de cliente com certificados SSL/TLS no lado do cliente.
Porque o protocolo MQTT visa ser um protocolo para dispositivos com recursos limitados e dispositivos IoT, SSL/TLS pode nem sempre ser uma opção e, em alguns casos, pode não ser desejado. Nessas ocasiões, a autenticação é apresentada como nome de usuário e senha em texto claro, que são enviados pelo cliente ao servidor - isso, como parte da sequência de pacotes CONNECT/CONNACK. Além disso, alguns brokers, especialmente brokers abertos publicados na internet, aceitarão clientes anônimos. Nesses casos, o nome de usuário e a senha são simplesmente deixados em branco.
Formato da mensagem MQTT
O MQTT é considerado um protocolo leve porque todas as suas mensagens têm um pequeno footprint de código. O pacote consiste em um cabeçalho fixo de 2 bytes + um cabeçalho variável e um payload. Nos primeiros 2 bytes, o cabeçalho fixo estará sempre presente em todos os pacotes e os outros dois, cabeçalho variável e payload, nem sempre estão presentes.
Dos dois bytes do cabeçalho fixo, o primeiro byte é o campo de controle. Esse campo de controle de 8 bits é dividido em dois campos de 4 bits. Os primeiros 4 bits mais significativos (MSB) são o campo do tipo de comando. Esse tipo determina a ação que será realizada: o cliente quer assinar o topic, uma nova mensagem é publicada para assinantes, entre outras.
Os próximos 4 bits são os bits de flag de controle e são usados pelo comando PUBLISH; para o restante dos comandos eles são reservados e o valor será 0.
O segundo byte do cabeçalho fixo contém o remaining length, que é o comprimento do cabeçalho variável + o comprimento do payload.
Um cabeçalho variável não está presente em todos os pacotes MQTT. Alguns comandos ou mensagens MQTT usam esse campo para fornecer informações adicionais ou flags e eles variam dependendo do tipo de pacote. Um identificador de pacote é comum na maioria dos tipos de pacote.
No final, o pacote pode conter um payload. Mesmo o payload é opcional e varia com o tipo de pacote. Esse campo geralmente contém os dados que estão sendo enviados. Ex.: Para pacotes CONNECT, o payload é o client ID e ‘username and password’ se estiverem presentes. E para o pacote PUBLISH, é a mensagem a ser publicada.
Qualidade de Serviço
QoS refere-se a um acordo entre o remetente de uma mensagem e o destinatário da mensagem. Atua como uma característica-chave no MQTT, dando ao cliente a capacidade de escolher entre três níveis de serviço.
Os três diferentes níveis de QoS determinam como o conteúdo é gerenciado pelo protocolo MQTT. Embora níveis mais altos de QoS sejam mais confiáveis, eles têm mais requisitos de latência e largura de banda, então clientes assinantes podem especificar o nível máximo de QoS que gostariam de receber.
O nível de QoS mais simples é um serviço sem confirmação. Esse nível de QoS utiliza uma sequência de pacotes PUBLISH; o publisher envia uma mensagem ao broker uma vez, e o broker repassa a mensagem aos assinantes uma vez. Não existe mecanismo para garantir que a mensagem foi recebida corretamente, e o broker não salva a mensagem. Esse nível de QoS também pode ser referido como no máximo uma vez, QoS0 ou fire and forget.
O segundo nível de QoS é o serviço com confirmação. Esse nível de QoS utiliza uma sequência de pacotes PUBLISH/PUBACK entre o publisher e seu broker, assim como entre o broker e os assinantes. Um pacote de reconhecimento verifica que o conteúdo foi recebido, e um mecanismo de retentativa enviará o conteúdo original novamente se um reconhecimento não for recebido em tempo hábil. Isso pode resultar no assinante recebendo múltiplas cópias da mesma mensagem. Esse nível de QoS também pode ser referido como pelo menos uma vez ou QoS1.
O terceiro nível de QoS é o serviço assegurado. Esse nível de QoS entrega a mensagem com dois pares de pacotes. O primeiro par é chamado PUBLISH/PUBREC, e o segundo par é chamado PUBREL/PUBCOMP. Os dois pares garantem que, independentemente do número de retentativas, a mensagem será entregue apenas uma vez. Esse nível de QoS também pode ser referido como exatamente uma vez ou QoS2.
Vantagens e desvantagens
Vantagens:
O MQTT é agnóstico quanto ao payload. O payload do protocolo MQTT pode transportar qualquer tipo de dado, como binário, texto ASCII, etc. O receptor precisa interpretar e decodificar conforme o formato usado pelo transmissor.
Utiliza pacotes de tamanho reduzido e pode ser usado para aplicações com baixa largura de banda.
Oferece menor consumo de energia da bateria.
É um protocolo confiável, pois utiliza opções de QoS para fornecer entrega garantida.
Devido ao seu modelo de publicação/assinatura, é escalável.
Oferece um design desacoplado, pois é fácil desacoplar o dispositivo e o servidor. Ideal para comunicações distribuídas one-to-many e aplicações separadas.
Um dispositivo publicador pode enviar dados ao servidor a qualquer momento, independentemente do seu estado.
Equipado com a função LWT (Last Will and Testament) para notificar as partes sobre uma desconexão anormal do cliente.
Depende de TCP/IP para tarefas básicas de comunicação.
Projetado para entregar mensagens segundo os modelos "no máximo uma vez", "pelo menos uma vez" e "exatamente uma vez".
Desvantagens:
O MQTT não suporta streaming de vídeo.
Problemas com latência.
Segurança não é incorporada. O MQTT é não criptografado. Em vez disso, utiliza TLS/SSL (Transport Layer Security/Secure Sockets Layer) para criptografia de segurança.
Um broker centralizado pode ser um ponto de falha, já que as conexões dos clientes com os brokers ficam abertas o tempo todo.
Não suporta recursos avançados como controle de fluxo.
Onde o MQTT pode ser usado
Como aplicações IoT estão sendo implementadas em larga escala, o MQTT ganhou destaque como uma forma aberta, simples e escalável de implementar computação distribuída e funcionalidades de IoT para uma base de usuários mais ampla — tanto nos mercados de consumo quanto nos industriais.
Gestão de frotas. Organizações estão usando MQTT para construir sistemas de gestão de frotas mais inteligentes que melhoram a otimização da frota, a segurança do motorista e reduzem os custos de combustível. Novos modos de transporte usando drones também estão mudando a forma como movemos mercadorias. A conectividade entre um dispositivo móvel usado pelo operador, informações telemétricas diretamente do veículo e a integração em sistemas de roteamento e agendamento de backend fornece a visibilidade necessária para melhorar a operação geral da frota.
Dados de sensores ambientais. O MQTT suporta o modelo de entrega de mensagens "no more than once". Em redes com cobertura parcial do território ou alta latência, isso significa que informações podem ser perdidas ou duplicadas. Em áreas onde sensores remotos registram e transmitem dados em intervalos especificados, isso não é um problema, uma vez que novas leituras são recebidas regularmente. Sensores em ambientes remotos geralmente são dispositivos de baixa potência, o que torna o MQTT uma solução ideal para sensores IoT com prioridade de transferência de dados relativamente baixa.
Dados de saúde de máquinas: para responder rapidamente a problemas emergentes e prevenir tempo de inatividade. Por exemplo, para uma usina eólica, é necessário garantir a entrega de indicadores de desempenho atuais às equipes locais mesmo antes dessas informações chegarem ao centro de processamento de dados. Em tais situações, a entrega de mensagens "pelo menos uma vez" garante que os sinais apropriados serão notados pelos especialistas necessários em tempo hábil, mesmo que cheguem como duplicatas. Isto é importante para comunicação máquina-a-máquina com prioridade mais alta.
Sistemas de faturamento: existem mensagens ainda mais prioritárias e precisas que precisam ser tratadas corretamente. Em situações de negócios onde a duplicação de registros é inaceitável, incluindo em sistemas de faturamento, a flag de QoS de transmissão "exatamente uma vez" é útil. Isso elimina a duplicação ou perda de pacotes em sistemas de cobrança ou faturamento, reduzindo o número de anomalias e contradições desnecessárias no acordo.
Aplicações de mensagens baseadas em texto para comunicação em tempo real que se beneficiam do baixo uso de dados e energia do MQTT. Por exemplo, o Facebook usa MQTT para seu app Messenger, não apenas porque o protocolo conserva bateria durante mensagens de telefone para telefone, mas também porque o protocolo permite que mensagens sejam entregues eficientemente em milissegundos, apesar de conexões de internet inconsistentes ao redor do mundo.
Dispositivos MQTT suportados pela Navixy
Xirgo Global FMS500 Light MQTT (IOTM
Xirgo Global FMS500 Light+ MQTT (IOTM)
Xirgo Global FMS500 StCAN MQTT (IOTM)
BCE FMS500 Light MQTT (IOTM)
BCE FMS500 Light+ MQTT (IOTM)
BCE FMS500 StCAN MQTT (IOTM)
GlobalmatiX xTCU
Como configurar dispositivos MQTT para trabalhar com Navixy
Configuração de dispositivo Xirgo & BCE MQTT
Para configurar o dispositivo Xirgo & BCE para trabalhar com MQTT:
Dentro do FMSET: escolha Connectivity → Telemetry server → MQTT broker address settings) especifique host: mqtt.eu.navixy.com para servidor EU e mqtt.us.navixy.com para servidor US, porta 1883.
E adicione o usuário padrão em MQTT Security -> Authorization
Configuração de dispositivo Globalmatix MQTT
Para configurar o dispositivo Globalmatix para trabalhar com MQTT:
Especifique o servidor http://mqtt.navixy.com porta 1883 para EU e http://mqtt.us.navixy.com porta 1883 para US
User/password - globalmatix/secretword
Topic globalmatix/in
Para configurar o dispositivo Globalmatix para trabalhar com MQTTS:
Especifique o servidor http://mqtt.navixy.com porta 8883 para EU e http://mqtt.us.navixy.com porta 8883 para US
User/password - globalmatix/secretword
Topic globalmatix/in
Atualizado
Isto foi útil?