O que é MQTT: o protocolo, suas versões e onde ele é usado

# A versão curta

MQTT (Message Queuing Telemetry Transport) é um protocolo de mensagens leve, baseado em publicar e assinar, criado para dispositivos com enlace ruim, pouca memória e uma bateria que precisa durar.

Foi criado em 1999 por Andy Stanford-Clark, da IBM, e Arlen Nipper, da Arcom, para levar por satélite a telemetria de oleodutos. As condições eram implacáveis: a banda era cara e escassa, o enlace caía o tempo todo e os dispositivos eram fracos. Essas restrições moldaram tudo no protocolo — um cabeçalho mínimo, uma única conexão de longa duração e a capacidade de sobreviver a uma queda sem perder mensagens.

Hoje o MQTT é um padrão da OASIS, e a versão 3.1.1 foi ainda adotada como norma internacional ISO/IEC 20922. Ele há muito superou a indústria do petróleo: casas conectadas, medidores, máquinas-ferramenta, carros e equipamentos médicos funcionam com ele.

O custo extra mínimo por mensagem é de dois bytes. Uma única requisição HTTP, em comparação, gasta centenas de bytes só em cabeçalhos, antes de qualquer conteúdo. Quando um dispositivo relata uma temperatura a cada segundo por um modem celular no meio do campo, essa diferença decide o projeto.

# Como funciona: publicar, assinar e o broker

No HTTP o cliente pergunta e o servidor responde. No MQTT ninguém pergunta nada a ninguém: um dispositivo publica uma mensagem em um tópico, e todos os que assinaram esse tópico a recebem. O emissor não sabe quem lê, nem se alguém lê; o destinatário não sabe quem enviou. A única coisa que os une é o nome do tópico.

No meio há sempre um broker — um servidor que mantém as conexões, guarda a árvore de assinaturas e distribui as mensagens. Sem ele o modelo não funciona: o broker é o que transforma «enviado ao vazio» em «entregue a todos que precisam».

O que o broker faz

• Aceita e mantém conexões — milhares ao mesmo tempo, por anos sem interrupção.
• Verifica quem está se conectando: usuário e senha, um certificado ou um token.
• Decide o que cada cliente pode fazer: as permissões de publicar e assinar são concedidas por tópico.
• Compara cada mensagem publicada com a árvore de assinaturas e distribui as cópias.
• Guarda estado: últimos valores conhecidos (retain), filas para clientes ausentes e confirmações pendentes.
• Acompanha quem está vivo e publica o testamento de quem desaparece.

Desacoplar emissor e destinatário não é um detalhe técnico, e sim o ponto central do modelo. Você pode trocar um sensor, acrescentar um segundo consumidor ou pendurar uma análise ao lado sem reescrever nada: todos conversam com um tópico, não entre si.

# Tópicos e curingas

Um tópico é uma cadeia de níveis separados por barras. Nada precisa ser registrado de antemão: publicar em um tópico novo o cria na hora.

escritorio/andar2/sala14/temperatura
escritorio/andar2/sala14/umidade
escritorio/andar2/sala15/temperatura

Uma assinatura pode capturar ramos inteiros com dois curingas:

O curinga # só vale como último nível: escritorio/#/temperatura não é um filtro válido. Os tópicos diferenciam maiúsculas de minúsculas, e escritorio/andar2 e escritorio/andar2/ são dois tópicos distintos.

# Qualidade de serviço: QoS 0, 1 e 2

O MQTT deixa você escolher quanto esforço gastar na entrega de cada mensagem. O nível é definido separadamente ao publicar e ao assinar; vale o menor dos dois.

O custo sobe com a garantia: QoS 2 são quatro pacotes em vez de um, mais estado nas duas pontas. Resista à vontade de «usar 2 em tudo por precaução»: dez mil sensores publicando a cada segundo em QoS 2 carregam um broker uma ordem de grandeza mais, sem ganho algum.

# Retain, Last Will, sessões e keep-alive

Retain — o último valor conhecido

Uma mensagem comum só alcança quem estiver assinando naquele momento. Uma mensagem com a marca retain é ainda lembrada pelo broker e entregue a cada novo assinante no instante em que ele assina. É a resposta padrão ao eterno problema do painel que abre vazio e assim permanece até um sensor se dignar a enviar a próxima leitura.

Um tópico guarda exatamente uma mensagem retida: a última. Para limpá-la, publique um payload vazio no mesmo tópico com a marca retain.

Last Will — uma mensagem para quando o enlace cai

Ao se conectar, um cliente pode entregar ao broker um testamento: um tópico, um payload e suas opções. Se a conexão morrer sem cerimônia — sem pacote DISCONNECT —, o broker publica essa mensagem em nome dele. O padrão clássico é um tópico retido device/42/status que recebe online ao conectar e traz offline como testamento. O sistema sempre sabe quem está presente, sem qualquer sondagem.

Sessões: limpas e persistentes

Uma sessão limpa dura exatamente o tempo da conexão: ao desconectar, as assinaturas são esquecidas. Uma persistente sobrevive à queda: o broker lembra as assinaturas e enfileira as mensagens QoS 1 e 2 enquanto o cliente está fora, entregando o acumulado quando ele volta. Para um dispositivo que acorda uma vez por hora, é a única forma de não perder nada.

Keep-alive — perceber que o enlace morreu

Uma conexão TCP rompida pode parecer perfeitamente viva nas duas pontas por muito tempo. Por isso o cliente declara um intervalo de keep-alive e, sem nada mais a dizer, envia um ping. Sem ouvir nada por um intervalo e meio, o broker dá o cliente por desaparecido, fecha a conexão e publica o testamento dele.

# As versões: 3.1, 3.1.1 e 5.0

Na prática aparecem três versões, e as diferenças não são cosméticas.

À parte fica o MQTT-SN, um protocolo irmão para redes sem TCP: ZigBee, enlaces de rádio, UDP. Não é «uma versão do MQTT», e sim uma especificação própria; essas redes ganham um gateway que traduz o tráfego para MQTT comum.

O que o MQTT 5.0 realmente traz

A versão 5 nasceu de incômodos acumulados na prática. O que tem mais peso:

• Códigos de motivo. No 3.1.1 uma recusa parecia um socket fechado em silêncio, e restava adivinhar. No 5.0 o servidor diz o que houve: senha errada, sem permissão para aquele tópico, pacote grande demais.
• Propriedades de pacote. Uma mensagem pode carregar metadados: Content Type, Correlation Data, pares chave-valor próprios. Antes tudo isso era enfiado no payload ou no nome do tópico.
• Requisição e resposta. Os campos Response Topic e Correlation Data tornam o RPC comum um padrão de primeira classe, em vez de uma convenção improvisada.
• Assinaturas compartilhadas via $share/grupo/filtro: várias instâncias de um consumidor dividem o fluxo. Isso é balanceamento de carga e tolerância a falhas no próprio protocolo.
• Tempos de vida de sessões e mensagens. Session Expiry e Message Expiry permitem dizer «guarde por um dia e depois esqueça» em vez da escolha binária entre limpa e não limpa.
• Controle de fluxo. Receive Maximum limita quantas mensagens sem confirmação viajam ao mesmo tempo, e Maximum Packet Size protege um dispositivo pequeno de um pacote que ele não consegue digerir.
• Aliases de tópicos. Um nome longo é enviado uma vez e depois substituído por um número de dois bytes — uma economia real em hierarquias profundas.
• Identificadores de assinatura, No Local, Retain As Published, Retain Handling. Detalhes que eliminam armadilhas antigas: ouvir o eco das próprias mensagens, uma avalanche de retidas a cada reconexão, não saber por qual assinatura uma mensagem chegou.
• Testamento adiado. O Will Delay Interval evita que uma oscilação momentânea dispare um alarme: o testamento só é publicado se o cliente não voltar a tempo.

A conclusão prática: comece projetos novos no 5.0. Assinaturas compartilhadas e códigos de erro compreensíveis poupam semanas de depuração, e a compatibilidade com dispositivos antigos não se perde.

# MQTT diante do HTTP e das alternativas

«Para que MQTT se existe REST?» é uma pergunta justa. A diferença não é moda, e sim o sentido e o custo de uma conversa.

A consulta periódica deixa isso claro. Para saber de um evento em menos de um segundo por HTTP, mil dispositivos precisam perguntar mil vezes por segundo, e quase toda resposta será «nada de novo». No MQTT o evento chega sozinho no instante em que acontece e, nesse meio-tempo, não consome tráfego.

E quanto a CoAP, AMQP e WebSocket

• CoAP é REST sobre UDP para nós muito pequenos. Mais leve que o MQTT, mas não oferece filas nem entrega confiável sem esforço.
• AMQP é mais pesado e mais rico: roteamento elaborado, transações, filas de nível corporativo. Faz sentido entre servidores, é excessivo para um sensor.
• WebSocket é um transporte, não uma alternativa: o próprio MQTT roda sobre WebSocket para funcionar dentro de um navegador.
• Sparkplug B não é rival, e sim uma camada sobre o MQTT: ele dita como nomear tópicos e codificar payloads em sistemas industriais, para que softwares SCADA de fabricantes diferentes entendam os mesmos dados.

# Transporte, portas e payloads

O MQTT roda sobre TCP e pede apenas entrega confiável e ordenada. As portas de praxe:

Para o protocolo, um payload é apenas uma sequência de bytes. O MQTT nada sabe do conteúdo e nada impõe: JSON, CBOR, protobuf, um simples número ou uma imagem servem igualmente. O limite formal é de 256 MB, mas na prática tudo acima de algumas centenas de kilobytes pertence ao HTTP, viajando pelo MQTT apenas um link.

Na prática o JSON domina: uma pessoa consegue lê-lo, qualquer linguagem o interpreta e ele é compacto o bastante. Em um enlace estreito, um formato binário ganha seu espaço — e é exatamente aí que a propriedade Content Type do MQTT 5.0 ajuda, dizendo com honestidade o que há dentro.

# Segurança

O MQTT nada criptografa por si só: na porta 1883 o usuário e a senha trafegam em texto puro. A segurança vem de três camadas independentes, e nenhuma delas é opcional.

Criptografar o canal

TLS na porta 8883. Para dispositivos fracos demais para TLS, a única opção decente é mantê-los em uma rede isolada e não deixar nada sair a não ser por um gateway.

Autenticação

O clássico é usuário e senha no pacote CONNECT. Mais rígido: certificados de cliente, com o dispositivo apresentando o seu e o broker conferindo a assinatura. Mais flexível: JWT, em que o dispositivo traz um token assinado e com prazo, e revogar o acesso não exige mexer no broker. Bons brokers também sabem ler contas de um banco externo, de um arquivo CSV ou de um serviço HTTP, para que a lista de dispositivos não precise existir em duplicata.

Permissões por tópico

A autenticação responde «quem é você»; a autorização, «o que você pode fazer». As listas de controle de acesso dizem quais tópicos um cliente pode ler e quais pode escrever. O ajuste correto é negar tudo, exceto o explicitamente permitido.

A isso somam-se limites de taxa de publicação (para que um único dispositivo enlouquecido não soterre o broker), um tamanho máximo de pacote e a higiene de rede de sempre: o painel do broker não tem o que fazer voltado para a internet aberta.

# Onde o MQTT é realmente usado

Casa conectada e automação predial

O maior campo em volume. Home Assistant, Zigbee2MQTT, ESPHome e openHAB conversam por meio de um broker MQTT, que ainda faz o papel de cola entre equipamentos de fabricantes diferentes: uma tomada, um sensor de vazamento e um controlador de aquecimento de três marcas cooperam perfeitamente, porque cada um simplesmente escreve no próprio tópico.

Indústria e SCADA

Leituras de máquina, estado da linha, contadores de horas. O arranjo clássico é um gateway que lê Modbus ou OPC UA do equipamento e republica por MQTT, depois do que SCADA, um historiador e um sistema de manutenção preditiva consomem tudo ao mesmo tempo sem atrapalhar uns aos outros. É aqui que o Sparkplug B e as assinaturas compartilhadas do MQTT 5.0 ganham seu lugar.

Medição e concessionárias

Medidores de água, gás, energia e calor: dispositivos a bateria que acordam uma vez por hora, informam uma leitura e voltam a dormir. Aqui as sessões persistentes e o retain fazem o trabalho pesado — o servidor sempre vê o último valor mesmo que um medidor só se manifeste à noite.

Transporte e telemática

Coordenadas, consumo de combustível, estado do baú refrigerado, comportamento do motorista. O enlace é uma rede celular que some em túneis e fora da cidade. Filas e reenvio após a reconexão transformam uma conexão em farrapos num fluxo contínuo de dados.

Energia, agricultura, saúde

Usinas solares e subestações, sistemas de irrigação e estações meteorológicas, monitores de pacientes e geladeiras de vacinas. O que têm em comum: muitos pontos, um enlace fraco, eventos que não podem se perder e a necessidade de saber de uma falha imediatamente.

Cidades inteligentes e logística

Iluminação pública, estacionamento, contêineres que informam o quanto estão cheios, rastreamento de carga e temperatura da cadeia de frio. Dezenas de milhares de dispositivos enviando mensagens curtas e espaçadas — exatamente o perfil de carga para o qual o MQTT foi projetado.

# Projetar seus tópicos: decisões que valem cedo

Seu esquema de tópicos é a API do seu sistema. Mudá-lo depois dói, porque firmware e servidor precisam ser atualizados em conjunto. Algumas regras que poupam tempo.

• Do geral ao específico. fabrica/galpao3/linha2/maquina7/temperatura permite assinar em qualquer nível. A ordem inversa torna os curingas inúteis.
• Dê ao identificador do dispositivo um nível próprio. É isso que permite a uma única regra de ACL confinar um dispositivo ao seu ramo.
• Sem barra inicial. /escritorio/temp cria um primeiro nível vazio — válido, mas fonte duradoura de confusão.
• Só letras latinas, dígitos, hífen e sublinhado. Espaços e os caracteres +, # e $ em nomes provocam falhas que ninguém espera.
• Nunca codifique dados variáveis no tópico. sensor/42/temp/21.5 é um erro: o valor vai no payload, senão o broker acaba com uma árvore de tópicos sem limite e o retain deixa de servir.
• Separe estado de comandos. Por exemplo device/42/state para o que o dispositivo informa e device/42/cmd para o que se manda a ele. Caso contrário, o eco dos próprios comandos acabará realimentando a lógica.
• Retain para estado, não para telemetria. O retain serve para o «último estado conhecido» e não faz sentido para um fluxo de leituras.

# Escolher um broker

Há muitos brokers, e a escolha em geral se resume a um punhado de perguntas.

• O MQTT 5.0 é suportado por inteiro? Suporte parcial é comum, e costuma-se descobrir isso no pior momento possível.
• Dá para ver o que está acontecendo? Poder observar quem está conectado, quais tópicos têm vida e o que passa agora poupa horas de depuração. Um broker sem painel transforma cada problema em arqueologia de logs.
• Como os dispositivos são cadastrados? Com milhares deles, fazer à mão está fora de questão — é preciso uma API ou contas em um banco externo.
• Ele sobrevive a uma reinicialização? Mensagens retidas, sessões persistentes e filas precisam chegar ao disco, senão uma reinicialização planejada significa perder dados.
• Que limites existem? Um dispositivo enlouquecido não pode derrubar o sistema: limites de taxa e de volume importam.
• Quanto custa e onde roda? Um serviço em nuvem é cômodo até começar a cobrar por mensagem; um servidor próprio precisa ser administrado, mas mantém os dados com você.

Para uma instalação pequena ou média — de uma casa conectada a uma fábrica com alguns milhares de pontos — normalmente basta um único broker em uma máquina modesta. Cluster é necessário bem menos vezes do que parece durante o projeto; mais vezes compensa ligar dois brokers independentes com uma ponte que encaminhe apenas os tópicos que importam.

# Começar em cinco minutos

O jeito mais rápido de entender tudo isso é subir um broker e observar as mensagens você mesmo. No Debian ou no Ubuntu são três comandos:

sudo wget -qO /usr/share/keyrings/elx-repo.gpg https://repo.um-d.ru/elx-repo.gpg
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" | sudo tee /etc/apt/sources.list.d/elx-repo.list
sudo apt-get update && sudo apt-get install elxmqttbroker

O painel abre em http://seu-servidor:8567. Crie um usuário e experimente a troca com qualquer cliente — as ferramentas de console do mosquitto, por exemplo:

# em uma janela — assinar tudo o que o dispositivo envia
mosquitto_sub -h localhost -u sensor-42 -P senha -t 'sensor-42/#' -v

# em outra — publicar uma leitura
mosquitto_pub -h localhost -u sensor-42 -P senha -t 'sensor-42/temp' -m '21.5'

# o mesmo, mas lembrado para os futuros assinantes
mosquitto_pub -h localhost -u sensor-42 -P senha -t 'sensor-42/temp' -m '21.5' -r

Depois disso, brinque com a marca retain, desconecte um assinante e veja o que se acumula em uma sessão persistente, coloque um testamento e puxe o cabo. Meia hora disso ensina mais que qualquer artigo, este incluído.

# Respostas rápidas