MQTT a fondo: modelo de publicación/suscripción, QoS de tres niveles y novedades de 5.0

Compartir Recursos Tutoriales & Documentos
,
1

Si has trabajado en proyectos de IoT, es muy probable que no puedas evitar encontrarte con una palabra: MQTT. Desde las bombillas inteligentes del hogar hasta los sensores de humedad del suelo en el campo, desde las máquinas de las líneas de producción hasta las bicicletas compartidas junto a la carretera, miles de millones de dispositivos se comunican entre sí gracias a este protocolo nacido en 1999. ¿Por qué se ha convertido en el estándar de facto del IoT? ¿En qué es realmente mejor que HTTP? En este artículo iremos desde el modelo de publicación/suscripción hasta los tres niveles de QoS, los mensajes de testamento, las novedades de MQTT 5.0, además de incluir una comparación de protocolos y un fragmento de código en Python que puedes ejecutar directamente, para ayudarte a entender MQTT de una vez por todas.

Uno. Empecemos por un invernadero inteligente: por qué el IoT no puede usar solo HTTP

Imagina un invernadero agrícola inteligente típico: cientos de sensores de temperatura, humedad, luz y humedad del suelo están repartidos por el campo, alimentados por baterías y paneles solares, y envían datos a la nube a través de una red 4G que funciona mejor o peor; la nube, a su vez, debe controlar de forma remota toldos, ventiladores y válvulas de riego en función de los datos en tiempo real.

Durante la revisión de la solución, la primera reacción del equipo de desarrollo suele ser: «Usemos HTTP, ¿no? Basta con hacer un POST». La idea no está mal, pero en escenarios reales con redes débiles, cientos o miles de dispositivos y necesidad de estar en línea 7×24, las limitaciones de HTTP quedan totalmente al descubierto:

  • La nube no puede enviar datos de forma activa. HTTP funciona con un modelo de solicitud/respuesta. Si la nube quiere enviar una instrucción como «enciende el ventilador para enfriar», solo puede esperar a que el dispositivo haga la siguiente consulta. Si el intervalo de consulta es largo, la latencia de la instrucción se vuelve enorme; si es corto, miles de dispositivos consultan al mismo tiempo y el servidor y la red se saturan con solicitudes innecesarias.
  • La sobrecarga de cabeceras es demasiado grande. Una sola solicitud HTTP puede tener cabeceras de varios cientos de bytes, mientras que los datos que el dispositivo realmente necesita enviar pueden ser solo unos pocos bytes —por ejemplo, un valor de temperatura como «26,5»—. Es como enviar una nota en papel dentro de una caja de cartón enorme.
  • El consumo energético no lo aguanta. Cada comunicación requiere un handshake completo de TCP + TLS. Para un sensor alimentado por batería, que el módulo de radiofuncione un segundo más ya es dinero quemado.

Este no es solo un problema de los escenarios agrícolas, sino una cuestión común de toda la industria del IoT: una cantidad masiva de dispositivos, redes débiles, restricciones de bajo consumo y comunicación bidireccional en tiempo real. HTTP fue diseñado para que las personas naveguen por la web, no para que las máquinas charlen entre sí. MQTT, en cambio, nació precisamente para eso.

Dos. Qué es MQTT: un protocolo creado para «ahorrar costes»

MQTT era originalmente la abreviatura de Message Queuing Telemetry Transport (transporte de telemetría con cola de mensajes). Sin embargo, hoy la especificación oficial ya no lo interpreta como una abreviatura; dentro del protocolo no existe realmente una cola de mensajes en el sentido tradicional, y este nombre es más bien una herencia histórica.

Su origen lo dice todo. En 1999, Andy Stanford-Clark, de IBM, y Arlen Nipper, de Arcom, diseñaron este protocolo para un escenario muy concreto: monitorizar oleoductos que cruzaban tierras desoladas mediante enlaces satelitales. La comunicación satelital se facturaba por volumen de tráfico, el ancho de banda era extremadamente estrecho, la latencia era alta y los dispositivos de monitorización a lo largo de la ruta funcionaban con baterías. Por eso, los objetivos de diseño eran muy sencillos: paquetes pequeños, protocolo eficiente energéticamente y capacidad para resistir cortes de red.

Estos tres objetivos sencillos moldearon el ADN que MQTT mantiene hasta hoy:

  • Paquetes extremadamente pequeños: la cabecera fija mínima ocupa solo 2 bytes; comparado con las cabeceras de texto de HTTP, que suelen ocupar cientos de bytes, el ahorro es máximo.
  • Ligero: funciona sobre TCP (puerto predeterminado 1883, 8883 con cifrado TLS), y un microcontrolador con unas decenas de KB de memoria ya puede ejecutar un cliente MQTT.
  • Diseñado para redes inestables: incorpora de serie mecanismos como latidos, mensajes de testamento y QoS por niveles, todo un conjunto de funciones de «autoprotección ante desconexiones».

Alrededor de 2013, IBM presentó MQTT a la organización de estandarización OASIS. En 2014, MQTT 3.1.1 se convirtió en estándar oficial de OASIS y más tarde fue aceptado como estándar internacional ISO (ISO/IEC 20922). Actualmente, las versiones principales son MQTT 3.1.1 y MQTT 5.0 (publicada en 2019); 5.0 es la versión recomendada hoy, y más adelante hablaremos de ella en detalle.

eeClub-Comunidad de ingenieros electrónicos: https://bbs.eeclub.top/

Grupo QQ para intercambio técnico sobre electrónica/microcontroladores: 2169025065

Tres. Arquitectura central: no es «hacer una llamada», sino «suscribirse a un periódico»

Para entender MQTT, lo más importante es comprender su modelo de comunicación: el modelo de publicación/suscripción (Publish/Subscribe).

El modelo de solicitud/respuesta de HTTP es como hacer una llamada: marcas el número de la otra parte y conversas directamente; ambos deben estar en línea al mismo tiempo y conocer el «número» del otro.

El modelo de publicación/suscripción, en cambio, es como suscribirse a un periódico: la editorial (el publicador) imprime el periódico y lo entrega a la oficina postal (el Broker); tú (el suscriptor) te registras antes en la oficina postal diciendo «quiero la sección de tecnología»; cada día, cuando llega el periódico, la oficina postal lo entrega según la lista de suscriptores. La editorial no sabe quiénes son los lectores, y los lectores no necesitan conocer el teléfono de la editorial: ambas partes quedan completamente desacopladas, y la oficina postal es el único punto central.

En este modelo hay tres roles principales:

  • Publisher (publicador): el dispositivo o programa que genera mensajes, por ejemplo, un sensor que informa la temperatura.
  • Broker (servidor intermediario): la «oficina postal» de todo el sistema. Recibe mensajes, los distribuye por tema a todos los suscriptores y se encarga de tareas como conexiones, sesiones y mensajes retenidos. Es el único componente que necesita ser alcanzable desde Internet.
  • Subscriber (suscriptor): el dispositivo o programa interesado en cierto tipo de mensajes, por ejemplo, una aplicación móvil o un panel de datos.

Cabe aclarar que publicador y suscriptor son roles lógicos; un mismo dispositivo puede desempeñar ambas funciones. Una cámara puede publicar alertas en la nube y, al mismo tiempo, suscribirse a instrucciones de control enviadas desde la nube. Además, como los dispositivos solo necesitan conectarse activamente al Broker hacia el exterior, no necesitan una IP pública ni abrir ningún puerto, lo que evita de forma natural los problemas de NAT y cortafuegos. Esta es también una de las razones importantes por las que MQTT es más popular que soluciones como «abrir un puerto en el dispositivo y esperar conexiones».

Topic: el «número de buzón» de la oficina postal

¿Cómo se distribuyen los mensajes? Mediante Topic (tema). Un Topic es una cadena UTF-8 dividida en niveles con /, parecida a una ruta de archivo:

home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature

Al suscribirse se pueden usar dos comodines:

  • + comodín de un solo nivel: coincide exactamente con un nivel. Por ejemplo, home/+/temperature permite recibir tanto la temperatura del salón como la del dormitorio.
  • # comodín multinivel: coincide con cualquier cantidad de niveles posteriores, pero solo puede colocarse al final. Por ejemplo, home/# permite recibir todos los mensajes bajo home.

Cuatro. Características clave explicadas una por una

MQTT puede mantenerse firme en redes débiles gracias a un conjunto de mecanismos bien diseñados. Las siguientes características son las que aparecen con más frecuencia en entrevistas y en escenarios reales.

1. QoS: tres «servicios de mensajería» para la entrega de mensajes

MQTT divide la calidad de entrega de mensajes (Quality of Service) en tres niveles, que pueden entenderse como tres tipos de envío:

  • QoS 0 — como máximo una vez (At most once): equivale al correo ordinario. Se envía y ya está; no hay confirmación ni reenvío. Puede perderse, pero nunca se duplica. Es adecuado para datos de alta frecuencia donde no importa perder algunos, como valores en tiempo real enviados una vez por segundo: si se pierde este marco, en el siguiente segundo habrá otro nuevo.
  • QoS 1 — al menos una vez (At least once): equivale al correo certificado. El receptor debe responder con PUBACK para confirmar; si el emisor no recibe la confirmación, reenvía. Garantiza la llegada, pero puede duplicarse: si el paquete de confirmación se pierde en camino, el emisor enviará otro mensaje. Es adecuado para alertas, cambios de estado y mensajes del tipo «mejor que se repita a que se pierda»; el receptor debe implementar idempotencia.
  • QoS 2 — exactamente una vez (Exactly once): equivale a un envío especial con firma por ambas partes. Mediante cuatro fases —PUBREC, PUBREL y PUBCOMP— se garantiza que no se pierda ni se duplique, aunque es el modo con mayor sobrecarga y más lento. Es adecuado para escenarios como facturación, donde «cobrar un yuan de más ya es un accidente».

La regla es sencilla: cuanto mayor sea el QoS, mayor será la fiabilidad, pero también la sobrecarga y la latencia. En ingeniería, elegir QoS 1 por defecto suele ser el compromiso más rentable.

Hay un detalle que suele pasarse por alto: el QoS lo declaran por separado el publicador y el suscriptor, y cuando el Broker entrega realmente el mensaje toma el valor menor de ambos. Si el publicador usa QoS 2 pero el suscriptor solo se suscribe con QoS 0, el mensaje se entregará finalmente con QoS 0. Por eso, al depurar preguntas como «por qué se pierden mis mensajes de QoS alto», recuerda revisar ambos extremos.

2. Mensajes retenidos (Retained): la nota pegada en el buzón

Los mensajes ordinarios se «autodestruyen después de leerse»: si el suscriptor no está en línea, el mensaje desaparece después de enviarse. Pero si al publicar se activa la marca Retain, el Broker guardará para ese Topic el último mensaje retenido. Después, cualquier nuevo suscriptor que se suscriba a ese tema lo recibirá de inmediato.

Un uso típico es que, cuando un dispositivo se conecta, publique su estado —por ejemplo, «online» o el estado actual del interruptor— con Retain. Así, sin importar cuándo abra la aplicación, podrá ver de inmediato el último estado del dispositivo sin tener que esperar penosamente a la siguiente subida. Ten en cuenta que cada tema solo almacena un mensaje retenido; los nuevos sobrescriben a los antiguos. Para borrar el mensaje retenido de un tema, basta con publicar en ese tema un mensaje Retain con carga útil vacía.

3. Mensajes de testamento (LWT): el «último deseo» que deja el dispositivo

Last Will and Testament (mensaje de testamento) es el diseño con más humanidad de MQTT. Cuando un cliente se conecta al Broker, puede registrar por adelantado: «si muero de forma inexplicable (desconexión anómala), por favor publica este mensaje en mi nombre».

Por ejemplo, una cámara puede registrar al conectarse el testamento camera/01/status = "offline" (Retained). Si el dispositivo pierde energía o se queda sin red y la conexión se corta de forma anómala, el Broker publicará el mensaje de testamento en su nombre, y todos los suscriptores sabrán de inmediato que «este dispositivo ha caído». Combinado con Retained, los usuarios que abran la aplicación más tarde también podrán ver el estado sin conexión.

4. Keep Alive: latido para confirmar que ambos siguen vivos

TCP tarda mucho en detectar que el extremo contrario está «muerto en apariencia». MQTT añade un latido en la capa de aplicación: cuando el cliente se conecta, acuerda con el Broker un intervalo Keep Alive (por ejemplo, 60 segundos); cuando está inactivo, envía un paquete PINGREQ extremadamente pequeño, y el Broker responde con PINGRESP. Si el Broker no recibe ningún mensaje del cliente durante 1,5 veces el tiempo de Keep Alive, determina que ha muerto, cierra la conexión y activa el mensaje de testamento.

5. Clean Session: después de reconectar, ¿todavía me recuerdas?

El cliente le indica al Broker, mediante la marca Clean Session, si debe conservar la sesión. Cuando se establece en 0 (sesión persistente), el Broker recuerda las suscripciones de ese cliente y los mensajes QoS 1/2 que se perdió mientras estaba desconectado, para reenviárselos cuando se reconecte; si se establece en 1, tras la reconexión todo empieza de cero.

MQTT 5.0 dividió este mecanismo en Clean Start (si se empieza de cero) y Session Expiry Interval (tiempo de expiración de la sesión), lo que permite expresarlo con mayor precisión: por ejemplo, conservar la sesión durante 24 horas, en lugar de la opción simple de «existir para siempre/no existir».

6. Estructura del paquete: compresión extrema que empieza con 2 bytes

Un paquete MQTT se compone de cabecera fija + cabecera variable + carga útil. Los 4 bits altos del primer byte de la cabecera fija indican el tipo de paquete (CONNECT, PUBLISH, SUBSCRIBE, PINGREQ, etc., 14 tipos en total), y los 4 bits bajos son marcas. Después viene el campo de «longitud restante» codificado en longitud variable, que ocupa como mínimo solo 1 byte. Es decir, un paquete de latido ocupa en total solo 2 bytes: esa es la base de lo «ligero» de MQTT.

Cinco. MQTT 5.0: una actualización muy bien planteada

MQTT 5.0, publicado en 2019, mantiene la ligereza y añade muchas mejoras para cubrir carencias de ingeniería:

  • Códigos de motivo (Reason Code): casi todos los paquetes de respuesta incluyen un código de motivo estandarizado. Que una conexión sea rechazada o una suscripción falle ya no significa simplemente «error», sino que indica claramente por qué.
  • Sistema de propiedades (Properties): los paquetes pueden llevar pares clave-valor de metadatos flexibles; muchas capacidades nuevas se basan en este mecanismo.
  • Suscripción compartida (Shared Subscription): varios suscriptores forman un grupo de consumo (por ejemplo, $share/group1/topic), y el mismo mensaje se entrega solo a un miembro del grupo, logrando de forma natural el equilibrio de carga. Esto en la época de 3.1.1 requería muchos rodeos.
  • Expiración de mensajes (Message Expiry Interval): al publicar, se puede asignar un período de validez al mensaje; los mensajes fuera de línea expirados ya no se reenvían, evitando que el dispositivo sea bombardeado con instrucciones obsoletas al conectarse.
  • Otras mejoras: alias de tema (usar un número corto para sustituir un nombre de tema largo y ahorrar tráfico), control de flujo mediante Receive Maximum, notificación de desconexión iniciada por el servidor, soporte para patrones de solicitud-respuesta basados en Response Topic, etc.

En resumen: 3.1.1 es suficiente, 5.0 es más cómodo; para proyectos nuevos, lo recomendable es usar directamente 5.0.

Seis. Comparación lateral: MQTT vs HTTP vs CoAP vs WebSocket

No basta con decir que MQTT es bueno; al ponerlo junto a otros protocolos, su posición queda mucho más clara:

Dimensión MQTT HTTP CoAP WebSocket
Modelo de comunicación Publicación/suscripción Solicitud/respuesta Solicitud/respuesta (tipo REST) Flujo de datos full dúplex
Capa de transporte TCP TCP UDP TCP
Sobrecarga mínima del paquete 2 bytes Cientos de bytes en cabecera 4 bytes Desde 2 bytes de cabecera de trama
Envío activo desde la nube Soporte nativo No compatible (requiere polling/adaptación) Requiere combinar con Observe Compatible
Mecanismos de fiabilidad de mensajes QoS de tres niveles integrado Depende de TCP Confirmación/reenvío opcional Ninguno; hay que implementarlo por cuenta propia
Adaptación a bajo consumo Excelente Pobre Excelente (UDP consume menos) Media
Escenarios típicos Dispositivos hacia la nube, telemetría, control remoto Web, API abiertas, transferencia de archivos Redes de sensores con recursos extremadamente limitados Interacción en tiempo real en web, salas de chat

Una frase para definirlo: HTTP es para las personas, WebSocket es para los navegadores, CoAP es para dispositivos con recursos extremadamente limitados y MQTT es para escenarios de «miles de millones de dispositivos + redes débiles + tiempo real bidireccional».

Siete. Escenarios de uso típicos: quizá lo usas todos los días

  • Hogar inteligente: es la base más grande de MQTT. En la plataforma de código abierto Home Assistant, un gran número de dispositivos se conectan mediante MQTT; es muy posible que la bombilla, el enchufe o el termohigrómetro de tu casa estén ahora mismo manteniendo una conexión persistente con algún Broker.
  • IoT industrial (IIoT): PLC, máquinas-herramienta e instrumentos de las líneas de producción envían datos a un Broker de planta, y los sistemas MES y las pantallas de monitorización se suscriben según sus necesidades. En plataformas cloud como Alibaba Cloud IoT y AWS IoT Core, el protocolo principal de la capa de acceso de dispositivos también es MQTT.
  • Conectividad vehicular: las plataformas de gestión de flotas envían instrucciones a miles de vehículos mediante MQTT y recopilan el estado de cada vehículo. La clasificación por QoS encaja perfectamente con necesidades diferenciadas como «la posición puede perderse, pero el bloqueo remoto del vehículo debe llegar».
  • Monitorización ambiental y agrícola: sensores de suelo en el campo y estaciones de control de calidad del agua junto a embalses funcionan con baterías y energía solar; el bajo consumo y la capacidad de caché ante desconexiones de MQTT son indispensables.

Ocho. Primeros pasos prácticos: ejecuta tu primer mensaje MQTT en diez minutos

Lo que se aprende solo en papel nunca es suficiente, pero la barrera para hacerlo en la práctica es muy baja.

Elegir un Broker

  • EMQX: código abierto chino, alto rendimiento, documentación amigable en chino y un Broker público de pruebas en línea, broker.emqx.io; es la primera opción para practicar.
  • Mosquitto: proyecto de la Eclipse Foundation, escrito en C, extremadamente ligero, puede ejecutarse incluso en una Raspberry Pi, ideal para depuración local.
  • HiveMQ: solución empresarial del ecosistema Java, con soporte comercial completo.

Elegir una herramienta cliente

  • MQTTX: cliente de escritorio multiplataforma de EMQ (también disponible en CLI y versión web), con una interfaz intuitiva; imprescindible para ajustar protocolos.
  • mqtt-cli / mosquitto_pub, mosquitto_sub: herramientas prácticas para quienes prefieren la línea de comandos.

Un ejemplo en Python que funciona

Instala la dependencia: pip install paho-mqtt

Lado suscriptor (subscriber.py):

import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("已连接:", reason_code)
    client.subscribe("home/livingroom/temperature", qos=1)

def on_message(client, userdata, msg):
    print(f"收到 [{msg.topic}] {msg.payload.decode()}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.emqx.io", 1883, 60)
client.loop_forever()

Lado publicador (publisher.py):

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.connect("broker.emqx.io", 1883, 60)
client.publish("home/livingroom/temperature", "26.5", qos=1)
client.disconnect()
print("已发送")

Ejecuta primero el lado suscriptor y luego el publicador; verás ese «26,5» en la terminal del suscriptor. Ese es el «latido» más pequeño del mundo del IoT.

Una última advertencia: el Broker público de pruebas es compartido por todos; no subas nunca a él ningún dato sensible. Para proyectos formales, crea tu propio Broker o contrata un servicio de Broker, y asegúrate de activar el cifrado TLS y la autenticación de cuentas.

Nueve. Resumen

El éxito de MQTT no radica en lo avanzado que sea, sino en su extrema contención: los paquetes pequeños, el bajo consumo y la resistencia a redes débiles, surgidos por necesidad en un entorno tan exigente como «oleoducto + enlace satelital», encajan justo con las necesidades principales de la enorme cantidad de dispositivos IoT. Su modelo desacoplado de publicación/suscripción, la fiabilidad flexible de los tres niveles de QoS y diseños prácticos como los mensajes de testamento y los mensajes retenidos, centrados en la realidad de que «los dispositivos se desconectan», lo han convertido en el protocolo estándar de facto del IoT actual.

Si estás trabajando en hardware inteligente o desarrollo backend, mi consejo es: primero usa un bróker público y MQTTX para probar la publicación/suscripción; luego lee con atención los mecanismos de QoS y de sesión. Si dominas bien estas dos partes, ya tendrás casi dominado MQTT.

Hace treinta años, ese oleoducto que cruzaba la estepa probablemente no imaginaba que el pequeño protocolo diseñado para él hoy se ejecutaría en miles de millones de dispositivos. La vitalidad de la tecnología suele estar precisamente en diseños que son «justo lo necesario».

Recursos de aprendizaje complementarios

Lecturas recomendadas

Versión en inglés del artículo: https://blog.zeruns.top/archives/96.html