Se puede decir que el protocolo MQTT es el protocolo de capa de aplicación de IoT más utilizado en la actualidad. MQTT resuelve uno de los problemas más básicos en Internet de las cosas, es decir, la comunicación entre dispositivos y dispositivos, y entre dispositivos y servicios en la nube. El escenario de aplicación principal es proporcionar garantía de comunicación para una gran cantidad de dispositivos de Internet de las cosas poco fiables y de bajo consumo. Este artículo explica principalmente algunas preguntas para principiantes. Por ejemplo, ¿sabe por qué los mensajes de QoS2 pueden garantizar que los mensajes no se recibirán repetidamente? ¿Por qué proporcionar una garantía de comunicación confiable? No se muestran más detalles del acuerdo, puede consultar el sitio web chino de MQTT .

2. Características básicas del protocolo MQTT:

Simple de implementar
Proporcionar QoS para la transmisión de datos.
Ancho de banda ligero y reducido
Se puede transmitir cualquier tipo de datos
Sesión que se puede mantener (Sesión)

Tres características del protocolo MQTT

Protocolo de capa de aplicación basado en conexión larga TCP;
Basado en arquitectura Cliente / Servidor;
Utilice el modelo de suscripción / publicación para desacoplar el remitente y el receptor del mensaje;
Proporciona 3 tipos de mensajes QoS (Quality of Service): como máximo una vez, al menos una vez y solo una vez;
El envío y la recepción de mensajes son asincrónicos y el remitente no necesita esperar a que el receptor responda;

Cuatro, modelo de comunicación de protocolo MQTT

4.1 Arquitectura cliente / servidor

El protocolo MQTT completo incluye dos partes, MQTT Client y MQTT Server, entre las cuales MQTT Server también es Broker;

4.1.1 Cliente MQTT

Siempre que el dispositivo esté conectado al MQTT Broker según el protocolo MQTT, el dispositivo se considera un Cliente MQTT. El Cliente MQTT puede actuar como editor y suscriptor solo, o como editor y suscriptor al mismo tiempo. hora.

4.1.2 Broker MQTT

MQTT Broker es el núcleo del protocolo MQTT, su función principal es recibir mensajes de los editores y luego reenviarlos a los suscriptores correspondientes. El Broker puede autorizar el acceso a Clinet y controlar los derechos del Cliente. La biblioteca de código abierto más utilizada de MQTT Broker escrita en lenguaje C es Mosquitto. Para obtener más información, consulte https://github.com/mqtt/mqtt.github.io/wiki/servers . Si necesita un entorno Broker para aprender MQTT, puede crearlo usted mismo a través de estas bibliotecas de código abierto, o puede utilizar los servicios Broker proporcionados por las principales plataformas en la nube, como Alibaba Cloud y Tencent Cloud.

4.2 Modelo de publicación / suscripción

MQTT se implementa a través del modelo de publicación / suscripción. Dado que el editor y el suscriptor no están conectados directamente, se requiere un intermediario para publicar y almacenar mensajes. A este intermediario lo llamamos Broker, que es simplemente la implementación del servidor basada en el protocolo mqtt. (Hay muchas implementaciones de código abierto en github), el editor y el suscriptor conectados al Broker actúan como clientes;

Tanto el editor como el suscriptor han establecido una conexión TCP con el Broker;
El suscriptor informa al Broker del tema al que quiere suscribirse;
El editor envía el mensaje al Broker y especifica el tema del mensaje (Tema);
Una vez que el corredor recibe el mensaje, detecta qué suscriptores se han suscrito al tema correspondiente y luego envía el mensaje al suscriptor;
El suscriptor obtiene el mensaje del Broker;
Si un suscriptor está fuera de línea, el Broker puede guardar el mensaje correspondiente primero, y cuando el suscriptor se conecte al Broker la próxima vez, el mensaje anterior se enviará al suscriptor;

Cinco, formato de protocolo MQTT

El protocolo MQTT utiliza un paquete de datos binarios, que consta de tres partes: encabezado fijo, encabezado variable y cuerpo del mensaje;

Encabezado fijo: existe en todos los paquetes de datos MQTT, la longitud es de 2 ~ 5 bytes, incluidas 3 partes, el tipo de paquete de datos (4 bits), el bit de identificación (4 bits), la longitud restante del paquete de datos (1 ~ 4 bytes), Significado específico se refiere al protocolo MQTT
Encabezado variable: parte del paquete MQTT contiene
Cuerpo del mensaje: parte del paquete MQTT contiene

En el protocolo MQTT, la longitud restante del paquete de datos en el encabezado fijo incluye el encabezado variable y la longitud del cuerpo del mensaje. La longitud restante se puede representar por 1 ~ 4Byte, y el máximo de 4Byte puede representar 256 MB (0xFFFFFF7F). Algunos paquetes de datos no tienen encabezados ni cuerpos de mensaje variables. Por ejemplo, el paquete de datos PINGREQ tiene solo 2 bytes, por lo que se pueden calcular los valores máximo y mínimo del paquete de datos MQTT.

Máximo: 256 MB + 5 bytes, donde 256 MB es la longitud restante máxima, incluido el encabezado variable y el cuerpo del mensaje; 5 bytes es el encabezado fijo, tipo de paquete de datos (4 bits), bit de identificación (4 bits), longitud restante del paquete de datos (4 bits);
Valor mínimo: 2 bytes, como paquete de datos PINGREQ, solo encabezado fijo, sin encabezado variable, cuerpo del mensaje;

Seis, principio de implementación del protocolo MQTT

6.1 Establecer una conexión

Antes de que el Cliente pueda publicar y suscribirse a mensajes, primero debe conectarse al Broker. Esta conexión no es solo para establecer una conexión TCP, sino también para establecer una conexión en la capa de aplicación. El proceso de establecimiento de la conexión MQTT es el siguiente:

El cliente envía el paquete CONNECT al Broker;
Una vez que el corredor recibe el paquete CONNECT, si se permite el acceso, responderá con un paquete CONNACK con un código de retorno de 0. Si se niega a acceder, responderá con un paquete de CONNACK con un código de retorno distinto de 0. La devolución el código indica el motivo de la falla;

6.2 Cerrar conexión

El cierre de la conexión puede ser iniciado por el Cliente o el Broker. También existe un tercer caso que cerrará la conexión, es decir, el tiempo de espera del latido, y los diferentes procedimientos de cierre son diferentes:

El cliente cierra la conexión: el cliente envía un paquete de DESCONEXIÓN al Broker, sin esperar a que el Broker responda el paquete de DESCONEXIÓN, el Broker no responderá y puede cerrar la conexión TCP subyacente después de enviarlo; la razón por la que tiene que enviar antes desconectar la conexión TCP no tiene interacción con el Broker El paquete de datos es para permitirle al Broker reconocer que es una desconexión normal. El Broker descartará el último mensaje de deseo de la conexión actual, de lo contrario será reconocido como una conexión anormal y el el mensaje del hospital conectado actualmente no se perderá;
El intermediario cierra la conexión: no es necesario enviar ningún paquete MQTT, cierra directamente la conexión TCP subyacente
Keepalive timeout: El protocolo MQTT estipula que el Broker debe mantener la conexión antes de recibir el paquete DISCONNECT del Cliente. Sin embargo, si el Broker no recibe ningún paquete de datos del Cliente durante el intervalo keepalive, cerrará activamente la conexión. El valor de este keepalive lo especifica el tipo de paquete de datos cuando el Cliente inicia una conexión;

6.3 Publicar y suscribirse

Todos deben comprender bien el concepto de publicación y suscripción. Para el paquete de datos del protocolo de interacción específico, puede ver el protocolo MQTT e introducir varias características clave:

Soporte para recibir mensajes fuera de línea: MQTT admite suscriptores que aceptan mensajes fuera de línea, pero no significa que los mensajes se puedan recibir fuera de línea, lo que significa que si el editor publica un mensaje al Broker cuando el suscriptor está fuera de línea, se suscribe a la suscripción del tema correspondiente Después de conectarse al Broker nuevamente, el editor recibirá el mensaje publicado por el editor durante su período fuera de línea. El requisito para recibir mensajes fuera de línea es que el Cliente necesita usar una sesión persistente, y la QoS al publicar no es menor a 1;
Comodines de tema: se pueden usar comodines para los temas de mensajes de publicación y suscripción. La función principal de los comodines es especificar el nivel del nombre del tema del mensaje. Hay un caso especial. El comodín no funciona al cancelar la suscripción. El nombre del tema cancelado debe coincidir con todas las palabras de la suscripción. El nombre del sujeto especificado en ese momento es el mismo;

6.4 Qos

La intención original del diseño del protocolo MQTT es proporcionar un conjunto de mecanismos para garantizar la transmisión estable de mensajes para la transmisión de datos en un entorno con un ancho de banda de red estrecho y señales inestables. Este conjunto de mecanismos incluye la respuesta, el almacenamiento y la retransmisión de mensajes. Bajo este mecanismo, se proporcionan tres niveles diferentes de QoS (Calidad de servicio) QoS es un acuerdo alcanzado entre el Remitente y el Receptor, no un acuerdo alcanzado entre el Publicador y el Suscriptor. Es decir, la calidad del servicio entre el editor y el corredor, y la calidad del servicio entre el suscriptor y el corredor, no existe una relación directa entre los dos.

QoS0: como máximo una vez
QoS1: al menos una vez
QoS2: asegúrese solo una vez

Los anteriores son tres niveles de servicio de QoS. Es posible que muchos principiantes no comprendan el principio de implementación en la etapa inicial de aprendizaje de MQTT, especialmente cómo asegurarse de que QoS2 solo se envíe una vez. De hecho, se comprende bien a partir del análisis del protocolo MQTT en sí. ;

6.4.1 QoS0

Qos0 es el nivel de servicio de calidad de mensaje más simple. El remitente envía un paquete PUBLISH que contiene datos del mensaje a Receiver y luego descarta el paquete PUBLISH enviado directamente sin importar el resultado, por lo que Receiver recibe como máximo una vez.

6.4.2 QoS1

Para asegurarse de que el receptor reciba el mensaje al menos una vez, QoS1 agrega un mecanismo de respuesta; el remitente envía un paquete de datos PUBLISH con datos del mensaje al receptor y guarda este paquete de datos localmente. El receptor devolverá un paquete de datos PUBACK después de recibirlo, PUBACK El El encabezado variable del paquete de datos tiene el mismo identificador de paquete que el paquete de datos PUBLICAR. Después de recibir PUBACK, el remitente encuentra el paquete de datos guardado localmente de acuerdo con el identificador de paquete (identificador de paquete) y lo descarta, y la transmisión se completa .

Si el remitente no recibe el paquete PUBACK dentro de un cierto período de tiempo después de enviar el paquete PUBLISH, establecerá el indicador DUP en el paquete PUBLISH en 1 (lo que indica que el paquete se retransmite) y lo reenviará, repita los pasos anteriores hasta que recibe el PUBACK, por lo que si debido a la demora de la red y otras razones, el Receptor no recibe el paquete PUBLISH o el PUBACK no se envía dentro del período de tiempo de espera, lo que hará que el Receptor reciba varias veces.

6.4.3 QoS2

QoS2 no solo debe asegurar que el Receptor pueda recibir el paquete de datos enviado por el Remitente, sino que tampoco se pueda repetir, es decir, solo se puede recibir una vez, por lo que el mecanismo de retransmisión y respuesta es más complicado. Entre los tres niveles de servicio, QoS2 es el más caro y el más lento. Sí, claro que también es el más seguro.

QoS2 utiliza 2 conjuntos de procedimientos de solicitud / respuesta, es decir, un protocolo de enlace de 4 segmentos para garantizar que el receptor solo reciba un mensaje enviado por el remitente una vez.

1) El remitente envía un paquete PUBLICAR con un valor de QoS de 2, asumiendo que el paquete contiene un Identificador de paquete como P, y guarda el paquete PUBLICAR localmente;

2) Después de que el receptor recibe el paquete PUBLISH, guarda el identificador de paquete del paquete PUBLISH como P localmente y responde al remitente con un paquete PUBREC. PUBREC contiene el identificador del paquete como P, pero no hay cuerpo del mensaje;

3) Después de recibir el PUBREC, el remitente puede descartar el paquete PUBLISH con el identificador de paquete de P, guardar el paquete de PUBREC localmente y responder al receptor con un paquete de PUBREL. El identificador de paquete en el paquete de PUBREL es P y no hay cuerpo del mensaje; si el paquete PUBREC no se recibe dentro del período de tiempo de espera del remitente, el indicador DUP en PUBLISH se establecerá en 1 y el paquete PUBREC se enviará nuevamente;

4) Cuando el receptor recibe un paquete PUBREL, puede descartar el identificador de paquete P almacenado localmente y responder al remitente con un paquete PUBCOMP. El identificador de paquete en el encabezado variable del paquete PUBCOMP es P y no hay cuerpo del mensaje.

5) Cuando el remitente recibe el paquete de datos PUBCOMP, la transmisión del paquete de datos se completa y el paquete de datos PUBREC local se pierde. Si el remitente no recibe el paquete PUBCOMP dentro del período de tiempo de espera, repetirá el paquete PUBREL;

Lo anterior es el proceso de completar un paquete de datos de nivel QoS2. Deben enviarse al menos 4 paquetes de datos. Sin embargo, algunos estudiantes encontraron en el paso 3 que cuando el remitente no recibió el paquete de datos PUBREC del receptor, el paquete de datos PUBLISH aún sería enviado repetidamente. Entonces, ¿cómo asegurarse de que el receptor solo lo reciba una vez?

La razón es que cuando Receiver recibe un paquete PUBLISH, no lo entrega a la capa superior del protocolo inmediatamente, sino que guarda el mensaje localmente al persistirlo y luego entrega el mensaje a la capa superior del protocolo después de recibir PUBREL. paquete, y luego envía el identificador de paquete guardado localmente P. Dado que no hay ningún identificador de paquete P en el paquete PUBREL, incluso si PUBCOMP no se envía correctamente y PUBREL se retransmite, el receptor solo necesita responder a PUBCOMP, y no necesita entregar repetidamente paquetes PUBLICAR a la capa superior del protocolo;

El principio de implementación del nivel de servicio QoS2 se puede ver en este blog, que es muy detallado: https://blog.csdn.net/zerooffdate/article/details/78950907

6.5 keepalive y conexión keepalive

6.5.1 El papel de keepalive

Cuando se utiliza realmente el protocolo MQTT, tanto el Broker como el Cliente deben saber si MQTT se desconecta a tiempo; MQTT es un protocolo de capa de aplicación basado en el protocolo TCP. En teoría, la aplicación de capa superior será notificada cuando TCP se desconecte. pero el protocolo TCP tiene un medio abierto El problema de conexión, en este estado, un segmento de la conexión TCP ha fallado, pero el otro extremo no lo sabe, y se tarda mucho en percibir que la conexión del par se ha desconectado ; por lo tanto, no es suficiente confiar en la supervisión del estado de la conexión de la capa TCP. Por lo tanto, MQTT diseñó un conjunto de mecanismos de mantenimiento activo,

El protocolo MQTT estipula que si el Broker no recibe ningún paquete de datos del Cliente dentro del intervalo de tiempo de 1.5 * keepalive, el Broker considera que la conexión con el Cliente está desconectada; por la misma razón, el Cliente no recibe ningún paquete de datos. del Broker dentro de este intervalo de tiempo. El Cliente también pensará que su conexión con el Broker está desconectada;

El protocolo MQTT diseña un par de paquetes de datos PINGREQ / PINGRESP. Cuando no hay interacción de datos entre el Broker y el Cliente, este par de paquetes de datos puede cumplir con el acuerdo keepalive y el monitoreo del estado de la red;

6.5.2 características keepalive

Si dentro de un intervalo de tiempo de Keepalive, el Cliente y el Broker tienen transmisión de paquetes de datos, el Cliente no necesita usar el paquete de datos PINGREQ;
El valor de Keepalive lo especifica el Cliente al enviar el paquete CONNECT, y diferentes Clientes pueden especificar valores diferentes;
El valor máximo de Keepalive es 18:12:15
Cuando el valor de Keepalive es 0, significa que el mecanismo Keepalive no se utiliza

6.6 Mensaje retenido

6.6.1 El papel del mensaje retenido

Habrá tal escenario, después de que el editor publica un mensaje, el suscriptor se suscribe a este tema, entonces este suscriptor no recibirá el mensaje publicado por el editor antes de suscribirse. El mensaje Retenido es para resolver este problema. El mensaje Retenido se refiere al mensaje con el indicador Retenido establecido en 1 en el paquete PUBLISH. Después de recibir dicho paquete PUBLISH, el Broker guardará el mensaje para el tema como una nueva suscripción. Cuando el suscriptor se suscribe al tema, el corredor enviará este mensaje al suscriptor.

6.6.2 Características del mensaje retenido

Un tema tiene solo un mensaje retenido y la publicación de un nuevo mensaje retenido sobrescribirá el antiguo mensaje retenido;
Si los suscriptores se suscriben a temas utilizando comodines, recibirán todos los mensajes retenidos que coincidan con los temas;
Solo los nuevos suscriptores recibirán mensajes retenidos. Si los suscriptores se suscriben repetidamente a un tema, serán tratados como nuevos suscriptores y recibirán mensajes retenidos;
Publique un mensaje retenido con una longitud de carga útil de 0 en el tema para eliminar el mensaje retenido de este tema;

6.6.3 Mensajes retenidos y sesiones persistentes

No hay relación entre los dos, el corredor almacena el mensaje retenido por separado para cada tema y el corredor almacena la sesión persistente por separado para cada cliente;

6.7 LWT (voluntad)

El nombre completo de LWT es Última voluntad y testamento, que es el último deseo, incluido el tema del último deseo, la QoS del último deseo, el mensaje del último deseo, etc. Consulte el protocolo MQTT para obtener más detalles. deseo tiene las siguientes características:

Los ajustes relevantes del último deseo se especifican en el paquete CONNECT cuando se establece la conexión;
El último deseo se utiliza en caso de desconexión anormal, cuando el Broker detecta la desconexión anormal del Cliente, publicará un mensaje al sujeto del último deseo del Cliente;
El cliente libera el paquete DISCONNECT para desconectarse, que es una desconexión normal y no activará el mecanismo LWT, y el Broker perderá los parámetros LWT especificados cuando el Cliente esté conectado.

Seven, versión MQTT

Los anteriores se basan en MQTT 3.1.1. Para obtener más información sobre MQTT 5.0, consulte la documentación oficial.

Introducción al protocolo MQTT

I. Introducción