¿Qué es MQTT? Una introducción práctica

MQTT (originalmente MQ Telemetry Transport) es un protocolo de mensajería ligero basado en el patrón publicación/suscripción. Los clientes nunca hablan entre sí directamente — envían mensajes a un broker central, etiquetados con un topic, y el broker reenvía cada mensaje a todos los clientes suscritos a un topic coincidente. Ese modelo tan sencillo es la razón por la que MQTT mueve de todo, desde redes de sensores y hogares inteligentes hasta telemetría de vehículos y dashboards en tiempo real.

Esta introducción explica cómo funciona MQTT, cuáles son sus funciones importantes y cuándo es (y cuándo no) la herramienta adecuada. Si quieres ir probando sobre la marcha, abre el cliente MQTT online en otra pestaña.

Un poco de historia

MQTT fue diseñado en 1999 por Andy Stanford-Clark (IBM) y Arlen Nipper para monitorizar oleoductos a través de enlaces por satélite caros y poco fiables. Los objetivos de diseño — paquetes diminutos, código de cliente mínimo, tolerancia a redes inestables — resultaron encajar a la perfección con el Internet de las Cosas. MQTT 3.1.1 se convirtió en estándar OASIS en 2014 (y más tarde en ISO/IEC 20922), y MQTT 5.0 llegó en 2019 con códigos de motivo, propiedades de usuario, caducidad de mensajes y más. Ambas versiones están muy extendidas hoy; consulta MQTT 5 vs 3.1.1 para ver las diferencias.

Cómo funciona MQTT: publicación/suscripción

En MQTT solo hay dos roles:

• Clientes — cualquier programa o dispositivo que se conecta al broker. Un cliente puede publicar, suscribirse o ambas cosas. Un sensor de temperatura, una app móvil y un servicio backend son todos simplemente clientes.
• El broker — el servidor que acepta conexiones, autentica a los clientes, hace coincidir los topics y entrega los mensajes. Entre los brokers más populares están Mosquitto, EMQX y HiveMQ.

Publicadores y suscriptores están desacoplados: un publicador no sabe quién recibe su mensaje (si es que alguien lo recibe), y los suscriptores no saben quién lo envió. Solo comparten el nombre de un topic. Esto facilita añadir un nuevo consumidor — un dashboard, un proceso que escribe en base de datos, un servicio de alertas — sin tocar los dispositivos que producen los datos.

sensor-17  --PUBLISH home/kitchen/temperature "21.5"-->  broker
broker     --PUBLISH home/kitchen/temperature "21.5"-->  dashboard   (subscribed to home/+/temperature)
broker     --PUBLISH home/kitchen/temperature "21.5"-->  logger      (subscribed to home/#)

Topics: la dirección de un mensaje

Un topic es una cadena UTF-8 con niveles separados por barras, como factory/line-2/press-4/pressure. Los topics no se crean de antemano — existen en cuanto alguien publica en ellos. Los suscriptores pueden usar dos comodines: + coincide exactamente con un nivel y # coincide con cualquier número de niveles al final. Un buen diseño de topics importa mucho para los permisos y la escalabilidad; nuestra guía de topics y comodines MQTT lo trata en profundidad.

La conexión y sus paquetes

MQTT funciona sobre una conexión de larga duración — normalmente TCP, opcionalmente envuelta en TLS, o WebSockets para los navegadores. La sesión empieza con un paquete CONNECT (client ID, usuario y contraseña opcionales, keep-alive, Last Will) y el broker responde con CONNACK. A partir de ahí, los paquetes más habituales son:

La cabecera fija de un paquete MQTT ocupa solo dos bytes, y el payload es binario opaco — JSON, texto plano, Protobuf o bytes en bruto funcionan igual. Esa sobrecarga mínima es lo que hace atractivo a MQTT en dispositivos con recursos limitados y redes de datos medidas.

Funciones clave de MQTT

Calidad de servicio (QoS)

Cada publicación y cada suscripción tiene un nivel de QoS: 0 (como máximo una vez), 1 (al menos una vez) o 2 (exactamente una vez). Los niveles más altos añaden paquetes de confirmación a cambio de garantías de entrega más fuertes. Los detalles y los flujos de paquetes están en los niveles de QoS de MQTT explicados.

Mensajes retenidos (retained)

Un mensaje publicado con el flag retain lo guarda el broker como último valor conocido de ese topic y se entrega de inmediato a cada nuevo suscriptor. Es ideal para estados como online/offline o la consigna actual. Consulta los mensajes retenidos.

Last Will and Testament

Un cliente puede registrar un mensaje que el broker publicará en su nombre si el cliente desaparece sin una desconexión limpia — la forma estándar de detectar dispositivos desconectados. Consulta Last Will and Testament.

Sesiones persistentes

Con una sesión persistente (cleanSession=false en 3.1.1, cleanStart=false más un intervalo de caducidad de sesión en MQTT 5), el broker recuerda las suscripciones de un cliente y encola los mensajes QoS 1 y 2 mientras está desconectado, entregándolos cuando se vuelve a conectar.

Prueba MQTT en dos minutos

La forma más rápida de entender MQTT es ver un mensaje hacer el viaje de ida y vuelta. Conéctate a un broker público, suscríbete a un topic único y publica en él:

1. Abre el cliente online y conéctate a un broker de la lista de brokers públicos.
2. Suscríbete a testmqtt/your-name/#.
3. Publica hello en testmqtt/your-name/greeting y observa cómo llega.

Pruébalo en el cliente MQTT online

O bien, desde una terminal con los clientes de Mosquitto instalados:

# terminal 1
mosquitto_sub -h test.mosquitto.org -t 'testmqtt/intro/#' -v

# terminal 2
mosquitto_pub -h test.mosquitto.org -t 'testmqtt/intro/greeting' -m 'hello'

Cuándo usar MQTT (y cuándo no)

MQTT encaja muy bien cuando:

• Muchos dispositivos envían mensajes pequeños y frecuentes (telemetría, lecturas de sensores, estado).
• Las redes son poco fiables o el ancho de banda es limitado, y necesitas reconexiones automáticas y cola de mensajes sin conexión.
• Los datos deben enviarse a los clientes en tiempo real en lugar de consultarse periódicamente (polling).
• Quieres distribución uno-a-muchos sin conectar productores con consumidores.

Encaja peor cuando:

• Necesitas petición/respuesta con una semántica rica — las APIs HTTP simples son más sencillas (MQTT 5 añade response topics, pero sigue siendo mensajería).
• Necesitas almacenamiento a largo plazo o reproducir un historial completo de eventos — eso es trabajo de un log como Kafka o de una base de datos alimentada por MQTT.
• Transfieres archivos grandes; MQTT puede transportarlos, pero no está diseñado para ello.

Para una comparación lado a lado, lee MQTT vs HTTP.

Próximos pasos

Ahora que sabes qué es MQTT, aprende a elegir niveles de QoS, a diseñar una jerarquía de topics y a probar un broker MQTT de principio a fin. Todas las guías están en el centro de aprendizaje MQTT.

Preguntas frecuentes