As limitações de um broker MQTT público são fáceis de ignorar na primeira hora empolgante de um projeto e dolorosas de descobrir na frente de um cliente. Este artigo explica as quatro principais restrições dos brokers públicos de testes, usando o servidor MQTT público da ConnectMQ, broker.connectmq.com, como exemplo concreto, mostra como projetar os seus testes para funcionar dentro delas e lista os sinais claros de que chegou a hora de migrar para um broker privado.
Por que brokers públicos têm limites
Um broker público é um serviço compartilhado e anônimo. Qualquer pessoa na internet pode se conectar, publicar e assinar sem conta. Essa abertura é exatamente o que o torna útil para tutoriais e testes rápidos, e exatamente o motivo pelo qual ele precisa de limites: sem eles, um único script com problema poderia inundar o broker e arruiná-lo para todos os outros.
Os limites não são um defeito. São eles que mantêm utilizável um serviço comunitário gratuito. A ConnectMQ mantém o broker.connectmq.com exatamente com esse propósito: um lugar sem configuração para aprender MQTT, testar uma biblioteca ou mostrar uma demonstração, ao lado de brokers privados para cargas de trabalho reais. O artigo sobre o servidor MQTT público (gratuito) descreve como usar o broker.connectmq.com com eficiência; este artigo foca no que ele não consegue fazer.
Limitação 1: nenhuma privacidade
Em um broker público, todo topic pode ser lido por todo cliente. Quem assina # recebe tudo o que é publicado, sujeito às proteções do próprio broker. Nomes de topics não são segredos, e prefixos obscuros apenas reduzem colisões acidentais.
Na prática, isso significa:
- Nunca publique dados pessoais, rastros de localização, imagens de câmeras ou qualquer coisa que identifique uma pessoa ou uma casa; no Brasil, isso também esbarra nas obrigações da LGPD.
- Nunca publique credenciais, chaves de API ou senhas de Wi-Fi, nem "temporariamente".
- Nunca controle equipamentos reais a partir de um topic público. Qualquer pessoa pode publicar no seu topic de comandos, e não apenas lê-lo.
- Presuma que os payloads são registrados por alguém, em algum lugar.
Use um prefixo aleatório como connectmq/demo/9b2e7/ para que o seu tráfego de teste não colida com o de outras pessoas. É uma cortesia e uma conveniência, não uma medida de segurança.
Limitação 2: nenhuma garantia de serviço
Brokers públicos são oferecidos como serviço de melhor esforço. Não há SLA, uptime garantido nem compromisso de suporte. O broker pode reiniciar para manutenção, os limites podem mudar e as sessões não sobrevivem além da janela de expiração. No broker.connectmq.com, a expiração de sessão é limitada a 30 minutos, então um dispositivo que fica offline por mais tempo começa do zero.
Para uma demonstração ou um workshop, tudo bem. Para um produto, um piloto ou qualquer coisa da qual um cliente dependa, não.
Planeje para o silêncio
Como não há garantias, escreva os seus clientes de teste para lidar com interrupções. Ative a reconexão automática, refaça as assinaturas no callback de conexão em vez de uma única vez na inicialização e não trate uma mensagem ausente como bug no seu próprio código até descartar um reinício do broker. Esses hábitos são boas práticas em qualquer broker e tornam mais tranquila a migração posterior para produção.
Limitação 3: um espaço de topics compartilhado
Todos os usuários públicos compartilham uma única árvore de topics. As consequências incluem:
- Colisões. Nomes populares como
test,sensor/tempouhome/livingroomsão usados por muita gente. Você vai receber as mensagens dessas pessoas, e elas, as suas. - Surpresas com retained messages. A retained message de outra pessoa em um topic genérico aparece no instante em que você assina.
- Ruído de curingas. Assinar de forma ampla retorna tráfego que você nunca pediu e desperdiça a sua cota de taxa.
Sempre coloque os topics sob um prefixo único e assine de forma restrita.
Limitação 4: limites de taxa, tamanho e assinaturas
O servidor MQTT público da ConnectMQ limita os recursos por cliente para que todos tenham acesso justo. Em broker.connectmq.com, os limites são:
| Limite | Valor no servidor MQTT público | Por que existe |
|---|---|---|
| Tamanho da mensagem | 64 KB por mensagem | Evita que payloads grandes dominem a banda |
| Taxa de publicação | 10 mensagens por segundo por cliente | Impede que scripts inundem o broker |
| Assinaturas | 10 por cliente | Limita o custo de fan-out por cliente |
| Profundidade do topic | 8 níveis de topic | Mantém a correspondência de topics eficiente |
| QoS | 0, 1 e 2 | Comportamento completo do protocolo para aprendizado |
| Expiração de sessão | Até 30 minutos | Libera recursos de sessões abandonadas |
| Autenticação | Anônima, qualquer client ID único e não vazio | Zero configuração para quem está aprendendo |
Exceder um limite pode resultar em operações rejeitadas ou em desconexão. Se você se conectar com MQTT 5, registre os reason codes que o seu cliente recebe; eles dizem muito mais do que um genérico "connection lost".
Projetando testes que respeitam os limites
Aqui está um publicador Python (paho-mqtt 2.x) que fica bem dentro dos limites públicos: client ID único, prefixo único, topics rasos, limite de taxa e payloads compactos.
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN_ID = uuid.uuid4().hex[:6]
PREFIX = f"connectmq/demo/{RUN_ID}" # 3 níveis, deixa espaço abaixo
MAX_RATE = 5 # mensagens por segundo, abaixo do limite de 10/s
INTERVAL = 1.0 / MAX_RATE
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code, "prefix:", PREFIX)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Disconnected:", reason_code)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=f"limits-demo-{RUN_ID}",
protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
try:
for i in range(50):
payload = json.dumps({"i": i, "t": round(20 + random.random() * 2, 2)})
assert len(payload.encode()) < 64 * 1024
client.publish(f"{PREFIX}/sensor/temp", payload, qos=1)
time.sleep(INTERVAL)
finally:
client.loop_stop()
client.disconnect()
Acompanhe a partir de um segundo terminal, assinando de forma restrita apenas o seu próprio prefixo:
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-RUNID -t "connectmq/demo/RUNID/#" -v
Substitua RUNID pelo prefixo exibido pelo script.
Armadilhas comuns
- Client ID vazio. O servidor MQTT público exige um client ID não vazio. Gere um único a cada execução.
- Dois scripts com o mesmo client ID. Cada conexão derruba a outra, gerando um loop de reconexões.
- Loops de publicação apertados. Um
while Truesem sleep excede o limite de taxa em um segundo. - Árvores de topics profundas.
connectmq/demo/abc/site/area/line/cell/machine/sensortem 9 níveis e excede o limite de 8. Achate os topics de teste. - JSON grande ou imagens. Qualquer coisa perto de 64 KB pertence a um broker privado, e imagens raramente pertencem ao MQTT.
Sinais de que chegou a hora de um broker privado
Saia do servidor MQTT público assim que notar qualquer um destes sinais:
- Os dados constrangeriam ou prejudicariam alguém se um estranho os lesse.
- Um dispositivo executa os comandos que recebe, como uma bomba de irrigação numa fazenda ou uma válvula numa estação de saneamento.
- Um cliente, colega ou professor depende de o sistema funcionar amanhã.
- Você precisa de mais de 10 assinaturas por cliente, mensagens maiores ou hierarquias de topics mais profundas.
- Você quer ver quem está conectado e manter credenciais por dispositivo.
A comparação broker MQTT público vs. privado mostra a troca passo a passo, e do protótipo à produção cobre o restante da jornada.
O que muda em um plano privado
Um broker MQTT gerenciado privado da ConnectMQ mantém o mesmo protocolo e o mesmo código de cliente, mas muda as regras:
- Autenticação com usuário, senha e client ID gerados, com o client ID vinculado a essas credenciais.
- Isolamento dos outros tenants, para que o espaço de topics seja só seu.
- TLS na 8883 e Secure WebSocket na 8084 com certificado Let's Encrypt.
- Limites por plano: o plano Serverless gratuito permite até 25 conexões, QoS até 1 e mensagens de 256 KB; o plano Serverless pago eleva isso para até 1.000 conexões, QoS 2, mensagens de 1 MB e shared subscriptions.
- Ferramentas do portal, como cliente no navegador, explorador de topics ao vivo, dashboard e alertas por limite.
Migre para um broker privado da ConnectMQ gratuitamente
Quando o servidor MQTT público tiver cumprido o seu papel, crie o seu broker privado gratuito no plano Serverless, sem cartão de crédito, e aponte o mesmo script para a porta 8883 com as novas credenciais. Leia o guia de broker MQTT na nuvem para planejar os próximos passos, veja por que um broker MQTT gerenciado poupa esforço de operação ou visite connectmq.com para comparar os planos.
Perguntas frequentes
É seguro usar um broker MQTT público?
É seguro para aprendizado e demonstrações com dados inofensivos. Não é seguro para dados pessoais, credenciais ou controle de equipamentos reais, porque qualquer pessoa pode ler e publicar em qualquer topic.
O que acontece se eu exceder o limite de taxa do servidor MQTT público?
As operações podem ser rejeitadas ou o cliente desconectado. Mantenha a publicação abaixo de 10 mensagens por segundo por cliente e verifique os reason codes do MQTT 5 ao depurar.
Por que recebo mensagens que eu não publiquei?
Outros usuários publicam nos mesmos nomes de topic. Use um prefixo único como connectmq/demo/<random-id>/ e assine apenas esse prefixo.
O servidor MQTT público mantém a minha sessão se o meu dispositivo ficar offline?
Apenas dentro da janela de expiração de sessão, que é limitada a 30 minutos no broker.connectmq.com. Depois disso, o dispositivo começa uma sessão nova.
