Quantas conexões um broker MQTT suporta? A resposta honesta é "depende", mas depende de uma lista curta e específica de recursos que você pode medir e planejar. Este artigo explica o que limita as conexões MQTT simultâneas, por que os números divulgados raramente correspondem à sua carga de trabalho, como testar a capacidade por conta própria e como os provedores de broker MQTT gerenciado traduzem tudo isso em limites de plano.
Por Que Não Existe um Número Único
Você encontrará contagens de conexões impressionantes no marketing de fornecedores e em palestras de conferências. Normalmente são reais, mas foram medidas em condições específicas: clientes ociosos, sem TLS ou com retomada de sessão, payloads minúsculos ou inexistentes, hardware generoso e kernels cuidadosamente ajustados. Mude qualquer um desses fatores e o número muda.
O que importa para você não é o máximo que um broker atinge em laboratório, mas quantos dos seus clientes, com o seu keepalive, TLS, assinaturas e padrões de mensagens, uma determinada implantação consegue atender com folga. Para isso, é preciso entender os gargalos.
O Que Limita as Conexões MQTT Simultâneas
| Recurso | Por que cada conexão o consome | O que piora a situação |
|---|---|---|
| Memória | Buffers de socket, estado TLS, objeto de sessão, assinaturas, mensagens em trânsito | Buffers grandes, muitas assinaturas por cliente, mensagens QoS 1/2 enfileiradas |
| File descriptors | Todo socket TCP é um arquivo aberto em sistemas do tipo Unix | Ulimits padrão baixos, descritores extras para logs e persistência |
| CPU para TLS | Os handshakes envolvem criptografia de chave pública | Tempestades de reconexão, ausência de retomada de sessão, chaves grandes |
| CPU para keepalives | PINGREQ e PINGRESP de cada cliente a cada intervalo | Intervalos de keepalive muito curtos em frotas grandes |
| Rede e kernel | Tabelas de conexão, filas de accept, limites do load balancer | Backlog de accept pequeno, tabelas conntrack, limites por IP |
| Estado de sessão | Sessões persistentes sobrevivem a desconexões | Expiração de sessão longa para clientes que nunca voltam |
Memória
A memória costuma ser o primeiro limite rígido em grandes frotas de dispositivos pouco ativos. Cada conexão carrega buffers de socket do kernel, as estruturas por cliente do próprio broker, o estado da sessão TLS e eventuais mensagens enfileiradas. As assinaturas somam mais, especialmente com muitos filtros curinga. Clientes que se desconectam com sessões persistentes continuam usando memória até a sessão expirar.
File descriptors
No Linux, cada socket consome um file descriptor. O limite flexível padrão em muitas distribuições é baixo demais para um broker, e é por isso que "too many open files" é um dos erros mais comuns quando alguém começa a hospedar o próprio broker. Você pode inspecionar e aumentar esse limite:
# Limites atuais do shell
ulimit -n
ulimit -Hn
# Limites de um processo de broker em execução (substitua PID)
cat /proc/PID/limits | grep "open files"
# Contar os sockets abertos do broker
ls /proc/PID/fd | wc -l
Para um serviço systemd, aumente o limite em um arquivo drop-in:
# /etc/systemd/system/mosquitto.service.d/limits.conf
[Service]
LimitNOFILE=200000
Em seguida, execute sudo systemctl daemon-reload && sudo systemctl restart mosquitto.
TLS
O TLS protege toda conexão de produção, e isso tem um custo. A criptografia contínua de mensagens MQTT pequenas é barata, mas o handshake é comparativamente caro. Isso pesa mais quando muitos clientes se conectam ao mesmo tempo, por exemplo após uma queda de energia em todo o site ou um reinício do broker. Um broker que sustenta com tranquilidade sua frota em regime estável pode ainda assim ter dificuldade para aceitar todos no mesmo minuto. Atrasos de reconexão com jitter nos clientes são a melhor defesa.
Keepalives
Cada cliente envia um PINGREQ quando não tem mais nada a enviar dentro do seu intervalo de keepalive. Em uma frota grande, keepalives muito curtos geram uma carga de fundo constante. Um keepalive entre 30 e 60 segundos é um equilíbrio comum entre detecção rápida de falhas e overhead; dispositivos a bateria costumam usar valores maiores.
Caminho de rede
Load balancers, gateways NAT e firewalls mantêm estado por conexão e têm seus próprios limites. Em ambientes auto-hospedados, verifique o backlog de accept do kernel (net.core.somaxconn) e o tamanho das tabelas de connection tracking se houver um firewall stateful na frente do broker.
Como Testar a Capacidade de Conexões por Conta Própria
Se você opera seu próprio broker, meça em vez de adivinhar. O script abaixo abre muitas conexões ociosas a partir de uma máquina contra um broker que você controla, como uma instância local do Mosquitto. Não execute testes de conexão contra um broker compartilhado ou público; você vai esbarrar na proteção contra flood e afetar outros usuários.
# conn_test.py - abre N conexões MQTT ociosas no SEU PRÓPRIO broker de teste
import sys
import time
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "localhost"
COUNT = int(sys.argv[2]) if len(sys.argv) > 2 else 500
connected = 0
def on_connect(client, userdata, flags, reason_code, properties):
global connected
if not reason_code.is_failure:
connected += 1
clients = []
start = time.time()
for i in range(COUNT):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"conn-test-{i}")
c.on_connect = on_connect
try:
c.connect(HOST, 1883, keepalive=60)
c.loop_start()
clients.append(c)
except OSError as exc:
print(f"failed at {i}: {exc}")
break
if i % 100 == 0:
time.sleep(0.5) # controlar o ritmo da rampa
time.sleep(5)
print(f"{connected}/{COUNT} connected in {time.time() - start:.1f}s")
input("Press Enter to disconnect all clients...")
for c in clients:
c.disconnect()
c.loop_stop()
Execute com python conn_test.py localhost 2000 enquanto acompanha a memória e a CPU do broker com top ou htop. Observe que cada cliente paho inicia sua própria thread, então em algum momento a própria máquina de teste vira o gargalo; ferramentas de carga dedicadas, baseadas em event loops, escalam mais. Aumente também o ulimit -n na máquina de teste. Repita o teste com TLS habilitado e com assinaturas realistas, porque números com TCP simples e clientes ociosos são os mais otimistas que você verá.
Como Brokers MQTT Gerenciados Definem Limites de Conexão
Os provedores de broker MQTT gerenciado enfrentam as mesmas restrições, mas as transformam em cotas de plano para que você não precise ajustar kernels. Em um cluster compartilhado, a cota também protege cada tenant de todos os demais.
A ConnectMQ publica estes limites de conexão por plano:
| Plano | Limite de conexões | Outros limites principais |
|---|---|---|
| Servidor MQTT público (apenas testes) | Uso justo, limites por cliente | Mensagens de 64 KB, 10 msg/s, 10 assinaturas por cliente |
| Serverless (Free) | Até 25 | QoS até 1, mensagens de 256 KB |
| Serverless (Paid) | Até 1.000 | QoS 2, mensagens de 1 MB, shared subscriptions |
| Dedicated | Dimensionado para sua carga em um cluster isolado | Definidos com a equipe |
| BYOC | Dimensionado para sua carga na sua própria conta de nuvem | Definidos com a equipe |
| Self Managed Enterprise | Você opera e dimensiona | Definidos com a equipe |
Para Dedicated e BYOC, o número certo depende dos fatores deste artigo: seu keepalive, uso de TLS, taxa de mensagens e comportamento de sessão. Compartilhe esses detalhes ao definir o escopo da implantação em vez de pedir um único número de destaque. Se você ultrapassar uma cota, clientes MQTT 5 recebem o reason code 0x97 quota exceeded; nosso guia sobre cotas de conexão de broker MQTT explica como lidar com isso.
Contando as Conexões Corretamente
As equipes frequentemente subestimam. Use este checklist ao estimar:
- Cada dispositivo ou gateway com sua própria sessão MQTT.
- Cada instância de serviço de backend: gravadores de banco de dados, alertas, APIs.
- Cada ferramenta de integração, como Node-RED, Telegraf ou Home Assistant.
- Cada dashboard ou aba do navegador executando um cliente MQTT via WebSocket.
- Ferramentas de desenvolvimento: exploradores desktop, sessões de CLI, scripts de teste.
- Sobreposição temporária durante deploys, quando instâncias antigas e novas de serviços rodam juntas.
- Folga para crescimento nos próximos seis a doze meses.
Gateways mudam a conta. Um gateway industrial que agrega cinquenta tags de CLP ou um gateway BLE que encaminha dezenas de sensores usa uma única conexão MQTT, não cinquenta. Se você está perto do limite de um plano, agregar na borda costuma sair mais barato do que fazer upgrade.
Conclusões Práticas
- A capacidade de conexões é função de memória, file descriptors, custo de TLS, tráfego de keepalive e estado de sessão, e não um número fixo.
- Capacidade em regime estável e capacidade durante tempestades de reconexão são coisas diferentes; projete clientes com backoff e jitter.
- Teste sua própria carga de trabalho em hardware que você controla, com TLS ativado.
- Em um broker MQTT gerenciado, as cotas do plano são o número que importa, e você deve contar todos os clientes, não apenas os dispositivos.
Para vazão em vez de conexões, leia como estimar mensagens MQTT por segundo e, para estratégias de crescimento, veja como escalar um broker MQTT. O guia de broker MQTT na nuvem coloca tudo isso no contexto das opções de hospedagem.
Comece com a ConnectMQ
A ConnectMQ é um broker MQTT gerenciado com limites de conexão claros por plano, para que você planeje a capacidade sem ajustar servidores. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e passe para Serverless pago, Dedicated ou BYOC à medida que sua frota crescer.
Perguntas frequentes
Quantas conexões um broker MQTT suporta em um único servidor?
Depende de memória, limites de file descriptors, uso de TLS, intervalos de keepalive e estado de sessão. Meça com o comportamento real dos seus clientes e com TLS habilitado, em vez de confiar em um número de destaque.
O TLS reduz o número de conexões MQTT que um broker suporta?
O TLS adiciona memória por conexão e torna os handshakes intensivos em CPU, o que pesa mais durante tempestades de reconexão. O tráfego criptografado em regime estável com mensagens pequenas é comparativamente barato.
Clientes MQTT ociosos ainda consomem recursos do broker?
Sim. Um cliente ocioso ainda mantém um socket, memória para sua sessão e assinaturas, e envia pings de keepalive, então frotas pouco ativas também consomem capacidade.
Quantas conexões o plano gratuito da ConnectMQ permite?
O plano Serverless (Free) permite até 25 conexões simultâneas, e o plano Serverless pago permite até 1.000. Implantações Dedicated e BYOC são dimensionadas para a sua carga de trabalho.
