Protocolos de comunicación de dispositivos

AWS IoT Core admite dispositivos y clientes que utilizan los protocolos MQTT y MQTT over WebSocket Secure (WSS) para publicar mensajes y suscribirse a ellos, y dispositivos y clientes que utilizan el protocolo HTTPS para publicar mensajes. Todos los protocolos son compatibles con IPv4 e IPv6. En esta sección se describen las diferentes opciones de conexión para dispositivos y clientes.

TLS 1.2 y TLS 1.3

AWS IoT Core utiliza la versión 1.2 de TLS y la versión 1.3 de TLS para cifrar todas las comunicaciones. Al conectar los dispositivos a AWS IoT Core, los clientes pueden enviar la extensión de indicación del nombre del servidor (SNI); esto no es obligatorio, pero sí muy recomendable. Para usar características como el registro de varias cuentas, los dominios personalizados y los puntos de conexión de VPC, debe usar la extensión SNI. Para obtener más información, consulte Seguridad del transporte en. AWS IoT

Los AWS IoT SDK de dispositivo admiten MQTT y MQTT a través de WSS y cumplen los requisitos de seguridad de las conexiones de los clientes. Recomendamos utilizar los AWS IoT SDK de dispositivo para conectar los clientes a AWS IoT.

Protocolos, asignaciones de puertos y autenticación

La forma en que un dispositivo o cliente se conecta al agente de mensajes mediante un punto de conexión de dispositivo depende del protocolo que utilice. En la siguiente tabla se enumeran los protocolos que admiten los puntos finales del AWS IoT dispositivo y los métodos y puertos de autenticación que utilizan.

Protocolos, autenticación y asignaciones de puertos
Protocolo	Operaciones admitidas	Autenticación	Puerto	Nombre del protocolo ALPN
MQTT ha terminado WebSocket	Publicar, suscribirse	Signature Version 4	443	N/A
Se acabó MQTT WebSocket	Publicar, suscribirse	Autenticación personalizada	443	N/A
MQTT	Publicar, suscribirse	Certificado de cliente X.509	443†	x-amzn-mqtt-ca
MQTT	Publicar, suscribirse	Certificado de cliente X.509	8883	N/A
MQTT	Publicar, suscribirse	Autenticación personalizada	443†	mqtt
HTTPS	Solo publicar	Signature Version 4	443	N/A
HTTPS	Solo publicar	Certificado de cliente X.509	443†	x-amzn-http-ca
HTTPS	Solo publicar	Certificado de cliente X.509	8443	N/A
HTTPS	Solo publicar	Autenticación personalizada	443	N/A

Negociación de protocolo de capa de aplicación (ALPN)

^† Los clientes que se conecten al puerto 443 con un certificado de cliente X.509 deben implementar la extensión TLS de negociación de protocolos de capa de aplicación (ALPN) y usar el nombre del protocolo ALPN que aparece en el ALPN ProtocolNameList enviado por el cliente como parte del mensaje. ClientHello

En el puerto 443, el extremo IoT:DATA-ATS admite HTTP x-amzn-http-ca ALPN, pero el punto final IoT:Jobs no.

En el puerto 8443 HTTPS y el puerto 443 MQTT con ALPN, no se puede usar la autenticación personalizada. x-amzn-mqtt-ca

Los clientes se conectan a los puntos finales Cuenta de AWS de sus dispositivos. Consulte AWS IoT datos del dispositivo y puntos finales de servicio para obtener información sobre cómo encontrar los puntos de conexión de los dispositivos de su cuenta.

nota

AWS Los SDK no requieren la URL completa. Solo requieren el nombre de host del punto final, como en el pubsub.pyejemplo de AWS IoT Device SDK for Python on GitHub. Pasar la URL completa como se indica en la siguiente tabla puede generar un error (como un nombre de host no válido).

Conectándose a AWS IoT Core
Protocolo	Punto de enlace o URL
MQTT	iot-endpoint
MQTT a través de WSS	wss://iot-endpoint/mqtt
HTTPS	https://iot-endpoint/topics

Elección de un protocolo para la comunicación entre dispositivos

Para la mayoría de las comunicaciones entre dispositivos IoT a través de los puntos de conexión del dispositivo, lo óptimo es utilizar los protocolos MQTT o MQTT a través de WSS; sin embargo, los puntos de conexión de dispositivo también admiten HTTPS. En la siguiente tabla se compara el modo en que se AWS IoT Core utilizan los dos protocolos para la comunicación entre dispositivos.

AWS IoT protocolos del dispositivo side-by-side
Característica	MQTT	HTTPS
Soporte para publicación/suscripción	Publicar y suscribirse	Solo publicar
Soporte para SDK	AWS Los SDK de dispositivo son compatibles con los protocolos MQTT y WSS	No compatible con el SDK, pero es posible usar métodos de lenguajes específicos para realizar solicitudes HTTPS
Soporte para calidad del servicio	Niveles 0 y 1 de calidad del servicio de MQTT	Se admite la calidad del servicio al pasar un parámetro de cadena de consulta ?qos=qos donde el valor puede ser 0 o 1. Puede agregar esta cadena de consulta para publicar un mensaje con el valor de calidad del servicio que desee.
¿Se pueden perder los mensajes recibidos mientras el dispositivo estaba sin conexión?	Sí	No
Soporte de campo de clientId	Sí	No
Detección de desconexión de dispositivos	Sí	No
Comunicaciones seguras	Sí Consulte Protocolos, asignaciones de puertos y autenticación	Sí Consulte Protocolos, asignaciones de puertos y autenticación
Definiciones de temas	Definido por la aplicación	Definido por la aplicación
Formato de datos de mensajes	Definido por la aplicación	Definido por la aplicación
Sobrecarga de protocolo	Más baja	Más alta
Consumo eléctrico	Más bajo	Más alto

Límites de duración de la conexión

No se garantiza que las conexiones HTTPS duren más del tiempo necesario para recibir las solicitudes y responder.

La duración de la conexión MQTT depende de la característica de autenticación que utilice. La siguiente tabla muestra la duración máxima de la conexión en condiciones ideales para cada característica.

Duración de la conexión MQTT por característica de autenticación
Característica	Duración máxima*
Certificado de cliente X.509	De 1 a 2 semanas
Autenticación personalizada	De 1 a 2 semanas
Signature Version 4	Hasta 24 horas

^* No garantizado

Con los certificados X.509 y la autenticación personalizada, la duración de la conexión no tiene un límite estricto, pero puede durar incluso solo unos minutos. Las interrupciones en la conexión pueden producirse por diversos motivos. A continuación, se presentan algunos de los casos más comunes.

• Interrupciones en la disponibilidad de la conexión wifi

• Interrupciones de conexión del proveedor de servicios de Internet (ISP)

• Parches de servicio

• Implementaciones de servicios

• Escalado automático de servicios

• Host de servicio no disponible

• Problemas y actualizaciones del equilibrador de carga

• Errores del cliente

Los dispositivos deben implementar estrategias para detectar las desconexiones y volver a conectarse. Para obtener información sobre los eventos de desconexión y saber cómo gestionarlos, consulteEventos de conexión/desconexión en Eventos del ciclo de vida.