9. MQTT y arquitecturas publish/subscribe

El protocolo MQTT fue creado para conectar sensores y sistemas SCADA mediante enlaces de bajo ancho de banda. Su arquitectura publish/subscribe desacopla productores de consumidores y minimiza el tamaño de cada mensaje, lo que lo hace ideal para IoT, domótica y monitoreo industrial.

9.1 Protocolo ligero basado en publish/subscribe

En lugar de realizar peticiones directas, los dispositivos publican mensajes en “topics”. Cualquier cliente suscrito a ese topic los recibe inmediatamente. Este esquema reduce el acoplamiento entre emisores y receptores.

Elemento Descripción
Topic Cadena jerárquica (por ejemplo, casa/sala/temperatura) que organiza los mensajes.
Publicador Envía datos al topic correspondiente; no necesita conocer a los suscriptores.
Suscriptor Recibe mensajes de uno o varios topics; puede usar comodines para abarcar jerarquías.

9.2 Necesita un broker central (Mosquitto, HiveMQ, EMQX)

El broker es el intermediario que recibe las publicaciones y las reenvía a los suscriptores. Algunas implementaciones populares son:

  • Eclipse Mosquitto: liviano, de código abierto y disponible en la mayoría de distribuciones.
  • HiveMQ: orientado a empresas, con herramientas de monitoreo y clustering.
  • EMQX: soporta millones de conexiones concurrentes y escalado horizontal.

El broker gestiona autenticación, autorización, retención y distribución eficiente de mensajes.

9.3 Niveles de QoS: 0, 1 y 2

MQTT ofrece tres niveles de calidad de servicio para adaptarse a distintos requerimientos:

  • QoS 0 (at most once): entrega “mejor esfuerzo”, sin confirmaciones. Útil para telemetría frecuente donde perder un mensaje no es grave.
  • QoS 1 (at least once): garantiza recepción pero puede duplicar mensajes. Se usa en comandos donde más vale repetir que perder.
  • QoS 2 (exactly once): evita duplicados mediante un handshake adicional. Recomendado para transacciones críticas.

La elección del QoS afecta el uso de ancho de banda y la complejidad del broker, por lo que conviene asignarlo topic por topic.

9.4 Persistencia de mensajes y sesiones

Además del QoS, MQTT incluye mecanismos para mantener el estado:

  • Retain flag: almacena el último mensaje publicado en un topic, de modo que los nuevos suscriptores reciban el valor más reciente de inmediato.
  • Session persistence: permite que un cliente que se desconectó conserve sus suscripciones y mensajes pendientes.
  • Last Will and Testament (LWT): el broker envía un mensaje predefinido si un cliente se desconecta de forma inesperada.

Gracias a estos mecanismos, las redes IoT toleran caídas temporales sin perder datos relevantes.

9.5 Ejemplo práctico: sensores IoT publicando datos

Un flujo típico consiste en que un sensor publique su temperatura y un panel web la consuma: 

# Terminal 1: suscribirse
mosquitto_sub -h test.mosquitto.org -t "casa/sala/temperatura" -v

# Terminal 2: publicar un valor simulando un sensor
mosquitto_pub -h test.mosquitto.org -t "casa/sala/temperatura" -m "25.3"

El mensaje aparece instantáneamente en la terminal suscrita. Cambiando el topic se pueden separar zonas, tipos de sensores o niveles de QoS distintos.

9.6 Buenas prácticas para desplegar MQTT

Para asegurar un entorno estable:

  • Cifrar el canal: MQTT puede viajar sobre TLS (puerto 8883) para proteger credenciales y datos sensibles.
  • Definir políticas ACL: limitar qué topics puede publicar o suscribir cada dispositivo.
  • Monitorear el broker: revisar métricas de conexiones activas, mensajes por segundo y latencias con herramientas del proveedor.
  • Planificar escalabilidad: cuando se superen decenas de miles de dispositivos, evaluar clústeres o particionamiento por topics.

Estos lineamientos evitan que un solo cliente comprometido afecte a toda la red de sensores.

Retornar