Protocoles de communication des appareils - AWS IoT Core
Choix d'un protocole pour la communication de votre appareilLimites de durée de connexion

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Protocoles de communication des appareils

AWS IoT Core prend en charge les appareils et les clients qui utilisent les protocoles MQTT et MQTT over WebSocket Secure (WSS) pour publier des messages et s'y abonner, ainsi que les appareils et clients qui utilisent le protocole HTTPS pour publier des messages. Elle prend en charge les protocoles IPv4 et IPv6. Cette section décrit les différentes options de connexion pour les appareils et les clients.

TLS 1.2 et TLS 1.3

AWS IoT Core utilise TLS version 1.2 et TLS version 1.3 pour chiffrer toutes les communications. Lors de la connexion d'appareils à AWS IoT Core, les clients peuvent envoyer l'extension Server Name Indication (SNI), ce qui n'est pas obligatoire mais fortement recommandé. Pour utiliser des fonctionnalités telles que l'enregistrement multi-comptes, les domaines personnalisés et les points de terminaison d'un VPC, vous devez utiliser l'extension SNI. Pour plus d'informations, consultez la section Sécurité du transport dans AWS IoT.

Les AWS IoT SDK pour appareils prennent en charge le MQTT et le MQTT sur WSS et répondent aux exigences de sécurité des connexions client. Nous vous recommandons d'utiliser le AWS IoT SDK pour appareils pour connecter les clients à AWS IoT.

Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification)

La manière dont un appareil ou un client se connecte au agent de messages à l'aide d'un point de terminaison dépend du protocole utilisé. Le tableau suivant répertorie les protocoles pris en charge par les points de terminaison de l' AWS IoT appareil ainsi que les méthodes d'authentification et les ports qu'ils utilisent.

Protocoles, authentification et mappages de port
Protocole Opérations prises en charge Authentification Port Nom du protocole ALPN

MQTT terminé WebSocket

 Publier/s'abonner Signature Version 4 443

N/A

MQTT terminé WebSocket

 Publier/s'abonner Authentification personnalisée 443

N/A

MQTT

 Publier/s'abonner

Certificat de client X.509

443†

x-amzn-mqtt-ca
MQTT Publier/s'abonner Certificat de client X.509 8883 N/A

MQTT

 Publier/s'abonner

Authentification personnalisée

443†

mqtt

HTTPS

 Publier uniquement

Signature Version 4

443

N/A

HTTPS

 Publier uniquement

Certificat de client X.509

443†

x-amzn-http-ca
HTTPS Publier uniquement Certificat de client X.509 8443 N/A
HTTPS Publier uniquement Authentification personnalisée 443 N/A
Application Layer Protocol Negotiation (ALPN)

† Les clients qui se connectent sur le port 443 avec l'authentification par certificat client X.509 doivent implémenter l'extension TLS ALPN (Application Layer Protocol Negotiation) et utiliser le nom du protocole ALPN indiqué dans l'ALPN ProtocolNameList envoyé par le client dans le cadre du message. ClientHello

Sur le port 443, le point de terminaison IoT:Data-ATS prend en charge le x-amzn-http-ca protocole HTTP ALPN, mais pas le point de terminaison IoT:Jobs.

Sur le port 8443 HTTPS et le port 443 MQTT avec ALPN x-amzn-mqtt-ca, l'authentification personnalisée ne peut pas être utilisée.

Les clients se connectent aux terminaux Compte AWS de leurs appareils. Consultez la section AWS IoT données de l'appareil et points de terminaison de service pour plus d'informations sur la façon de trouver les points de terminaison de l'appareil de votre compte.

Note

AWS Les SDK ne nécessitent pas l'URL complète. Ils ont uniquement besoin du nom d'hôte du point de terminaison, tel que l'pubsub.pyexemple du AWS IoT Device SDK for Python on. GitHub La transmission de l'URL complète comme indiqué dans le tableau suivant peut générer une erreur telle qu'un nom d'hôte non valide.

Connexion à AWS IoT Core

Protocole

Point de terminaison ou URL

MQTT

iot-endpoint

MQTT via WSS

wss://iot-endpoint/mqtt

HTTPS

https://iot-endpoint/topics

Choix d'un protocole pour la communication de votre appareil

Pour la plupart des communications entre appareils IoT via les points de terminaison de l'appareil, vous devez utiliser les protocoles MQTT ou MQTT que WSS ; toutefois, les points de terminaison de l'appareil prennent également en charge le protocole HTTPS. Le tableau suivant compare l' AWS IoT Core utilisation des deux protocoles pour la communication entre appareils.

AWS IoT protocoles de l'appareil side-by-side

Fonctionnalité

MQTT

HTTPS

Assistance pour la publication/abonnement

Publication et d'abonnement

Publier uniquement

Prise en charge de SDK

AWS Les SDK des appareils prennent en charge les protocoles MQTT et WSS

Pas de prise en charge du SDK, mais vous pouvez utiliser des méthodes spécifiques à la langue pour effectuer des requêtes HTTPS

Prise en charge de la qualité de service

QoS MQTT niveaux 0 et 1

 La QoS est prise en charge en transmettant un paramètre de chaîne de requête ?qos=qos dont la valeur peut être 0 ou 1. Vous pouvez ajouter cette chaîne de requête pour publier un message avec la valeur de QoS souhaitée.
Les messages de réception peuvent-ils être manqués lorsque l'appareil était hors ligne Oui Non

Soutien sur le terrain clientId

Oui

Non

Détection de déconnexion de l'appareil

Oui

Non

Communications sécurisées

Oui. Consultez Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).

Oui. Consultez Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).

Définitions de rubriques

Application définie

Application définie

Format des données des messages

Application définie

Application définie
Surcharge de protocole Inférieur Supérieur
Consommation d’énergie Inférieur Supérieur

Limites de durée de connexion

Il n'est pas garanti que les connexions HTTPS durent plus longtemps que le temps nécessaire pour recevoir et répondre aux demandes.

La durée de connexion MQTT dépend de la fonctionnalité d'authentification que vous utilisez. Le tableau suivant répertorie la durée maximale de connexion dans des conditions idéales pour chaque fonctionnalité.

Durée de connexion MQTT par fonction d'authentification

Fonctionnalité

Durée maximum *

Certificat de client X.509

1 à 2 semaines

Authentification personnalisée

1 à 2 semaines

Signature Version 4

Jusqu'à 24 heures

* Non garanti

Avec les certificats X.509 et l'authentification personnalisée, la durée de connexion n'est pas limitée, mais elle peut être aussi courte que quelques minutes. Ces erreurs peuvent se produire pour diverses raisons. La liste suivante contient certaines des raisons les plus courantes.

  • Interruptions de disponibilité du Wi-Fi

  • Interruptions de connexion du fournisseur de services Internet (FSI)

  • Correctifs de service

  • Déploiements de services

  • Service Auto Scaling

  • Service hôte non disponible

  • Problèmes et mises à jour de l'équilibreur de charge

  • Erreurs côté du client

Vos appareils doivent mettre en œuvre des stratégies pour détecter les déconnexions et les reconnexions. Pour plus d'informations sur les événements de déconnexion et des conseils sur la façon de les gérer, consultez Événements de connexion/déconnexion àÉvénements du cycle de vie.