Qué es MQTT: el protocolo, sus versiones y dónde se usa

# La versión corta

MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería ligero, basado en publicar y suscribirse, creado para dispositivos con mal enlace, poca memoria y una batería que debe durar.

Lo crearon en 1999 Andy Stanford-Clark, de IBM, y Arlen Nipper, de Arcom, para llevar por satélite la telemetría de oleoductos. Las condiciones eran implacables: el ancho de banda era caro y escaso, el enlace se caía sin parar y los dispositivos eran endebles. Esas restricciones moldearon todo el protocolo: una cabecera mínima, una única conexión de larga duración y la capacidad de sobrevivir a un corte sin perder mensajes.

Hoy MQTT es un estándar de OASIS, y la versión 3.1.1 se adoptó además como norma internacional ISO/IEC 20922. Hace mucho que superó la industria petrolera: hogares conectados, contadores, máquinas herramienta, coches y equipos médicos funcionan con él.

El sobrecoste mínimo por mensaje es de dos bytes. Una sola petición HTTP, en cambio, gasta cientos de bytes en cabeceras antes de cualquier contenido. Cuando un dispositivo informa de una temperatura cada segundo por un módem celular en pleno campo, esa diferencia decide el diseño.

# Cómo funciona: publicar, suscribirse y el broker

En HTTP el cliente pregunta y el servidor responde. En MQTT nadie pregunta nada a nadie: un dispositivo publica un mensaje en un topic y todos los que están suscritos a ese topic lo reciben. El emisor no sabe quién lee, ni siquiera si alguien lee; el receptor no sabe quién envió. Lo único que los une es el nombre del topic.

En medio siempre hay un broker: un servidor que sostiene las conexiones, mantiene el árbol de suscripciones y reparte los mensajes. Sin él el modelo no funciona: el broker es lo que convierte «enviado al vacío» en «entregado a todos los que lo necesitan».

Qué hace el broker

• Acepta y mantiene conexiones: miles a la vez, durante años sin interrupción.
• Comprueba quién se conecta: usuario y contraseña, un certificado o un token.
• Decide qué puede hacer cada cliente: los permisos de publicar y suscribirse se conceden por topic.
• Compara cada mensaje publicado con el árbol de suscripciones y reparte las copias.
• Conserva estado: últimos valores conocidos (retain), colas para clientes ausentes y confirmaciones pendientes.
• Vigila quién sigue vivo y publica el testamento de quien desaparece.

Desacoplar al emisor del receptor no es un detalle técnico, sino la esencia del modelo. Puede sustituir un sensor, añadir un segundo consumidor o acoplar una analítica al margen sin reescribir nada: todos hablan con un topic, no entre sí.

# Topics y comodines

Un topic es una cadena de niveles separados por barras. No hay que registrar nada de antemano: publicar en un topic nuevo lo crea en el acto.

oficina/planta2/sala14/temperatura
oficina/planta2/sala14/humedad
oficina/planta2/sala15/temperatura

Una suscripción puede abarcar ramas enteras con dos comodines:

El comodín # solo es válido como último nivel: oficina/#/temperatura no es un filtro legal. Los topics distinguen mayúsculas de minúsculas, y oficina/planta2 y oficina/planta2/ son dos topics distintos.

# Calidad de servicio: QoS 0, 1 y 2

MQTT permite elegir cuánto esfuerzo dedicar a entregar cada mensaje. El nivel se fija por separado al publicar y al suscribirse; el efectivo es el menor de los dos.

El coste sube con la garantía: QoS 2 son cuatro paquetes en vez de uno, más estado en ambos extremos. Resista la tentación de «usar 2 en todas partes por si acaso»: diez mil sensores publicando cada segundo con QoS 2 cargan un broker un orden de magnitud más, sin ganar nada.

# Retain, Last Will, sesiones y keep-alive

Retain: el último valor conocido

Un mensaje corriente solo llega a quienes estén suscritos en ese momento. Un mensaje con la marca retain lo recuerda además el broker y se lo entrega a cada nuevo suscriptor en el instante en que se suscribe. Es la respuesta estándar al eterno problema del panel que se abre vacío y sigue vacío hasta que un sensor se digna a enviar su siguiente lectura.

Un topic guarda exactamente un mensaje retenido: el último. Para borrarlo, publique una carga útil vacía en el mismo topic con la marca retain.

Last Will: un mensaje para cuando se cae el enlace

Al conectarse, un cliente puede entregar al broker un testamento: un topic, una carga útil y sus opciones. Si la conexión muere sin cortesía, sin paquete DISCONNECT, el broker publica ese mensaje en su nombre. El patrón clásico es un topic retenido device/42/status que recibe online al conectar y lleva offline como testamento. El sistema sabe siempre quién está presente, sin sondeo alguno.

Sesiones: limpias y persistentes

Una sesión limpia dura exactamente lo que la conexión: al desconectar se olvidan las suscripciones. Una persistente sobrevive al corte: el broker recuerda las suscripciones y encola los mensajes QoS 1 y 2 mientras el cliente falta, y le entrega lo acumulado a su regreso. Para un dispositivo que despierta una vez por hora, es la única forma de no perderse nada.

Keep-alive: darse cuenta de que el enlace ha muerto

Una conexión TCP rota puede parecer perfectamente viva en ambos extremos durante mucho tiempo. Por eso el cliente declara un intervalo de keep-alive y, si no tiene otra cosa que decir, envía un ping. Si no oye nada durante un intervalo y medio, el broker da al cliente por desaparecido, cierra la conexión y publica su testamento.

# Las versiones: 3.1, 3.1.1 y 5.0

En la práctica aparecen tres versiones, y las diferencias no son cosméticas.

Aparte queda MQTT-SN, un protocolo hermano para redes sin TCP: ZigBee, enlaces de radio, UDP. No es «una versión de MQTT», sino una especificación propia; esas redes reciben una pasarela que traduce el tráfico a MQTT corriente.

Qué aporta realmente MQTT 5.0

La versión 5 nació de molestias acumuladas en la práctica. Lo de mayor calado:

• Códigos de razón. En 3.1.1 un rechazo parecía un socket cerrado en silencio y había que adivinar. En 5.0 el servidor dice de qué se trata: contraseña incorrecta, sin permiso para ese topic, paquete demasiado grande.
• Propiedades de paquete. Un mensaje puede llevar metadatos: Content Type, Correlation Data, pares clave-valor propios. Antes todo eso se metía en la carga útil o en el nombre del topic.
• Petición y respuesta. Los campos Response Topic y Correlation Data convierten el RPC corriente en un patrón de primera clase en vez de un apaño convenido.
• Suscripciones compartidas mediante $share/grupo/filtro: varias instancias de un consumidor se reparten el flujo. Eso es reparto de carga y tolerancia a fallos en el propio protocolo.
• Tiempos de vida de sesiones y mensajes. Session Expiry y Message Expiry permiten decir «guárdalo un día y luego olvídalo» en lugar de la elección binaria entre limpia y no limpia.
• Control de flujo. Receive Maximum limita cuántos mensajes sin confirmar viajan a la vez, y Maximum Packet Size protege a un dispositivo pequeño de un paquete que no puede digerir.
• Alias de topics. Un nombre largo se envía una vez y luego se sustituye por un número de dos bytes: un ahorro real en jerarquías profundas.
• Identificadores de suscripción, No Local, Retain As Published, Retain Handling. Detalles que eliminan trampas antiguas: oír el eco de los mensajes propios, una avalancha de retenidos en cada reconexión, no saber por qué suscripción llegó un mensaje.
• Testamento diferido. Will Delay Interval evita que un parpadeo momentáneo dispare una alarma: el testamento se publica solo si el cliente no regresa a tiempo.

La conclusión práctica: empiece los proyectos nuevos en 5.0. Las suscripciones compartidas y unos códigos de error comprensibles ahorran semanas de depuración, y no se pierde la compatibilidad con dispositivos antiguos.

# MQTT frente a HTTP y las alternativas

«¿Para qué quiero MQTT si existe REST?» es una pregunta legítima. La diferencia no es de moda, sino de dirección y de coste de la conversación.

El sondeo lo deja claro. Para enterarse de un evento en menos de un segundo por HTTP, mil dispositivos deben preguntar mil veces por segundo, y casi todas las respuestas serán «nada nuevo». En MQTT el evento llega solo en el instante en que ocurre y, entretanto, no consume tráfico.

Y CoAP, AMQP y WebSocket

• CoAP es REST sobre UDP para nodos muy pequeños. Más ligero que MQTT, pero no ofrece colas ni entrega fiable sin esfuerzo.
• AMQP es más pesado y más rico: enrutamiento elaborado, transacciones, colas de nivel empresarial. Razonable entre servidores, excesivo para un sensor.
• WebSocket es un transporte, no una alternativa: el propio MQTT viaja sobre WebSocket para funcionar dentro de un navegador.
• Sparkplug B no es un rival, sino una capa sobre MQTT: dicta cómo nombrar topics y codificar cargas útiles en sistemas industriales, para que software SCADA de distintos fabricantes entienda los mismos datos.

# Transporte, puertos y cargas útiles

MQTT va sobre TCP y solo pide entrega fiable y ordenada. Los puertos habituales:

Para el protocolo, una carga útil no es más que una secuencia de bytes. MQTT no sabe nada del contenido ni impone nada: JSON, CBOR, protobuf, un simple número o una imagen valen igual. El límite formal son 256 MB, pero en la práctica todo lo que pase de unos cientos de kilobytes corresponde a HTTP, viajando por MQTT solo un enlace.

En la práctica domina JSON: lo lee una persona, lo analiza cualquier lenguaje y resulta bastante compacto. En un enlace estrecho, un formato binario se gana su sitio, y ahí es exactamente donde ayuda la propiedad Content Type de MQTT 5.0, al declarar con honestidad qué hay dentro.

# Seguridad

MQTT no cifra nada por sí mismo: en el puerto 1883 el usuario y la contraseña viajan en claro. La seguridad viene de tres capas independientes, y ninguna es opcional.

Cifrar el canal

TLS en el puerto 8883. Para dispositivos demasiado débiles para TLS, la única opción decente es mantenerlos en una red aislada y no dejar salir nada salvo a través de una pasarela.

Autenticación

Lo clásico es usuario y contraseña en el paquete CONNECT. Más estricto: certificados de cliente, con el dispositivo presentando el suyo y el broker verificando la firma. Más flexible: JWT, donde el dispositivo trae un token firmado y con caducidad, y revocar el acceso no exige tocar el broker. Los buenos brokers también saben leer cuentas de una base externa, un archivo CSV o un servicio HTTP, para que la lista de dispositivos no tenga que existir por duplicado.

Permisos por topic

La autenticación responde a «quién es usted»; la autorización, a «qué puede hacer». Las listas de control de acceso dicen qué topics puede leer un cliente y cuáles puede escribir. El ajuste correcto es denegar todo salvo lo permitido explícitamente.

A eso se suman límites de ritmo de publicación (para que un dispositivo enloquecido no sepulte al broker), un tamaño máximo de paquete y la higiene de red habitual: el panel del broker no pinta nada asomado a la Internet abierta.

# Dónde se usa MQTT de verdad

Hogar conectado y automatización de edificios

El mayor campo por volumen. Home Assistant, Zigbee2MQTT, ESPHome y openHAB hablan a través de un broker MQTT, que además hace de argamasa entre equipos de distintos fabricantes: un enchufe, un detector de fugas y un controlador de calefacción de tres marcas cooperan a la perfección, porque cada uno se limita a escribir en su propio topic.

Industria y SCADA

Lecturas de máquina, estado de la línea, contadores de horas. El montaje clásico es una pasarela que lee Modbus u OPC UA del equipo y lo republica por MQTT, tras lo cual SCADA, un historiador y un sistema de mantenimiento predictivo lo consumen a la vez sin estorbarse. Aquí es donde Sparkplug B y las suscripciones compartidas de MQTT 5.0 se ganan su sitio.

Contadores y suministros

Contadores de agua, gas, electricidad y calor: dispositivos a batería que despiertan una vez por hora, informan de una lectura y vuelven a dormir. Aquí las sesiones persistentes y retain hacen el trabajo pesado: el servidor ve siempre el último valor aunque un contador no vaya a asomarse hasta la noche.

Transporte y telemática

Coordenadas, consumo, estado del equipo frigorífico, conducta del conductor. El enlace es una red celular que desaparece en túneles y fuera de la ciudad. La cola y el reenvío tras la reconexión convierten una conexión hecha jirones en un flujo continuo de datos.

Energía, agricultura, sanidad

Plantas solares y subestaciones, sistemas de riego y estaciones meteorológicas, monitores de pacientes y neveras de vacunas. Lo que comparten: muchos puntos finales, un enlace débil, eventos que no se pueden perder y la necesidad de enterarse de una avería al instante.

Ciudades inteligentes y logística

Alumbrado público, aparcamiento, contenedores que informan de su llenado, seguimiento de carga y temperatura de la cadena de frío. Decenas de miles de dispositivos enviando mensajes cortos y espaciados: exactamente el perfil de carga para el que se diseñó MQTT.

# Diseñar los topics: decisiones que conviene tomar pronto

Su esquema de topics es la API de su sistema. Cambiarlo después duele, porque firmware y servidor han de actualizarse a la vez. Unas cuantas reglas que ahorran tiempo.

• De lo general a lo concreto. planta/nave3/linea2/maquina7/temperatura permite suscribirse a cualquier nivel. El orden inverso vuelve inútiles los comodines.
• Dé al identificador del dispositivo su propio nivel. Es lo que permite que una sola regla ACL confine un dispositivo a su rama.
• Sin barra inicial. /oficina/temp crea un primer nivel vacío: legal, pero fuente duradera de confusión.
• Solo letras latinas, cifras, guion y guion bajo. Los espacios y los caracteres +, # y $ en los nombres provocan fallos que nadie espera.
• Nunca codifique datos cambiantes en el topic. sensor/42/temp/21.5 es un error: el valor va en la carga útil, o el broker acaba con un árbol de topics sin límite y retain deja de servir.
• Separe estado de órdenes. Por ejemplo device/42/state para lo que informa el dispositivo y device/42/cmd para lo que se le ordena. Si no, el eco de las propias órdenes acabará realimentando la lógica.
• Retain para el estado, no para la telemetría. Retain sirve para el «último estado conocido» y no tiene sentido para un flujo de lecturas.

# Elegir un broker

Hay muchos brokers, y la elección suele reducirse a un puñado de preguntas.

• ¿Admite MQTT 5.0 por completo? La compatibilidad parcial es frecuente, y uno se entera casi siempre en el peor momento posible.
• ¿Se ve lo que ocurre? Poder observar quién está conectado, qué topics tienen vida y qué pasa ahora mismo ahorra horas de depuración. Un broker sin panel convierte cada problema en arqueología de registros.
• ¿Cómo se dan de alta los dispositivos? Con miles, hacerlo a mano queda descartado: hace falta una API o cuentas en una base externa.
• ¿Sobrevive a un reinicio? Mensajes retenidos, sesiones persistentes y colas deben llegar al disco, o un reinicio planificado significará perder datos.
• ¿Qué límites ofrece? Un dispositivo enloquecido no debe tumbar el sistema: los límites de ritmo y de volumen importan.
• ¿Cuánto cuesta y dónde se ejecuta? Un servicio en la nube es cómodo hasta que empieza a cobrar por mensaje; un servidor propio hay que administrarlo, pero los datos siguen siendo suyos.

Para una instalación pequeña o mediana —de un hogar conectado a una planta con unos miles de puntos— suele bastar un único broker en una máquina modesta. El clustering hace falta mucho menos de lo que parece durante el diseño; más a menudo compensa enlazar dos brokers independientes con un puente que reenvíe solo los topics importantes.

# Empezar en cinco minutos

La forma más rápida de entender todo esto es levantar un broker y mirar los mensajes uno mismo. En Debian o Ubuntu son tres comandos:

sudo wget -qO /usr/share/keyrings/elx-repo.gpg https://repo.um-d.ru/elx-repo.gpg
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" | sudo tee /etc/apt/sources.list.d/elx-repo.list
sudo apt-get update && sudo apt-get install elxmqttbroker

El panel se abre en http://su-servidor:8567. Cree un usuario y pruebe el intercambio con cualquier cliente, por ejemplo las herramientas de consola de mosquitto:

# en una ventana: suscribirse a todo lo que envía el dispositivo
mosquitto_sub -h localhost -u sensor-42 -P contrasena -t 'sensor-42/#' -v

# en otra: publicar una lectura
mosquitto_pub -h localhost -u sensor-42 -P contrasena -t 'sensor-42/temp' -m '21.5'

# lo mismo, pero recordado para los futuros suscriptores
mosquitto_pub -h localhost -u sensor-42 -P contrasena -t 'sensor-42/temp' -m '21.5' -r

A partir de ahí, juegue con la marca retain, desconecte un suscriptor y observe qué se acumula en una sesión persistente, ponga un testamento y tire del cable. Media hora de eso enseña más que cualquier artículo, este incluido.

# Respuestas rápidas