Broker MQTT Público vs. Privado: Qual Combina com o Seu Projeto?

Escolher entre um broker MQTT público e um privado se resume a uma pergunta: quem mais pode ver e mexer nas suas mensagens? Este guia explica como os dois diferem em privacidade, autenticação, limites e confiabilidade, e mostra exatamente quando e como passar de um servidor MQTT público para um privado sem reescrever o seu código.

O que é um broker MQTT público

Um broker público é um servidor MQTT acessível pela internet ao qual qualquer pessoa pode se conectar sem conta. Você escolhe um client ID, assina um topic e começa a publicar. Existem vários; a ConnectMQ mantém o servidor MQTT público broker.connectmq.com, descrito em detalhes no artigo sobre o servidor MQTT público gratuito.

Brokers públicos são feitos para aprendizado, demonstrações, verificações rápidas de conectividade e compartilhamento de exemplos. Eles são abertos de propósito, e é exatamente por isso que não são lugar para dados reais de dispositivos.

Principais características de um broker público:

• Acesso anônimo. Sem usuário nem senha, então qualquer pessoa pode se conectar.
• Espaço de topics compartilhado. Todos os clientes veem a mesma árvore de topics. Se você assina um topic, um estranho também pode assinar.
• Limites de proteção. Para continuar utilizável por todos, brokers públicos limitam o tamanho das mensagens, a taxa e as assinaturas.
• Nenhuma garantia. São um serviço comunitário gratuito, não uma plataforma de produção.

O que é um broker MQTT privado

Um broker privado aceita apenas clientes com credenciais válidas. O espaço de topics pertence a você e aos seus dispositivos. Ele pode ser auto-hospedado ou um broker MQTT gerenciado; em qualquer caso, as características que o definem são:

• Autenticação. Os clientes apresentam usuário, senha e, normalmente, um client ID que o broker reconhece.
• Isolamento. Outros tenants não conseguem ler nem publicar nos seus topics.
• Criptografia por padrão. TLS na 8883 e Secure WebSocket na 8084 para navegadores.
• Limites dimensionados para o seu plano, e não para uma multidão de usuários anônimos.

Se quiser um contexto mais amplo sobre brokers MQTT, esse artigo aborda o próprio modelo publish/subscribe.

Broker MQTT público vs. privado em resumo

O protocolo é idêntico. MQTT 3.1.1 e MQTT 5.0 se comportam da mesma forma nos dois; só o acesso e os limites mudam.

Quando um broker público é a ferramenta certa

Use um broker público quando os dados não tiverem valor para mais ninguém e a velocidade for o que mais importa:

1. Aprender MQTT. Publique, assine, experimente curingas e retained messages em minutos.
2. Workshops e salas de aula. Todos os participantes se conectam sem configurar nada.
3. Testar uma nova biblioteca ou placa. Confirme se o seu ESP32 ou script Python consegue sequer alcançar um broker.
4. Compartilhar um exemplo reproduzível. Um post de blog ou relato de bug que qualquer pessoa pode executar.

Um teste rápido fica assim:

# Assine com um prefixo único para não se misturar com outros usuários
mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-c41d -t "connectmq/demo/c41d/#" -v

# Publique a partir de outro terminal
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-c41d -t "connectmq/demo/c41d/hello" -m "it works"

Use sempre um prefixo de topic aleatório e único, como connectmq/demo/c41d/. Ele mantém o seu tráfego de teste separado do de outras pessoas, embora não o torne privado.

Quando você precisa de um broker privado

Passe para um broker privado assim que qualquer uma destas situações for verdadeira:

• Os dados identificam uma pessoa, casa, veículo ou localização. Valores de sensores que revelam quando uma casa está vazia são sensíveis, e dados pessoais também estão sujeitos à LGPD.
• Os dispositivos aceitam comandos. Em um broker público, qualquer pessoa pode publicar no seu topic de comandos, por exemplo o que liga uma bomba em uma estação de saneamento.
• Você está rodando um piloto com um cliente. Ele vai esperar autenticação e criptografia.
• Você precisa de mensagens maiores, mais throughput ou mais assinaturas do que os limites públicos permitem.
• O uptime importa. Um serviço público de testes não é base para construir um produto.

O artigo sobre limitações de broker MQTT público explica cada uma dessas restrições com mais profundidade.

Migrando do público para o privado sem reescrever nada

Como os dois lados falam MQTT padrão, a troca é uma mudança de configuração. Aqui está um exemplo em Python com paho-mqtt 2.x que lê o destino de variáveis de ambiente, de modo que o mesmo código roda contra os dois:

import os
import ssl
import paho.mqtt.client as mqtt

HOST = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
USERNAME = os.getenv("MQTT_USERNAME")          # não definido para o broker público
PASSWORD = os.getenv("MQTT_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "demo-c41d-py")
TOPIC = os.getenv("MQTT_TOPIC", "connectmq/demo/c41d/temp")


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)
    client.publish(TOPIC, "21.7", qos=1)


def on_message(client, userdata, msg):
    print(msg.topic, msg.payload.decode())


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=CLIENT_ID,
    protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_message = on_message

if USERNAME:
    client.username_pw_set(USERNAME, PASSWORD)
if PORT == 8883:
    client.tls_set(cert_reqs=ssl.CERT_REQUIRED)

client.connect(HOST, PORT, keepalive=60)

try:
    client.loop_forever()
except KeyboardInterrupt:
    client.disconnect()

Para o broker privado, defina as variáveis a partir do seu portal da ConnectMQ:

export MQTT_HOST=broker.connectmq.com
export MQTT_PORT=8883
export MQTT_USERNAME=YOUR_USERNAME
export MQTT_PASSWORD=YOUR_PASSWORD
export MQTT_CLIENT_ID=YOUR_CLIENT_ID
export MQTT_TOPIC=plant1/line1/temp
python client.py

Observe que, na ConnectMQ, o client ID fica vinculado às credenciais emitidas, então use o client ID gerado pelo portal em vez de inventar um novo.

Erros comuns na hora de trocar

• Deixar a porta 1883 no firmware de produção. Use 8883 (TLS) para dispositivos e 8084 com o caminho /mqtt para navegadores.
• Manter o prefixo de topic da demonstração. Renomeie os topics para uma estrutura real, por exemplo site/área/linha/dispositivo. O guia de broker MQTT na nuvem traz orientações sobre design de topics para brokers hospedados.
• Deixar credenciais fixas no código em um repositório público. Carregue-as de variáveis de ambiente, de um cofre de segredos ou do provisionamento dos dispositivos.
• Reutilizar o mesmo client ID em vários dispositivos. O broker desconecta a sessão mais antiga toda vez que o outro se conecta, causando um loop de reconexões.
• Presumir QoS 2 em todo lugar. O plano Serverless gratuito suporta QoS até 1. Se precisar de QoS 2, use um plano pago ou projete um tratamento idempotente com QoS 1. Veja níveis de QoS do MQTT explicados.

Checklist de segurança para o seu broker privado

Migrar para um broker privado elimina o acesso anônimo, mas alguns hábitos determinam o quão seguro o resultado realmente é:

1. Um conjunto de credenciais por dispositivo ou serviço. Se um dispositivo for perdido ou comprometido, você pode revogá-lo sem mexer nos outros.
2. TLS em todo lugar fora do laboratório. Verifique o certificado do servidor no seu cliente em vez de desativar a verificação para contornar um erro.
3. Separe topics de telemetria e de comando. Deixe óbvio na árvore de topics quais mensagens alteram o estado de equipamentos reais e revise quem publica nelas.
4. Acompanhe o log de conexões. Logins malsucedidos repetidos geralmente indicam um dispositivo mal configurado ou uma credencial vazada. O seu broker pode bloquear um IP após falhas repetidas, mas você ainda vai querer encontrar a causa.
5. Mantenha um prefixo de topic de teste para experimentos, para que o tráfego de depuração nunca se misture com os dados de produção.

O guia de boas práticas de segurança MQTT aprofunda cada um desses pontos.

Uma regra prática simples

Use o servidor MQTT público para qualquer coisa que você ficaria à vontade em postar em um fórum. Use um broker privado para todo o resto. Como a migração custa apenas alguns valores de configuração, não há motivo para manter dispositivos reais em um broker público além da primeira tarde.

Tenha o seu broker privado na ConnectMQ

Quando estiver pronto para ir além dos testes, cadastre-se em um plano Serverless gratuito, sem cartão de crédito. Crie um broker, copie o usuário, a senha e o client ID gerados e aponte o mesmo código para a porta 8883. O cliente MQTT no navegador e o explorador de topics ao vivo do portal permitem confirmar o tráfego na hora. Saiba mais sobre a ConnectMQ e sobre como um broker MQTT gerenciado elimina o trabalho de operação.

Perguntas frequentes

Outras pessoas podem ver as minhas mensagens em um broker MQTT público?

Sim. Qualquer pessoa pode assinar qualquer topic em um broker público, inclusive com curingas como #. Nunca envie dados pessoais, credenciais ou comandos que controlem equipamentos reais.

Um broker MQTT privado é sempre criptografado?

Não automaticamente, mas um bom broker MQTT gerenciado privado oferece TLS na 8883 e Secure WebSocket na 8084. Use essas portas em produção em vez de TCP simples na 1883.

Preciso mudar o meu código para passar do público para o privado?

Normalmente só mudam o host, a porta, as credenciais e o client ID. Se o seu código lê esses valores da configuração, a troca leva minutos.

Um broker privado gratuito é suficiente para um protótipo?

Para muitos protótipos, sim. O plano Serverless gratuito da ConnectMQ permite até 25 conexões, QoS até 1 e mensagens de 256 KB, o que cobre a maioria dos pilotos pequenos.