Cuotas de conexión de un broker MQTT: conexiones, tasas de mensajes y límites de payload

Las cuotas de conexión de un broker MQTT deciden cuántos clientes puedes conectar, a qué velocidad pueden publicar y qué tamaño puede tener cada mensaje. Esta guía explica cada cuota habitual en un broker MQTT gestionado, cómo señalan los brokers MQTT 3.1.1 y MQTT 5 que has alcanzado una y cómo escribir clientes que se mantengan holgadamente dentro de los límites de tu plan.

Por qué los brokers MQTT gestionados aplican cuotas

Un broker MQTT gestionado es infraestructura compartida, incluso cuando tienes un clúster dedicado. La memoria, la CPU, el ancho de banda de red y los descriptores de archivo son finitos, y un solo cliente que se comporte mal, como un firmware atascado en un bucle de publicación o una tormenta de reconexiones tras un corte de Wi-Fi, puede degradar el servicio de todos los demás que comparten las mismas máquinas. Las cuotas convierten esos recursos finitos en límites explícitos y predecibles.

En un servicio multiinquilino, las cuotas son también la forma en que funciona el aislamiento en la práctica. ConnectMQ, por ejemplo, aplica cuotas por plan, protección contra inundaciones y bloqueo de IP tras varios inicios de sesión fallidos, para que el problema de un inquilino siga siendo solo suyo. Si el modelo es nuevo para ti, nuestro artículo sobre qué hace un broker MQTT cubre los fundamentos de cómo interactúan clientes y brokers.

Las cuotas más habituales de un broker MQTT

La mayoría de los proveedores aplican alguna combinación de las siguientes. Los nombres cambian, pero los conceptos son los mismos en todas partes.

Límites reales de planes como ejemplo

Así fija ConnectMQ sus límites por plan:

• Serverless (Free): hasta 25 conexiones, QoS hasta 1, mensajes de hasta 256 KB.
• Serverless (Paid): hasta 1.000 conexiones, QoS 2, mensajes de hasta 1 MB, suscripciones compartidas.
• Dedicated, BYOC y Self Managed Enterprise: despliegues aislados dimensionados para tu carga de trabajo.
• Servidor MQTT público gratuito (broker.connectmq.com): 64 KB por mensaje, 10 mensajes por segundo por cliente, 10 suscripciones por cliente, 8 niveles de topic, QoS 0 a 2 y caducidad de sesión de hasta 30 minutos.

Cómo señalan los brokers que has alcanzado una cuota

Aquí la versión del protocolo importa mucho.

MQTT 3.1.1: adivinar a partir de las desconexiones

MQTT 3.1.1 solo tiene unos pocos códigos de retorno en CONNACK y ninguna forma de que el broker explique una desconexión. Cuando un cliente 3.1.1 supera un límite, el broker normalmente se limita a cerrar la conexión TCP. El cliente ve un genérico "conexión perdida" y se reconecta, a menudo chocando de nuevo con el mismo límite. Diagnosticar problemas de cuotas en 3.1.1 implica correlacionar los logs del cliente con lo que muestre la consola del proveedor.

MQTT 5: reason codes explícitos

MQTT 5 añadió reason codes a CONNACK, PUBACK, SUBACK y DISCONNECT, lo que hace visibles los problemas de cuotas para el cliente. Los que encontrarás con más frecuencia están definidos en la especificación OASIS MQTT 5.0:

ConnectMQ admite los reason codes de MQTT 5, incluido 0x97 quota exceeded, de modo que un cliente con MQTT 5 puede registrar una causa precisa en lugar de una desconexión imprecisa. Solo eso ya es un buen motivo para usar MQTT 5 en proyectos nuevos; consulta las funciones de MQTT 5 para conocer el resto.

Los brokers MQTT 5 también pueden anunciar sus límites de antemano en propiedades de CONNACK como Maximum Packet Size, Receive Maximum, Topic Alias Maximum y Maximum QoS. Un cliente bien escrito las lee y se adapta.

Cómo diseñar clientes que respeten sus cuotas

La mejor estrategia frente a las cuotas es un cliente que nunca se acerque al límite. Estas prácticas evitan la mayoría de los incidentes por cuotas.

Leer los límites del broker al conectar

El ejemplo en Python siguiente se conecta con paho-mqtt 2.x sobre TLS, imprime los límites que anuncia el broker y registra los reason codes al desconectarse.

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

Si primero quieres experimentar sin cuenta, apunta el mismo script al servidor MQTT público gratuito en el puerto 1883 con un client ID único y sin credenciales; úsalo solo para pruebas y prototipos, nunca con datos de producción.

Limitar la tasa de publicación en el cliente

No confíes nunca en que el broker te limite. Un pequeño token bucket mantiene las ráfagas bajo control, algo especialmente importante cuando un dispositivo se reconecta e intenta vaciar un 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: como máximo RATE mensajes por segundo, ráfagas de hasta 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 el vaciado de un backlog tras una caída.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));

Backoff con jitter al reconectar

Cuando una planta pierde la conectividad, cientos de dispositivos pueden reconectarse en el mismo segundo. Sin un backoff aleatorizado, chocan juntos con la cuota de tasa de conexiones, fallan juntos y reintentan juntos. Añade un jitter aleatorio a cada espera de reconexión y limita la espera máxima a uno o dos minutos.

Client IDs únicos y estables

En los brokers MQTT gestionados que vinculan los client IDs a las credenciales emitidas, como hace ConnectMQ, los duplicados son una trampa habitual. Si copias un mismo juego de credenciales en dos dispositivos, cada conexión expulsa a la otra, lo que MQTT 5 notifica como 0x8E session taken over. El resultado parece una conexión inestable y agota rápidamente los límites de tasa de conexiones. Emite un juego de credenciales por dispositivo o servicio.

Agrupar lecturas pequeñas

Diez valores de sensor en un solo mensaje JSON cuestan una publicación en lugar de diez. Agrupar mantiene bajas las tasas de mensajes y normalmente reduce el ancho de banda, siempre que el lote quede muy por debajo del límite de payload de tu plan.

Menos suscripciones, pero más amplias

Un único comodín como site1/+/telemetry es más fácil de gestionar que decenas de suscripciones exactas y te mantiene lejos de los topes de suscripciones por cliente.

Checklist de preparación frente a cuotas

Antes del despliegue, repasa esta lista para cada tipo de cliente:

1. Cuenta las conexiones simultáneas, incluidos dashboards, scripts e integraciones.
2. Calcula el pico de publicaciones por segundo por cliente, no solo la media.
3. Mide el payload más grande, incluidos los vaciados de backlog y los volcados de errores.
4. Confirma el nivel de QoS que necesita cada topic y que el plan lo admite.
5. Verifica que cada dispositivo tiene su propio client ID y sus propias credenciales.
6. Implementa backoff exponencial con jitter para las reconexiones.
7. Registra los reason codes de MQTT 5 y envíalos a algún lugar donde puedas buscarlos.
8. Deja margen: planifica para aproximadamente el doble de la carga esperada para que el crecimiento no te sorprenda.

Para los cálculos de dimensionamiento de los puntos 2 y 3, lee cómo estimar los mensajes MQTT por segundo. Si comparas opciones de entrada, nuestra guía del broker MQTT con plan gratuito muestra cómo varían las cuotas entre planes gratuitos, y la guía principal del broker MQTT en la nube cubre las opciones de alojamiento de forma más amplia.

Resolución de problemas de cuotas

• Las conexiones se caen cada pocos segundos: comprueba antes que nada si hay client IDs duplicados.
• Los mensajes grandes desaparecen: compara el tamaño del payload con el límite del plan y con la propiedad Maximum Packet Size del broker.
• Las suscripciones no reciben nada sin dar error: revisa los reason codes del SUBACK; un código de error significa que el filtro no se aceptó.
• Todo falla tras una caída en toda la planta: tu lógica de reconexión no tiene jitter y estás disparando la protección de tasa de conexiones.
• Desconexiones inexplicables en MQTT 3.1.1: cambia temporalmente el cliente a MQTT 5 para obtener un reason code.

Empieza con un plan de broker MQTT gestionado

ConnectMQ publica con claridad los límites de sus planes e informa de los problemas de cuotas con reason codes de MQTT 5, para que puedas diseñar teniéndolos en cuenta desde el primer día. Empieza con el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y sube después a Serverless de pago, Dedicated o BYOC a medida que crezca tu flota. Si prefieres que otro se encargue por completo de la infraestructura, un broker MQTT gestionado se ocupa de los parches, TLS y la capacidad por ti.

Preguntas frecuentes

¿Qué significa el reason code 0x97 de MQTT?

0x97 es "Quota exceeded" en MQTT 5. El broker le indica al cliente que se ha alcanzado un límite de la implementación o del plan, así que el cliente debe esperar antes de reintentar en lugar de hacerlo de inmediato.

¿Cuentan los dashboards y los scripts para las cuotas de conexión?

Sí. Cada cliente MQTT con una sesión abierta cuenta como una conexión, ya sea un sensor, un flujo de Node-RED o una pestaña del navegador.

¿Cómo sé el tamaño máximo de mensaje que acepta mi broker?

Consulta la documentación del plan y, en MQTT 5, lee la propiedad Maximum Packet Size del CONNACK. El plan Serverless gratuito de ConnectMQ permite 256 KB y el plan Serverless de pago permite 1 MB.

¿Por qué mi dispositivo se reconecta una y otra vez en bucle?

La causa más habitual son dos clientes que comparten un mismo client ID, lo que hace que el broker desconecte la sesión más antigua cada vez. Da a cada dispositivo sus propias credenciales y su propio client ID.