Um broker MQTT é o servidor central que recebe todas as mensagens MQTT e as entrega aos clientes que as solicitaram. Neste guia para iniciantes você vai aprender como funciona o modelo publish/subscribe, o que um broker MQTT faz nos bastidores, como topics e wildcards são estruturados, quais as diferenças entre MQTT 3.1.1 e 5.0, e como enviar suas primeiras mensagens pela linha de comando e em Python.
O Que É MQTT?
MQTT é um protocolo de mensageria leve, projetado para dispositivos com banda, energia ou capacidade de processamento limitadas. Ele roda sobre TCP (e sobre WebSocket para navegadores), tem um cabeçalho fixo minúsculo de apenas dois bytes e mantém uma única conexão de longa duração aberta, em vez de fazer polling. Isso o torna uma escolha natural para sensores, gateways, veículos, medidores inteligentes e máquinas industriais, de uma usina em Minas Gerais a um frigorífico no Paraná, e igualmente útil para dashboards e serviços de backend que consomem esses dados.
MQTT é um padrão aberto da OASIS; a página oficial do protocolo é mqtt.org.
O Modelo Publish/Subscribe
Em um sistema clássico de request/response, como o HTTP, o cliente chama um servidor específico e espera a resposta. O MQTT usa publish/subscribe:
- Um publisher envia uma mensagem para um topic, por exemplo
home/livingroom/temperature. - Um subscriber informa ao broker em quais topics tem interesse.
- O broker fica no meio e encaminha cada mensagem para todos os subscribers cuja assinatura corresponde ao topic.
O fluxo fica assim:
[Temperature sensor] --PUBLISH home/livingroom/temperature 22.5--> [MQTT broker]
[MQTT broker] --deliver--> [Mobile app] (subscribed to home/+/temperature)
[MQTT broker] --deliver--> [Analytics service] (subscribed to home/#)
Três tipos de desacoplamento tornam isso poderoso:
- Espaço: o sensor não conhece o endereço do app, e o app não conhece o do sensor. Ambos só conhecem o broker.
- Tempo: com sessões persistentes e retained messages, o subscriber não precisa estar online no exato momento em que a mensagem é publicada.
- Escala: adicionar o décimo ou o milésimo subscriber não muda nada no publisher.
O Que Faz um Broker MQTT?
O broker MQTT é muito mais do que um repetidor. Ele cuida de várias tarefas ao mesmo tempo.
Gerenciar conexões
Cada cliente abre uma conexão TCP, TLS ou WebSocket e envia um pacote CONNECT com um client ID, usuário e senha opcionais, um intervalo de keep-alive e flags de sessão. O broker autentica o cliente, responde com CONNACK e depois monitora a conexão com PINGREQ/PINGRESP para detectar clientes que caíram.
Manter sessões
Uma sessão guarda as assinaturas de um cliente e as mensagens enfileiradas enquanto ele estava offline. Com uma clean session, o estado é descartado na desconexão. Com uma sessão persistente, o broker o mantém, e um dispositivo que perde a rede móvel recebe o que perdeu quando volta. O MQTT 5 substitui a antiga flag liga/desliga por um session expiry interval medido em segundos.
Rotear por topic
Cada PUBLISH recebido é comparado com todas as assinaturas ativas, incluindo filtros com wildcard, e entregue aos clientes correspondentes. O roteamento é o coração do broker MQTT, e é por isso que o design de topics importa.
Retained messages
O publisher pode ativar a flag retain. O broker guarda a última retained message de cada topic e a envia imediatamente a qualquer novo subscriber. Isso é ideal para estados como device/42/status = online ou para a configuração mais recente: um dashboard aberto depois ainda vê o valor atual sem esperar a próxima atualização.
Last Will and Testament
Ao se conectar, o cliente pode registrar uma mensagem de "last will", por exemplo device/42/status = offline. Se o cliente sumir sem um DISCONNECT limpo (queda de energia, falha de rede, timeout de keep-alive), o broker publica o will em nome dele. Combinado com uma mensagem online retida, isso garante uma detecção de presença confiável.
Quality of Service
O MQTT define três garantias de entrega, e o broker as aplica nos dois trechos do caminho (publisher até o broker, broker até o subscriber):
| QoS | Nome | Garantia | Uso típico |
|---|---|---|---|
| 0 | At most once | Envia e esquece, sem confirmação | Leituras frequentes de sensores em que perder uma amostra não tem problema |
| 1 | At least once | Confirmado com PUBACK, pode haver duplicatas | A maior parte da telemetria e dos eventos |
| 2 | Exactly once | Handshake em quatro etapas, sem duplicatas | Faturamento, comandos que não podem se repetir |
O QoS efetivo para um subscriber é o menor entre o QoS da publicação e o QoS da assinatura. Para se aprofundar, leia Níveis de QoS MQTT Explicados.
Topics e Wildcards MQTT
Topics são strings UTF-8 divididas em níveis por barras. Eles são criados na hora: não há nada para declarar com antecedência.
factory1/line1/cnc1/temperature
factory1/line1/cnc1/spindle_rpm
factory1/line2/press3/status
home/kitchen/light/state
Um bom design de topics vai do geral para o específico, evita barras iniciais e espaços e não coloca dados sensíveis nos nomes dos topics. Topics que começam com $ são reservados ao broker; por exemplo, o ConnectMQ publica $SYS/broker/connection/{clientId}/state.
Wildcard de um nível: +
O sinal de mais corresponde a exatamente um nível.
| Filtro de assinatura | Corresponde | Não corresponde |
|---|---|---|
factory1/+/cnc1/temperature |
factory1/line1/cnc1/temperature |
factory1/line1/cell2/cnc1/temperature |
home/+/light/state |
home/kitchen/light/state |
home/light/state |
Wildcard de vários níveis:
O sustenido corresponde a qualquer número de níveis, inclusive zero, e precisa ser o último caractere do filtro.
| Filtro de assinatura | Corresponde |
|---|---|
factory1/# |
factory1, factory1/line1/cnc1/temperature, factory1/line2/press3/status |
factory1/line1/# |
Tudo abaixo de factory1/line1 |
# |
Todos os topics que não começam com $ e que o cliente tem permissão de ver |
Wildcards só podem ser usados na assinatura; a publicação é sempre em um topic concreto. Em projetos industriais, uma hierarquia consistente como a ISA-95 (empresa, site, área, linha, célula) se torna um Unified Namespace; veja Sparkplug B e Unified Namespace para esse padrão.
MQTT 3.1.1 vs MQTT 5.0
A maioria dos brokers e bibliotecas atuais suporta as duas versões. O MQTT 5.0 mantém o mesmo modelo e adiciona recursos que facilitam a operação de grandes implantações.
| Recurso | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| Retorno de erros | Return codes limitados | Reason codes na maioria das confirmações (por exemplo 0x97 Quota exceeded) |
| Duração da sessão | Clean session liga/desliga | Session expiry interval |
| Duração da mensagem | Não disponível | Message expiry interval |
| Balanceamento de carga | Fora do padrão | Shared subscriptions $share/{group}/{filter} |
| Economia de banda | Topic completo toda vez | Topic aliases |
| Request/response | Convenções improvisadas | Response topic e correlation data |
| Limites do broker | Implícitos | Anunciados no CONNACK (Maximum QoS, Receive Maximum etc.) |
| Metadados | Só o payload | User properties |
Se você está começando um projeto novo, use MQTT 5.0, a menos que alguma biblioteca de dispositivo só suporte 3.1.1. A especificação completa é publicada pela OASIS em docs.oasis-open.org, e nosso panorama dos recursos do MQTT 5 cobre os destaques práticos.
Mão na Massa: Teste um Broker MQTT em Cinco Minutos
A forma mais rápida de entender um broker MQTT é usar um. O servidor MQTT público (gratuito) em broker.connectmq.com aceita testes anônimos e serve apenas para testes e protótipos, não para dados de produção.
| Protocolo | Porta | URL |
|---|---|---|
| MQTT (TCP) | 1883 | mqtt://broker.connectmq.com:1883 |
| MQTT sobre TLS | 8883 | mqtts://broker.connectmq.com:8883 |
| WebSocket | 8083 | ws://broker.connectmq.com:8083/mqtt |
| WebSocket seguro | 8084 | wss://broker.connectmq.com:8084/mqtt |
Regras do servidor MQTT público: conecte sem usuário nem senha, use um client ID único e não vazio (um client ID vazio é rejeitado) e lembre-se de que tudo o que você publica pode ser lido por qualquer pessoa. Escolha um prefixo aleatório como connectmq/demo/<your-random-id>/ e nunca envie dados pessoais ou sensíveis. Os limites são 64 KB por mensagem, 10 mensagens por segundo e 10 assinaturas por cliente, e até 8 níveis de topic.
Assine e publique com o mosquitto
Instale os clientes de linha de comando do Eclipse Mosquitto, abra um terminal e assine com um wildcard. Troque k9x2 por uma string aleatória sua:
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-k9x2 \
-t "connectmq/demo/k9x2/#" -v
Em um segundo terminal, publique uma leitura:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/temp" -m '{"temp":22.5}' -q 1
O primeiro terminal imprime:
connectmq/demo/k9x2/room1/temp {"temp":22.5}
Agora teste uma retained message. Publique um status com -r e depois inicie um novo subscriber que use apenas o wildcard de um nível:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/status" -m "online" -r
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub2-k9x2 \
-t "connectmq/demo/k9x2/+/status" -v -C 1
O novo subscriber recebe online imediatamente, mesmo tendo se conectado depois do envio da mensagem. É o broker guardando e reenviando o valor retido. Para apagá-lo, publique uma retained message vazia com -r -n.
Para tráfego criptografado, mude para a porta 8883, aponte o cliente para os certificados de CA do sistema (por exemplo --capath /etc/ssl/certs no Linux) e adicione -V mqttv5 para usar MQTT 5.0.
Exemplo em Python com last will
Instale o paho-mqtt 2.x com pip install paho-mqtt e execute:
import json
import uuid
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}"
CLIENT_ID = f"py-{uuid.uuid4().hex[:8]}"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{PREFIX}/#", qos=1)
client.publish(f"{PREFIX}/sensor1/status", "online", qos=1, retain=True)
client.publish(f"{PREFIX}/sensor1/temp", json.dumps({"temp": 21.8}), qos=1)
def on_message(client, userdata, msg):
print(f"{msg.topic} -> {msg.payload.decode()}")
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID,
protocol=mqtt.MQTTv5,
)
client.will_set(f"{PREFIX}/sensor1/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=30)
client.loop_forever()
O script registra um last will, se anuncia como online com uma retained message e publica uma leitura de temperatura que ele mesmo recebe de volta pela própria assinatura com wildcard. Se você encerrar o processo abruptamente, o broker publica offline no topic de status assim que o keep-alive expirar.
Prefere usar o navegador? O mesmo broker aceita conexões WebSocket nas portas 8083 e 8084; veja MQTT sobre WebSocket.
Do Servidor MQTT Público à Produção
O servidor MQTT público é perfeito para aprender e prototipar, mas produção exige credenciais privadas, TLS e isolamento de outros usuários. O ConnectMQ opera o broker para você: crie um no portal, receba usuário, senha e client ID e conecte via mqtts:// na porta 8883. Seus topics ficam isolados de outros tenants e do servidor MQTT público, e o portal oferece um explorador de topics ao vivo, dashboards e regras de alerta. Leia o guia sobre o broker MQTT gerenciado para comparar as opções de hospedagem.
Comece com o ConnectMQ
Cadastre-se em app.connectmq.com para criar seu próprio broker MQTT no plano Serverless (Free), sem cartão de crédito. Em poucos minutos você estará enviando mensagens via TLS, com os mesmos comandos que acabou de testar.
Perguntas frequentes
O que é um broker MQTT, em termos simples?
Um broker MQTT é um servidor que recebe mensagens de clientes que publicam e as encaminha a todos os clientes assinantes de um topic correspondente. Os dispositivos nunca falam diretamente entre si; eles só falam com o broker.
Qual a diferença entre um broker MQTT e um cliente MQTT?
Um cliente é qualquer dispositivo ou aplicação que publica ou assina, como um sensor ou um dashboard. O broker é o servidor no meio que autentica os clientes, mantém as sessões e roteia as mensagens entre eles.
Qual porta um broker MQTT usa?
As portas padrão são 1883 para MQTT sem criptografia e 8883 para MQTT sobre TLS. Conexões WebSocket costumam usar portas separadas; no broker.connectmq.com elas são 8083 e 8084, com o caminho /mqtt.
Existe um broker MQTT gratuito para testar?
Sim. O servidor MQTT público broker.connectmq.com aceita testes anônimos, e o plano Serverless (Free) do ConnectMQ oferece um broker MQTT gerenciado privado com credenciais e TLS.
Devo usar MQTT 3.1.1 ou MQTT 5.0?
Use MQTT 5.0 em projetos novos, porque ele adiciona reason codes, expiração de sessão e de mensagem, shared subscriptions e topic aliases. Recorra ao 3.1.1 apenas quando uma biblioteca de dispositivo não suportar a versão 5.
