MQTT son las siglas de Message Queuing Telemetry Transport. Se trata de un protocolo de mensajería ligero para usar en casos de clientes que necesitan una huella de código pequeña, que están conectados a redes no fiables o con recursos limitados en cuanto al ancho de banda. Se utiliza principalmente para comunicaciones de máquina a máquina (M2M) o conexiones del tipo de Internet de las cosas.
MQTT fue creado originalmente por el Dr. Andy Stanford-Clark y Arlen Nipper en 1999. El propósito original de este método de comunicación era permitir que los dispositivos de monitoreo utilizados en la industria del petróleo y el gas enviaran sus datos a servidores remotos. En muchos casos, estos dispositivos de monitoreo se empleaban en ubicaciones remotas donde establecer cualquier tipo de línea fija, conexión por cable o enlace de transmisión de radio sería ya no simplemente difícil, sino incluso imposible. En ese momento, la única opción para encarar tales situaciones eran las comunicaciones por satélite, tremendamente costosas y que se facturaban en función de la cantidad de datos utilizada. Con miles de sensores en el campo, la industria necesitaba una forma de comunicación que pudiera proporcionar datos de manera suficientemente fiable para su uso, mientras empleaba un ancho de banda mínimo.
MQTT fue estandarizado como código abierto por medio de la organización para el avance de estándares de información estructurada (OASIS) en 2013. OASIS aún gestiona el estándar MQTT.
MQTT se ejecuta sobre TCP/IP utilizando una topología PUSH/SUBSCRIBE. En la arquitectura MQTT, existen dos tipos de sistemas: clientes y brókeres. Un bróker es el servidor con el que se comunican los clientes: recibe comunicaciones de unos y se las envía a otros. Los clientes no se comunican directamente entre sí, sino que se conectan con el bróker. Cada cliente puede ser un editor, un suscriptor o ambos.
MQTT es un protocolo controlado por eventos, donde no hay transmisión de datos periódica o continua. Así se mantiene el volumen de transmisión al mínimo. Un cliente sólo publica cuando hay información para enviar, y un bróker sólo envía información a los suscriptores cuando llegan nuevos datos.
Otra forma en que MQTT minimiza sus transmisiones es con un tamaño de mensaje pequeño y bien definido. Cada mensaje tiene un encabezado fijo de apenas 2 bytes. Se puede utilizar un encabezado opcional, pero eso incrementa el tamaño del mensaje. La carga útil del mensaje está limitada a únicamente 256 MB. Tres niveles diferentes de calidad de servicio (QoS) permiten a los diseñadores de redes elegir entre minimizar la transmisión de datos y maximizar la fiabilidad.
- QoS 0: ofrece la cantidad mínima de transmisión de datos. Con este nivel, cada mensaje se entrega a un suscriptor una vez, sin confirmación, por lo que no hay forma de saber si los suscriptores recibieron el mensaje. Este método a veces se denomina “lanzar y olvidar” o “una entrega como máximo”. Debido a que este nivel asume que la entrega está completa, los mensajes no se almacenan para entregarlos a los clientes desconectados que luego se vuelven a conectar.
- QoS 1: el bróker intenta entregar el mensaje y, luego, espera una respuesta de confirmación del suscriptor. Si no se recibe una confirmación dentro de un período de tiempo especificado, el mensaje se envía de nuevo. Usando este método, el suscriptor puede recibir el mensaje más de una vez si el bróker no recibe el acuse de recibo del suscriptor a tiempo. Esto se suele denominar “entregado al menos una vez”.
- QoS 2: el cliente y el bróker utilizan un protocolo de enlace de cuatro pasos para garantizar no sólo que el mensaje se reciba, sino que lo haga una única vez. También se conoce como “entrega exactamente una vez”.
QoS 0 puede ser la mejor opción para situaciones donde las comunicaciones son fiables pero limitadas. En aquellos casos en que las comunicaciones no sean fiables, pero donde las conexiones tampoco gozan de recursos limitados, QoS 2 sería la mejor opción. QoS 1 proporciona una solución a caballo entre ambos mundos, pero requiere que la aplicación que recibe los datos sepa cómo gestionar los duplicados.
Tanto en QoS 1 como en QoS 2, los mensajes se guardan o se ponen en cola para los clientes que están desconectados y que tienen una sesión persistente establecida. Estos mensajes se reenvían (de acuerdo con el nivel de QoS apropiado) una vez que el cliente vuelve a conectarse.
Los mensajes dentro de MQTT se publican como temas. Los temas son estructuras en una jerarquía que utilizan el carácter de barra (/) como delimitador. Esta estructura se asemeja a la de un árbol de directorios en un sistema de archivos de ordenador. Una estructura como sensores/Gas/Presión/ permite a un suscriptor especificar que sólo se deben enviar datos de clientes que publican al tema Presión o, para una vista más amplia, tal vez los datos de todos clientes que publican a cualquier tema de sensor/Gas. Los temas no se crean explícitamente en MQTT. Si un agente recibe datos publicados sobre un tema que actualmente no existe, simplemente se crea dicho tema y los clientes pueden suscribirse al mismo.
Para mantener una impronta pequeña, los mensajes recibidos no se almacenan en el bróker a menos que estén marcados con la bandera de retención. A esto se le llama mensaje retenido. Los usuarios que deseen almacenar los mensajes recibidos deberán almacenarlos en otro lugar fuera del protocolo MQTT. Sin embargo, hay una excepción.
Al ser un protocolo basado en eventos, es posible, incluso probable, que un suscriptor reciba muy pocos mensajes sobre un tema determinado, incluso durante un largo período de tiempo. En la estructura de temas mencionada anteriormente, quizás los mensajes acerca del tema Presión sólo se envíen cuando un sensor detecte que la presión ha excedido un cierto nivel. Suponiendo que lo que sea que esté monitoreando ese sensor no falle con frecuencia, podrían pasar meses o incluso años antes de que un cliente publique un mensaje sobre ese tema.
Para asegurarse de que un nuevo suscriptor reciba los mensajes de un tema, los brókeres pueden conservar el último mensaje enviado a cada tema. A esto se le llama mensaje retenido. Cada vez que un nuevo cliente se suscriba a un tema o cuando un cliente existente vuelva a conectarse, el mensaje retenido se envía a los suscriptores, lo que garantiza que la suscripción esté activa y que tenga la información más reciente.
Cuando las comunicaciones no son fiables, es posible que un editor se desconecte de la red sin previo aviso. En tales casos, un editor puede registrar un mensaje para enviarlo a los suscriptores por si se desconecta inesperadamente, en lo que se denomina última voluntad y testamento. Este mensaje se almacena en la caché del bróker y, normalmente, incluye información que permite identificar al editor desconectado para que se puedan tomar las medidas adecuadas.
Para mantener el protocolo al mínimo, sólo se pueden efectuar cuatro acciones en cualquier comunicación: publicar, suscribirse, cancelar suscripción o hacer ping.
- Publicar: envía un bloque de datos que contiene el mensaje que se va a enviar. Estos datos son específicos de cada implementación, pero pueden ser algo tan simple como una indicación de encendido/apagado o un valor de un determinado sensor, como temperatura, presión, etc. En el caso de que el tema que se está publicando no exista, este se crea en el bróker.
- Suscribirse: convierte a un cliente en suscriptor de un tema. Se puede suscribir a temas en concreto o mediante comodines, que permiten suscripciones a toda una rama de temas o a parte de ella. Para suscribirse, un cliente envía un paquete SUBSCRIBE y recibe un paquete SUBACK a cambio. Si hay un mensaje retenido para el tema, el nuevo suscriptor también lo recibe.
- PING: un cliente puede hacer ping al bróker. El suscriptor envía un paquete PINGREQ y, como respuesta, se recibe un paquete PINGRESP. Se pueden utilizar pings para garantizar que la conexión siga funcionando y que la sesión TCP no haya sido cerrada inesperadamente por otro equipo de red, como un router o una puerta de enlace.
- DESCONECTAR: un suscriptor o editor puede enviar un mensaje de DISCONNECT al bróker. Este mensaje informa al bróker de que ya no necesitará enviar o poner en cola mensajes para un suscriptor y que ya no recibirá datos de un editor. Este tipo de cierre permite al cliente volver a conectarse utilizando la misma identidad de cliente que en ocasiones anteriores. Cuando un cliente se desconecta sin enviar un mensaje de desconexión, se envía su última voluntad y testamento a los suscriptores.
El objetivo original del protocolo MQTT era hacer posible la transmisión de datos de una forma más pequeña y eficiente a través de líneas de comunicación costosas y poco fiables. Como tal, la seguridad no fue una de las principales preocupaciones durante el diseño e implementación de MQTT.
Sin embargo, hay algunas opciones de seguridad disponibles a costa de una carga superior en la transmisión de datos y una mayor impronta.
- Seguridad de red: si la red en sí puede protegerse, la transmisión de datos inseguros en MQTT es irrelevante. En tal caso, los problemas de seguridad tendrían que producirse desde el interior de la propia red, quizás a través de un actor malicioso u otra forma de penetración en la red.
- Nombre de usuario y contraseña: MQTT permite nombres de usuario y contraseñas para que un cliente establezca una conexión con un bróker. Lamentablemente, para mantener la claridad, los nombres de usuario y las contraseñas se transmiten en texto sin cifrar. En 1999, esto era más que suficiente porque interceptar una comunicación por satélite para lo que era esencialmente una lectura de sensor sin importancia habría sido prohibitivamente difícil. Sin embargo, hoy en día, la interceptación de muchos tipos de comunicaciones de red inalámbrica se ha convertido en algo trivial, lo que hace que dicha autenticación sea casi inútil.
Muchos casos de uso requieren un nombre de usuario y una contraseña ya no como protección contra actores maliciosos, sino como una forma de evitar conexiones involuntarias. - SSL/TLS: al ejecutarse sobre TCP/IP, la solución obvia para proteger las transmisiones entre clientes y brókeres es la implementación de SSL/TLS. Lamentablemente, esto añade una sobrecarga sustancial a unas comunicaciones, por lo demás, livianas.
El 3 de abril de 2019, OASIS publicó el estándar oficial 5.0 de MQTT
Principales novedades de MQTT v5.0
- Códigos de motivo: originalmente, si se producía un error, MQTT simplemente no realizaba ninguna acción. El fallo en sí era el único código de error. En la versión 5.0, los reconocimientos admiten el uso de códigos de retorno que pueden proporcionar una razón clara y representable en forma de error. Por supuesto, el uso de códigos de retorno aumenta ligeramente la huella.
- Suscripciones compartidas: demasiados suscriptores a un tema específico en un bróker pueden crear problemas de carga. Las suscripciones compartidas permiten equilibrar la carga entre los clientes.
- Caducidad del mensaje: se pueden configurar los mensajes para que se eliminen si no se entregan dentro de un período establecido. Esto evita la entrega de mensajes antiguos y desactualizados a los suscriptores que estuvieron desconectados durante un cierto período de tiempo.
- Alias de tema: los nombres de los temas en sí pueden llegar a ser tan largos como para afectar al reducido tamaño del protocolo. Las cadenas de temas ahora se pueden reemplazar con un solo número cuando se usan repetidamente los mismos temas.
Obtenga gratis dos white paper
White paper I
En las infraestructuras industriales modernas, los equipos necesitan datos precisos y fiables. Esta guía muestra cómo implementar un monitoreo completo que combine elementos de TI, OT e IIoT.
White paper II
Nuestra segunda guía le ofrece inspiración e ideas para cuadros de mando que incluyen datos de TI, OT e IIoT, todo en un mismo lugar. Le mostramos cómo son los cuadros de mando industriales verdaderamente convergentes.