As cotas de conexão de broker MQTT decidem quantos clients você pode conectar, com que rapidez eles podem publicar e qual o tamanho máximo de cada mensagem. Este guia explica todas as cotas comuns em um broker MQTT gerenciado, como brokers MQTT 3.1.1 e MQTT 5 sinalizam que você atingiu uma delas e como escrever clients que fiquem com folga dentro dos limites do seu plano.
Por Que Brokers MQTT Gerenciados Aplicam Cotas
Um broker MQTT gerenciado é infraestrutura compartilhada, mesmo quando você tem um cluster dedicado. Memória, CPU, banda de rede e descritores de arquivo são finitos, e um único client mal-comportado, como um firmware preso em um loop de publicação ou uma tempestade de reconexões após uma queda de Wi-Fi, pode degradar o serviço para todos os outros nas mesmas máquinas. As cotas transformam esses recursos finitos em limites explícitos e previsíveis.
Em um serviço multi-tenant, as cotas também são a forma como o isolamento funciona na prática. A ConnectMQ, por exemplo, aplica cotas por plano, proteção contra flood e bloqueio de IP após falhas repetidas de login, para que o problema de um tenant continue sendo problema só daquele tenant. Se o modelo é novo para você, nosso explicativo sobre o que um broker MQTT faz cobre o básico de como clients e brokers interagem.
As Cotas Comuns de Broker MQTT
A maioria dos provedores aplica alguma combinação das cotas abaixo. Os nomes variam, mas os conceitos são os mesmos em todo lugar.
| Cota | O que conta | Sintoma típico ao exceder |
|---|---|---|
| Conexões simultâneas | Sessões de clients abertas no mesmo instante | Novo CONNECT é recusado |
| Taxa de conexões | Novas conexões por segundo ou minuto | Reconexões falham durante tempestades |
| Taxa de mensagens | Publicações por segundo por client ou conta | O client sofre throttling ou é desconectado |
| Tamanho máximo de payload | Bytes em um único PUBLISH | Publicação rejeitada ou conexão fechada |
| Assinaturas por client | Filtros de topic que um client pode manter | O SUBACK retorna um código de falha |
| Profundidade de topic | Número de níveis separados por / |
Publicação ou assinatura rejeitada |
| QoS mais alto | 0, 1 ou 2 | Assinatura concedida com QoS menor |
| Expiração de sessão | Por quanto tempo o broker mantém uma sessão offline | Mensagens enfileiradas perdidas após a expiração |
Limites reais de planos como exemplo
Veja como a ConnectMQ define seus limites por plano:
- Serverless (Free): até 25 conexões, QoS até 1, mensagens de até 256 KB.
- Serverless (Paid): até 1.000 conexões, QoS 2, mensagens de até 1 MB, shared subscriptions.
- Dedicated, BYOC e Self Managed Enterprise: implantações isoladas dimensionadas para a sua carga.
- Servidor MQTT público (broker.connectmq.com), apenas para testes e protótipos: 64 KB por mensagem, 10 mensagens por segundo por client, 10 assinaturas por client, 8 níveis de topic, QoS de 0 a 2 e expiração de sessão de até 30 minutos.
Como os Brokers Sinalizam que Você Atingiu uma Cota
É aqui que a versão do protocolo faz muita diferença.
MQTT 3.1.1: adivinhando a partir das desconexões
O MQTT 3.1.1 tem apenas um punhado de códigos de retorno no CONNACK e nenhuma forma de o broker explicar uma desconexão. Quando um client 3.1.1 excede um limite, o broker normalmente apenas fecha a conexão TCP. O client vê um genérico "connection lost" e reconecta, muitas vezes batendo de novo no mesmo limite. Diagnosticar problemas de cota no 3.1.1 significa correlacionar logs do client com o que o console do provedor mostrar.
MQTT 5: reason codes explícitos
O MQTT 5 adicionou reason codes a CONNACK, PUBACK, SUBACK e DISCONNECT, o que torna os problemas de cota visíveis para o client. Os que você mais vai encontrar estão definidos na especificação OASIS MQTT 5.0:
| Código | Nome | Significado na prática |
|---|---|---|
| 0x87 | Not authorized | Credenciais ou client ID não permitem esta ação |
| 0x8E | Session taken over | Outro client conectou com o mesmo client ID |
| 0x95 | Packet too large | O payload excede o tamanho máximo de pacote |
| 0x96 | Message rate too high | Taxa de publicação excedida |
| 0x97 | Quota exceeded | Uma cota da implementação ou do plano foi atingida |
| 0x9F | Connection rate exceeded | Tentativas de conexão demais |
A ConnectMQ suporta os reason codes do MQTT 5, incluindo 0x97 quota exceeded, para que um client com MQTT 5 registre uma causa precisa em vez de uma desconexão vaga. Só isso já é um forte motivo para usar MQTT 5 em projetos novos; veja recursos do MQTT 5 para o restante.
Brokers MQTT 5 também podem anunciar limites logo de início em propriedades do CONNACK, como Maximum Packet Size, Receive Maximum, Topic Alias Maximum e Maximum QoS. Um client bem escrito as lê e se adapta.
Como Projetar Clients que Ficam Dentro das Cotas
A melhor estratégia de cotas é um client que nunca chega perto do limite. Estas práticas evitam a maioria dos incidentes de cota.
Leia os limites do broker no momento da conexão
O exemplo em Python abaixo conecta com paho-mqtt 2.x sobre TLS, imprime os limites que o broker anuncia e registra os reason codes na desconexão.
import paho.mqtt.client as mqtt
LIMIT_PROPS = ("MaximumPacketSize", "ReceiveMaximum",
"TopicAliasMaximum", "MaximumQoS", "SharedSubscriptionAvailable")
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("connect refused:", reason_code)
return
print("connected")
for name in LIMIT_PROPS:
value = getattr(properties, name, None)
if value is not None:
print(f" broker limit {name} = {value}")
def on_disconnect(client, userdata, flags, reason_code, properties):
print("disconnected:", reason_code)
if reason_code == "Quota exceeded":
print("plan quota hit; back off and alert an operator")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Se quiser experimentar antes sem conta, aponte o mesmo script para o servidor MQTT público (gratuito) na porta 1883, com um client ID único e sem credenciais.
Limite a taxa de publicação no client
Nunca dependa do broker para fazer throttling por você. Um pequeno token bucket mantém as rajadas sob controle, o que importa principalmente quando um dispositivo reconecta e tenta descarregar um backlog.
const mqtt = require("mqtt");
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
clientId: "YOUR_CLIENT_ID",
username: "YOUR_USERNAME",
password: "YOUR_PASSWORD",
protocolVersion: 5,
reconnectPeriod: 5000,
});
// Token bucket: no máximo RATE mensagens por segundo, rajada de até BURST.
const RATE = 5;
const BURST = 10;
let tokens = BURST;
setInterval(() => { tokens = Math.min(BURST, tokens + RATE); }, 1000);
const queue = [];
function enqueue(topic, payload) { queue.push({ topic, payload }); }
setInterval(() => {
while (tokens >= 1 && queue.length > 0 && client.connected) {
const { topic, payload } = queue.shift();
client.publish(topic, payload, { qos: 1 });
tokens -= 1;
}
}, 100);
client.on("connect", () => console.log("connected"));
client.on("disconnect", (packet) => console.log("broker disconnect, reason", packet.reasonCode));
// Simula o envio de um backlog após uma queda.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));
Use backoff com jitter na reconexão
Quando um site, como uma mineradora no Pará ou uma fazenda com link rural instável, perde conectividade, centenas de dispositivos podem reconectar no mesmo segundo. Sem backoff randomizado, eles batem juntos na cota de taxa de conexões, falham juntos e tentam de novo juntos. Adicione jitter aleatório a cada atraso de reconexão e limite o atraso máximo a um ou dois minutos.
Mantenha os client IDs únicos e estáveis
Em brokers MQTT gerenciados que vinculam client IDs às credenciais emitidas, como a ConnectMQ, duplicatas são uma armadilha comum. Se você copiar um conjunto de credenciais para dois dispositivos, cada conexão derruba a outra, o que o MQTT 5 reporta como 0x8E session taken over. O resultado parece uma conexão instável e consome rapidamente os limites de taxa de conexões. Emita um conjunto de credenciais por dispositivo ou serviço.
Agrupe leituras pequenas
Dez valores de sensor em uma mensagem JSON custam uma publicação em vez de dez. O agrupamento mantém as taxas de mensagens baixas e geralmente reduz a banda, desde que o lote fique bem abaixo do limite de payload do seu plano.
Use menos assinaturas, e mais amplas
Um único curinga como site1/+/telemetry é mais barato de gerenciar do que dezenas de assinaturas exatas e mantém você longe dos tetos de assinaturas por client.
Checklist de Preparação para Cotas
Antes do rollout, percorra esta lista para cada tipo de client:
- Conte as conexões simultâneas, incluindo dashboards, scripts e integrações.
- Calcule o pico de publicações por segundo por client, não apenas a média.
- Meça o maior payload, incluindo envios de backlog e dumps de erro.
- Confirme o nível de QoS de que cada topic precisa e se o plano o suporta.
- Verifique se cada dispositivo tem o seu próprio client ID e credenciais.
- Implemente backoff exponencial com jitter para reconexões.
- Registre os reason codes do MQTT 5 e envie-os para um lugar onde você possa pesquisar.
- Deixe folga: planeje para cerca do dobro da carga esperada, para que o crescimento não surpreenda você.
Para a matemática de dimensionamento por trás dos pontos 2 e 3, leia como estimar mensagens MQTT por segundo. Se você está comparando opções de entrada, nosso guia sobre broker MQTT com plano gratuito mostra como as cotas diferem entre planos grátis, e o guia principal de broker MQTT na nuvem cobre as escolhas de hospedagem de forma mais ampla.
Solução de Problemas de Cota
- Conexões caem a cada poucos segundos: verifique client IDs duplicados antes de qualquer outra coisa.
- Mensagens grandes desaparecem: compare o tamanho do payload com o limite do plano e com a propriedade Maximum Packet Size do broker.
- Assinaturas silenciosamente não recebem nada: inspecione os reason codes do SUBACK; um código de falha significa que o filtro não foi aceito.
- Tudo falha após uma queda geral do site: sua lógica de reconexão não tem jitter e você está acionando a proteção de taxa de conexões.
- Desconexões sem explicação no MQTT 3.1.1: mude temporariamente o client para MQTT 5 para obter um reason code.
Comece com um Plano MQTT Gerenciado
A ConnectMQ publica os limites dos seus planos com clareza e reporta problemas de cota com reason codes do MQTT 5, para que você projete em torno deles desde o primeiro dia. Comece no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, e depois suba para Serverless pago, Dedicated ou BYOC conforme a frota cresce. Se preferir que outra pessoa opere toda a infraestrutura, um broker MQTT gerenciado cuida de patches, TLS e capacidade para você.
Perguntas frequentes
O que significa o reason code MQTT 0x97?
0x97 é "Quota exceeded" no MQTT 5. O broker está dizendo ao client que um limite da implementação ou do plano foi atingido, então o client deve aplicar backoff em vez de tentar de novo imediatamente.
Dashboards e scripts contam para as cotas de conexão?
Sim. Todo client MQTT com uma sessão aberta conta como uma conexão, seja um sensor, um flow do Node-RED ou uma aba de navegador.
Como sei o tamanho máximo de mensagem que meu broker aceita?
Consulte a documentação do plano e, no MQTT 5, leia a propriedade Maximum Packet Size no CONNACK. O plano Serverless gratuito da ConnectMQ permite 256 KB, e o plano Serverless pago permite 1 MB.
Por que meu dispositivo fica reconectando em loop?
A causa mais comum são dois clients compartilhando um client ID, o que faz o broker desconectar a sessão mais antiga a cada vez. Dê a cada dispositivo as suas próprias credenciais e client ID.



