MQTT

MQTT (Transporte de telemetría de colas de mensajes) es un protocolo de mensajería ligero y ampliamente adoptado que está diseñado para dispositivos restringidos. La compatibilidad de AWS IoT Core con MQTT se basa en la especificación MQTT v3.1.1 y en la especificación MQTT v5.0, con algunas diferencias, tal y como se documenta en AWS IoT diferencias con las especificaciones de MQTT. Al ser la última versión del estándar, MQTT 5 presenta varias características clave que hacen que un sistema basado en MQTT sea más robusto, incluidas nuevas mejoras de escalabilidad, informes de errores mejorados con respuestas de códigos de motivo, temporizadores de caducidad de mensajes, y sesiones y encabezados de mensajes de usuario personalizados. Para obtener más información sobre las funciones compatibles con MQTT 5, consulte Funciones AWS IoT Core compatibles con MQTT 5. AWS IoT Core también admite la comunicación entre versiones MQTT (MQTT 3 y MQTT 5). Un editor de MQTT 3 puede enviar un mensaje de MQTT 3 a un suscriptor de MQTT 5 que recibirá un mensaje de publicación de MQTT 5, y viceversa.

AWS IoT Core admite conexiones de dispositivos que utilizan el protocolo MQTT y el protocolo MQTT sobre el protocolo WSS y que se identifican mediante un ID de cliente. AWS IoT Dispositivo SDKs es compatible con ambos protocolos y son las formas recomendadas de conectar los dispositivos a AWS IoT Core. El AWS IoT dispositivo SDKs admite las funciones necesarias para que los dispositivos y los clientes se conecten a los servicios y accedan AWS IoT a ellos. El dispositivo SDKs admite los protocolos de autenticación que requieren los AWS IoT servicios y los requisitos de identificación de conexión que requieren el protocolo MQTT y los protocolos MQTT sobre WSS. Para obtener información sobre cómo conectarse AWS IoT mediante el AWS dispositivo SDKs y enlaces a ejemplos AWS IoT en los idiomas compatibles, consulte. Conexión con MQTT mediante el dispositivo AWS IoT SDKs Para obtener más información acerca de los métodos de autenticación y las asignaciones de puertos para mensajes MQTT, consulte Protocolos, asignaciones de puertos y autenticación.

Si bien recomendamos usar el AWS IoT dispositivo SDKs para conectarse AWS IoT, no son obligatorios. Sin embargo SDKs, si no utiliza el AWS IoT Dispositivo, debe proporcionar la seguridad de conexión y comunicación necesaria. Los clientes también deben enviar la extensión TLS de Indicación de nombre de servidor (SNI) en la solicitud de conexión. Se rechazan los intentos de conexión que no incluyan la SNI. Para obtener más información, consulte Seguridad en el transporte en AWS IoT. Los clientes que utilizan usuarios y AWS credenciales de IAM para autenticar a los clientes deben proporcionar la autenticación correcta de la versión 4 de Signature.

Conexión con MQTT mediante el dispositivo AWS IoT SDKs

Esta sección contiene enlaces al AWS IoT dispositivo SDKs y al código fuente de programas de muestra que ilustran cómo conectar un dispositivo al AWS IoT mismo. Las aplicaciones de muestra enlazadas aquí muestran cómo conectarse AWS IoT mediante el protocolo MQTT y MQTT a través de WSS.

Opciones de calidad de servicio (QoS) de MQTT

AWS IoT y el AWS IoT dispositivo SDKs admiten los niveles de calidad de servicio (QoS) 0 de MQTT y. 1 El protocolo MQTT define un tercer nivel de QoS, el 2 nivel, AWS IoT pero no lo admite. Solo el protocolo MQTT admite la característica QoS. HTTPS admite QoS al pasar un parámetro de cadena de consulta ?qos=qos donde el valor puede ser 0 o 1.

En esta tabla se describe cómo afecta cada nivel de QoS a los mensajes publicados en el agente de mensajes y por este.

Sesiones persistentes de MQTT

Las sesiones persistentes almacenan las suscripciones y los mensajes de un cliente, con una calidad de servicio (QoS) de 1, que el cliente no ha reconocido. Cuando el dispositivo se vuelve a conectar a una sesión persistente, la sesión se reanuda, las suscripciones se restablecen y los mensajes suscritos no confirmados recibidos y almacenados antes de la reconexión se envían al cliente.

El procesamiento de los mensajes almacenados se registra en y se registra. CloudWatch CloudWatch Para obtener información sobre las entradas escritas CloudWatch y los CloudWatch registros, consulte Métricas del agente de mensajes yEntrada de registro en cola.

Creación de una sesión persistente

En MQTT 3, puede crear una sesión persistente de MQTT enviando un mensaje CONNECT, que establezca la marca cleanSession en 0. Si no existe ninguna sesión para el cliente que envía el mensaje CONNECT, se crea una sesión persistente nueva. Si ya existe una sesión para el cliente, el cliente reanuda la sesión existente. Para crear una sesión limpia, se envía un mensaje CONNECT y se establece la marca cleanSession en 1, y el agente no almacenará ningún estado de la sesión cuando el cliente se desconecte.

En MQTT 5, las sesiones persistentes se gestionan configurando la marca Clean Start y Session Expiry Interval. Clean Start controla el inicio de la sesión de conexión y el final de la sesión anterior. Si se establece Clean Start = 1, se crea una nueva sesión y, si existe, se termina la sesión anterior. Si se establece Clean Start = 0, la sesión de conexión reanuda la sesión anterior, si ya existe. El intervalo de caducidad de la sesión controla el final de la sesión de conexión. El intervalo de caducidad de la sesión especifica el tiempo, en segundos (entero de 4 bytes), que durará una sesión tras la desconexión. La configuración Session Expiry interval = 0 hace que la sesión finalice inmediatamente después de la desconexión. Si el intervalo de caducidad de la sesión no se especifica en el mensaje CONNECT, el valor predeterminado es 0.

En MQTT 5, si establece Clean Start = 1 y Session Expiry Interval =0, equivale a una sesión limpia de MQTT 3. Si establece Clean Start = 0 y Session Expiry Interval >0, equivale a una sesión persistente de MQTT 3.

Operaciones durante una sesión persistente

Los clientes utilizan el atributo sessionPresent del mensaje de confirmación de conexión (CONNACK) para determinar si existe una sesión persistente. Si sessionPresent es 1, hay una sesión persistente y todos los mensajes almacenados para el cliente se envían al cliente después de que el cliente reciba el CONNACK, tal y como se describe en Tráfico de mensajes tras la reconexión a una sesión persistente. Si sessionPresent es 1, el cliente no necesita volver a suscribirse. Sin embargo, si sessionPresent está establecido en 0, significa que no existe ninguna sesión persistente y que el cliente debe volver a suscribirse a sus filtros de temas.

Una vez que el cliente se une a una sesión persistente, puede publicar mensajes y suscribirse a filtros de temas sin ningún indicador adicional en cada operación.

Tráfico de mensajes tras volver a conectarse a una sesión persistente

Una sesión persistente representa una conexión en curso entre un cliente y un agente de mensajes de MQTT. Cuando un cliente se conecta al agente de mensajes mediante una sesión persistente, el agente de mensajes guarda todas las suscripciones que el cliente realiza durante la conexión. Cuando el cliente se desconecta, el agente de mensajes almacena los mensajes QoS 1 sin confirmar y los mensajes QoS 1 nuevos publicados en los temas a los que el cliente está suscrito. Los mensajes se almacenan según el límite de la cuenta. Mensajes que superen el límite se eliminarán. Para más información acerca de los límites de mensajes persistentes, consulte Puntos de conexión y cuotas de AWS IoT Core. Cuando el cliente vuelve a conectarse la sesión persistente, todas las suscripciones se restablecen y todos los mensajes almacenados se envían al cliente a una velocidad máxima de 10 mensajes por segundo. En MQTT 5, si un QoS1 saliente con un intervalo de caducidad de mensajes caduca cuando un cliente está desconectado, una vez que se reanude la conexión, el cliente no recibirá el mensaje caducado.

Tras la reconexión, los mensajes almacenados se envían al cliente a una velocidad limitada a 10 mensajes almacenados por segundo, junto con el tráfico de mensajes actual hasta que se alcance el límite de Publish requests per second per connection. Como la velocidad de entrega de los mensajes almacenados es limitada, se tardarán varios segundos en entregar todos los mensajes almacenados si una sesión tiene más de 10 mensajes almacenados que entregar después de la reconexión.

Finalizar una sesión persistente

Las sesiones persistentes pueden finalizar de una de las siguientes formas:

En MQTT 3, el valor predeterminado del tiempo de caducidad de las sesiones persistentes es de una hora, y esto se aplica a todas las sesiones de la cuenta.

En MQTT 5, puede establecer el intervalo de caducidad de la sesión para cada sesión en los paquetes CONNECT y DISCONNECT.

Para el intervalo de caducidad de la sesión en el paquete DISCONNECT:

Reconexión después de que haya caducado una sesión persistente

Si un cliente no se vuelve a conectar a su sesión persistente antes de que caduque, la sesión finaliza y los mensajes almacenados se descartan. Cuando un cliente se vuelve a conectar después de que la sesión haya caducado con una marca cleanSession establecida en 0, el servicio crea una nueva sesión persistente. Las suscripciones o los mensajes de la sesión anterior no están disponibles para esta sesión porque se descartaron al expirar la sesión anterior.

Cargos por mensajes de sesión persistentes

Los mensajes se cobran Cuenta de AWS cuando el agente de mensajes envía un mensaje a un cliente o a una sesión persistente fuera de línea. Cuando un dispositivo desconectado con una sesión persistente se vuelve a conectar y reanuda la sesión, los mensajes almacenados se envían al dispositivo y se vuelven a cargar a su cuenta. Para obtener más información sobre los precios de los mensajes, consulte los Precios de AWS IoT Core : Mensajería.

El tiempo de caducidad predeterminado de la sesión persistente, de una hora, se puede aumentar mediante el proceso de aumento de límites estándar. Tenga en cuenta que aumentar el tiempo de caducidad de la sesión puede aumentar los cargos por mensajes, ya que el tiempo adicional podría permitir almacenar más mensajes para el dispositivo sin conexión y esos mensajes adicionales se cargarían en su cuenta según la tarifa de mensajería estándar. El tiempo de caducidad de la sesión es aproximado y una sesión puede prolongarse hasta 30 minutos más que el límite de la cuenta; sin embargo, una sesión no superará el límite de la cuenta. Para obtener más información acerca de los límites de sesión, consulte Cuotas de servicio de AWS.

Mensajes retenidos de MQTT

AWS IoT Core admite el indicador RETAIN descrito en el protocolo MQTT. Cuando un cliente establece el indicador RETAIN en un mensaje MQTT que publica, AWS IoT Core guarda el mensaje. A continuación, puede enviarse a los nuevos suscriptores, recuperarse mediante una llamada a la operación GetRetainedMessage y visualizarse en la consola de AWS IoT.

Las tareas habituales con mensajes MQTT retenidos en AWS IoT Core

AWS IoT Core guarda los mensajes MQTT con el indicador RETAIN establecido. Estos mensajes retenidos se envían a todos los clientes que se han suscrito al tema, como un mensaje MQTT normal, y también se almacenan para enviarlos a los nuevos suscriptores del tema.

Los mensajes MQTT retenidos requieren políticas específicas para autorizar a los clientes a acceder a ellos. Para ver ejemplos del uso de políticas de mensajes retenidos, consulte Ejemplos de políticas de mensajes retenidos.

En esta sección se describen las operaciones comunes que implican los mensajes retenidos.

Facturación y mensajes retenidos

La publicación de mensajes con la marca RETAIN activada desde un cliente, mediante la consola de AWS IoT o mediante una llamada a Publish conlleva los gastos de mensajería adicionales descritos en la sección Precios de mensajería de AWS IoT Core.

La recuperación de los mensajes retenidos por parte de un cliente, mediante una AWS IoT consola o mediante una llamada GetRetainedMessageconlleva gastos de mensajería además de los cargos por uso normal de la API. Los cargos adicionales se describen en Precios de mensajería de AWS IoT Core.

Los mensajes Will que se publiquen cuando un dispositivo se desconecte inesperadamente incurrirán en los cargos de mensajería descritos en el apartado Precios de mensajería de AWS IoT Core.

Para obtener más información sobre los costes de mensajería, consulte Precios de mensajería de AWS IoT Core.

Comparación de los mensajes retenidos de MQTT y las sesiones persistentes de MQTT

Los mensajes retenidos y las sesiones persistentes son características estándar de MQTT que permiten a los dispositivos recibir los mensajes que se publicaron sin conexión a Internet. Los mensajes retenidos se pueden publicar desde sesiones persistentes. En esta sección se describen los aspectos clave de estas características y la forma en que funcionan juntas.

Para obtener más información acerca del almacenamiento persistente, consulte Sesiones persistentes de MQTT.

Con mensajes retenidos, el cliente de publicación determina si un mensaje debe conservarse y entregarse a un dispositivo después de que se conecte, independientemente de que haya tenido una sesión anterior o no. La elección de almacenar un mensaje la realiza el editor y el mensaje almacenado se entrega a todos los clientes actuales y futuros que se suscriban con suscripciones QoS 0 o QoS 1. Los mensajes retenidos guardan solo un mensaje sobre un tema determinado cada vez.

Cuando una cuenta ha almacenado el número máximo de mensajes retenidos, AWS IoT Core devuelve una respuesta limitada a los mensajes publicados con la marca RETAIN activada y con cargas útiles superiores a 0 bytes hasta que se eliminen algunos mensajes retenidos y el recuento de mensajes retenidos caiga por debajo del límite.

Los mensajes retenidos por MQTT y Device Shadows AWS IoT

Tanto los mensajes retenidos como las sombras de dispositivo retienen los datos de un dispositivo, pero se comportan de manera diferente y tienen diferentes propósitos. En esta sección se describen sus similitudes y diferencias.

Mensajes Last Will and Testament (LWT) de MQTT

Last Will and Testament (LWT) es una característica de MQTT. Con LWT, los clientes pueden especificar un mensaje que el agente publicará en un tema definido por el cliente y lo enviará a todos los clientes que se hayan suscrito al tema cuando se produzca una desconexión no iniciada. El mensaje que especifican los clientes se denomina mensaje LWT o mensaje Will, y el tema que definen los clientes se denomina tema Will. Puede especificar un mensaje LWT cuando un dispositivo se conecte al agente. Estos mensajes se pueden conservar configurando la marca Will Retain en el campo Connect Flag bits durante la conexión. Por ejemplo, si la marca Will Retain está establecido en 1, el mensaje Will se almacenará en el agente en el tema Will asociado. Para obtener más información, consulte Plantillas de mensaje.

El agente almacenará los mensajes Will hasta que se produzca una desconexión no iniciada. Cuando eso suceda, el agente publicará los mensajes para todos los clientes que se hayan suscrito al tema Will para notificarles la desconexión. Si el cliente se desconecta del agente con una desconexión iniciada por el cliente mediante el mensaje MQTT DISCONNECT, el agente no publicará los mensajes LWT almacenados. En el resto de los casos, se enviarán los mensajes de LWT. Para obtener una lista completa de los escenarios de desconexión en los que el agente enviará los mensajes de LWT, consulte Eventos de conexión y desconexión.

Uso de connectAttributes

ConnectAttributes le permite especificar qué atributos quiere usar en su mensaje de conexión en sus políticas de IAM, como PersistentConnect y LastWill. Con ConnectAttributes, puede crear políticas que no otorguen a los dispositivos acceso a nuevas características de forma predeterminada, lo que puede resultar útil si un dispositivo se ve comprometido.

connectAttributes admite las siguientes características:

De forma predeterminada, su política tiene una conexión no persistente y no se transfieren atributos para esta conexión. Debe especificar una conexión persistente en su política de IAM si desea tener una.

Para ver ejemplos de ConnectAttributes, consulte Ejemplos de políticas de conexión.

Características compatibles con MQTT 5

AWS IoT Core la compatibilidad con MQTT 5 se basa en la especificación MQTT v5.0 con algunas diferencias, tal como se describe en. AWS IoT diferencias con las especificaciones de MQTT

Suscripciones compartidas

AWS IoT Core admite suscripciones compartidas para MQTT 3 y MQTT 5. Las suscripciones compartidas permiten que varios clientes compartan una suscripción a un tema y solo un cliente recibirá los mensajes publicados sobre ese tema mediante una distribución aleatoria. Las suscripciones compartidas pueden equilibrar eficazmente la carga de los mensajes MQTT entre varios suscriptores. Por ejemplo, supongamos que tiene 1000 dispositivos que publican sobre el mismo tema y 10 aplicaciones de segundo plano que procesan esos mensajes. En ese caso, las aplicaciones de segundo plano pueden suscribirse al mismo tema y cada una de ellas recibiría de forma aleatoria los mensajes publicados por los dispositivos en el tema compartido. De hecho, se trata de “compartir” la carga de esos mensajes. Las suscripciones compartidas también brindan una mayor resiliencia. Cuando una aplicación de segundo plano se desconecta, el agente distribuye la carga entre los suscriptores restantes del grupo.

Para usar las suscripciones compartidas, los clientes se suscriben al filtro de temas de una suscripción compartida de la siguiente manera:

$share/{ShareName}/{TopicFilter}

Las suscripciones que tienen el mismo {ShareName}/{TopicFilter} pertenecen al mismo grupo de suscripciones compartidas. Puede crear varios grupos de suscripciones compartidas y no superar el límite de suscripciones compartidas por grupo. Para obtener más información, consulte Puntos de conexión y cuotas de AWS IoT Core en la Referencia general de AWS .

En las siguientes tablas se comparan las suscripciones no compartidas y las suscripciones compartidas:

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Flujo de suscripciones no compartidas	Flujo de suscripciones compartidas

Notas importantes sobre el uso de las suscripciones compartidas

Para obtener más información sobre los límites de las suscripciones compartidas, consulte Puntos de conexión y las cuotas de AWS IoT Core en la Referencia general de AWS . Para probar las suscripciones compartidas mediante el cliente AWS IoT MQTT de la AWS IoT consola, consulte. Probar las suscripciones compartidas en el cliente MQTT Para obtener más información sobre las suscripciones compartidas, consulte Suscripciones compartidas de la especificación MQTTv5 .0.

Inicio limpio y caducidad de la sesión

Puede usar las funciones de inicio limpio y caducidad de la sesión para gestionar sus sesiones persistentes con más flexibilidad. Un marca de inicio limpio indica si la sesión debe iniciarse sin utilizar una sesión existente. Un intervalo de caducidad de la sesión indica cuánto tiempo se debe conservar la sesión tras una desconexión. El intervalo de caducidad de la sesión se puede modificar al desconectarse. Para obtener más información, consulte Sesiones persistentes de MQTT.

Código de motivo en todas ACKs

Puede depurar o procesar los mensajes de error más fácilmente utilizando los códigos de motivo. El agente de mensajes devuelve los códigos de motivo en función del tipo de interacción con el agente (suscribirse, publicar o confirmar). Para obtener más información, consulte Códigos de motivo de MQTT. Para obtener una lista completa de los códigos de motivo de MQTT, consulte la especificación de MQTT v5.

Alias de temas

Puede sustituir el nombre de un tema por un alias de tema, que es un entero de dos bytes. El uso de alias de temas puede optimizar la transmisión de los nombres de los temas y reducir potencialmente los costos de datos en los servicios de datos medidos. AWS IoT Core tiene un límite predeterminado de 8 alias de temas. Para obtener más información, consulte Puntos de conexión y cuotas de AWS IoT Core en la Referencia general de AWS .

Caducidad de los mensajes

Puede agregar valores de caducidad de los mensajes a los mensajes publicados. Estos valores representan el intervalo de caducidad de los mensajes en segundos. Si los mensajes no se envían a los suscriptores en ese intervalo, los mensajes caducan y se eliminan. Si no establece el valor de caducidad del mensaje, el mensaje no caducará.

Al salir, el suscriptor recibirá un mensaje con el tiempo restante del intervalo de caducidad. Por ejemplo, si un mensaje de publicación entrante tiene una caducidad de 30 segundos y se envía al suscriptor después de 20 segundos, el campo de caducidad del mensaje se actualizará a 10. Es posible que el mensaje recibido por el suscriptor tenga un MEI actualizado de 0. Esto se debe a que tan pronto como el tiempo restante sea de 999 ms o menos, se actualizará a 0.

En AWS IoT Core, el intervalo mínimo de caducidad de los mensajes es 1. Si el intervalo se establece en 0 desde el lado del cliente, se ajustará a 1. El intervalo máximo de caducidad de mensajes es 604800 (7 días). Cualquier valor superior a este valor se ajustará al valor máximo.

En la comunicación entre versiones, el comportamiento de caducidad del mensaje lo decide la versión MQTT del mensaje de publicación entrante. Por ejemplo, un mensaje con fecha de caducidad enviado por una sesión a través de la cual se ha conectado MQTT5 puede caducar en el caso de los dispositivos suscritos con sesiones. MQTT3 En la siguiente tabla se muestra cómo la caducidad de los mensajes admite los siguientes tipos de mensajes de publicación:

Otras características de MQTT 5

Desconexión del servidor

Cuando se produce una desconexión, el servidor puede enviar de forma proactiva al cliente una desconexión para notificar el cierre de la conexión con un código de motivo de la desconexión.

Solicitud/respuesta

Los editores pueden solicitar que el destinatario envíe una respuesta a un tema especificado por el editor en el momento de la recepción.

Tamaño máximo de paquete

El cliente y el servidor pueden especificar de forma independiente el tamaño máximo de paquete que admiten.

Formato de carga y tipo de contenido

Puede especificar el formato de carga (binario, texto) y el tipo de contenido al publicar un mensaje. Se reenvían al destinatario del mensaje.

Propiedades de MQTT 5

Las propiedades de MQTT 5 son adiciones importantes al estándar MQTT para admitir las nuevas características de MQTT 5, como la caducidad de sesión y el patrón de solicitud/respuesta. En AWS IoT Core, puede crear reglas que reenvíen las propiedades de los mensajes salientes o usar HTTP Publish para publicar mensajes MQTT con algunas de las nuevas propiedades.

En la siguiente tabla se enumeran todas las propiedades de MQTT 5 compatibles. AWS IoT Core

Códigos de motivo de MQTT

MQTT 5 introduce una mejora en la notificación de errores con respuestas en códigos de motivo. AWS IoT Core puede devolver códigos de motivo, incluidos, entre otros, los siguientes agrupados por paquetes. Para obtener una lista completa de los códigos de motivo compatibles con MQTT 5, consulte las especificaciones de MQTT 5.

AWS IoT diferencias con las especificaciones de MQTT

La implementación del agente de mensajes se basa en la especificación MQTT v3.1.1 y la especificación MQTT v5.0, pero se diferencia de las especificaciones en los siguientes aspectos: