MQTT é um protocolo leve de mensagens criado para comunicação eficiente entre dispositivos, aplicações, sensores, gateways, plataformas em nuvem e sistemas de controle. Ele é amplamente usado em redes IoT, sistemas de telemetria, edifícios inteligentes, monitoramento industrial, plataformas veiculares, sistemas de energia, automação residencial, gerenciamento remoto de equipamentos e aplicações móveis em que largura de banda, energia ou estabilidade de rede podem ser limitadas.

O protocolo é baseado em um modelo de publicação/assinatura. Em vez de um dispositivo enviar dados diretamente para outro, as mensagens são enviadas a um broker. Em seguida, o broker distribui essas mensagens aos clientes que assinaram tópicos correspondentes. Essa estrutura torna a comunicação flexível, escalável e adequada para sistemas com muitos dispositivos que não precisam conhecer o endereço de rede uns dos outros.

Outra forma de pensar sobre mensagens entre dispositivos

A comunicação cliente-servidor tradicional geralmente funciona como uma solicitação e uma resposta diretas. Um cliente pede informações a um servidor, e o servidor responde. O MQTT segue uma ideia diferente. Um dispositivo pode publicar uma mensagem sem saber quem a receberá, enquanto outro dispositivo pode assinar um tópico sem saber quem publicará nele.

Essa separação é útil em grandes sistemas distribuídos. Um sensor de temperatura não precisa saber qual painel, banco de dados, aplicativo móvel ou regra de automação consumirá seus dados. Ele só precisa publicar em um tópico definido. O broker cuida da distribuição.

O resultado é um padrão de comunicação que reduz o acoplamento rígido entre dispositivos. Os sistemas podem adicionar novos assinantes sem alterar o sensor. Também podem adicionar novos publicadores sem reescrever todas as aplicações. Esse é um dos motivos pelos quais o protocolo é popular em projetos de IoT e telemetria.

O broker como hub de mensagens

O broker é o componente central da arquitetura. Ele aceita conexões de clientes, autentica clientes quando necessário, recebe mensagens publicadas, compara tópicos com assinaturas e encaminha as mensagens aos assinantes corretos.

Um broker pode operar em uma plataforma em nuvem, servidor privado, gateway de borda, computador industrial, dispositivo embarcado ou serviço gerenciado de mensagens. Em implantações pequenas, um broker pode tratar todo o tráfego. Em implantações maiores, vários brokers podem ser agrupados, interligados, balanceados ou distribuídos entre regiões.

O broker também controla muitos comportamentos operacionais, como estado de sessão, mensagens retidas, controle de acesso, entrega por qualidade de serviço, tempo limite de keepalive, limites de conexão, autorização por tópico e persistência de mensagens. Por isso, o projeto do broker tem impacto direto na confiabilidade, escalabilidade e segurança.

Ciclo de vida da conexão

O cliente estabelece uma sessão

Primeiro, o cliente abre uma conexão de rede com o broker. O MQTT normalmente roda sobre TCP, e implantações seguras costumam usar criptografia TLS. Depois que a conexão de transporte é estabelecida, o cliente envia um pacote CONNECT com informações como ID do cliente, dados de autenticação, valor de keepalive, comportamento da sessão e configurações opcionais de mensagem de testamento.

O broker verifica a solicitação de conexão e responde com um pacote CONNACK. Se a conexão for aceita, o cliente pode começar a publicar, assinar, cancelar assinaturas e receber mensagens. Se a conexão for recusada, o broker fornece um motivo de acordo com a versão do protocolo e a configuração.

O heartbeat mantém o link ativo

O mecanismo de keepalive ajuda os dois lados a detectar conexões interrompidas. Se nenhum dado tiver sido trocado dentro do tempo acordado, o cliente envia um pacote PINGREQ e o broker responde com PINGRESP.

Isso é importante porque dispositivos IoT podem operar em redes instáveis, links móveis, Wi-Fi, conexões celulares, enlaces via satélite ou caminhos WAN remotos. Uma rede pode falhar silenciosamente sem fechar a conexão de forma limpa. O keepalive ajuda a detectar essa condição.

Desconexão e reconexão

Um cliente pode se desconectar normalmente enviando um pacote DISCONNECT. Ele também pode desaparecer inesperadamente por perda de energia, falha de rede, travamento de firmware ou perda de sinal. O broker então aplica as regras de sessão e de mensagem de testamento configuradas para esse cliente.

O comportamento de reconexão é importante em implantações reais. Os dispositivos devem lidar com interrupções de rede de forma controlada, evitar tempestades de reconexão e retomar a comunicação conforme a política de sessão necessária.

Nomes de tópicos e roteamento de mensagens

Tópicos são caminhos em texto usados para classificar mensagens. Um tópico pode parecer uma hierarquia, como building/floor1/room102/temperature ou factory/line3/motor7/status. Publicadores enviam mensagens para tópicos, e assinantes recebem mensagens dos tópicos que assinaram.

Um bom projeto de tópicos é uma das partes mais importantes de uma implantação bem-sucedida. Os nomes devem ser previsíveis, legíveis e alinhados com a estrutura real do sistema. Um projeto ruim dificulta filtragem, permissões, monitoramento e manutenção de longo prazo.

Assinantes podem usar tópicos exatos ou assinaturas com curingas. Um curinga de nível único corresponde a um nível do tópico, enquanto um curinga multinível pode corresponder a muitos níveis. Curingas são úteis para painéis, plataformas analíticas, ferramentas de monitoramento e aplicações de gestão que precisam receber mensagens de muitos dispositivos.

Fluxo de publicação e assinatura

Publicação de dados

Quando um cliente publica dados, ele envia um pacote PUBLISH ao broker. O pacote inclui o nome do tópico, a carga útil, o nível de qualidade de serviço, a flag de retenção e o identificador de pacote quando exigido pelo nível QoS selecionado.

A carga útil pode conter muitos formatos de dados. Pode ser texto simples, JSON, dados binários, valores de sensores, mensagens de status, comandos, alarmes, registros de telemetria ou dados de aplicação codificados. O MQTT em si não define o significado da carga útil. A aplicação decide como estruturá-la e interpretá-la.

Recebimento de assinaturas

Um cliente assina enviando um pacote SUBSCRIBE com um ou mais filtros de tópico. O broker responde com SUBACK e começa a entregar mensagens correspondentes ao cliente conforme o nível QoS solicitado e concedido.

Assinantes podem ser painéis, bancos de dados, motores de automação, serviços em nuvem, aplicativos móveis, controladores de dispositivos ou outros equipamentos de campo. Uma mensagem publicada pode ser entregue a muitos assinantes ao mesmo tempo.

Remoção do interesse

Quando um cliente não deseja mais certas mensagens, ele envia um pacote UNSUBSCRIBE. O broker para de encaminhar mensagens de tópicos correspondentes depois de confirmar a solicitação.

Isso permite que as aplicações alterem dinamicamente seu interesse por dados. Por exemplo, um painel pode assinar um prédio enquanto o usuário o visualiza e cancelar a assinatura quando o usuário muda para outro local.

O modelo de publicação/assinatura permite que produtores e consumidores de dados evoluam de forma independente, enquanto o broker gerencia roteamento, comportamento de sessão e controle de entrega.

Níveis de qualidade de serviço

QoS 0: no máximo uma vez

QoS 0 é o nível de entrega mais simples. A mensagem é enviada uma vez e não há confirmação do receptor na camada MQTT. Se a mensagem se perder, o protocolo não a retransmite.

Esse nível é útil para telemetria frequente quando perder uma atualização ocasional é aceitável. Por exemplo, um sensor de temperatura enviando dados a cada poucos segundos talvez não precise que cada leitura chegue.

QoS 1: pelo menos uma vez

QoS 1 exige confirmação. O remetente retransmite a mensagem se não receber confirmação. Isso melhora a confiabilidade da entrega, mas o receptor pode receber mensagens duplicadas.

Aplicações que usam QoS 1 devem estar preparadas para tratar duplicatas. Isso é comum em alarmes, mudanças de estado, comandos e telemetria importante, quando a entrega é mais relevante do que evitar repetição.

QoS 2: exatamente uma vez

QoS 2 usa uma troca mais complexa para garantir que uma mensagem seja entregue exatamente uma vez no nível do protocolo. Ele fornece a garantia de entrega mais forte, mas acrescenta mais sobrecarga e latência.

Esse nível pode ser usado quando o processamento duplicado seria prejudicial. No entanto, muitas implantações reais usam QoS 0 ou QoS 1 porque oferecem melhor equilíbrio entre desempenho e confiabilidade.

Mensagens retidas e último estado conhecido

Uma mensagem retida é armazenada pelo broker como a mensagem mais recente de um tópico. Quando um novo assinante assina esse tópico, o broker envia imediatamente a mensagem retida para que o assinante veja o estado conhecido mais recente.

Isso é útil para informações de estado, como status online do dispositivo, estado de chave, valor de sensor, versão de configuração, estado de alarme ou modo operacional atual. Sem mensagens retidas, um novo assinante talvez tenha que esperar até a próxima atualização para conhecer a condição atual.

Mensagens retidas devem ser usadas com cuidado. Elas são úteis para estado, mas nem sempre são adequadas para fluxos de eventos. Um evento retido de “porta aberta” pode confundir um novo assinante se já não for verdadeiro. Tópicos de estado e tópicos de eventos devem ser projetados separadamente.

Comportamento de sessão e entrega offline

O MQTT oferece comportamento de sessão que determina o que acontece quando um cliente se desconecta e depois se reconecta. Dependendo da versão do protocolo e da configuração, o broker pode armazenar assinaturas, mensagens em fila e estado de sessão de um cliente.

Isso é útil para dispositivos que dormem, se movem entre redes ou perdem conectividade temporariamente. Quando o dispositivo se reconecta, pode continuar recebendo mensagens que ficaram em fila enquanto estava offline, desde que a política de sessão e as regras de QoS permitam.

A persistência de sessão deve corresponder ao papel do dispositivo. Um sensor alimentado por bateria talvez não precise manter todos os comandos em fila para sempre. Um controlador remoto pode exigir atualizações de configuração em fila. Fila offline em excesso consome recursos do broker, enquanto fila insuficiente pode causar perda de comandos.

Mensagens de testamento para falhas inesperadas

Uma mensagem de testamento permite que um cliente defina uma mensagem que o broker deve publicar se o cliente se desconectar inesperadamente. Isso ajuda outros sistemas a detectar falha de dispositivo, perda de rede ou desligamento anormal.

Por exemplo, um dispositivo pode configurar uma mensagem de testamento em um tópico de status como device/123/status. Se o dispositivo perder energia sem enviar uma desconexão normal, o broker publica a mensagem offline configurada.

Esse recurso é amplamente usado em painéis de monitoramento, sistemas de saúde de dispositivos, telemetria industrial, supervisão de gateways e gestão remota de ativos. Ele oferece uma forma simples de expor desconexões anormais a outras partes do sistema.

Segurança e controle de acesso

Autenticação

O broker deve verificar a identidade do cliente antes de permitir acesso. A autenticação pode usar nome de usuário e senha, certificados de cliente, tokens, credenciais API ou integração com um sistema externo de identidade.

Autenticação fraca pode permitir que dispositivos não autorizados publiquem dados falsos, assinem tópicos sensíveis ou interrompam o ambiente de mensagens.

Autorização

Depois que a identidade é verificada, o broker deve decidir em quais tópicos o cliente pode publicar e quais pode assinar. Um sensor não deve poder publicar comandos para dispositivos não relacionados. Uma aplicação de um locatário não deve receber dados de outro locatário.

Permissões em nível de tópico são essenciais em implantações com muitos dispositivos, muitos locais e múltiplos locatários.

Criptografia

A criptografia TLS protege dados em trânsito entre clientes e o broker. Isso é importante quando mensagens passam por redes públicas, redes celulares, conexões em nuvem ou infraestrutura não confiável.

A criptografia deve ser combinada com gestão de certificados, armazenamento seguro de chaves e provisionamento cuidadoso de clientes. Uma camada de transporte segura não ajuda se credenciais estiverem expostas em firmware ou arquivos de configuração.

Padrões de implantação

Dispositivo para nuvem

Em muitos sistemas IoT, sensores e gateways publicam dados em um broker de nuvem. Aplicações em nuvem então armazenam, visualizam, analisam e agem sobre os dados. Esse modelo é comum em edifícios inteligentes, gestão de energia, monitoramento de frotas e plataformas de equipamentos remotos.

As principais preocupações de projeto são segurança, resiliência de rede, identidade de dispositivos, volume de mensagens e escalabilidade no lado da nuvem.

Agregação por gateway de borda

Um gateway de borda pode coletar dados de dispositivos locais e publicar dados resumidos ou filtrados em um broker central. Ele também pode assinar tópicos de comando e encaminhar instruções aos equipamentos locais.

Isso reduz largura de banda, melhora o controle local e permite que o local mantenha algumas funções mesmo quando a conexão com a nuvem não está disponível.

Broker local para sistemas de site

Algumas implantações usam um broker local dentro de uma fábrica, prédio, laboratório, campus ou sala de controle. Dispositivos e aplicações trocam dados localmente com baixa latência e menor dependência de redes externas.

Um broker local pode depois fazer ponte de dados selecionados para uma plataforma em nuvem ou empresarial. Isso dá aos projetistas mais controle sobre o fluxo de dados e a dependência de rede.

Aplicações em sistemas conectados

Monitoramento industrial

Fábricas e instalações de utilidades usam MQTT para coletar status de equipamentos, dados de sensores, mensagens de alarme, valores de energia, leituras de temperatura, dados de vibração e métricas de produção. O protocolo se ajusta a ambientes em que muitos dispositivos enviam pequenas mensagens para plataformas supervisórias.

Implantações industriais devem considerar segmentação de rede, redundância de broker, seleção de QoS, estado retido e provisionamento seguro de dispositivos.

Edifícios inteligentes

Sistemas prediais podem usar o protocolo para conectar iluminação, HVAC, controle de acesso, sensores de ocupação, medidores, elevadores, painéis de sala e dashboards. A estrutura de tópicos pode refletir a hierarquia de prédio, andar, sala e dispositivo.

Isso facilita organizar dados e ajuda regras de automação a assinar apenas eventos ou estados relevantes.

Energia e medição

Plataformas de energia podem usar MQTT para coletar leituras de medidores, dados de inversores, status de baterias, informações de carga e telemetria relacionada à rede. Mensagens leves são úteis quando muitos dispositivos reportam pequenos valores periodicamente.

Como sistemas de energia podem afetar cobrança, controle ou segurança, autenticação e integridade das mensagens devem ser tratadas com cuidado.

Veículos conectados e mobilidade

Plataformas veiculares, estações de recarga, sistemas de frota e serviços de mobilidade podem usar o protocolo para telemetria, atualizações de localização, diagnósticos, alertas e funções de controle remoto.

Redes móveis podem ser instáveis, portanto tratamento de sessão, lógica de reconexão e projeto eficiente da carga útil são importantes.

Consumo e automação residencial

Sistemas de automação residencial usam MQTT para conectar sensores, interruptores, luzes, termostatos, câmeras, hubs e regras de automação. O modelo de publicação/assinatura facilita que um evento de sensor acione várias ações.

Em implantações domésticas, nomes simples de tópicos e configuração segura do broker local são importantes para evitar confusão e acesso não autorizado.

Considerações de desempenho e escalabilidade

O tamanho da mensagem deve ser mantido razoável. O MQTT é eficiente para mensagens pequenas, mas não é ideal para arquivos muito grandes ou fluxos pesados de mídia. Cargas grandes podem aumentar uso de memória do broker, congestionamento de rede e atraso de processamento.

O projeto de tópicos afeta o desempenho. O uso excessivo de assinaturas com curingas amplos pode aumentar a carga do broker, pois muitas mensagens precisam ser comparadas e entregues a muitos clientes. Uma hierarquia clara ajuda os sistemas a escalar de forma mais previsível.

A quantidade de conexões é outro fator. Um broker atendendo milhares ou milhões de clientes deve lidar com tráfego keepalive, autenticação, estado de sessão, mensagens retidas, mensagens em fila e limites de rede. Escalar pode exigir clustering, balanceamento de carga, agregação na borda ou particionamento de tópicos.

O nível QoS também afeta o desempenho. QoS 2 oferece semântica de entrega mais forte, mas cria mais troca de pacotes. Para telemetria de alto volume, usar QoS 0 ou QoS 1 com lógica no nível da aplicação pode ser mais prático.

Erros comuns de projeto

Nomes de tópicos pouco claros

Nomes de tópicos aleatórios ou inconsistentes dificultam gerenciar permissões, painéis, alertas e análises. Um plano de tópicos deve ser criado antes de uma implantação em grande escala.

Usar mensagens retidas para eventos

Mensagens retidas são melhores para estado atual. Usá-las para eventos únicos pode enganar novos assinantes, pois eles podem receber um evento antigo como se tivesse acabado de ocorrer.

Sem tratamento de duplicatas

QoS 1 pode entregar duplicatas. As aplicações devem usar carimbos de tempo, IDs de mensagem, números de sequência ou processamento idempotente quando mensagens duplicadas puderem causar problemas.

Gestão fraca de credenciais

Senhas compartilhadas codificadas, IDs de cliente reutilizados e certificados sem proteção podem criar riscos sérios de segurança. Cada dispositivo deve ter uma identidade gerenciável e um caminho de revogação.

Ignorar falha do broker

O broker é central na arquitetura. Se ele falhar e não houver redundância ou plano de recuperação, a comunicação pode parar. Implantações críticas devem considerar clustering, brokers de backup, projeto de ponte ou comportamento local de contingência.

O MQTT funciona bem quando tópicos, sessões, QoS, estado retido, segurança e capacidade do broker são projetados em conjunto, em vez de configurados como ajustes isolados.

Manutenção e monitoramento

Equipes operacionais devem monitorar CPU do broker, memória, número de conexões, taxa de mensagens, quantidade de mensagens retidas, número de assinaturas, mensagens em fila, falhas de autenticação, conexões derrubadas e latência de rede.

A saúde dos clientes também deve ser visível. Reconexões repetidas, sessões expiradas, IDs de cliente duplicados, taxas anormais de publicação e acesso inesperado a tópicos podem indicar falhas de dispositivo ou problemas de segurança.

Backups de configuração são importantes. Configurações do broker, listas de controle de acesso, certificados, políticas de tópicos, ajustes de ponte e comportamento de estado retido devem ser documentados e recuperáveis.

Perguntas frequentes

O MQTT pode funcionar sobre WebSocket?

Sim. Muitos brokers oferecem suporte a MQTT sobre WebSocket, permitindo que aplicações baseadas em navegador e painéis web se comuniquem por caminhos de transporte amigáveis à web.

Ele é adequado para enviar vídeo grande ou conteúdo de arquivo?

Normalmente não como método principal. Ele é melhor para pequenas mensagens, telemetria, eventos, comandos e atualizações de estado. Arquivos grandes geralmente são transferidos por outros protocolos, com uma mensagem carregando a referência do arquivo.

O que acontece se dois clientes usam o mesmo ID de cliente?

Muitos brokers desconectarão o cliente existente quando um novo cliente se conectar com o mesmo ID. IDs de cliente exclusivos são importantes para comportamento de sessão estável.

Um broker pode se conectar a outro broker?

Sim. Ponte entre brokers ou clustering podem ser usados para trocar tópicos selecionados entre sites, regiões, gateways de borda e plataformas em nuvem, dependendo da capacidade do broker.

Como os nomes de tópicos devem ser planejados?

Use uma hierarquia consistente baseada em site, sistema, dispositivo, tipo de dado e função. Evite nomes aleatórios, informações sensíveis em caminhos de tópicos e dependência excessiva de curingas amplos.