¿Cuántas conexiones soporta un broker MQTT?

¿Cuántas conexiones soporta un broker MQTT? La respuesta honesta es "depende", pero depende de una lista breve y concreta de recursos que puedes medir y planificar. Este artículo explica qué limita las conexiones MQTT simultáneas, por qué las cifras publicadas rara vez coinciden con tu carga de trabajo, cómo medir la capacidad por tu cuenta y cómo los proveedores de un broker MQTT gestionado traducen todo esto en límites de plan.

Por qué no hay una cifra única

Encontrarás cifras de conexiones impresionantes en el marketing de los proveedores y en charlas de conferencias. Normalmente son reales, pero se miden en condiciones concretas: clientes inactivos, sin TLS o con reanudación de sesión TLS, payloads diminutos o inexistentes, hardware generoso y kernels cuidadosamente ajustados. Cambia cualquiera de esas condiciones y la cifra se mueve.

Lo que te importa no es el máximo que un broker puede alcanzar en un laboratorio, sino cuántos de tus clientes, con tu keepalive, tu uso de TLS, tus suscripciones y tus patrones de mensajes, puede atender un despliegue concreto con margen. Para eso hay que entender los cuellos de botella.

Qué limita las conexiones MQTT simultáneas

Memoria

La memoria suele ser el primer límite duro en flotas grandes de dispositivos poco activos. Cada conexión lleva buffers de socket del kernel, las estructuras por cliente del propio broker, el estado de la sesión TLS y los mensajes en cola. Las suscripciones añaden más, sobre todo con muchos filtros con comodines. Los clientes que se desconectan con sesiones persistentes siguen consumiendo memoria hasta que la sesión caduca.

Descriptores de archivo

En Linux, cada socket consume un descriptor de archivo. El límite flexible por defecto en muchas distribuciones es demasiado bajo para un broker, por eso "too many open files" es uno de los errores más habituales cuando alguien autoaloja un broker por primera vez. Puedes consultarlo y aumentarlo:

# Límites actuales de la shell
ulimit -n
ulimit -Hn

# Límites de un proceso de broker en ejecución (sustituye PID)
cat /proc/PID/limits | grep "open files"

# Contar los sockets abiertos del broker
ls /proc/PID/fd | wc -l

Para un servicio systemd, aumenta el límite en un archivo drop-in:

# /etc/systemd/system/mosquitto.service.d/limits.conf
[Service]
LimitNOFILE=200000

Después ejecuta sudo systemctl daemon-reload && sudo systemctl restart mosquitto.

TLS

TLS protege cada conexión de producción, y tiene un coste. El cifrado continuo de mensajes MQTT pequeños es barato, pero el handshake es comparativamente caro. Eso importa sobre todo cuando muchos clientes se conectan a la vez, por ejemplo tras un corte de luz en toda una planta o un reinicio del broker. Un broker que mantiene holgadamente su flota en régimen estable puede tener dificultades para aceptarla entera en el mismo minuto. Los retardos de reconexión con jitter en los clientes son la mejor defensa.

Keepalives

Cada cliente envía un PINGREQ cuando no tiene nada más que enviar dentro de su intervalo de keepalive. En una flota grande, los keepalives muy cortos generan una carga de fondo constante. Un keepalive de entre 30 y 60 segundos es un equilibrio habitual entre detección rápida de fallos y sobrecarga; los dispositivos con batería suelen usar valores más largos.

Ruta de red

Los balanceadores de carga, las pasarelas NAT y los firewalls mantienen estado por conexión y tienen sus propios límites. En instalaciones autoalojadas, revisa el backlog de accept del kernel (net.core.somaxconn) y el tamaño de las tablas de seguimiento de conexiones si colocas un firewall con estado delante del broker.

Cómo medir tú mismo la capacidad de conexiones

Si ejecutas tu propio broker, mide en lugar de adivinar. El script siguiente abre muchas conexiones inactivas desde una máquina contra un broker que controles, como una instancia local de Mosquitto. No hagas pruebas de conexiones contra un broker compartido o público; activarás la protección contra inundaciones y afectarás a otros usuarios.

# conn_test.py - abre N conexiones MQTT inactivas contra TU PROPIO broker de pruebas
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)        # dosifica la rampa de subida

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()

Ejecútalo con python conn_test.py localhost 2000 mientras observas la memoria y la CPU del broker con top o htop. Ten en cuenta que cada cliente paho arranca su propio hilo, así que en algún momento la propia máquina de pruebas se convierte en el cuello de botella; las herramientas de carga dedicadas basadas en bucles de eventos llegan más lejos. Aumenta también ulimit -n en la máquina de pruebas. Repite la prueba con TLS activado y con suscripciones realistas, porque las cifras con clientes inactivos sobre TCP sin cifrar son las más optimistas que verás jamás.

Cómo fijan los brokers MQTT gestionados los límites de conexiones

Los proveedores de brokers MQTT gestionados se enfrentan a las mismas restricciones, pero las convierten en cuotas de plan para que no tengas que ajustar kernels. En un clúster compartido, la cuota también protege a cada inquilino de todos los demás.

ConnectMQ publica estos límites de conexiones por plan:

En Dedicated y BYOC, la cifra adecuada depende de los factores de este artículo: tu keepalive, tu uso de TLS, tu tasa de mensajes y el comportamiento de las sesiones. Comparte esos detalles al definir el alcance del despliegue en lugar de pedir una única cifra de titular. Si superas una cuota, los clientes MQTT 5 reciben el reason code 0x97 quota exceeded; nuestra guía sobre cuotas de conexión de un broker MQTT explica cómo gestionarlo. El servidor MQTT público gratuito (broker.connectmq.com) sirve para pruebas y prototipos, no para datos de producción ni para pruebas de carga.

Cómo contar bien las conexiones

Los equipos suelen quedarse cortos al contar. Usa esta checklist al estimar:

1. Cada dispositivo o pasarela con su propia sesión MQTT.
2. Cada instancia de servicio backend: escritores en base de datos, alertas, APIs.
3. Cada herramienta de integración, como Node-RED, Telegraf o Home Assistant.
4. Cada dashboard o pestaña del navegador con un cliente MQTT sobre WebSocket.
5. Herramientas de desarrollo: exploradores de escritorio, sesiones de CLI, scripts de prueba.
6. El solapamiento temporal durante los despliegues, cuando conviven instancias antiguas y nuevas de un servicio.
7. Margen de crecimiento para los próximos seis a doce meses.

Las pasarelas cambian las cuentas. Una pasarela industrial que agrega cincuenta tags de PLC o una pasarela BLE que reenvía decenas de sensores usa una conexión MQTT, no cincuenta. Si estás cerca del límite de un plan, agregar en el edge suele ser más barato que subir de plan.

Conclusiones prácticas

• La capacidad de conexiones depende de la memoria, los descriptores de archivo, el coste de TLS, el tráfico de keepalive y el estado de sesión; no es una cifra fija.
• La capacidad en régimen estable y la capacidad ante tormentas de reconexión son distintas; diseña los clientes con backoff con jitter.
• Prueba tu propia carga de trabajo en hardware que controles, con TLS activado.
• En un broker MQTT gestionado, la cifra que importa son las cuotas del plan, y debes contar todos los clientes, no solo los dispositivos.

Para el rendimiento en lugar de las conexiones, lee cómo estimar los mensajes MQTT por segundo, y para las estrategias de crecimiento consulta cómo escalar un broker MQTT. La guía del broker MQTT en la nube lo sitúa todo en el contexto de las opciones de alojamiento.

Empieza con ConnectMQ

ConnectMQ es un broker MQTT gestionado con límites de conexiones claros por plan, para que puedas planificar la capacidad sin ajustar servidores. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y pasa a Serverless de pago, Dedicated o BYOC a medida que crezca tu flota.

Preguntas frecuentes

¿Cuántas conexiones soporta un broker MQTT en un único servidor?

Depende de la memoria, los límites de descriptores de archivo, el uso de TLS, los intervalos de keepalive y el estado de sesión. Mide con el comportamiento real de tus clientes y con TLS activado en lugar de fiarte de una cifra de titular.

¿Reduce TLS el número de conexiones MQTT que soporta un broker?

TLS añade memoria por conexión y hace que los handshakes consuman mucha CPU, algo que importa sobre todo durante las tormentas de reconexión. El tráfico cifrado en régimen estable para mensajes pequeños es comparativamente barato.

¿Siguen usando recursos del broker los clientes MQTT inactivos?

Sí. Un cliente inactivo sigue manteniendo un socket y memoria para su sesión y sus suscripciones, y envía pings de keepalive, así que las flotas poco activas también consumen capacidad.

¿Cuántas conexiones permite el plan gratuito de ConnectMQ?

El plan Serverless (Free) permite hasta 25 conexiones simultáneas y el plan Serverless de pago permite hasta 1.000. Los despliegues Dedicated y BYOC se dimensionan para tu carga de trabajo.