MQTT es un protocolo de mensajería ligero diseñado para una comunicación eficiente entre dispositivos, aplicaciones, sensores, pasarelas, plataformas en la nube y sistemas de control. Se utiliza ampliamente en redes IoT, sistemas de telemetría, edificios inteligentes, supervisión industrial, plataformas vehiculares, sistemas de energía, automatización del hogar, gestión remota de equipos y aplicaciones móviles donde el ancho de banda, la energía o la estabilidad de la red pueden ser limitados.

El protocolo se basa en un modelo de publicación/suscripción. En lugar de que un dispositivo envíe datos directamente a otro, los mensajes se envían a un broker. Después, el broker distribuye esos mensajes a los clientes que se han suscrito a temas coincidentes. Esta estructura hace que la comunicación sea flexible, escalable y adecuada para sistemas con muchos dispositivos que no necesitan conocer la dirección de red de los demás.

Otra forma de entender la mensajería entre dispositivos

La comunicación cliente-servidor tradicional suele funcionar como una petición y una respuesta directas. Un cliente solicita información a un servidor y el servidor responde. MQTT sigue una idea distinta. Un dispositivo puede publicar un mensaje sin saber quién lo recibirá, mientras que otro puede suscribirse a un tema sin saber quién publicará en él.

Esta separación es útil en sistemas distribuidos grandes. Un sensor de temperatura no necesita saber qué panel, base de datos, aplicación móvil o regla de automatización consumirá sus datos. Solo tiene que publicar en un tema definido. El broker se encarga de la distribución.

El resultado es un patrón de comunicación que reduce el acoplamiento fuerte entre dispositivos. Los sistemas pueden añadir nuevos suscriptores sin cambiar el sensor. También pueden añadir nuevos publicadores sin reescribir cada aplicación. Esta es una de las razones por las que el protocolo es popular en diseños de IoT y telemetría.

El broker como centro de mensajes

El broker es el componente central de la arquitectura. Acepta conexiones de clientes, autentica clientes cuando es necesario, recibe mensajes publicados, compara temas con suscripciones y reenvía los mensajes a los suscriptores correctos.

Un broker puede ejecutarse en una plataforma en la nube, un servidor privado, una pasarela de borde, un ordenador industrial, un dispositivo integrado o un servicio de mensajería gestionado. En despliegues pequeños, un solo broker puede manejar todo el tráfico. En despliegues grandes, varios brokers pueden agruparse, enlazarse, balancearse o distribuirse entre regiones.

El broker también controla muchos comportamientos operativos, como el estado de sesión, los mensajes retenidos, el control de acceso, la entrega por calidad de servicio, el tiempo de espera de keepalive, los límites de conexión, la autorización por tema y la persistencia de mensajes. Por eso, el diseño del broker influye directamente en la fiabilidad, la escalabilidad y la seguridad.

Ciclo de vida de la conexión

El cliente establece una sesión

Primero, el cliente abre una conexión de red con el broker. MQTT suele ejecutarse sobre TCP, y los despliegues seguros normalmente usan cifrado TLS. Después de establecer la conexión de transporte, el cliente envía un paquete CONNECT con información como ID de cliente, datos de autenticación, valor keepalive, comportamiento de sesión y ajustes opcionales de mensaje de última voluntad.

El broker revisa la solicitud de conexión y responde con un paquete CONNACK. Si la conexión se acepta, el cliente puede empezar a publicar, suscribirse, cancelar suscripciones y recibir mensajes. Si se rechaza, el broker proporciona una razón según la versión del protocolo y la configuración.

El latido mantiene activo el enlace

El mecanismo keepalive ayuda a ambas partes a detectar conexiones rotas. Si no se ha intercambiado ningún dato dentro del tiempo acordado, el cliente envía un paquete PINGREQ y el broker responde con PINGRESP.

Esto es importante porque los dispositivos IoT pueden operar en redes inestables, enlaces móviles, Wi-Fi, conexiones celulares, enlaces satelitales o rutas WAN remotas. Una red puede fallar en silencio sin cerrar la conexión correctamente. Keepalive ayuda a detectar esta condición.

Desconexión y reconexión

Un cliente puede desconectarse normalmente enviando un paquete DISCONNECT. También puede desaparecer de forma inesperada por pérdida de energía, fallo de red, bloqueo de firmware o pérdida de señal. El broker aplica entonces las reglas de sesión y de mensaje de última voluntad configuradas para ese cliente.

El comportamiento de reconexión es importante en despliegues reales. Los dispositivos deben manejar las interrupciones de red de forma controlada, evitar tormentas de reconexión y reanudar la comunicación de acuerdo con la política de sesión requerida.

Nombres de temas y enrutamiento de mensajes

Los temas son rutas de texto utilizadas para clasificar mensajes. Un tema puede parecer una jerarquía, como building/floor1/room102/temperature o factory/line3/motor7/status. Los publicadores envían mensajes a temas, y los suscriptores reciben mensajes de los temas a los que se suscriben.

Un buen diseño de temas es una de las partes más importantes de un despliegue correcto. Los nombres deben ser previsibles, legibles y alineados con la estructura real del sistema. Un mal diseño dificulta el filtrado, los permisos, la supervisión y el mantenimiento a largo plazo.

Los suscriptores pueden usar temas exactos o suscripciones con comodines. Un comodín de un solo nivel puede coincidir con un nivel del tema, mientras que un comodín multinivel puede coincidir con muchos niveles. Los comodines son útiles para paneles, plataformas analíticas, herramientas de supervisión y aplicaciones de gestión que necesitan recibir mensajes de muchos dispositivos.

Flujo de publicación y suscripción

Publicación de datos

Cuando un cliente publica datos, envía un paquete PUBLISH al broker. El paquete incluye el nombre del tema, la carga útil, el nivel de calidad de servicio, la bandera retenida y el identificador de paquete cuando el nivel QoS seleccionado lo requiere.

La carga útil puede contener muchos formatos de datos. Puede ser texto plano, JSON, datos binarios, valores de sensores, mensajes de estado, comandos, alarmas, registros de telemetría o datos de aplicación codificados. MQTT no define el significado de la carga útil; la aplicación decide cómo estructurarla e interpretarla.

Recepción de suscripciones

Un cliente se suscribe enviando un paquete SUBSCRIBE con uno o varios filtros de tema. El broker responde con SUBACK y comienza a entregar los mensajes coincidentes al cliente según el nivel QoS solicitado y concedido.

Los suscriptores pueden ser paneles, bases de datos, motores de automatización, servicios en la nube, aplicaciones móviles, controladores de dispositivos u otros equipos de campo. Un mensaje publicado puede entregarse a muchos suscriptores al mismo tiempo.

Eliminación del interés

Cuando un cliente ya no quiere ciertos mensajes, envía un paquete UNSUBSCRIBE. El broker deja de reenviar mensajes de temas coincidentes después de confirmar la solicitud.

Esto permite que las aplicaciones cambien dinámicamente su interés por los datos. Por ejemplo, un panel puede suscribirse a un edificio mientras el usuario lo visualiza y cancelar la suscripción cuando se mueve a otro sitio.

El modelo de publicación/suscripción permite que productores y consumidores de datos evolucionen de forma independiente, mientras el broker gestiona el enrutamiento, el comportamiento de sesión y el control de entrega.

Niveles de calidad de servicio

QoS 0: como máximo una vez

QoS 0 es el nivel de entrega más simple. El mensaje se envía una vez y no hay confirmación del receptor en la capa MQTT. Si el mensaje se pierde, el protocolo no lo retransmite.

Este nivel es útil para telemetría frecuente cuando perder una actualización ocasional es aceptable. Por ejemplo, un sensor de temperatura que envía datos cada pocos segundos puede no necesitar que llegue cada lectura.

QoS 1: al menos una vez

QoS 1 requiere confirmación. El emisor retransmite el mensaje si no recibe confirmación. Esto mejora la fiabilidad de entrega, pero el receptor puede recibir mensajes duplicados.

Las aplicaciones que usan QoS 1 deben estar preparadas para manejar duplicados. Es común en alarmas, cambios de estado, comandos y telemetría importante donde la entrega importa más que evitar la repetición.

QoS 2: exactamente una vez

QoS 2 utiliza un intercambio más complejo para garantizar que un mensaje se entregue exactamente una vez a nivel de protocolo. Ofrece la garantía de entrega más fuerte, pero añade más sobrecarga y latencia.

Este nivel puede utilizarse cuando el procesamiento duplicado sería perjudicial. Sin embargo, muchos despliegues reales usan QoS 0 o QoS 1 porque ofrecen un mejor equilibrio entre rendimiento y fiabilidad.

Mensajes retenidos y último estado conocido

Un mensaje retenido es almacenado por el broker como el mensaje más reciente de un tema. Cuando un nuevo suscriptor se suscribe a ese tema, el broker envía inmediatamente el mensaje retenido para que el suscriptor vea el último estado conocido.

Esto es útil para información de estado como estado en línea del dispositivo, estado de un interruptor, valor de sensor, versión de configuración, estado de alarma o modo operativo actual. Sin mensajes retenidos, un nuevo suscriptor podría tener que esperar hasta la siguiente actualización para conocer la condición actual.

Los mensajes retenidos deben usarse con cuidado. Son útiles para estados, pero no siempre son adecuados para flujos de eventos. Un evento retenido de “puerta abierta” puede confundir a un nuevo suscriptor si ya no es cierto. Los temas de estado y de eventos deben diseñarse por separado.

Comportamiento de sesión y entrega sin conexión

MQTT admite un comportamiento de sesión que determina qué ocurre cuando un cliente se desconecta y luego se reconecta. Según la versión del protocolo y la configuración, el broker puede almacenar suscripciones, mensajes en cola y estado de sesión para un cliente.

Esto es útil para dispositivos que duermen, se mueven entre redes o pierden conectividad temporalmente. Cuando el dispositivo vuelve a conectarse, puede seguir recibiendo mensajes que quedaron en cola mientras estaba desconectado, siempre que la política de sesión y las reglas QoS lo permitan.

La persistencia de sesión debe coincidir con el rol del dispositivo. Un sensor con batería puede no necesitar que todos los comandos queden en cola indefinidamente. Un controlador remoto puede requerir actualizaciones de configuración en cola. Demasiada cola sin conexión consume recursos del broker, y muy poca puede provocar comandos perdidos.

Mensajes de última voluntad para fallos inesperados

Un mensaje de última voluntad permite que un cliente defina un mensaje que el broker debe publicar si el cliente se desconecta de forma inesperada. Esto ayuda a otros sistemas a detectar fallos de dispositivo, pérdida de red o apagados anormales.

Por ejemplo, un dispositivo puede definir un mensaje de última voluntad en un tema de estado como device/123/status. Si el dispositivo pierde energía sin enviar una desconexión normal, el broker publica el mensaje sin conexión configurado.

Esta función se usa ampliamente en paneles de supervisión, sistemas de salud de dispositivos, telemetría industrial, supervisión de pasarelas y gestión remota de activos. Ofrece una forma sencilla de exponer desconexiones anormales a otras partes del sistema.

Seguridad y control de acceso

Autenticación

El broker debe verificar la identidad del cliente antes de permitir el acceso. La autenticación puede usar nombre de usuario y contraseña, certificados de cliente, tokens, credenciales API o integración con un sistema externo de identidad.

Una autenticación débil puede permitir que dispositivos no autorizados publiquen datos falsos, se suscriban a temas sensibles o interrumpan el entorno de mensajería.

Autorización

Después de verificar la identidad, el broker debe decidir en qué temas puede publicar el cliente y a cuáles puede suscribirse. Un sensor no debería poder publicar comandos a dispositivos no relacionados. Una aplicación de un inquilino no debería recibir datos de otro inquilino.

Los permisos a nivel de tema son esenciales en despliegues con múltiples dispositivos, sitios y clientes.

Cifrado

El cifrado TLS protege los datos en tránsito entre clientes y broker. Es importante cuando los mensajes viajan por redes públicas, redes celulares, conexiones en la nube o infraestructura no confiable.

El cifrado debe combinarse con gestión de certificados, almacenamiento seguro de claves y aprovisionamiento cuidadoso de clientes. Una capa de transporte segura no ayuda si las credenciales quedan expuestas en firmware o archivos de configuración.

Patrones de despliegue

Del dispositivo a la nube

En muchos sistemas IoT, sensores y pasarelas publican datos en un broker de nube. Las aplicaciones en la nube luego almacenan, visualizan, analizan y actúan sobre los datos. Este modelo es común en edificios inteligentes, gestión energética, supervisión de flotas y plataformas de equipos remotos.

Las principales preocupaciones de diseño son seguridad, resiliencia de red, identidad de dispositivos, volumen de mensajes y escalado en la nube.

Agregación mediante pasarela de borde

Una pasarela de borde puede recoger datos de dispositivos locales y publicar datos resumidos o filtrados en un broker central. También puede suscribirse a temas de comandos y reenviar instrucciones a equipos locales.

Esto reduce el ancho de banda, mejora el control local y permite que el sitio mantenga algunas funciones incluso cuando la conexión con la nube no está disponible.

Broker local para sistemas de sitio

Algunos despliegues usan un broker local dentro de una fábrica, edificio, laboratorio, campus o sala de control. Los dispositivos y aplicaciones intercambian datos localmente con baja latencia y menor dependencia de redes externas.

Un broker local puede luego enlazar datos seleccionados con una plataforma en la nube o empresarial. Esto da a los diseñadores más control sobre el flujo de datos y la dependencia de red.

Aplicaciones en sistemas conectados

Supervisión industrial

Fábricas y servicios públicos usan MQTT para recopilar estado de equipos, datos de sensores, alarmas, valores energéticos, lecturas de temperatura, vibraciones y métricas de producción. El protocolo encaja en entornos donde muchos dispositivos envían mensajes pequeños a plataformas de supervisión.

Los despliegues industriales deben considerar segmentación de red, redundancia de broker, selección de QoS, estado retenido y aprovisionamiento seguro de dispositivos.

Edificios inteligentes

Los sistemas de edificios pueden usar el protocolo para conectar iluminación, HVAC, control de acceso, sensores de ocupación, medidores, ascensores, paneles de sala y paneles de control. La estructura de temas puede reflejar la jerarquía de edificio, planta, sala y dispositivo.

Esto facilita organizar los datos y ayuda a que las reglas de automatización se suscriban solo a eventos o estados relevantes.

Energía y medición

Las plataformas energéticas pueden usar MQTT para recopilar lecturas de medidores, datos de inversores, estado de baterías, información de carga y telemetría relacionada con la red. La mensajería ligera es útil cuando muchos dispositivos informan pequeños valores periódicamente.

Como los sistemas energéticos pueden afectar facturación, control o seguridad, la autenticación y la integridad de mensajes deben tratarse con cuidado.

Vehículos conectados y movilidad

Plataformas vehiculares, estaciones de carga, sistemas de flota y servicios de movilidad pueden usar el protocolo para telemetría, actualizaciones de ubicación, diagnósticos, alertas y funciones de control remoto.

Las redes móviles pueden ser inestables, por lo que el manejo de sesión, la lógica de reconexión y un diseño eficiente de la carga útil son importantes.

Consumo y automatización del hogar

Los sistemas de automatización doméstica usan MQTT para conectar sensores, interruptores, luces, termostatos, cámaras, hubs y reglas de automatización. El modelo de publicación/suscripción facilita que un evento de sensor active varias acciones.

En despliegues domésticos, una nomenclatura sencilla de temas y una configuración segura del broker local son importantes para evitar confusión y acceso no autorizado.

Consideraciones de rendimiento y escalabilidad

El tamaño del mensaje debe mantenerse razonable. MQTT es eficiente para mensajes pequeños, pero no es ideal para archivos muy grandes o flujos multimedia pesados. Las cargas grandes pueden aumentar el uso de memoria del broker, la congestión de red y el retraso de procesamiento.

El diseño de temas afecta al rendimiento. El uso excesivo de suscripciones con comodines amplios puede aumentar la carga del broker porque muchos mensajes deben coincidir y entregarse a muchos clientes. Una jerarquía clara ayuda a escalar de forma más previsible.

El número de conexiones es otro factor. Un broker que atiende a miles o millones de clientes debe gestionar tráfico keepalive, autenticación, estado de sesión, mensajes retenidos, mensajes en cola y límites de red. La escalabilidad puede requerir clustering, balanceo de carga, agregación en el borde o partición de temas.

El nivel QoS también afecta al rendimiento. QoS 2 ofrece semánticas de entrega más fuertes, pero crea más intercambio de paquetes. Para telemetría de gran volumen, puede ser más práctico usar QoS 0 o QoS 1 con lógica a nivel de aplicación.

Errores comunes de diseño

Nombres de temas poco claros

Los nombres de temas aleatorios o inconsistentes dificultan la gestión de permisos, paneles, alertas y análisis. Debe crearse un plan de temas antes de un despliegue a gran escala.

Usar mensajes retenidos para eventos

Los mensajes retenidos son mejores para el estado actual. Usarlos para eventos puntuales puede engañar a nuevos suscriptores porque pueden recibir un evento antiguo como si acabara de ocurrir.

Sin manejo de duplicados

QoS 1 puede entregar duplicados. Las aplicaciones deben usar marcas de tiempo, ID de mensaje, números de secuencia o procesamiento idempotente cuando los duplicados puedan causar problemas.

Gestión débil de credenciales

Contraseñas compartidas codificadas, ID de cliente reutilizados y certificados sin protección pueden crear riesgos de seguridad graves. Cada dispositivo debe tener una identidad gestionable y una ruta de revocación.

Ignorar el fallo del broker

El broker es central para la arquitectura. Si falla y no hay redundancia ni plan de recuperación, la comunicación puede detenerse. Los despliegues críticos deben considerar clustering, brokers de respaldo, diseño de puente o comportamiento local de reserva.

MQTT funciona bien cuando temas, sesiones, QoS, estado retenido, seguridad y capacidad del broker se diseñan en conjunto, no como ajustes aislados.

Mantenimiento y supervisión

Los equipos de operación deben supervisar CPU del broker, memoria, número de conexiones, tasa de mensajes, cantidad de mensajes retenidos, número de suscripciones, mensajes en cola, fallos de autenticación, conexiones caídas y latencia de red.

La salud de los clientes también debe ser visible. Reconexiones repetidas, sesiones expiradas, ID de cliente duplicados, tasas anormales de publicación y accesos inesperados a temas pueden indicar fallos de dispositivo o problemas de seguridad.

Las copias de seguridad de configuración son importantes. Ajustes del broker, listas de control de acceso, certificados, políticas de temas, ajustes de puente y comportamiento de estado retenido deben documentarse y poder recuperarse.

Preguntas frecuentes

¿Puede MQTT funcionar sobre WebSocket?

Sí. Muchos brokers admiten MQTT sobre WebSocket, lo que permite a aplicaciones basadas en navegador y paneles web comunicarse mediante rutas de transporte compatibles con la web.

¿Es adecuado para enviar video o archivos grandes?

Normalmente no como método principal. Es mejor para mensajes pequeños, telemetría, eventos, comandos y actualizaciones de estado. Los archivos grandes suelen transferirse mediante otros protocolos, con un mensaje que lleva la referencia del archivo.

¿Qué ocurre si dos clientes usan el mismo ID de cliente?

Muchos brokers desconectarán al cliente existente cuando un nuevo cliente se conecte con el mismo ID. Los ID de cliente únicos son importantes para un comportamiento de sesión estable.

¿Puede un broker conectarse a otro broker?

Sí. El puente entre brokers o el clustering pueden usarse para intercambiar temas seleccionados entre sitios, regiones, pasarelas de borde y plataformas en la nube, según la capacidad del broker.

¿Cómo deben planificarse los nombres de tema?

Use una jerarquía coherente basada en sitio, sistema, dispositivo, tipo de datos y función. Evite nombres aleatorios, información sensible en las rutas de temas y dependencia excesiva de comodines amplios.