Conociendo MQTT

¿Por qué MQTT es uno de los mejores protocolos de red para el

Internet de las Cosas?

Michael Yuan 05-12-2018

(Primera publicación 04-10-2017)

Este artículo ofrece una presentación técnica acerca del protocolo MQTT. Aprenderá qué
es MQTT, por qué es adecuado para aplicaciones de IoT y cómo empezar a desarrollar
aplicaciones que usan MQTT.

Para los dispositivos de Internet de las Cosas (IoT), la conexión a Internet es un requisito. La
conexión a Internet permite que los dispositivos trabajen entre sí y con servicios de backend.
El protocolo de red subyacente de Internet es el TCP/IP. Desarrollado con base en la pila TCP/
IP, el MQTT (Message Queue Telemetry Transport) se ha convertido en el patrón para las
comunicaciones del IoT.

Inicialmente, MQTT fue inventado y desarrollado por IBM a finales de los 90. Su aplicación original
era vincular sensores en oleoductos de petróleo a satélites. Tal como sugiere su nombre, se trata
de un protocolo de mensajería con soporte para la comunicación asíncrona entre las partes. Un
protocolo de sistema de mensajes asíncrono separa al emisor y al receptor del mensaje tanto
en el tiempo como en el espacio y, por lo tanto, es escalable en ambientes de red que no sean
de confianza. Pese a su nombre, no tiene nada que ver con colas de mensajes; en realidad,
utiliza un modelo de publicación y suscripción. A final de 2014, se convirtió oficialmente en un
patrón abierto OASIS, con soporte en los lenguajes de programación populares, usando diversas
implementaciones de software libre.

Por qué elegir MQTT

MQTT es un protocolo de red leve y flexible que ofrece el equilibrio ideal para los desarrolladores
de IoT:

• Un protocolo liviano permite la implementación en hardware de dispositivos altamente

restringidos y en redes de ancho de banda limitada y de alta latencia.
• Su flexibilidad hace posible el suporte a diversos escenarios de aplicación para dispositivos y
servicios de IoT.

© Copyright IBM Corporation 2017, 2018 Marcas

Conociendo MQTT Pagina 1 de 9
developerWorks® ibm.com/developerWorks/ssa/

Para entender por qué el MQTT es tan adecuado para los desarrolladores de IoT, analizaremos la
razón por la que otros protocolos de red populares han fallado en el IoT.

Por qué no usar alguno de los otros numerosos protocolos de red

La mayoría de los desarrolladores ya se acostumbró a los servicios de la Web HTTP. Así que,
¿por qué no conectar los dispositivos de IoT a los servicios web? El dispositivo podría enviar sus
datos como una solicitud HTTP y recibir actualizaciones del sistema como una respuesta HTTP.
Tal patrón de solicitud y respuesta tiene algunas graves limitaciones:

• HTTP es un protocolo síncrono. El cliente espera a que el servidor responda. Los

navegadores web tienen este requisito, pero el costo es la baja escalabilidad. En el mundo de
IoT, la comunicación sincrónica ha sido un problema debido al gran número de dispositivos
y a la red, a menudo no confiable y de alta latencia. Un protocolo de mensajería asíncrono
es mucho más adecuado para aplicaciones de IoT. Los sensores pueden enviar lecturas
y permitir que la red descubra el camino y la sincronización ideales para entregar a los
dispositivos y servicios de destino.
• HTTP es unidireccional. El cliente necesita iniciar la conexión. En un aplicativo de IoT, los
dispositivos y sensores generalmente son clientes, lo que significa que no pueden recibir
comandos de la red de forma pasiva.
• HTTP es un protocolo de uno a uno. El cliente realiza una solicitud y el servidor responde. Es
difícil y costoso transmitir un mensaje a todos los dispositivos en red, lo que es algo común
en aplicaciones de IoT.
• HTTP es un protocolo pesado con muchos encabezados y reglas. No es adecuado para
redes restringidas.

Por todas estas razones, la mayoría de los sistemas escalables de alto rendimiento utilizan un
bus de sistema de mensajes asíncrono, en vez de servicios web para el intercambio de datos
internos. De hecho, el protocolo de sistema de mensajes más popular que se utiliza en sistemas
de middleware corporativos se llama AMQP (Advanced Message Queuing Protocol). Sin embargo,
en un entorno de alto rendimiento, la capacidad de cálculo y la latencia de la red no suelen ser
una preocupación. El AMQP fue creado para asegurar la confiabilidad y la interoperabilidad
en aplicaciones corporativas. Posee un buen conjunto en recursos, pero no es adecuado para
aplicaciones de IoT con restricción de recursos.

Además del AMQP, existen otros protocolos populares de sistema de mensajes. Por ejemplo,
XMPP (Extensible Messaging and Presence Protocol) es un protocolo de mensajería instantánea
(IM) de punto a punto. Es pesado en recursos con soporte para casos de uso de IM, tales como
presencia y archivos adjuntos audiovisuales. En comparación con MQTT, este exige mucho más
recursos en el dispositivo y en la red.

Entonces, ¿cómo logra ser tan leve y flexible MQTT? Un recurso importante del protocolo MQTT
es el modelo de publicación y suscripción. Como en todos los protocolos de sistema de mensajes,
separa al editor y al consumidor de datos.

Conociendo MQTT Pagina 2 de 9

ibm.com/developerWorks/ssa/ developerWorks®

Modelo de publicación y de suscripción

El protocolo MQTT define dos tipos de entidades en la red: un bróker de mensajería y numerosos
clientes. Bróker es un servidor que recibe todos los mensajes de los clientes y, en seguida,
redirige estos mensajes a los clientes de destino relevantes. Un cliente es cualquier cosa que
pueda interactuar con el bróker y recibir mensajes. Un cliente puede ser un sensor de IoT en
campo o una aplicación en un centro de datos que procesa datos de IoT.

1. El cliente se conecta al bróker. Puede suscribirse a cualquier "tema" de mensajería del

bróker. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada
para mensajes sensibles.
2. El cliente publica los mensajes en un tema, enviando el mensaje y el tema al bróker.
3. Después, el bróker remite el mensaje a todos los clientes que se suscriben a este tema.

Como los mensajes de MQTT se organizan por temas, el desarrollador de aplicaciones tiene la
flexibilidad de especificar que determinados clientes solo pueden interactuar con determinados
mensajes. Por ejemplo, los sensores publicarán sus lecturas en el tema "sensor_data" y se
suscribirán al tema "config_change". Las aplicaciones de procesamiento de datos que guardan
los datos del sensor en una base de datos de backend se suscribirán al tema "sensor_data".
Una aplicación de consola administrativa podría recibir comandos del administrador del sistema
para ajustar las configuraciones de los sensores, tales como la sensibilidad y la frecuencia de
muestreo, y publicar dichos cambios en el tema "config_change". (Consulte Figura 1.)

Figura 1. El modelo de publicación y de suscripción de MQTT para sensores

de IoT

Al mismo tiempo, MQTT es liviano. Tiene un encabezado simple para especificar el tipo de
mensaje, un tema basado en texto y, posteriormente, una carga útil binaria arbitraria. La aplicación

Conociendo MQTT Pagina 3 de 9

developerWorks® ibm.com/developerWorks/ssa/

puede tener cualquier formato de datos para la carga útil, como JSON, XML, binario cifrado o
Base64, siempre que los clientes de destino puedan analizar la carga útil.

Introducción al desarrollo con MQTT

La herramienta más fácil para empezar el desarrollo con MQTT es el módulo Python mosquitto,
que forma parte del proyecto Eclipse Paho y proporciona SDKs y bibliotecas de MQTT en
varios lenguajes de programación. Contiene un bróker de MQTT que puede ser ejecutado
en la computadora local y herramientas de línea de comandos que pueden interactuar con el
bróker usando mensajes. Es posible descargar e instalar el módulo mosquitto en elsitio web de
mosquitto.

El comando mosquitto ejecuta el bróker de MQTT en la computadora local. Opcionalmente, es

posible usar la opción -d para ejecutarlo en segundo plano.

$ mosquitto -d

Después, en otra ventana de la terminal, es posible usar el comando mosquitto_sub para

conectarse al bróker local y suscribirse a un tema. Tras la ejecución del comando, esperará e
imprimirá todos los mensajes que reciba de la suscripción a medida que estos lleguen.

$ mosquitto_sub -t "dw/demo"

En otra ventana de la terminal es posible usar el comando mosquitto_pub para conectarse al

bróker local y, en seguida, publicar un mensaje en un tema.

$ mosquitto_pub -t "dw/demo" -m "hello world!"

En este momento, la terminal que ejecuta mosquitto_sub deberá exhibir "hello world!" en la
pantalla. ¡Usted acaba de enviar y recibir un mensaje usando un bróker de MQTT!

Por supuesto que en un sistema de producción no es posible utilizar una computadora local como
bróker. En ese caso, es posible usar el Servicio de la plataforma para Internet de las Cosas de
IBM Cloud; un servicio bajo demanda y confiable que funciona como un bróker de MQTT. (Lea
más acerca de cómo este servicio de IBM Cloud se integra y usa MQTT como su protocolo para
comunicarse con dispositivos y aplicaciones en la documentación del servicio.)

O en el Servicio de la plataforma para Internet de las Cosas de IBM Cloud funciona de la siguiente
forma.

• En la consola de IBM Cloud, es posible crear, bajo demanda, una instancia del servicio de la
plataforma para la Internet de las Cosas.
• Á Continuación, es posible añadir dispositivos que puedan conectar la instancia de servicio
utilizando el MQTT. Cada dispositivo tendrá un ID y un nombre. Solamente los dispositivos
enumerados pueden acceder al servicio, y el papel de la plataforma Watson IoT relatará
informaciones sobre tráfico y uso de estos servicios, en los correspondientes dispositivos.

Conociendo MQTT Pagina 4 de 9

ibm.com/developerWorks/ssa/ developerWorks®

• Para cada cliente del dispositivo, IBM Cloud designará un nombre del host, un nombre de
usuario y una contraseña para la conexión con una instancia de servicio (el bróker de MQTT).
(En IBM Cloud, el nombre de usuario siempre es use-token-auth y la contraseña es el token
que se muestra en Figura 2 para cada dispositivo conectado).

Figura 2. Creando una instancia de servicio de la plataforma para el Internet

de las Cosas en IBM Cloud

Al usar un bróker remoto del MQTT, será necesario obtener la aprobación de las credenciales de
autenticación y de nombre del host del bróker para los comandos mosquitto_sub y mosquitto_pub.
Por ejemplo, el siguiente comando se suscribe al tema de demonstración de nuestro servicio de
plataforma para Internet de las Cosas con el nombre de usuario y contraseña proporcionados por
IBM Cloud:

$ mosquitto_sub -t "demo" -h host.iotp.mqtt.bluemix.com -u nombre de usuario -P

contraseña

Para conocer más opciones sobre cómo usar las herramientas de mosquitto y la API de mosquitto
para crear sus propias aplicaciones clientes del MQTT, consulte la documentación en el sitio web
de mosquitto.

Ahora que ya tiene las herramientas necesarias, investiguemos más profundamente el protocolo
MQTT.

Conociendo MQTT Pagina 5 de 9

developerWorks® ibm.com/developerWorks/ssa/

Comprendiendo el protocolo MQTT

MQTT es un protocolo de conexión que explica cómo los bytes de datos son organizados y
transmitidos por la red TCP/IP. Pero, por razones prácticas, los desarrolladores no necesitan
comprender el protocolo de enlace. Basta con saber que cada mensaje tiene una carga útil de
comando y datos. El comando define el tipo de mensaje (por ejemplo, un mensaje CONNECT
o un mensaje SUBSCRIBE). Todas las bibliotecas y herramientas de MQTT ofrecen maneras
sencillas de manipular directamente tales mensajes y pueden completar algunos campos
necesarios automáticamente, como los IDs del mensaje y del cliente.

Primeramente, el cliente se conecta al bróker enviando un mensaje CONNECT. El mensaje

CONNECT pide para que se establezca una conexión entre el cliente y el bróker. El mensaje
CONNECT contiene los siguientes parámetros de contenido.

Tabla 1. Parámetros del mensaje CONNECT

Parámetro Descripción

cleanSession Esta señalización dice si la conexión es persistente o no. Una

sesión persistente almacena todas las suscripciones y los mensajes
posiblemente perdidos (dependiendo del QoS) en el bróker. (Consulte
Tabla 3 para obtener una descripción de la QoS).

nombre de usuario Las credenciales de autenticación y autorización del bróker.

contraseña Las credenciales de autenticación y autorización del bróker.

lastWillTopic Cuando la conexión se cae inesperadamente, el bróker

automáticamente publicará en un tema un mensaje de "último deseo".

lastWillQos La QoS del mensaje de "último deseo". (Consulte Tabla 3 para obtener
una descripción de la QoS).

lastWillMessage El mensaje en sí de "último deseo".

keepAlive Este es el intervalo de en el que el cliente necesita realizar un ping en

el bróker para mantener activa la conexión.

El cliente recibirá un mensaje CONNACK del bróker. El mensaje CONNACK contiene los
siguientes parámetros de contenido.

Tabla 2. Parámetros del mensaje CONNACK

Parámetro Descripción

sessionPresent Indica si la conexión ya contiene una sesión persistente. O sea, la

conexión ya contiene temas suscritos y recibirá la entrega de mensajes
ausentes.

returnCode 0 indica éxito. Otros valores identifican la causa de la falla.

Una vez establecida la conexión, el cliente podrá enviar uno o más mensajes SUBSCRIBE al
bróker para indicar que recibirá mensajes de determinados temas del bróker. El mensaje puede
tener una o varias repeticiones de los siguientes parámetros

Tabla 3. Parámetros del mensaje SUBSCRIBE

Parámetro Descripción

Conociendo MQTT Pagina 6 de 9

ibm.com/developerWorks/ssa/ developerWorks®

qos La señalización qos (calidad de servicio o QoS) indica con qué

consistencia los mensajes, en este tema, necesitan ser entregados a
los clientes.
• Valor 0: no confiable, el mensaje es entregado como máximo
una sola vez; en caso de que el cliente no se encuentre
disponible en este momento, perderá el mensaje.
• Valor 1: el mensaje se debe entregar al menos una vez.
• Valor 2: el mensaje se debe entregar exactamente una vez.

tema Puede suscribirse a un tema. Un tema puede contener varios niveles

separados por caracteres de barra. Por ejemplo, "dw/demo" y "ibm/
bluemix/mqtt" son temas válidos.

Después de que el cliente se haya suscrito a un tema con éxito, el bróker retornará un mensaje
SUBACK con uno o más parámetros returnCode.

Tabla 4. Parámetros del mensaje SUBACK

Parámetro Descripción

returnCode Existe un código de retorno para cada uno de los temas en el comando
SUBSCRIBE. Los valores de retorno son los siguientes.
• Valores 0 a 2: éxito como nivel de QoS correspondiente.
(Consulte Tabla 3 para saber más sobre la QoS.)
• Valor 128: falla.

Según el mensaje SUBSCRIBE, el cliente también podrá UNSUBSCRIBE (cancelar la

suscripción) de uno o varios temas.

Tabla 5. Parámetros del mensaje UNSUBSCRIBE

Parámetro Descripción

tema Este parámetro puede repetirse en varios temas.

El cliente puede enviar mensajes PUBLISH al bróker. El mensaje contiene un tema y una carga
útil de datos. Después, el bróker remite el mensaje a todos los clientes que se suscriben a este
tema.

Tabla 6. Parámetros del mensaje PUBLISH

Parámetro Descripción

topicName El tema en el cual se publica el mensaje.

qos El nivel de calidad de servicio de la entrega del mensaje. (Consulte

Tabla 3 para obtener una descripción de la QoS).

retainFlag Esta señalización indica si el bróker retendrá el mensaje como el último

mensaje conocido de este tema.

carga útil Los datos reales en el mensaje. Puede ser una secuencia de texto o un
blob binario de datos.

Consejos y soluciones alternativas

El poder de MQTT es su simplicidad. No existen restricciones con relación al tipo de tema o de
carga útil de mensaje que se puede usar. Eso permite algunos casos de uso interesantes. Por
ejemplo, considere estas cuestiones:

Conociendo MQTT Pagina 7 de 9

developerWorks® ibm.com/developerWorks/ssa/

¿Cómo ejecutar mensajes de uno a uno con MQTT? Ambas partes pueden ponerse de acuerdo
en usar un tema que sea exclusivo para estas. Por ejemplo, el nombre del tema puede contener
los IDs de los dos clientes para garantizar su exclusividad.

¿Cómo un cliente transmite su status de presencia? El sistema puede ponerse de acuerdo con
una convención de nomenclatura para temas de "presencia". Por ejemplo, el tema "presence/
client-id" puede contener la información de presencia del cliente. El cliente define el mensaje
como "true" cuando se conecta y "false" cuando se desconecta. El cliente también puede
configurar un mensaje de "last will" como "false" para ser definida cuando la conexión se caiga.
El bróker puede retener el mensaje para que nuevos clientes puedan leer el tema y descubrir el
estatus de presencia.

¿Cómo proteger las comunicaciones? La conexión del cliente con el bróker puede ser una
conexión TLS cifrada para proteger los datos en tránsito. Además, como el protocolo MQTT no
impone restricciones con relación al formato de datos de la carga útil, el sistema puede concordar
con un método de cifrado y un mecanismo de actualización de claves. Posteriormente, todo el
contenido en la carga útil puede ser de datos binarios cifrados de los mensajes JSON o XML
reales.

Conclusión
En este artículo, proporcioné una presentación técnica acerca del protocolo MQTT. Ha aprendido
lo que es MQTT, por qué es adecuado para aplicaciones que usan IoT y cómo empezar a
desarrollar aplicaciones que usan MQTT.

En uno de mis próximos artículos, mostraré cómo desarrollar una solución completa de sensor de
IoT con servicios del MQTT de backend y usando una placa NodeMCU.

Recursos

Conociendo MQTT Pagina 8 de 9

ibm.com/developerWorks/ssa/ developerWorks®

Temas relacionados
• El sitio web oficial de MQTT
• MQTT v3.1.1 es un estándar OASIS oficial
• El proyecto Eclipse Paho incluye implementaciones populares de MQTT de software libre
• El proyecto mosquitto, un bróker y una biblioteca del cliente de MQTT Python de software
libre
• Documentación del MQTT para el servicio de la plataforma para Internet de las Cosas

© Copyright IBM Corporation 2017, 2018

(www.ibm.com/legal/copytrade.shtml)
Marcas
(www.ibm.com/developerworks/ssa/ibm/trademarks/)

Conociendo MQTT Pagina 9 de 9