MQTT, Qué es, ¿cómo se puede usar? y Cómo funciona

por Redacción · Publicada · Actualizado

¿Qué es MQTT?

MQTT es un protocolo de mensajería ligero de publicación/suscripción diseñado para telemetría M2M (máquina a máquina) en entornos de bajo ancho de banda. Fue diseñado por Andy Stanford-Clark (IBM) y Arlen Nipper en 1999 para conectar sistemas de telemetría de oleoductos por satélite. Aunque comenzó como un protocolo propietario, fue liberado libre de regalías en 2010 y se convirtió en un estándar OASIS en 2014.

MQTT significa MQ Telemetry Transport, pero anteriormente se conocía como Message Queuing Telemetry Transport. MQTT se está convirtiendo rápidamente en uno de los principales protocolos para despliegues de IOT (Internet de las cosas).

Es un interesante protocolo que se puede usar con nuestros Arduino o Raspberry Pi para comunicarse con distintos sensores, uno de los campos donde mejores resultados se pueden dar es en el de la domótica.

Versiones MQTT

Existen dos variantes diferentes de MQTT y varias versiones.

MQTT v3.1.0 –
MQTT v3.1.1 – En uso común
MQTT v5 – Actualmente uso limitado
MQTT-SN – Ver notas más adelante

El MQTT original, diseñado en 1999 y en uso desde hace muchos años, está diseñado para redes TCP/IP.

MQTTv3.1.1 es la versión de uso común. Hay muy poca diferencia entre la v3.10 y la 3.1.1. Aquí hay una página de Github que detalla las principales diferencias.

Aquí está la actual especificación MQTT V3.1 y aquí una visión general más detallada de la estructura de paquetes del protocolo MQTT.

La última versión MQTT(v5) , puedes descargar la especificación aquí.

Lo básico

Antes de aprender a construir una red MQTT, te ayudará a entender parte de la jerga que se utiliza y cómo cada pieza encaja para crear tu red.

Broker – El broker es el servidor que distribuye la información a los clientes interesados conectados al servidor.
Cliente – El dispositivo que se conecta al broker para enviar o recibir información.
Topìc- El nombre del mensaje. Los clientes publican, se suscriben o hacen ambas cosas a un tema.
Publicar – Clientes que envían información al broker para distribuirla a los clientes interesados en base al nombre del tema.
Suscribirse – Los clientes le dicen al agente de bolsa qué tema(s) les interesa(n). Cuando un cliente se suscribe a un tema, cualquier mensaje publicado al broker es distribuido a los suscriptores de ese tema. Los clientes también pueden cancelar la suscripción para dejar de recibir mensajes del corredor sobre ese tema.
QoS – Calidad de Servicio. Cada conexión puede especificar una calidad de servicio al broker con un valor entero que va de 0 a 2. La calidad de servicio no afecta al manejo de las transmisiones de datos TCP, sólo entre los clientes MQTT. Nota: En los ejemplos siguientes, sólo utilizaremos la QoS 0.
- 0 especifica como máximo una vez, o una vez y sólo una vez sin requerir un acuse de recibo de la entrega. A menudo esto se denomina «fire and forget» (disparar y olvidar).
- 1 especifica al menos una vez. El mensaje se envía varias veces hasta que se recibe un acuse de recibo, lo que se conoce como acuse de recibo.
- 2 especifica exactamente una vez. Los clientes remitente y receptor utilizan un apretón de manos de dos niveles para asegurarse de que sólo se recibe una copia del mensaje, lo que se conoce como entrega asegurada.

Cómo funciona MQTT

Una sesión MQTT se divide en cuatro etapas: conexión, autenticación, comunicación y terminación. Un cliente comienza creando una conexión de Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP) con el broker utilizando un puerto estándar o un puerto personalizado definido por los operadores del broker. Al crear la conexión, es importante reconocer que el servidor puede continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada.

Los puertos estándar son 1883 para la comunicación no cifrada y 8883 para la comunicación cifrada – usando Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Durante la conexión SSL/TLS, el cliente valida el certificado del servidor y autentica el servidor. El cliente también puede proporcionar un certificado de cliente al agente durante el apretón de manos. El agente puede utilizarlo para autenticar al cliente. Aunque no es específicamente parte de la especificación MQTT, se ha convertido en una costumbre que los agentes soporten la autenticación de clientes con certificados SSL/TLS del lado del cliente.

Debido a que el protocolo MQTT tiene como objetivo ser un protocolo para dispositivos con recursos limitados y dispositivos de IO, SSL/TLS puede no ser siempre una opción y, en algunos casos, puede no ser deseado. En tales ocasiones, la autenticación se presenta como un nombre de usuario y una contraseña en texto claro, que son enviados por el cliente al servidor — esto, como parte de la secuencia de paquetes CONNECT/CONNNACK. Además, algunos brokers, especialmente los brokers abiertos publicados en Internet, aceptarán clientes anónimos. En estos casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.

MQTT se llama un protocolo ligero porque todos sus mensajes tienen una pequeña huella de código. Cada mensaje consiste en un encabezado fijo — 2 bytes — un encabezado variable opcional, una carga útil del mensaje que está limitada a 256 megabytes (MB) de información y un nivel de calidad de servicio (QoS).

Durante la fase de comunicación, un cliente puede realizar operaciones de publicación, suscripción, desinscripción y ping. La operación de publicación envía un bloque binario de datos (el contenido) a un tema definido por el editor.

MQTT soporta grandes objetos binarios de mensajes (BLOBs) de hasta 256 MB de tamaño. El formato del contenido será específico de la aplicación. Las suscripciones a los temas se realizan utilizando un par de paquetes SUBSCRIBE/SUBACK, y la cancelación de la suscripción se realiza de forma similar utilizando un par de paquetes UNSUBSCRIBE/UNSUBACK.

Los strings de temas forman un árbol temático natural con el uso de un carácter delimitador especial, la barra oblicua (/). Un cliente puede suscribirse y cancelar la suscripción a ramas enteras del árbol de temas utilizando caracteres comodines especiales. Existen dos caracteres comodín: un carácter comodín de un nivel, el carácter más (+); y un carácter comodín de varios niveles, el carácter de almohadilla (#). Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier suscripción de comodín de raíz. Normalmente, $ se usa para transportar mensajes específicos del servidor o del sistema.

Otra operación que un cliente puede realizar durante la fase de comunicación es hacer ping al servidor del agente usando una secuencia de paquetes PINGREQ/PINGRESP. Esta secuencia de paquetes se traduce aproximadamente en ESTÁ USTED VIVO/SÍ ESTOY VIVO. Esta operación no tiene otra función que la de mantener una conexión viva y asegurarse de que la conexión TCP no ha sido cerrada por un gateway o router.

Cuando un editor o suscriptor quiere terminar una sesión MQTT, envía un mensaje de DESCONEXIÓN al broker y luego cierra la conexión. Esto se llama un cierre elegante porque le da al cliente la capacidad de reconectarse fácilmente proporcionando su identidad de cliente y reanudando donde lo dejó.

En caso de que la desconexión se produzca de forma repentina y sin tiempo para que un publisher envíe un mensaje de DESCONEXIÓN, el broker puede enviar a los suscriptores un mensaje del publisher que el broker ha almacenado previamente en caché. El mensaje, que se denomina última voluntad y testamento, proporciona a los suscriptores instrucciones sobre lo que deben hacer si el editor muere inesperadamente.

Veámoslo en vídeo:

Historia del protocolo MQTT

Cómo hemos apuntado al principio MQTT fue creado por el Dr. Andy Stanford-Clark de IBM y Arlen Nipper de Arcom – ahora Eurotech – en 1999. MQTT fue creado como una forma rentable y fiable de conectar los dispositivos de monitorización utilizados en las industrias del petróleo y el gas a servidores empresariales remotos. Cuando fueron desafiados con encontrar una manera de empujar los datos de los sensores de la tubería en el desierto a los sistemas de control de supervisión y adquisición de datos (SCADA) fuera del sitio, decidieron una topología de publicación/suscripción basada en TCP/IP que sería impulsada por los eventos para mantener bajos los costos de transmisión del enlace satelital.

Aunque MQTT sigue estando estrechamente asociado con IBM, es ahora un protocolo abierto que es supervisado por la Organización para el Avance de los Estándares de Información Estructurada (OASIS).

Aunque el nombre lo sugiere, MQTT no es parte de la serie original de IBM MQSeries; sin embargo, a partir de la versión 7.1, está disponible en WebSphere MQ. MQTT fue previamente conocido como el protocolo SCADA, MQ Integrator SCADA Device Protocol (MQIsdp) y WebSphere MQTT (WMQTT), aunque todas estas variaciones han caído en desuso.

Aplicaciones y casos de uso del protocolo MQTT

Facebook utiliza actualmente MQTT para su aplicación de Messenger, no sólo porque el protocolo conserva la energía de la batería durante la mensajería de teléfono móvil a teléfono, sino también porque el protocolo permite que los mensajes se entreguen de manera eficiente en milisegundos (ms), a pesar de las inconsistentes conexiones de Internet en todo el mundo.

La mayoría de los principales proveedores de servicios en la nube, incluyendo Amazon Web Services (AWS), Google Cloud, IBM Cloud y Microsoft Azure, soportan MQTT.

MQTT es muy adecuado para aplicaciones que utilizan dispositivos M2M e IoT para propósitos tales como análisis en tiempo real, mantenimiento preventivo y monitorización en entornos, incluyendo hogares inteligentes, sanidad, logística, industria y fabricación.

¿Quién utiliza MQTT?

MQTT es usado por muchas compañías importantes, especialmente en los sectores de automoción, industria 4.0, transporte y entretenimiento. MQTT se utiliza para el intercambio de datos entre dispositivos restringidos y aplicaciones de servidor. Mantiene los requerimientos de ancho de banda al mínimo absoluto, maneja redes poco fiables, requiere poco esfuerzo de implementación para los desarrolladores y es, por lo tanto, ideal para la comunicación de máquina a máquina (M2M).

MQTT en IoT

El MQTT es uno de los protocolos más utilizados en relación con la Internet de las Cosas. El MQTT permite que los dispositivos de IoT con recursos limitados envíen o publiquen información sobre un tema determinado a un servidor que funciona como un agente de mensajes MQTT. El servidor envía la información a los clientes que se han suscrito previamente al tema. Para un humano, un tema tiene el aspecto de una ruta de archivo jerárquica. Los clientes pueden suscribirse a un nivel específico de la jerarquía de un tema o utilizar un carácter comodín para suscribirse a varios niveles.

Como ejemplos, las plataformas de IO Carriots, Evrything y ThingWorx soportan el protocolo MQTT.

Protocolos competidores

Otros protocolos de transferencia que compiten con MQTT son los siguientes:

Constrained Application Protocol (CoAP) es otro protocolo muy adecuado para la IO. El CoAP también utiliza un patrón de comunicación de solicitud/respuesta.
El Advanced Message Queuing Protocol (AMQP), como el MQTT, utiliza un patrón de comunicación de publicación/suscripción.
Simple/Streaming Text Oriented Messaging Protocol (STOMP) es un protocolo basado en texto. Sin embargo, STOMP no se ocupa de colas y temas; utiliza una semántica de envío con una cadena de destino.
Mosquitto es un broker MQTT de código abierto.
Simple Media Control Protocol (SMCP) es una pila CoAP que se utiliza en entornos embebidos. SMCP también está basado en C.
SSI (Simple Sensor Interface) es un protocolo de comunicaciones para la transferencia de datos entre una combinación de ordenadores y sensores.
El Servicio de Distribución de Datos (DDS) para sistemas en tiempo real es un estándar de middleware que puede publicar o suscribir directamente comunicaciones en tiempo real en sistemas embebidos.

Ventajas y desventajas de MQTT

MQTT tiene algunas ventajas y desventajas claras cuando se compara con los protocolos de la competencia. Las ventajas incluyen lo siguiente:

transmisión de datos eficiente y rápida de implementar debido a que es un protocolo ligero;
bajo uso de la red, debido a la minimización de los paquetes de datos;
distribución eficiente de los datos;
implementación exitosa de la teledetección y el control;
entrega de mensajes rápida y eficiente;
uso de pequeñas cantidades de energía, lo que es bueno para los dispositivos conectados; y
reducción del ancho de banda de la red

Las desventajas de MQTT incluyen lo siguiente:

MQTT tiene ciclos de transmisión más lentos en comparación con CoAP.
El descubrimiento de recursos de MQTT funciona con una suscripción de temas flexible, mientras que CoAP utiliza un sistema estable de descubrimiento de recursos.
MQTT no está encriptado. En su lugar, utiliza TLS/SSL para el cifrado de seguridad.
Es difícil crear una red MQTT globalmente escalable.

Desafíos de MQTT: Seguridad, interoperabilidad y autenticación

Debido a que el protocolo MQTT no fue diseñado con la seguridad en mente, el protocolo ha sido tradicionalmente usado en redes de back-end seguras para propósitos específicos de la aplicación. La estructura temática de MQTT puede formar fácilmente un árbol enorme, y no hay una forma clara de dividir un árbol en dominios lógicos más pequeños que puedan ser federados. Esto dificulta la creación de una red MQTT globalmente escalable porque, a medida que el tamaño del árbol de temas crece, la complejidad aumenta.

Otro aspecto negativo de MQTT es su falta de interoperabilidad. Debido a que las cargas útiles de los mensajes son binarias, sin información sobre cómo están codificadas, pueden surgir problemas – especialmente en arquitecturas abiertas donde se supone que diferentes aplicaciones de diferentes fabricantes trabajan sin problemas entre sí.

Como se mencionó anteriormente, MQTT tiene características mínimas de autenticación incorporadas en el protocolo. Los nombres de usuario y las contraseñas se envían en texto claro, y cualquier forma de uso seguro de MQTT debe emplear SSL/TLS, que, desafortunadamente, no es un protocolo ligero.

Autenticar clientes con certificados del lado del cliente no es un proceso simple, y no hay manera en MQTT de controlar quién es el dueño de un tema y quién puede publicar información sobre él, excepto usando medios propietarios fuera de la banda. Esto facilita la inyección de mensajes dañinos en la red, ya sea voluntariamente o por error.

Además, no hay manera de que el receptor del mensaje sepa quién envió el mensaje original, a menos que esa información esté contenida en el mensaje real. Las características de seguridad que tienen que ser implementadas en la parte superior de MQTT en una forma propietaria aumentan la huella del código y hacen que las implementaciones sean más difíciles.

Niveles de calidad de servicio

La calidad de servicio se refiere a un acuerdo entre el remitente de un mensaje y el destinatario del mismo. La QoS definirá la garantía de entrega en referencia a un mensaje específico. La QoS actúa como una característica clave en MQTT, dando al cliente la posibilidad de elegir entre tres niveles de servicio.

Los tres niveles de QoS diferentes determinan cómo se gestiona el contenido mediante el protocolo MQTT. Aunque los niveles más altos de QoS son más fiables, tienen más requisitos de latencia y ancho de banda, por lo que los clientes suscritos pueden especificar el nivel de QoS más alto que les gustaría recibir.

El nivel de QoS más simple es el servicio no reconocido. Este nivel de QoS utiliza una secuencia de paquetes PUBLISH; el editor envía un mensaje al agente una vez y el agente pasa el mensaje a los suscriptores una vez. No existe ningún mecanismo que asegure que el mensaje se ha recibido correctamente, y el agente no guarda el mensaje. Este nivel de QoS también puede denominarse como máximo una vez, QoS0 o «fire and forget» (disparar y olvidar).
El segundo nivel de QoS es el servicio de acuse de recibo. Este nivel de QoS utiliza una secuencia de paquetes PUBLISH/PUBACK entre el editor y su corredor, así como entre el corredor y los suscriptores. Un paquete de acuse de recibo verifica que se ha recibido el contenido, y un mecanismo de reintento enviará el contenido original de nuevo si no se recibe un acuse de recibo a tiempo. Esto puede dar lugar a que el suscriptor reciba varias copias del mismo mensaje. Este nivel de calidad de servicio también puede denominarse «al menos una vez» o «QoS1».
El tercer nivel de QoS es el servicio asegurado. Este nivel de QoS entrega el mensaje con dos pares de paquetes. El primer par se denomina PUBLISH/PUBREC, y el segundo par se denomina PUBREL/PUBCOMP. Los dos pares aseguran que, independientemente del número de reintentos, el mensaje sólo se entregará una vez. Este nivel de QoS también puede denominarse exactamente una vez o QoS2.

Especificaciones de MQTT

MQTT tiene diferentes especificaciones dependiendo de la versión específica. La versión 5.0 sustituyó a la última versión de MQTT, la versión 3.1.1. Algunas especificaciones más recientes, como las definidas por OASIS, incluyen lo siguiente:

el uso de patrones de mensajes de publicación/suscripción;
un mecanismo que puede notificar a los usuarios cuando se producen desconexiones anormales;
los tres niveles de entrega de mensajes: a lo sumo una vez, a lo menos una vez y exactamente una vez;
la minimización de la sobrecarga de transporte y los intercambios de protocolos para reducir el tráfico de red; y
un transporte de mensajería agnóstico que se refiere al contenido de la carga útil.

Más especificaciones se pueden encontrar en el sitio web de OASIS en este enlace.

Actualizaciones de MQTT

El MQTT fue aprobado oficialmente como un estándar OASIS el 28 de octubre de 2015. A finales de enero de 2016, fue aceptado como un estándar de la Organización Internacional de Normalización (ISO). El protocolo está en continua mejora y ahora soporta WebSockets, otro protocolo que permite la comunicación bidireccional entre clientes y corredores en tiempo real. Posteriormente, se han producido versiones destacadas como la v3.1.1 y la v5.0, ambas aprobadas como estándares OASIS. Como ejemplo de algunas de sus actualizaciones, la versión 5.0 incluía un mejor reporte de errores, incluyendo metadatos en los encabezados de los mensajes, suscripciones compartidas, expiraciones de mensajes y sesiones, y alias de temas.

Clientes de MQTT

Debido a que los clientes de MQTT no tienen direcciones como direcciones de correo electrónico, números de teléfono, etc. no es necesario asignar direcciones a los clientes como se hace con la mayoría de los sistemas de mensajería.

Para MQTTv3.1.1 hay software cliente disponible en casi todos los lenguajes de programación y para los principales sistemas operativos Linux, Windows, Mac del proyecto Eclipse Paho.

Para MQTTv5.0 hay un soporte limitado para el software cliente de Eclipse, actualmente sólo hay un cliente C disponible. Aquí hay un enlace a la tabla de comparación de clientes y a la página de descargas.

Actualmente estoy usando un cliente Python de esta página github que soporta v5.

MQTT Brokers o Servidores

El término original era «broker» pero ahora ha sido estandarizado como «Server». Verás que se utilizan ambos términos. Hay muchos brokers MQTT disponibles que puede utilizar para pruebas y para aplicaciones reales. Hay brokers gratuitos auto alojados, los más populares son Mosquitto y los comerciales como HiveMQ. Mosquitto es un broker MQTT de código abierto gratuito que funciona en Windows y Linux.

Si no deseas instalar y gestionar su propio broker puede utilizar un broker basado en la nube de los proveedores de servicios en la nube como IBM, Microsoft (Azure), etc.

Eclipse tiene un broker público gratuito MQTT y un servidor COAP que también puede utilizar para realizar pruebas. La dirección es iot.eclipse.org y el puerto es 1883 o 8883(SSL).

MQTT sobre WebSockets

Websockets te permite recibir los datos de MQTT directamente en un navegador web. Esto es importante ya que el navegador web puede convertirse en la interfase DE-facto para visualizar los datos MQTT.

El soporte de MQTT websocket para navegadores web es proporcionado por el Javascript MQTT Client.

¿Es seguro el MQTT?

MQTT soporta varias autenticaciones y mecanismos de seguridad de datos.

Es importante señalar que estos mecanismos de seguridad se configuran en el broker MQTT, y depende del cliente cumplir con los mecanismos establecidos.

MQTT está diseñado para permitir una comunicación muy segura. Como un protocolo de capa de aplicación introduce amplias posibilidades de autenticación y autorización de dispositivos. El protocolo de transporte TCP/IP subyacente puede añadir seguridad adicional a través de la encriptación TLS.

¿Es MQTT de código abierto?

MQTT es un protocolo abierto que está estandarizado por OASIS e ISO (ISO/IEC 20922:2016).
¿Cuál es la diferencia entre HTTP y MQTT?

MQTT es un protocolo binario centrado en datos, extremadamente ligero. Debido a su mínima sobrecarga de paquetes, MQTT sobresale en la transferencia de datos a través del cable en comparación con los protocolos centrados en el documento, como HTTP. A diferencia de HTTP, que se basa en un patrón de petición/respuesta, MQTT proporciona una comunicación basada en el push. Este push es posible a través de conexiones TCP permanentes.

¿Cuál es la diferencia entre AMQP y MQTT?

AMQP es un protocolo de mensajería bidireccional, síncrono y de par a par, que tiene altas exigencias de complejidad de implementación y una mayor sobrecarga de la red. Es un protocolo de cable binario, construido como reemplazo del middleware de mensajes con un enfoque principal en la interoperabilidad entre diferentes proveedores a través de características enriquecidas y varios patrones de intercambio.

MQTT es un protocolo binario con la fuerza en la simplicidad de ser ideal para la aplicación móvil de IO y M2M. Proporciona el patrón de mensajería pub/sub y está diseñado para dispositivos con recursos limitados, ancho de banda bajo y redes de alta latencia. MQTT está especificado por el estándar oficial OASIS.

¿Utiliza MQTT WebSockets?

Con la implementación del broker adecuado que soporte WebSockets nativos, MQTT con el 100% de su conjunto de características puede ser utilizado a través de WebSockets. Ya que proveen un canal de comunicación bidireccional, ordenado y sin pérdidas a través de TCP.

¿MQTT utiliza TCP o UDP?

MQTT utiliza TCP. Debido a los requisitos de pedido MQTT sobre UDP no está posible.

¿Requiere MQTT Internet?

Sí, para enviar o recibir mensajes, el cliente MQTT debe establecer una conexión TCP con el broker. Sin embargo, MQTT viene con las características diseñadas específicamente para hacer frente a las conexiones de red inestables, como el buffer de mensajes entrantes del corredor para los clientes desconectados.

¿Funciona MQTT con Apache Kafka?

Sí, MQTT y Kafka pueden ser integrados entre sí. La manera más eficiente de hacerlo es utilizando la Extensión Kafka de HiveMQ Enterprise.

¿Es MQTT independiente?

No. MQTT no es independiente y no proporciona un patrón de solicitud/respuesta. Es un protocolo de mensajería de capa de aplicación de publicación/suscripción que requiere una conexión TCP permanente y transmite mensajes de manera instantánea, por empuje.