MQTT

Arquitectura de MQTT

MQTT se ejecuta sobre TCP/IP utilizando una topología PUSH/SUBSCRIBE. En la arquitectura MQTT, existen dos tipos de sistemas: clientes y brokers. Un broker es el servidor con el que se comunican los clientes. El broker recibe las comunicaciones de los clientes y las envía a otros clientes. Los clientes no se comunican directamente entre sí, sino que se conectan al broker. Cada cliente puede ser un publicador, un suscriptor o ambos.

MQTT es un protocolo basado en eventos. No hay transmisión periódica o continua de datos. Esto mantiene la transmisión al mínimo. Un cliente sólo publica cuando hay información que enviar, y un broker sólo envía información a los suscriptores cuando llegan nuevos datos.

Arquitectura de mensajes

Otra forma en que MQTT minimiza sus transmisiones es con una construcción de mensajes pequeña y bien definida. Cada mensaje tiene una cabecera fija de sólo 2 bytes. Puede utilizarse una cabecera opcional, pero aumenta el tamaño del mensaje. La carga útil del mensaje se limita a 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 abonado una vez sin confirmación. No hay forma de saber si los abonados han recibido el mensaje. Este método se conoce a veces como "disparar y olvidar" o como "entrega como mucho una vez" Dado que este nivel asume que la entrega se ha completado, los mensajes no se almacenan para su entrega a clientes desconectados que se vuelvan a conectar más tarde.
• QoS 1 - El intermediario intenta entregar el mensaje y luego espera una respuesta de confirmación del suscriptor. Si no se recibe una confirmación en un plazo determinado, se vuelve a enviar el mensaje. Con este método, el abonado puede recibir el mensaje más de una vez si el intermediario no recibe la confirmación del abonado a tiempo. A veces se habla de "entrega al menos una vez".
• QoS 2 - El cliente y el intermediario utilizan un "handshake" de cuatro pasos para garantizar que el mensaje se recibe, y que sólo se recibe una vez. A veces se denomina "entrega exactamente una vez".
  
  

Para situaciones en las que las comunicaciones son fiables pero limitadas, la QoS 0 puede ser la mejor opción. Para situaciones en las que las comunicaciones son poco fiables, pero en las que las conexiones no tienen tantos recursos limitados, la QoS 2 sería la mejor opción. La QoS 1 ofrece una especie de solución "lo mejor de ambos mundos", pero requiere que la aplicación que recibe los datos sepa cómo gestionar los duplicados.

Tanto para la QoS 1 como para la QoS 2, los mensajes se guardan o se ponen en cola para los clientes que no están conectados y que tienen una sesión persistente establecida. Estos mensajes se reenvían (según el nivel de QoS apropiado) una vez que el cliente vuelve a estar en línea.

Temas

Los mensajes en MQTT se publican como temas. Los temas son estructuras jerárquicas que utilizan la barra (/) como delimitador. Esta estructura se asemeja a la de un árbol de directorios en un sistema de archivos informático. Una estructura como sensores/OilandGas/Presión/ permite a un suscriptor especificar que sólo se le envíen datos de los clientes que publican en el tema Presión, o para una visión más amplia, quizás todos los datos de los clientes que publican en cualquier tema sensores/OilandGas. Los temas no se crean explícitamente en MQTT. Si un corredor recibe datos publicados en un tema que no existe actualmente, el tema es simplemente creado, y los clientes pueden suscribirse al nuevo tema.

Mensajes retenidos

Para mantener un tamaño reducido, los mensajes recibidos no se almacenan en el broker a menos que estén marcados con la bandera de retenido. Esto se denomina mensaje retenido. Los usuarios que deseen almacenar los mensajes recibidos tendrán que almacenarlos en otro lugar fuera del protocolo MQTT. Hay una excepción.

Al tratarse de un protocolo basado en eventos, es posible, incluso probable, que un suscriptor reciba muy pocos mensajes de un tema determinado, incluso durante un largo periodo de tiempo. En la estructura de temas mencionada anteriormente, quizá sólo se envíen mensajes al tema Presión cuando un sensor detecte que la presión ha superado un determinado valor. Suponiendo que el sensor monitoreado no falle con frecuencia, podrían pasar meses o incluso años antes de que un cliente publique un mensaje en ese tema.

Para garantizar que un nuevo suscriptor reciba los mensajes de un tema, los brokers pueden conservar el último mensaje enviado a cada tema. Esto se denomina mensaje retenido. Cada vez que un nuevo cliente se suscribe a un tema o cuando un cliente existente vuelve a estar en línea, el mensaje retenido se envía a los suscriptores, asegurando así que la suscripción está activa, y que tiene la información más reciente.

Última voluntad

Cuando las comunicaciones no son fiables, es posible que un editor se desconecte de la red sin previo aviso. Un editor puede registrar un mensaje que se enviará a los abonados en caso de que el editor se desconecte inesperadamente, lo que se denomina última voluntad. Este mensaje se almacena en caché en el broker y se envía a los abonados en caso de que el editor se desconecte indebidamente. Normalmente, dicho mensaje incluye información que permite identificar al editor desconectado para que se puedan tomar las medidas oportunas.

Mensajes MQTT

Para mantener el protocolo pequeño, sólo hay cuatro acciones posibles con cualquier comunicación: publicar, suscribirse, darse de baja o hacer ping.

• Publicar - Envía un bloque de datos que contiene el mensaje a enviar. Estos datos son específicos de cada implementación, pero podrían 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 al que se está publicando no exista, el tema se crea en el broker.
• Suscribir - Convierte a un cliente en suscriptor de un tema. Los temas pueden suscribirse de forma específica o mediante comodines que permiten suscribirse a toda una rama de temas o a parte de cualquier rama de temas. Para suscribirse, un cliente envía un paquete SUBSCRIBE y recibe a cambio un paquete SUBACK. Si hay un mensaje retenido para el tema, el nuevo suscriptor recibe también ese mensaje.
• PING - Un cliente puede hacer ping al broker. El suscriptor envía un paquete PINGREQ y como respuesta un paquete PINGRESP. Los pings pueden utilizarse para asegurarse de que la conexión sigue funcionando y de que la sesión TCP no ha sido cerrada inesperadamente por otro equipo de red, como un router o una pasarela.
• DISCONNECT - Un suscriptor o publicador puede enviar un mensaje DISCONNECT al broker. Este mensaje informa al broker que ya no necesitará enviar o poner en cola mensajes para un suscriptor y que ya no recibirá datos de un publicador. Este tipo de desconexión permite al cliente volver a conectarse utilizando la misma identidad de cliente que antes. Cuando un cliente se desconecta sin enviar un mensaje de desconexión, su última voluntad se envía a los abonados

Seguridad

El objetivo original del protocolo MQTT era realizar la transmisión de datos más pequeña y eficiente posible a través de líneas de comunicación caras y poco fiables. Por ello, la seguridad no fue una de las principales preocupaciones durante el diseño y la implementación de MQTT.

Sin embargo, hay algunas opciones de seguridad disponibles a costa de una mayor transmisión de datos y una mayor huella.

• Seguridad de la red - Si la red en sí puede ser segura, entonces la transmisión de datos MQTT inseguros es irrelevante. En este caso, los problemas de seguridad tendrían que producirse desde dentro de la propia red, quizás a través de un actor malintencionado u otra forma de penetración en la red.
• Nombre deusuario y contraseña - MQTT permite nombres de usuario y contraseñas para que un cliente establezca una conexión con un broker. Desgraciadamente, para no sobrecargar la red, los nombres de usuario y las contraseñas se transmiten en texto claro. 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, interceptar muchos tipos de comunicaciones de redes inalámbricas es trivial, lo que hace que este tipo de autenticación sea prácticamente inútil.
  Muchos casos de uso requieren un nombre de usuario y una contraseña no como protección contra actores de mala fe, sino como una forma de evitar conexiones involuntarias.
• SSL/TLS - Corriendo sobre TCP/IP, la solución obvia para asegurar las transmisiones entre clientes y agentes es la implementación de SSL/TLS. Desafortunadamente, esto añade una sobrecarga sustancial a las comunicaciones, que de otro modo serían ligeras.