Subscribe to our Newsletter!
By subscribing to our newsletter, you agree with our privacy terms
Home > IoT > IIoT > Conheça o MQTT, protocolo de mensagens mais usado em IoT
Outubro 24, 2022
O crescimento explosivo da Internet das Coisas (IoT, Internet of Things) nos últimos anos levou a uma situação única em nossa história. Estamos cercados por um número crescente de dispositivos conectados, muitos deles invisíveis, que trabalham constantemente para tornar nosso ambiente mais seguro, mais confortável e nossa rotina mais eficiente.
Mas isolados, eles não conseguem fazer muita coisa. Seu potencial só é realizado quando podem se comunicar, o que gerou demanda por um protocolo de comunicação leve e escalável, que pudesse ser implementado em dispositivos de baixo custo, operando em conexões nem sempre confiáveis.
Este protocolo já existia, e estava esperando sua chance para brilhar. Criado em meados da década de 90 para atender a demandas da indústria petrolífera, o MQTT está rapidamente se tornando um padrão “de fato” para a troca de mensagens na internet das coisas, usado em aplicações tão diversas quanto o controle de uma frota de veículos ou um bate-papo com seus amigos.
Neste artigo, vamos explicar o que é o MQTT, como ele funciona, onde é usado e porque é tão atraente para o segmento de IoT.
MQTT é um protocolo para transmissão de mensagens de máquina para máquina (M2M, Machine to Machine), que tem como principais características a leveza e simplicidade. Ele foi projetado para uso em dispositivos com recursos e largura de banda limitados, se comunicando por conexões pouco confiáveis ou com alta latência.
Estas características o tornam ideal para aplicações em Internet das Coisas (IoT, Internet of Things), como no monitoramento remoto de dispositivos, ou na troca de mensagens entre dispositivos móveis, onde a largura de banda ou suprimento de energia são limitados, ou tem alto custo.
O MQTT foi desenvolvido em 1999 por Andy Stanford-Clark (da IBM) e Arlen Nipper (da Eurotech, Inc.). Nipper relembrou um pouco das circunstâncias que levaram ao surgimento do padrão durante uma participação em um podcast da IBM em 2011.
“No inicio, ou meados, dos anos 90, como você pode imaginar, não tínhamos a conectividade de rede que temos hoje. Um dos projetos nos quais eu estava trabalhando era com a Philips Conoco em um sistema SCADA (Supervisory control and data acquisition) para um novo oleoduto, onde precisávamos de entrega de dados em tempo real. Na época, o que estávamos fazendo na indústria de comunicações era conversar sobre linhas discadas de 1.200 Baud ou 300 Baud e terminais de satélite (VSAT) com banda muito limitada”.
“Nossos cinco objetivos na implementação do MQTT eram: ele precisa ser simples de implementar. Ele precisa entregar dados com Qualidade de Serviço (QoS). Ele precisa ser leve e eficiente no uso de largura de banda, porque na época banda custava caro. Ele precisa ser agnóstico em relação aos dados, e precisa ter persistência de sessão”, disse.
Mais tarde, o surgimento da Internet das Coisas (IOT, Internet of Things) criou a necessidade de um protocolo com exatamente as características do MQTT. Segundo Angel Diaz, Vice-Presidente de Padrões de Software na IBM:
“Como planeta, nos tornamos mais conectados. Uma internet das coisas começou a surgir. E a rede de dispositivos que são capazes de se comunicar uns com os outros e trabalhar uns com os outros realmente explodiu em tamanho”.
“Então o que aconteceu […] é que surgiu uma necessidade real por um tipo de protocolo com uma arquitetura Publicador-Assinante para ter entrega bidirecional de mensagens de forma mais previsível”.
“Com isso poderíamos começar a nos mover de uma simples interação ponto-a-ponto para uma interação mais sofisticada através da rede. Então o MQTT é um protocolo que permite exatamente isso: publicar e assinar mensagens e uma entrega previsível, bidirecional, destas mensagens”.
Originalmente MQTT era um acrônimo de “MQ Telemetry Transport”, sendo “MQ” uma referência a uma linha de produtos de middleware da IBM chamada MQSeries, onde significava “Message Queue” (Fila de Mensagens). Entretanto, desde 2013 o termo se tornou o nome próprio do protocolo, e não mais uma sigla.
Embora tenha sido originalmente desenvolvido pela IBM, desde 2013 o MQTT é um protocolo aberto mantido pelo consórcio OASIS (Organization for the Advancement of Structured Information Standards, Organização para o Avanço dos Padrões de Informação Estruturada), sediado em Massachusetts, nos EUA.
A primeira versão do protocolo lançada sob responsabilidade do OASIS foi a 3.1.1, em Outubro de 2014. Esta versão também é uma recomendação da ISO (international Standards Organization) e IEC (International Eletrotechnical Comission), chamada ISO/IEC 20922:2016.
A versão mais recente do MQTT é a 5, publicada pelo OASIS em março de 2019. Ao definir os objetivos da nova versão, o comitê responsável no OASIS (OASIS Message Queuing Telemetry Transport Technical Committee) tinha o desafio de adiconar recursos há muito desejados pelos usuários sem aumentar a carga ou diminuir a facilidade de uso, e melhorar o desempenho e escalabilidade sem adicionar complexidade desnecessária.
Para atender estas demandas, os seguintes objetivos foram definidos para a versão 5:
Além da leveza e simplicidade, uma das principais vantagens do MQTT é sua flexibilidade: ele foca no transporte de mensagens entre dois pontos, sem se preocupar em saber por quem os dados nestas mensagens foram produzidos ou como serão consumidos.
Ainda segundo Niper, “quando inventamos um dispositivo embarcado, a ideia é que, bem, se eu inventei um dispositivo, então tenho que inventar um protocolo. E então tenho que correr pro lado da TI e inventar uma aplicação que conversa com meu dispositivo. O resultado é uma solução […] que se torna congelada no tempo”.
“O que aprendi trabalhando com a IBM neste projeto é que ao adotar uma arquitetura Publicador-Assinante […] podemos separar a implementação dos produtores de dados, que podem estar no lado do negócio ou dos dispositivos, e dos consumidores de dados”.
“E agora os consumidores podem escrever aplicações muito interessantes em um dispositivo ponta-a-ponta, publicar os dados e ser completamente alheios à quem irá consumir os dados. E do outro lado posso ter pessoas consumindo eles”.
Além disso, o modelo Publicador-Assinante também facilita a escalabilidade. Não importa se há 10, 100 ou 1.000 assinantes em um determinado tópico, o esforço que um publicador precisa fazer para enviar uma mensagem a todos é o mesmo: uma única conexão com o intermediário, e uma única mensagem.
Como MQTT é um padrão aberto, há uma infinidade de implementações disponíveis, sejam comerciais ou open source. Isso significa que não importa a plataforma de hardware, sistema operacional ou linguagem de programação usados para desenvolver sua aplicação, certamente há uma ou mais implementações que atendem às suas necessidades.
O protocolo MQTT é usado em inúmeras situações, de ambientes industriais ao controle de dispositivos em uma casa inteligente. Basicamente, onde houver a necessidade de troca de mensagens entre dispositivos, é provável que você encontre o MQTT em operação.
A empresa alemã CASO Design produz dispositivos inteligentes para a cozinha, como adegas climatizadas e circuladores Sous-Vide. Ao desenvolver seus produtos, a empresa tinha entre seus objetivos permitir que fossem controlados por usuários a partir de praticamente qualquer lugar, que múltiplos usuários pudessem comandar um só dispositivo e que os dados pudessem ser utilizados por várias aplicações.
Soluções como uma conexão Bluetooth sobre o protocolo UDP foram descartadas, pois exigem proximidade física entre o usuário e o dispositivo. Por fim, a empresa optou pelo MQTT: usando conexões Wi-Fi ou redes de telefonia celular um dispositivo é capaz de “conversar” com um usuário em qualquer parte do mundo.
Múltiplos dispositivos podem ser controlados por um único app, que envia comandos e notifica os usuários usuários quando há mudanças de temperatura ou o fim do cozimento.
Já a BMW usa MQTT no BMW Mobility Services, um sistema de compartilhamento de veículos para operadores de frotas. Uma forma tradicional de controlar remotamente um veículo seria enviar uma mensagem SMS para “acordar” um computador de bordo, que inicia uma sessão HTTP com um serviço de back-end rodando na nuvem.
Entretanto, como qualquer pessoa que já sofreu para receber um código de autenticação deve saber, SMS nem sempre é algo previsível. Uma mensagem pode chegar instantaneamente, levar minutos para ser entregue ou simplesmente desaparecer no caminho. Além disso, HTTP é lento, e o tamanho das mensagens e a quantidade delas necessária para estabelecer uma conexão aumentam os custos de operação da rede.
Com sua leveza, facilidade de implementação e garantia de qualidade de serviço, o MQTT era a solução perfeita. Em um dia típico, o serviço da BMW processa 90 mil transações por minuto, com mais de 80 mil clientes conectados. E isso operando em um ambiente onde a confiabilidade da rede, pela própria natureza móvel e dispersa da aplicação, é baixa.
Mas segundo Stanford-Clark, co-criador do MQTT, o protocolo é usado em muito mais do que sistemas de automação. Em 2011, o Facebook o adotou como a camada de transporte para seu popular aplicativo de mensagens instantâneas, o Messenger. “Literalmente da noite para o dia, 800 milhões de pessoas estavam usando o MQTT”, afirmou.
No Messenger, cada conversa gera um tópico, e os membros do chat assinam e publicam neste tópico. Há vários intermediários, em vez de um só, e um “Diretor de Tópico” direciona os pacotes de dados para o intermediário responsável por um chat específico.
Além disso, o MQTT é usado em plataformas de cloud computing como a AWS, da Amazon, Azure, da Microsoft, Watson, da IBM, e nas plataformas de IoT do Google. Com isso, o MQTT se tornou em 2018 o protocolo preferido para transporte de mensagens na internet das coisas.
O MQTT funciona com uma arquitetura Publicador-Assinante (Publisher-Subscriber). Clientes podem enviar mensagens (atuando como publicadores) ou recebê-las (atuando como assinantes). Não há uma conexão direta entre eles: toda a comunicação é controlada por um intermediário (broker) que organiza as mensagens publicadas em uma hierarquia de tópicos e as distribui aos interessados.
Uma analogia é uma redação de um jornal tradicional. Os publicadores seriam os repórteres, que coletam e enviam as notícias à redação. Esta, por sua vez, atua como intermediária, organizando esta informação em seções ou tópicos. Já os assinantes consultam o jornal para consumir a informação dos tópicos que lhes interessam.
Em um exemplo mais prático, imagine que um cliente é um sensor encarregado de monitorar a temperatura de um motor. Quando o sensor tem uma nova informação (como um aumento na temperatura), ele envia uma mensagem para o intermediário especificando o tópico (ex: “Temperatura”) e a informação (ex: “+10 ºC”). O intermediário, por sua vez, transmite esta informação a todos os assinantes do tópico “Temperatura”.
Vale lembrar que os papéis de publicador e assinante não são exclusivos. O mesmo cliente que envia informações sobre a temperatura do motor pode assinar um tópico sobre o nível de fluido refrigerante usado para mantê-la sob controle, e usar esta informação para agir como necessário.
O intermediário, por sua vez, pode ser um appliance dedicado, um PC rodando software Open Source na rede local, um servidor em um datacenter corporativo ou mesmo uma instância virtualizada na nuvem. Sua localização e natureza não importam, desde que ele consiga “conversar” com os publicadores e assinantes via TCP/IP.
Assim como um jornal de bairro não publica informações sobre uma nova descoberta em física quântica, um intermediário descarta uma mensagem sobre tópicos para os quais não há assinantes. Mas opcionalmente, o publicador pode especificar que essa mensagem deve ser retida até que algum assinante expresse interesse no tópico.
Neste caso, o assinante receberá a mensagem assim que assinar o tópico correspondente. Isto permite que ele receba imediatamente a informação mais recente disponível, sem precisar esperar que um publicador envie uma atualização.
Publicadores também podem definir uma mensagem conhecida como “Testamento” (Last Will and Testament), que será enviada pelo intermediário a todos os assinantes de um tópico caso a conexão entre o intermediário e o publicador seja subitamente interrompida.
Por falar em conexões, o MQTT tem um recurso chamado “sessões persistentes”, que reduz a sobrecarga na reconexão de um cliente a um intermediário, especialmente em redes instáveis onde isso pode ocorrer com frequência.
Normalmente, ao se reconectar com um intermediário, um cliente precisa assinar novamente todos os tópicos de seu interesse. Mas ao solicitar uma sessão persistente, o intermediário armazena várias informações sobre o cliente, que estarão imediatamente disponíveis no momento da reconexão.
Assim, o cliente pode retomar a comunicação “de onde parou”, sem desperdiçar tempo (e recursos) assinando novamente tópicos, redefinindo níveis de QoS, etc.
A transmissão de dados do MQTT é geralmente feita sobre o protocolo TCP/IP (usando a porta padrão 1883) mas qualquer protocolo que ofereça conexões ordenadas, bidirecionais e sem perda de pacotes pode ser usado em seu lugar. O tamanho das mensagens é variável, e elas podem ter apenas 2 bytes ou até 256 Megabytes de dados, conforme a necessidade.
MQTT for Sensor Networks (MQTT-SN) é uma extensão do protocolo MQTT para uso em redes de sensores sem fios (WSN, Wireless Sensor Networks).
Tais redes geralmente consistem em um grande número de sensores e atuadores (SAs, Sensors and Actuators) com capacidade de processamento e armazenamento limitada, se comunicando por conexões sem fio com largura de banda reduzida, de curto alcance e baixa confiabilidade, já que são suscetíveis a interrupções por obstáculos ou interferência.
O protocolo MQTT parece ideal para esta situação, mas exige uma implementação TCP/IP, que pode ser onerosa demais em termos de poder de processamento para dispositivos e conexões tão simples como as usadas nos SAs.
O MQTT-SN elimina essa necessidade, e pode operar sobre qualquer tipo de rede capaz de realizar a transferência bidirecional de dados entre um dispositivo e um gateway.
Criado em 2007, também pela IBM, ele foi originalmente projetado para rodar em redes baseadas no protocolo Zigbee, que por sua vez é baseado em no padrão 802.15.4 do IEEE para Wireless Personal Area Networks (WPANs, Redes Sem Fios de Área Pessoal).
Assim como o MQTT, o MQTT-SN é hoje um padrão mantido pelo OASIS. A versão mais recente da especificação é a 1.2.
Ao estabelecer uma conexão com um intermediário, um cliente (seja publicador ou assinante) pode definir três níveis de qualidade de serviço, conforme as necessidades da aplicação.
O nível mais baixo, ou 0 (zero), também é conhecido como “no máximo uma vez” (“at most once”). Ou seja, uma mensagem é enviada apenas uma vez, e tanto o cliente quanto o intermediário não tomam medidas para garantir que ela tenha sido entregue ou recebida.
Uma analogia para este nível seria um supermercado que contrata uma empresa para distribuir, nas casas de uma cidade, folhetos com ofertas para seus clientes. Ele não pede confirmação da entrega de cada folheto, e os clientes também não se preocupam em ligar para o supermercado para informar que receberam uma cópia.
O nível 1 é conhecido como “pelo menos uma vez” (“at least once”). Neste nível, caso não haja confirmação do recebimento da mensagem após um intervalo de tempo, ela será reenviada até que isso aconteça. É possível que uma mensagem seja recebida ou entregue mais de uma vez: por exemplo, se a confirmação se perder no caminho devido a uma falha de conexão.
Neste caso, reutilizando a analogia anterior, poderíamos substituir os folhetos por uma carta de cobrança. Caso não haja confirmação do recebimento (com o pagamento da conta), ela será reenviada até que isso aconteça.
Por fim, o nível 2 é conhecido como “exatamente uma vez” (“exactly once”). Nele tanto o cliente quando o intermediário executam uma negociação (handshake) em dois níveis para garantir que apenas uma cópia da mensagem será entregue.
Mantendo nossa analogia postal, seria como se uma carta tivesse sido enviada com um aviso de recebimento (AR), que retorna para o remetente garantindo que ela foi entregue.
É importante lembrar que no MQTT sempre há um intermediário entre o publicador e o assinante, o que significa que existem duas conexões em toda “conversa”: uma entre o publicador e o intermediário, e outra entre o intermediário e o assinante.
Estas conexões podem ter níveis diferentes de QoS. Neste caso, um intermediário sempre entregará mensagens ao assinante usando o nível de QoS definido pelo assinante, independente do especificado pelo publicador.
Imagine que um publicador envia mensagens sobre um tópico como “Nível de Combustível” com QoS 1. Elas serão entregues ao intermediário respeitando esse nível, ou seja, com envio repetido até que haja uma confirmação de entrega. Mas se o assinante deste tópico especificou QoS 0, ele receberá a mensagem uma única vez, e o intermediário não terá confirmação.
Na versão 3.1 do protocolo é possível informar um usuário e senha para controle de uma conexão, mas estes dados são transmitidos “em aberto” (plain text) e não há criptografia.
Ela pode ser implementada usando SSL, independente do protocolo MQTT em si, mas há uma penalidade inerente em sobrecarga da rede e de processamento, já que SSL não é um protocolo leve. Conexões criptografadas usam por padrão a porta 8883.
Adicionalmente, aplicações também podem criptografar as informações que enviam e recebem, mas isso não é algo integrado ao protocolo, justamente para mantê-lo simples e leve.
Embora não tenha sido criado para a Internet das Coisas, o sucesso do MQTT está diretamente ligado à expansão dela, algo que não deve desacelerar tão cedo. Leve, flexível e com inúmeras implementações disponíveis, o protocolo certamente merece ser considerado na próxima vez em que você desenvolver um dispositivo ou aplicação de IoT.
Setembro 06, 2023
Agosto 07, 2023
Julho 10, 2023
Junho 23, 2023
Maio 31, 2023
Maio 11, 2023
Maio 08, 2023
Abril 26, 2023
Previous
Setor de manufatura é o que mais adota redes privadas 5G
Next
Agricultura é o principal foco de atenção de desenvolvedores IoT
