Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Gerätekommunikationsprotokolle
AWS IoT Core unterstützt Geräte und Clients, die die Protokolle MQTT und MQTT over WebSocket Secure (WSS) verwenden, um Nachrichten zu veröffentlichen und zu abonnieren, sowie Geräte und Clients, die das HTTPS-Protokoll zum Veröffentlichen von Nachrichten verwenden. Alle Protokolle unterstützen IPv4 und. IPv6 In diesem Abschnitt werden die verschiedenen Verbindungsoptionen für Geräte und Kunden beschrieben.
## TLS-Protokollversionen
AWS IoT Core verwendet [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) [Version 1.2](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2) und [TLS Version 1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3), um die gesamte Kommunikation zu verschlüsseln. Sie können zusätzliche TLS-Richtlinienversionen für Ihren Endpunkt konfigurieren, indem Sie die [TLS-Einstellungen in den Domänenkonfigurationen konfigurieren](https://docs.aws.amazon.com//iot/latest/developerguide/iot-endpoints-tls-config.html). [Beim Verbinden von Geräten mit können Clients die [Server Name Indication (SNI) -Erweiterung](https://tools.ietf.org/html/rfc3546#section-3.1) senden, die für Funktionen wie die [Registrierung mehrerer Konten](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html#multiple-account-cert), [konfigurierbare Endpunkte, [benutzerdefinierte Domänen](https://docs.aws.amazon.com//iot/latest/developerguide/iot-custom-endpoints-configurable-custom.html) und VPC-Endpunkte](https://docs.aws.amazon.com//iot/latest/developerguide/iot-custom-endpoints-configurable.html) erforderlich ist. AWS IoT Core](https://docs.aws.amazon.com//iot/latest/developerguide/IoTCore-VPC.html) Weitere Informationen finden Sie unter [Transportsicherheit in AWS IoT](transport-security.html).
[AWS IoT Gerät SDKs](iot-connect-devices.md#iot-connect-device-sdks) unterstützen MQTT und MQTT over WSS und unterstützen die Sicherheitsanforderungen von Client-Verbindungen. Wir empfehlen die Verwendung von [AWS IoT Gerät SDKs](iot-connect-devices.md#iot-connect-device-sdks), um Clients mit dem AWS IoT zu verbinden.
## Protokolle, Port-Zuweisungen und Authentifizierung
[Wie ein Gerät oder ein Client eine Verbindung zum Message Broker herstellt, kann mithilfe eines Authentifizierungstyps konfiguriert werden.](#connection-protocol-auth-mode) Standardmäßig oder wenn keine SNI-Erweiterung gesendet wird, basiert die Authentifizierungsmethode auf dem Anwendungsprotokoll, dem Port und der TLS-Erweiterung Application Layer Protocol Negotiation (ALPN), die Geräte verwenden. In der folgenden Tabelle ist die erwartete Authentifizierung auf der Grundlage von Port, Port und ALPN aufgeführt.
**Protokolle, Authentifizierung und Port-Zuweisungen**
| Protocol (Protokoll) | Unterstützte Operationen | Authentifizierung | Port | ALPN-Protokollname |
| --- | --- | --- | --- | --- |
| MQTT über WebSocket | Veröffentlichen, Abonnieren | Signaturversion 4 | 443 | – |
| MQTT vorbei WebSocket | Veröffentlichen, Abonnieren | Benutzerdefinierte Authentifizierung | 443 | – |
| MQTT | Veröffentlichen, Abonnieren | X.509-Clientzertifikat | 443† | `x-amzn-mqtt-ca` |
| MQTT | Veröffentlichen, Abonnieren | X.509-Clientzertifikat | 8883 | – |
| MQTT | Veröffentlichen, Abonnieren | Benutzerdefinierte Authentifizierung | 443† | `mqtt` |
| HTTPS | Nur veröffentlichen | Signaturversion 4 | 443 | – |
| HTTPS | Nur veröffentlichen | X.509-Clientzertifikat | 443† | `x-amzn-http-ca` |
| HTTPS | Nur veröffentlichen | X.509-Clientzertifikat | 8443 | – |
| HTTPS | Nur veröffentlichen | Benutzerdefinierte Authentifizierung | 443 | – |
**ALPN (Application Layer Protocol Negotiation)**
† Bei Verwendung von Standard-Endpunktkonfigurationen müssen Clients, die sich über Port 443 mit X.509-Client-Zertifikatsauthentifizierung verbinden, die TLS-Erweiterung [Application Layer Protocol Negotiation (ALPN)](https://tools.ietf.org/html/rfc7301) implementieren und den [ALPN-Protokollnamen](https://tools.ietf.org/html/rfc7301#section-3.1) verwenden, der in der vom Client ProtocolNameList gesendeten ALPN als Teil der Nachricht aufgeführt ist. `ClientHello`
[Auf Port 443 unterstützt der [IoT:Data-ATS-Endpunkt x-amzn-http-ca ALPN-HTTP, der IoT:Jobs-Endpunkt](iot-connect-devices.md#iot-connect-device-endpoint-table) jedoch nicht.](iot-connect-devices.md#iot-connect-device-endpoint-table)
[Auf Port 8443 HTTPS und Port 443 MQTT mit ALPN kann die benutzerdefinierte Authentifizierung nicht verwendet werden. x-amzn-mqtt-ca](custom-authentication.md)
Clients stellen eine Verbindung zu ihren Geräteendpunkten AWS-Konto her. Informationen darüber, wie Sie die Geräteendpunkte Ihres Kontos finden, finden Sie unter [AWS IoT Gerätedaten und Dienstendpunkte](iot-connect-devices.md#iot-connect-device-endpoints).
**Anmerkung**
AWS SDKs benötigen nicht die gesamte URL. Sie benötigen nur den Endpunkt-Hostnamen, z. B. das [`pubsub.py`Beispiel für AWS IoT Device SDK for Python on GitHub](https://github.com/aws/aws-iot-device-sdk-python-v2/blob/master/samples/pubsub.py#L100). Wenn Sie die gesamte URL wie in der folgenden Tabelle aufgeführt übergeben, kann dies zu einem Fehler wie einem ungültigen Hostnamen führen.
**Verbindung herstellen zu AWS IoT Core**
| Protocol (Protokoll) | Endpunkt oder URL |
| --- | --- |
| MQTT | `iot-endpoint` |
| MQTT over WSS | `wss://iot-endpoint/mqtt` |
| HTTPS | `https://iot-endpoint/topics` |
## Wählen Sie ein Anwendungsprotokoll für Ihre Gerätekommunikation
Für den Großteil der IoT-Gerätekommunikation über die Geräteendpunkte sollten Sie die Protokolle Secure MQTT oder MQTT over WebSocket Secure (WSS) verwenden. Die Geräteendpunkte unterstützen jedoch auch HTTPS.
In der folgenden Tabelle wird verglichen, wie die beiden High-Level-Protokolle (MQTT und HTTPS) für die Gerätekommunikation AWS IoT Core verwendet werden.
**AWS IoT Geräteprotokolle (MQTT und HTTPS) side-by-side**
| Funktion | [MQTT](mqtt.md) | [HTTPS](http.md) |
| --- | --- | --- |
| Unterstützung von Veröffentlichen/Abonnieren | Veröffentlichen und Abonnieren | Nur veröffentlichen |
| SDK-Unterstützung | [AWS Geräte SDKs](iot-connect-devices.md#iot-connect-device-sdks) unterstützen die Protokolle MQTT und WSS | Keine SDK-Unterstützung, aber Sie können sprachspezifische Methoden verwenden, um HTTPS-Anfragen zu stellen |
| Qualität der Service-Unterstützung | [MQTT QoS Stufen 0 und 1](mqtt.md#mqtt-qos) | QoS wird durch die Übergabe eines Abfragezeichenfolge-Parameter ?qos=qos unterstütz, dessen Wert 0 oder 1 sein kann. Sie können diese Abfragezeichenfolge hinzufügen, um eine Nachricht mit dem gewünschten QoS-Wert zu veröffentlichen. |
| Können empfangene Nachrichten verpasst werden, während das Gerät offline war | Ja | Nein |
| Unterstützung von `clientId`-Feldern | Ja | Nein |
| Erkennung von Geräteunterbrechungen | Ja | Nein |
| Sichere Kommunikationen | Ja. Siehe [Protokolle, Port-Zuweisungen und Authentifizierung](#protocol-mapping) | Ja. Siehe [Protokolle, Port-Zuweisungen und Authentifizierung](#protocol-mapping) |
| Themendefinitionen | Anwendung definiert | Anwendung definiert |
| Format der Nachrichtendaten | Anwendung definiert | Anwendung definiert |
| Protokoll-Overhead | Niedriger | Höher |
| Stromverbrauch | Niedriger | Höher |
## Wählen Sie einen Authentifizierungstyp für Ihre Gerätekommunikation
Sie können den Authentifizierungstyp für Ihren IoT-Endpunkt mithilfe konfigurierbarer Endpunkte konfigurieren. Verwenden Sie alternativ die Standardkonfiguration und legen Sie fest, wie sich Ihre Geräte mit der Kombination aus Anwendungsprotokoll, Port und ALPN TLS-Erweiterung authentifizieren. Der von Ihnen gewählte Authentifizierungstyp bestimmt, wie sich Ihre Geräte authentifizieren, wenn sie eine Verbindung herstellen. AWS IoT Core Es gibt fünf Authentifizierungstypen:
**X.509-Zertifikat enthalten**
Authentifizieren Sie Geräte mithilfe von [X.509-Client-Zertifikaten](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html), wodurch die Authentifizierung des AWS IoT Core Geräts bestätigt wird. Dieser Authentifizierungstyp funktioniert mit den Protokollen Secure MQTT (MQTT over TLS) und HTTPS.
**X.509-Zertifikat mit benutzerdefiniertem Authorizer**
Authentifizieren Sie Geräte mithilfe von [X.509-Client-Zertifikaten](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html) und führen Sie zusätzliche Authentifizierungsaktionen mit einem [benutzerdefinierten Authorizer](https://docs.aws.amazon.com//iot/latest/developerguide/config-custom-auth.html) durch, der X.509-Client-Zertifikatsinformationen empfängt. Dieser Authentifizierungstyp funktioniert mit den Protokollen Secure MQTT (MQTT over TLS) und HTTPS. Dieser Authentifizierungstyp ist nur mit konfigurierbaren Endpunkten mit benutzerdefinierter X.509-Authentifizierung möglich. Es gibt keine ALPN-Option.
**AWS Signatur Version 4 (SigV4)**
Authentifizieren Sie Geräte mit Cognito oder Ihrem Backend-Service und unterstützen Sie so den Verbund von sozialen Netzwerken und Unternehmen. Dieser Authentifizierungstyp funktioniert mit den Protokollen MQTT over WebSocket Secure (WSS) und HTTPS.
**Benutzerdefinierter Autorisierer**
Authentifizieren Sie Geräte, indem Sie eine Lambda-Funktion konfigurieren, um benutzerdefinierte Authentifizierungsinformationen zu verarbeiten, an die gesendet werden. AWS IoT Core Dieser Authentifizierungstyp funktioniert mit den Protokollen Secure MQTT (MQTT over TLS), HTTPS und MQTT over WebSocket Secure (WSS).
**Standard**
Authentifizieren Sie Geräte auf der Grundlage der von den Geräten verwendeten ALPN-Erweiterung (Port and/or Application Layer Protocol Negotiation). Einige zusätzliche Authentifizierungsoptionen werden nicht unterstützt. Weitere Informationen finden Sie unter [Protokolle, Port-Zuweisungen und Authentifizierung](#protocol-mapping).
Die folgende Tabelle zeigt alle unterstützten Kombinationen von Authentifizierungstypen und Anwendungsprotokollen.
**Unterstützte Kombinationen von Authentifizierungstypen und Anwendungsprotokollen**
| Authentifizierungstyp | Sicheres MQTT (MQTT über TLS) | MQTT über WebSocket Secure (WSS) | HTTPS | Standard |
| --- | --- | --- | --- | --- |
| X.509-Zertifikat enthalten | ✓ | | ✓ | |
| X.509-Zertifikat mit benutzerdefiniertem Authorizer | ✓ | | ✓ | |
| AWS Signatur Version 4 (Sigv4) | | ✓ | ✓ | |
| Benutzerdefinierter Autorisierer | ✓ | ✓ | ✓ | |
| Standard | | | | ✓ |
## Einschränkungen der Verbindungsdauer
Es kann nicht garantiert werden, dass HTTPS-Verbindungen länger dauern als die Zeit, die für den Empfang und die Beantwortung von Anfragen benötigt wird.
Die Dauer der MQTT-Verbindung ist von der Authentifizierungsfunktion abhängig, die Sie verwenden. In der folgenden Tabelle ist die maximale Verbindungsdauer unter idealen Bedingungen für jede Funktion aufgeführt.
**MQTT-Verbindungsdauer nach Authentifizierungsfunktion**
| Feature | Maximale Dauer \$1 |
| --- | --- |
| X.509-Clientzertifikat | 1 bis 2 Wochen |
| Benutzerdefinierte Authentifizierung | 1 bis 2 Wochen |
| Signaturversion 4 | Bis zu 24 Stunden |
\$1 Nicht garantiert
Mit X.509-Zertifikaten und benutzerdefinierter Authentifizierung gibt es keine feste Grenze für die Verbindungsdauer, sie kann jedoch auch nur wenige Minuten lang sein. Verbindungsunterbrechungen können aus verschiedenen Gründen auftreten. Die folgende Liste enthält einige der gängigsten Gründe.
+ Unterbrechungen der Wi-Fi-Verfügbarkeit
+ Verbindungsunterbrechungen des Internetdienstanbieters (ISP)
+ Service-Patches
+ Dienstbereitstellungen
+ Service Auto Scaling
+ Nicht verfügbarer Dienst-Host
+ Load Balancer-Probleme und -Aktualisierungen
+ Client-seitige Fehler
Ihre Geräte müssen Strategien zur Erkennung von Verbindungsabbrüchen und zur Wiederherstellung der Verbindung implementieren. Informationen zu Trennungsereignissen und Anleitungen, wie Sie damit umgehen können, finden Sie in [Ereignisse im Lebenszyklus](life-cycle-events.md) unter [„Verbinden/Verbindung trennen“-Ereignisse](life-cycle-events.md#connect-disconnect).
# MQTT
[MQTT](http://mqtt.org/) (Message Queuing Telemetry Transport) ist ein einfaches, weit verbreitetes Messaging-Protokoll, das für eingeschränkte Geräte konzipiert ist. AWS IoT Core Unterstützung für MQTT basiert auf der [MQTT-Spezifikation v3.1.1](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) und [v5.0](http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html), mit einigen Unterschieden, wie in [AWS IoT Unterschiede zu den MQTT-Spezifikationen](#mqtt-differences) dokumentiert. MQTT 5, die neueste Version des Standards, führt mehrere wichtige Funktionen ein, die ein MQTT-basiertes System robuster machen. Dazu gehören Verbesserungen der Skalierbarkeit, eine verbesserte Fehlerberichterstattung mit Reason-Code-Antworten, Timer für den Ablauf von Meldungen und Sitzungen sowie benutzerdefinierte Header für Benutzermeldungen. Weitere Informationen zu den Funktionen, die MQTT 5 AWS IoT Core unterstützen, finden Sie unter Von [MQTT 5 unterstützte](#mqtt5) Funktionen. AWS IoT Core unterstützt auch die Kommunikation zwischen MQTT-Versionen (MQTT 3 und MQTT 5). Ein MQTT-3-Publisher kann eine MQTT-3-Meldung an einen MQTT-5-Subscriber senden, der eine MQTT-5-Publish-Meldung erhält, und umgekehrt.
AWS IoT Core *unterstützt Geräteverbindungen, die das MQTT-Protokoll und das MQTT-over-WSS-Protokoll verwenden und die durch eine Client-ID identifiziert werden.* [AWS IoT Gerät SDKs](iot-connect-devices.md#iot-connect-device-sdks) unterstützen beide Protokolle und sind die empfohlenen Verbindungsmethoden für Geräte zu AWS IoT Core Das AWS IoT Gerät SDKs unterstützt die Funktionen, die Geräte und Clients benötigen, um eine Verbindung zu Diensten herzustellen und auf sie zuzugreifen AWS IoT . Das Gerät SDKs unterstützt die Authentifizierungsprotokolle, die für die AWS IoT Dienste erforderlich sind, und die Verbindungs-ID-Anforderungen, die für das MQTT-Protokoll und die Protokolle MQTT over WSS erforderlich sind. Informationen darüber, wie Sie AWS IoT mithilfe des AWS Geräts eine Verbindung herstellen können, SDKs sowie Links zu Beispielen AWS IoT in den unterstützten Sprachen finden Sie unter. [Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs](#mqtt-sdk) Weitere Informationen zu Authentifizierung und Portzuordnungen für MQTT-Meldungen unter [Protokolle, Port-Zuweisungen und Authentifizierung](protocols.md#protocol-mapping).
Wir empfehlen zwar, das AWS IoT Gerät SDKs für die Verbindung zu verwenden AWS IoT, sie sind jedoch nicht erforderlich. Wenn Sie das AWS IoT Gerät jedoch nicht verwenden SDKs, müssen Sie für die erforderliche Verbindungs- und Kommunikationssicherheit sorgen. Clients müssen auch die [Server Name Indication (SNI)-TLS-Erweiterung](https://tools.ietf.org/html/rfc3546#section-3.1) in der Verbindungsanforderung senden. Verbindungsversuche, die das SNI nicht enthalten, werden abgelehnt. Weitere Informationen finden Sie unter [Transportsicherheit in AWS IoT](transport-security.html). Clients, die IAM-Benutzer und AWS Anmeldeinformationen zur Authentifizierung von Clients verwenden, müssen die richtige [Signature Version 4-Authentifizierung](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) bereitstellen.
Nachdem Ihre Clients verbunden sind, können Sie ihre MQTT-Clientverbindungen mithilfe von überwachen und verwalten. APIs Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
**Topics**
+ [
## Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs
](#mqtt-sdk)
+ [
## MQTT QoS-(Quality of Service)-Optionen
](#mqtt-qos)
+ [
## Persistente MQTT-Sitzungen
](#mqtt-persistent-sessions)
+ [
## Beibehaltene MQTT-Meldungen
](#mqtt-retain)
+ [
## MQTT-Meldungen des letzten Willens und Testaments (LWT)
](#mqtt-lwt)
+ [
## ConnectAttributes verwenden
](#connect-attribute)
+ [
## Von MQTT 5 unterstützte Funktionen
](#mqtt5)
+ [
## MQTT 5 Eigenschaften
](#mqtt5-properties)
+ [
## MQTT-Ursachencodes
](#mqtt5-reason-codes)
+ [
## AWS IoT Unterschiede zu den MQTT-Spezifikationen
](#mqtt-differences)
+ [
## Verwaltung von MQTT-Verbindungen
](#mqtt-client-disconnect)
## Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs
Dieser Abschnitt enthält Links zum AWS IoT Gerät SDKs und zum Quellcode von Beispielprogrammen, die veranschaulichen, wie ein Gerät angeschlossen AWS IoT wird. Die hier verlinkten Beispiel-Apps zeigen, wie Sie AWS IoT mithilfe des MQTT-Protokolls und MQTT über WSS eine Verbindung herstellen können.
**Anmerkung**
Das AWS IoT Gerät SDKs hat einen MQTT 5-Client veröffentlicht.
------
#### [ C\$1\$1 ]
**Verwenden des AWS IoT C\$1\$1-Geräte-SDK zum Verbinden von Geräten**
+ [Quellcode einer App, als Beispiel für eine MQTT-Verbindung in C\$1\$1](https://github.com/aws/aws-iot-device-sdk-cpp-v2/blob/main/samples/mqtt/basic_connect/main.cpp)
+ [AWS IoT Geräte-SDK SDK for C\$1\$1 v2 auf GitHub](https://github.com/aws/aws-iot-device-sdk-cpp-v2)
------
#### [ Python ]
**Geräte mit dem AWS IoT Device SDK für Python verbinden**
+ [Quellcode einer App, als Beispiel für eine MQTT-Verbindung in Python](https://github.com/aws/aws-iot-device-sdk-python-v2/blob/master/samples/pubsub.py)
+ [AWS IoT Geräte-SDK v2 für Python auf GitHub](https://github.com/aws/aws-iot-device-sdk-python-v2)
------
#### [ JavaScript ]
**Verwenden des AWS IoT Geräte-SDK JavaScript zum Verbinden von Geräten**
+ [Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in zeigt JavaScript](https://github.com/aws/aws-iot-device-sdk-js-v2/blob/master/samples/node/pub_sub/index.ts)
+ [AWS IoT Geräte-SDK für JavaScript Version 2 auf GitHub](https://github.com/aws/aws-iot-device-sdk-js-v2)
------
#### [ Java ]
**Geräte mit dem AWS IoT Device SDK for Java verbinden**
**Anmerkung**
Das AWS IoT Device SDK for Java v2 unterstützt jetzt die Android-Entwicklung. Weitere Informationen finden Sie unter [AWS IoT Geräte-SDK SDK for Android](https://github.com/aws/aws-iot-device-sdk-java-v2/blob/main/documents/ANDROID.md).
+ [Quellcode einer App, die ein Beispiel für eine MQTT-Verbindung in Java zeigt](https://github.com/aws/aws-iot-device-sdk-java-v2/blob/master/samples/BasicPubSub/src/main/java/pubsub/PubSub.java)
+ [AWS IoT Geräte-SDK SDK for Java v2 auf GitHub](https://github.com/aws/aws-iot-device-sdk-java-v2)
------
#### [ Embedded C ]
**Verwenden Sie das AWS IoT Geräte-SDK für Embedded C, um Geräte zu verbinden**
**Wichtig**
Dieses SDK ist für die Verwendung durch erfahrene Entwickler eingebetteter Software vorgesehen.
+ [Quellcode einer App, die ein Beispiel für eine MQTT-Verbindung in Embedded C zeigt](https://github.com/aws/aws-iot-device-sdk-embedded-C/blob/master/demos/mqtt/mqtt_demo_basic_tls/mqtt_demo_basic_tls.c)
+ [AWS IoT Geräte-SDK für Embedded C aktiviert GitHub](https://github.com/aws/aws-iot-device-sdk-embedded-C)
------
## MQTT QoS-(Quality of Service)-Optionen
AWS IoT und das AWS IoT Gerät SDKs unterstützt die [MQTT Quality of Service (QoS) -Levels `0`](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349263) und. `1` Das MQTT-Protokoll definiert eine dritte Ebene von QoS, Ebene`2`, unterstützt AWS IoT diese jedoch nicht. Nur das MQTT-Protokoll unterstützt die QoS-Funktion. HTTPS unterstützt QoS, indem es einen Abfragezeichenfolge-Parameter `?qos=qos` übergibt, sein Wert kann 0 oder 1 sein.
Die Tabelle beschreibt, wie sich jede QoS-Stufe auf Meldungen auswirkt, die an und von Message Broker veröffentlicht werden.
| Mit einem QoS-Level von ... | Die Meldung ist … | Kommentare |
| --- | --- | --- |
| QoS Stufe 0 | Null oder mehr Mal gesendet | Diese Stufe sollte für Meldungen verwendet werden, die über zuverlässige Kommunikationsverbindungen gesendet werden oder die problemlos übersehen werden können. |
| QoS Stufe 1 | Mindestens einmal gesendet und dann wiederholt, bis eine `PUBACK` Antwort eingeht. | Die Meldung gilt erst dann als vollständig, wenn der Absender eine `PUBACK` Antwort erhält, die auf eine erfolgreiche Zustellung hinweist. |
## Persistente MQTT-Sitzungen
Persistente Sitzungen speichern Abonnements und Meldungen eines Kunden mit einer Quality of Service (QoS) von 1, sofern diese nicht vom Kunden bestätigt wurden. Wenn das Gerät wieder eine Verbindung zu einer dauerhaften Sitzung herstellt, wird die Sitzung wieder aufgenommen, Abonnements werden wieder hergestellt und unbestätigte abonnierte Meldungen, die vor der Wiederverbindung empfangen und gespeichert wurden, werden an den Client gesendet.
Die Verarbeitung der gespeicherten Nachrichten wird in CloudWatch Metriken und Protokollen aufgezeichnet. CloudWatch Informationen zu den Einträgen, in die geschrieben wurde, CloudWatch und zu den CloudWatch Protokollen finden Sie unter [Message Broker-Metriken](metrics_dimensions.md#message-broker-metrics) und[Protokolleintrag in der Warteschlange](cwl-format.md#log-mb-queued).
### Erstellen einer persistenten Sitzung
Erstellen Sie in MQTT 3 eine persistente MQTT-Sitzung, indem Sie eine `CONNECT`Meldung versenden und das `cleanSession` Flag auf `0` festlegen. Wenn für den Client, der die `CONNECT`-Meldung versendet, keine Sitzung vorhanden ist, wird eine neue persistente Sitzung erstellt. Wenn für den Client bereits eine Sitzung existiert, nimmt der Client die bestehende Sitzung wieder auf. Um eine saubere Sitzung zu erstellen, senden Sie eine `CONNECT` Meldung und setzen das `cleanSession` Flag auf `1`. Der Broker speichert dann keinen Sitzungsstatus, wenn der Client die Verbindung trennt.
In MQTT 5 behandeln Sie persistente Sitzungen, indem Sie das `Clean Start` Flag und `Session Expiry Interval` festlegen. Clean Start steuert den Beginn der Verbindungssitzung und das Ende der vorherigen Sitzung. Wenn Sie `Clean Start` = `1` setzen, wird eine neue Sitzung erstellt und eine vorherige Sitzung wird beendet, falls sie existiert. Wenn Sie `Clean Start` = `0` setzen, nimmt die Verbindungssitzung eine vorherige Sitzung wieder auf, falls sie existiert. Das Sitzungsablaufintervall bestimmt das Ende der Verbindungssitzung. Das Sitzungsablaufintervall gibt die Zeit in Sekunden (4-Byte-Ganzzahl) an, für die eine Sitzung nach der Trennung bestehen bleibt. Einstellung `Session Expiry interval` = `0` bewirkt, dass die Sitzung sofort nach der Trennung beendet wird. Wenn das Sitzungsablaufintervall nicht in der CONNECT-Meldung angegeben ist, ist der Standardwert 0.
**MQTT 5 Clean Start und Ablauf der Sitzung**
| Eigenschaftenwert | Description |
| --- | --- |
| Clean Start= 1 | Erzeugt eine neue Sitzung und beendet eine vorherige Sitzung, falls eine existiert. |
| Clean Start= 0 | Nimmt eine Sitzung wieder auf, falls eine vorherige Sitzung existiert. |
| Session Expiry Interval> 0 | Hält eine Sitzung aufrecht. |
| Session Expiry interval= 0 | Behält eine Sitzung nicht bei. |
Wenn Sie in MQTT 5 `Clean Start` = `1` und `Session Expiry Interval` = `0` setzen, entspricht dies einer sauberen MQTT-3-Sitzung. Wenn Sie `Clean Start` = `0` und `Session Expiry Interval` >`0` setzen, entspricht dies einer persistenten MQTT-3-Sitzung.
**Anmerkung**
MQTT-übergreifende (MQTT 3 und MQTT 5) persistente Sitzungen werden nicht unterstützt. Eine persistente MQTT 3-Sitzung kann nicht als MQTT 5-Sitzung wieder aufgenommen werden und umgekehrt.
### Operationen während einer persistenten Sitzung
Clients müssen das `sessionPresent`-Attribut in der Connection Acknowledged (`CONNACK`)-Meldung nutzen, um festzustellen, ob eine persistente Sitzung vorhanden ist. Wenn `sessionPresent` auf `1` gesetzt ist, liegt eine persistente Sitzung vor und alle gespeicherten Meldungen für den Client werden an den Client zugestellt, nachdem der Client `CONNACK` empfangen hat, wie unter [Meldungsverkehr nach Wiederverbindung mit einer persistenten](#persistent-session-reconnect) Sitzung beschrieben. Wenn `sessionPresent` auf `1` gesetzt ist, muss der Client kein erneutes Abonnement abschließen. Wenn `sessionPresent` auf `0` gesetzt ist, ist keine persistente Sitzung vorhanden, und der Client muss die Themenfilter erneut abonnieren.
Nachdem der Client der persistenten Sitzung beigetreten ist, kann er weiterhin Meldungen veröffentlichen und Themenfilter ohne zusätzliche Flags für jede Maßnahme abonnieren.
### Meldungsverkehr nach Wiederverbindung zu einer persistenten Sitzung
Eine persistente Sitzung stellt eine fortlaufende Verbindung zwischen einem Client und einem MQTT-Message Broker dar. Wenn ein Client eine Verbindung mit dem Message Broker über eine persistente Sitzung herstellt, speichert der Message Broker alle Abonnements, die der Client während der Verbindung erstellt. Wenn der Client getrennt wird, speichert der Message Broker unbestätigte QoS 1-Meldungen und neue QoS 1-Meldungen, die zu Themen veröffentlicht wurden, die der Client abonniert hat. Meldungen werden gemäß dem Kontolimit gespeichert. Meldungen, die das Limit überschreiten werden gelöscht. Weitere Informationen zu persistenten Nachrichtenlimits finden Sie unter [AWS IoT Core Endpunkte und Kontingente](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits). Wenn der Client die Verbindung zur persistenten Sitzung wiederherstellt, werden alle Abonnements reaktiviert und alle gespeicherten Meldungen werden bei einer maximalen Rate von 10 Meldungen pro Sekunde an den Client gesendet. Wenn in MQTT 5 eine ausgehende QoS 1-Verbindung mit dem Nachrichtenablaufintervall abläuft, wenn ein Client offline ist, empfängt der Client nach der Wiederaufnahme der Verbindung die abgelaufene Nachricht nicht.
Nach der Wiederverbindung werden die gespeicherten Meldungen an den Client gesendet, und zwar mit einer Geschwindigkeit, die auf 10 gespeicherte Meldungen pro Sekunde begrenzt ist, zusammen mit dem aktuellen Meldungsverkehr, bis das [https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits)-Limit erreicht ist. Da die Zustellungsrate der gespeicherten Meldungen begrenzt ist, dauert es mehrere Sekunden, bis alle gespeicherten Meldungen zugestellt werden, wenn in einer Sitzung nach der Wiederverbindung mehr als 10 gespeicherte Meldungen zugestellt werden müssen.
Bei geteilten Abonnenten werden Nachrichten in die Warteschlange gestellt, wenn mindestens ein Abonnent einer Gruppe eine persistente Sitzung verwendet und keine Abonnenten online sind, um die QoS 1-Nachricht zu empfangen. Das Löschen von Nachrichten aus der Warteschlange erfolgt mit einer maximalen Geschwindigkeit von 20 Nachrichten pro Sekunde pro aktivem Abonnenten in einer Gruppe. Weitere Informationen finden Sie unter [Nachrichtenwarteschlange für gemeinsame Abonnements](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt5-shared-subscription-queuing).
### Eine persistente Sitzung wird beendet.
Dauerhafte Sitzungen können wie folgt enden:
+ Die Ablaufzeit der persistenten Sitzung ist abgelaufen. Der Timer für den Ablauf einer persistenten Sitzung wird gestartet, wenn der Message Broker feststellt, dass ein Client die Verbindung getrennt hat, entweder weil der Client die Verbindung getrennt hat oder weil die Verbindung das Timeout überschritten hat.
+ Der Client sendet eine `CONNECT` Nachricht, die das `cleanSession` Flag auf `1` setzt.
+ Sie trennen den Client manuell und löschen die Sitzung mithilfe der `DeleteConnection` API. Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
In MQTT 3 ist der Standardwert für die Ablaufzeit persistenter Sitzungen eine Stunde, und dies gilt für alle Sitzungen im Konto.
In MQTT 5 können Sie das Sitzungsablaufintervall für jede Sitzung in den Paketen CONNECT und DISCONNECT festlegen.
Für das Sitzungsablaufintervall für das DISCONNECT-Paket:
+ Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von 0 hat, können Sie das Sitzungsablaufintervall für das DISCONNECT-Paket nicht auf einen Wert über 0 setzen.
+ Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von mehr als 0 hat und Sie das Sitzungsablaufintervall im DISCONNECT-Paket auf 0 setzen, wird die Sitzung auf DISCONNECT beendet.
+ Andernfalls aktualisiert das Sitzungsablaufintervall für das DISCONNECT-Paket das Sitzungsablaufintervall der aktuellen Sitzung.
**Anmerkung**
Die gespeicherten Meldungen, die darauf warten, am Ende einer Sitzung an den Client gesendet zu werden, werden verworfen. Sie werden jedoch weiterhin zum Standardnachrichtentarif in Rechnung gestellt, obwohl sie nicht gesendet werden konnten. Weitere Informationen zu Preisen erhalten Sie unter [AWS IoT Core Preise](https://aws.amazon.com/iot-core/pricing). Sie können das Ablaufzeitintervall konfigurieren.
### Wiederverbindung nach Ablauf einer persistenten Sitzung
Wenn ein Client vor Ablauf nicht wieder eine Verbindung zu seiner persistenten Sitzung herstellt, wird die Sitzung beendet und die gespeicherten Meldungen werden verworfen. Wenn ein Client nach Ablauf der Sitzung wieder eine Verbindung herstellt und das `cleanSession`-Flag auf `0` setzt, erstellt der Dienst eine neue persistente Sitzung. Alle Abonnements oder Meldungen aus der vorherigen Sitzung sind für diese Sitzung nicht verfügbar, da sie beim Ablauf der vorherigen Sitzung verworfen wurden.
### Gebühren für Meldungen während einer dauerhaften Sitzung
Nachrichten werden Ihnen in Rechnung gestellt AWS-Konto , wenn der Message Broker eine Nachricht an einen Client oder eine persistente Offline-Sitzung sendet. Wenn ein Offline-Gerät mit einer dauerhaften Sitzung erneut eine Verbindung herstellt und seine Sitzung wieder aufnimmt, werden die gespeicherten Meldungen an das Gerät übermittelt und Ihrem Konto erneut belastet. Weitere Informationen zu den Preisen für Meldungen finden Sie unter [AWS IoT Core Preise – Meldungsübermittlung](https://aws.amazon.com/iot-core/pricing/#Messaging).
Die standardmäßige Ablaufzeit einer persistenten Sitzung von einer Stunde kann erhöht werden, indem das standardmäßige Verfahren zum Erhöhen von Limits verwendet wird. Beachten Sie, dass durch eine Verlängerung der Sitzungsablaufzeit Ihre Meldungsgebühren steigen können, da durch die zusätzliche Zeit mehr Meldungen für das Offline-Gerät gespeichert werden können und diese zusätzlichen Meldungen Ihrem Konto zum Standardnachrichtentarif in Rechnung gestellt würden. Bei der Ablaufzeit der Sitzung handelt es sich um einen ungefähren Wert, und eine Sitzung kann bis zu 30 Minuten länger als das Kontolimit andauern. Eine Sitzung darf das Kontolimit jedoch nicht unterschreiten. Weitere Informationen zu Sitzungslimits finden Sie unter [AWS -Service Quotas](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits).
## Beibehaltene MQTT-Meldungen
AWS IoT Core unterstützt das im MQTT-Protokoll beschriebene `RETAIN` Flag. Wenn ein Client das `RETAIN` Flag für eine MQTT-Nachricht setzt, die er veröffentlicht, wird die Nachricht AWS IoT Core gespeichert. Sie kann dann an neue Abonnenten gesendet, durch Aufrufen des [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html)Vorgangs abgerufen und in der [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#/retainedMessages) angezeigt werden.
**Beispiele für die Verwendung von gespeicherten MQTT-Meldungen**
+
**Als erste Konfigurationsnachricht**
In MQTT gespeicherte Meldungen werden an einen Client gesendet, nachdem der Client ein Thema abonniert hat. Wenn Sie möchten, dass alle Clients, die ein Thema abonnieren, die beibehaltene MQTT-Nachricht direkt nach ihrem Abonnement erhalten, können Sie eine Konfigurationsnachricht mit gesetztem `RETAIN` Flag veröffentlichen. Abonnierende Clients erhalten außerdem Updates für diese Konfiguration, wenn eine neue Konfigurationsnachricht veröffentlicht wird.
+
**Als letzte bekannte Zustandsmeldung**
Geräte können Nachrichten mit dem aktuellen Status `RETAIN` kennzeichnen, sodass sie gespeichert AWS IoT Core werden. Wenn Anwendungen eine Verbindung herstellen oder erneut eine Verbindung herstellen, können sie dieses Thema abonnieren und sofort nach dem Abonnieren des beibehaltenen Nachrichtenthemas den zuletzt gemeldeten Status abrufen. Auf diese Weise können sie vermeiden, dass sie bis zur nächsten Meldung vom Gerät warten müssen, um den aktuellen Status zu sehen.
**Topics**
+ [
### Allgemeine Aufgaben mit gespeicherten MQTT-Nachrichten in AWS IoT Core
](#mqtt-retain-using)
+ [
### Abrechnung und gespeicherte Meldungen
](#mqtt-retain-billing)
+ [
### Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen
](#mqtt-retain-persist)
+ [
### MQTT hat Nachrichten und Device Shadows gespeichert AWS IoT
](#mqtt-retain-shadow)
### Allgemeine Aufgaben mit gespeicherten MQTT-Nachrichten in AWS IoT Core
AWS IoT Core speichert MQTT-Nachrichten mit gesetztem `RETAIN` Flag. Diese *gespeicherten Meldungen* werden als normale MQTT-Meldung an alle Clients gesendet, die das Thema abonniert haben, und sie werden auch gespeichert, um an neue Abonnenten des Themas gesendet zu werden.
Archivierte MQTT-Meldungen erfordern spezifische Richtlinienaktionen, um Clients den Zugriff auf sie zu autorisieren. Beispiele für die Verwendung von Richtlinien für gespeicherte Meldungen finden Sie unter [Beispielrichtlinien für beibehaltene Nachrichten](retained-message-policy-examples.md).
In diesem Abschnitt werden allgemeine Vorgänge beschrieben, bei denen gespeicherte Meldungen verwendet werden.
+
**Erstellen einer beibehaltenen Nachricht**
Der Client bestimmt, ob eine Meldung beibehalten wird, wenn er eine MQTT-Meldung veröffentlicht. Clients können das `RETAIN` Flag setzen, wenn sie eine Nachricht veröffentlichen, indem sie ein [Geräte-SDK](iot-sdks.md) verwenden. Anwendungen und Dienste können das `RETAIN` Kennzeichen setzen, wenn sie die [`Publish`Aktion](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_Publish.html) zum Veröffentlichen einer MQTT-Nachricht verwenden.
Pro Themenname wird nur eine Meldung beibehalten. Eine neue Meldung mit gesetztem RETAIN-Flag, die zu einem Thema veröffentlicht wurde, ersetzt alle vorhandenen beibehaltenen Meldungen, die zuvor an das Thema gesendet wurden.
**Anmerkung**
Sie können nicht in einem [reservierten Thema](reserved-topics.md) veröffentlichen, wenn das `RETAIN` Kennzeichen gesetzt ist.
+
**Abonnieren eines beibehaltenen Meldungsthemas**
Kunden abonnieren Themen für beibehaltene Meldungen wie jedes andere MQTT-Meldungsthema. Für zurückbehaltene Nachrichten, die Sie erhalten haben, indem Sie ein Thema abonniert haben, ist dieses `RETAIN` Kennzeichen gesetzt.
Aufbewahrte Nachrichten werden gelöscht, AWS IoT Core sobald ein Client eine beibehaltene Nachricht mit einer 0-Byte-Nachrichtennutzlast zum Thema der beibehaltenen Nachricht veröffentlicht. Clients, die das beibehaltene Meldungsthema abonniert haben, erhalten auch die 0-Byte-Nachricht.
Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.
**Anmerkung**
Um bei einem Abonnement eine beibehaltene Nachricht zu erhalten, muss der Themenfilter in der Abonnementanforderung exakt dem Thema der beibehaltenen Nachricht entsprechen.
Bei gespeicherten Nachrichten, die beim Abonnieren eines Themas für eine beibehaltene Nachricht empfangen wurden, ist die `RETAIN` Markierung gesetzt. Bei gespeicherten Meldungen, die nach dem Abonnement von einem abonnierten Client empfangen werden, ist dies nicht der Fall.
+
**Eine beibehaltene Meldung wird abgerufen.**
Aufbewahrte Meldungen werden automatisch an Clients zugestellt, wenn sie das Thema mit der gespeicherten Meldung abonnieren. Damit ein Kunde die beibehaltene Meldung nach dem Abonnement erhalten kann, muss er den genauen Themennamen der gespeicherten Meldung abonnieren. Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.
Dienste und Apps können gespeicherte Meldungen auflisten und abrufen, indem sie [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_ListRetainedMessages.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_ListRetainedMessages.html)und [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html)aufrufen.
Ein Client kann nicht daran gehindert werden, Nachrichten zu einem beibehaltenen Nachrichtenthema zu veröffentlichen, *ohne die `RETAIN` Markierung zu* setzen. Dies kann zu unerwarteten Ergebnissen führen, z. B. dass die gespeicherte Meldung nicht mit der Meldung übereinstimmt, die durch das Abonnieren des Themas empfangen wurde.
Wenn bei MQTT 5 für eine beibehaltene Meldung das Meldungsablaufintervall festgelegt ist und die beibehaltene Meldung abläuft, erhält ein neuer Abonnent, der dieses Thema abonniert, die beibehaltene Meldung bei erfolgreichem Abonnement nicht.
+
**Themen der beibehaltenen Meldungen auflisten**
Sie können die gespeicherten Meldungen auflisten, indem Sie [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_ListRetainedMessages.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_ListRetainedMessages.html) telefonisch abrufen, und die gespeicherten Meldungen können in der [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#/retainedMessages) eingesehen werden.
+
**Details zu gespeicherten Meldungen abrufen**
Sie können die gespeicherten Meldungsdetails telefonisch unter [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html) abrufen, und sie können in der [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#/retainedMessages) angezeigt werden.
+
**Beibehaltung einer Willensnachricht**
[http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#_Will_Flag](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#_Will_Flag), die erstellt werden, wenn ein Gerät eine Verbindung herstellt, können beibehalten werden, indem das `Will Retain` Flag im `Connect Flag bits` Feld gesetzt wird.
+
**Löschen einer beibehaltenen Nachricht**
Geräte, Anwendungen und Dienste können eine beibehaltene Nachricht löschen, indem sie eine Nachricht veröffentlichen, bei der das `RETAIN` Kennzeichen gesetzt ist und eine leere Nachrichten-Payload (0 Byte) zum Themennamen der zu löschenden Nachricht hinzugefügt wird. Solche Nachrichten löschen die gespeicherte Nachricht von AWS IoT Core, werden an Clients gesendet, die das Thema abonniert haben, aber sie werden nicht von gespeichert. AWS IoT Core
Beibehaltene Meldungen können auch interaktiv gelöscht werden, indem Sie in der [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#/retainedMessages) auf die gespeicherte Meldung zugreifen. Archivierte Meldungen, die mithilfe der [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#/retainedMessages) gelöscht werden, senden auch eine 0-Byte-Meldung an Clients, die das Thema der gespeicherten Meldung abonniert haben.
Aufbewahrte Meldungen können nicht wiederhergestellt werden, nachdem sie gelöscht wurden. Ein Client müsste eine neue beibehaltene Meldung veröffentlichen, um die gelöschte Meldung zu ersetzen.
+
**Debuggen und Problembehandlung bei gespeicherten Meldungen**
Die [AWS IoT Konsole](https://console.aws.amazon.com//iot/home#) bietet mehrere Tools, mit denen Sie Fehler bei gespeicherten Meldungen beheben können:
+
**Die Seite „**[Zurückbehaltene Meldungen](https://console.aws.amazon.com//iot/home#/retainedMessages)**“**
Die Seite „**Zurückbehaltene Meldungen**“ in der AWS IoT Konsole enthält eine paginierte Liste der gespeicherten Meldungen, die von Ihrem Konto in der aktuellen Region gespeichert wurden. Auf dieser Seite können Sie:
+ Sehen Sie sich die Details jeder gespeicherten Meldung an, z. B. die Meldungsnutzlast, QoS und den Zeitpunkt, zu dem sie empfangen wurde.
+ Aktualisieren Sie den Inhalt einer gespeicherten Nachricht.
+ Löscht eine beibehaltene Nachricht.
+
**Der **[MQTT-Testclient](https://console.aws.amazon.com//iot/home#/test)****
Auf der **MQTT-Testclient-Seite** in der AWS IoT Konsole können MQTT-Themen abonniert und veröffentlicht werden. Mit der Veröffentlichungsoption können Sie das RETAIN-Flag für die von Ihnen veröffentlichten Meldungen setzen, um zu simulieren, wie sich Ihre Geräte verhalten könnten. Sie können den MQTT-Testclient auch verwenden, um Nachrichten von verbundenen Clients zu überwachen, die Sie über die Client-Verbindungsschnittstelle verwalten. Weitere Informationen zur Verwaltung von Client-Verbindungen finden Sie unter[Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
Einige unerwartete Ergebnisse können auf diese Aspekte der Implementierung von gespeicherten Nachrichten zurückzuführen sein AWS IoT Core.
+
**Beibehaltene Meldungslimits**
Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat, wird eine gedrosselte Antwort auf Nachrichten AWS IoT Core zurückgegeben, die mit aktiviertem RETAIN und Payloads von mehr als 0 Byte veröffentlicht wurden, bis einige der gespeicherten Nachrichten gelöscht wurden und die Anzahl der gespeicherten Nachrichten unter den Grenzwert fällt.
+
**Beibehaltene Reihenfolge der Meldungszustellung**
Die Reihenfolge zwischen beibehaltener und abonnierter Meldungszustellung kann nicht garantiert werden.
### Abrechnung und gespeicherte Meldungen
[Beim Veröffentlichen von Nachrichten mit `RETAIN` gesetztem Kennzeichen auf einem Client, über die AWS IoT Konsole oder durch einen Anruf [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_Publish.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_Publish.html)fallen zusätzliche Gebühren für Nachrichtenübermittlung an, die unter Preise — Messaging beschrieben sind.AWS IoT Core](https://aws.amazon.com//iot-core/pricing/#Messaging)
Für das Abrufen von gespeicherten Nachrichten durch einen Client, über die AWS IoT Konsole oder durch einen Anruf [https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_GetRetainedMessage.html)fallen zusätzlich zu den normalen API-Nutzungsgebühren Gebühren für Nachrichtenübermittlung an. Die zusätzlichen Gebühren sind unter [AWS IoT Core Preise – Meldungsübermittlung](https://aws.amazon.com//iot-core/pricing/#Messaging) beschrieben.
Für *Will*-Meldungen, die veröffentlicht werden, wenn die Verbindung zu einem Gerät unerwartet unterbrochen wird, fallen Gebühren für die Meldungsübermittlung an, die unter [AWS IoT Core Preise – Meldungsübermittlung](https://aws.amazon.com//iot-core/pricing/#Messaging) beschrieben sind.
Weitere Informationen zu den Messaging-Kosten finden Sie unter [AWS IoT Core Preise – Meldungsübermittlung](https://aws.amazon.com//iot-core/pricing/#Messaging).
### Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen
Aufbewahrte Meldungen und persistente Sitzungen sind Standardfunktionen von MQTT, die es Geräten ermöglichen, Meldungen zu empfangen, die veröffentlicht wurden, während sie offline waren. Aufbewahrte Meldungen können aus persistenten Sitzungen heraus veröffentlicht werden. In diesem Abschnitt werden die wichtigsten Aspekte dieser Funktionen und ihr Zusammenspiel beschrieben.
| | Beibehaltene Meldungen | Persistente MQTT-Sitzungen |
| --- | --- | --- |
| **Schlüssel-Features** | Aufbewahrte Meldungen können verwendet werden, um große Gruppen von Geräten zu konfigurieren oder zu benachrichtigen, nachdem sie eine Verbindung hergestellt haben. Aufbewahrte Meldungen können auch verwendet werden, wenn Geräte nach einer erneuten Verbindung nur die zuletzt zu einem Thema veröffentlichte Meldung empfangen sollen. | Dauerhafte Sitzungen sind nützlich für Geräte, deren Konnektivität unterbrochen ist und bei denen möglicherweise mehrere wichtige Meldungen übersehen werden. Geräte können sich mit einer dauerhaften Sitzung verbinden, um Meldungen zu empfangen, die gesendet werden, während sie offline sind. |
| **Beispiele** | Gespeicherte Meldungen können Geräten Konfigurationsinformationen über ihre Umgebung geben, wenn sie online gehen. Die Erstkonfiguration könnte eine Liste anderer Meldungsthemen enthalten, die das Gerät abonnieren sollte, oder Informationen darüber, wie es seine lokale Zeitzone konfigurieren sollte. | Geräte, die über ein Mobilfunknetz mit intermittierender Konnektivität eine Verbindung herstellen, könnten persistente Sitzungen verwenden, um zu verhindern, dass wichtige Meldungen verpasst werden, die gesendet werden, wenn ein Gerät nicht mit Netzempfang versorgt ist oder sein Mobilfunknetz ausgeschaltet werden muss. |
| **Meldungen, die beim ersten Abonnement eines Themas eingegangen sind** | Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen. | Nach dem Abonnieren eines Themas ohne beibehaltene Meldung wird keine Meldung empfangen, bis eine Meldung zu dem Thema veröffentlicht wird. |
| **Abonnierte Themen nach dem erneuten Verbindungsaufbau** | Ohne eine dauerhafte Sitzung muss der Client nach der Wiederverbindung Themen abonnieren. | Abonnierte Themen werden nach der Wiederverbindung wiederhergestellt. |
| **Nach der Wiederverbindung empfangene Meldungen** | Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen. | Alle Meldungen, die mit QOS = 1 veröffentlicht und mit QOS =1 abonniert wurden, während das Gerät getrennt wurde, werden gesendet, nachdem das Gerät wieder eine Verbindung hergestellt hat. |
| **Sitzungsablauf** | In MQTT 3 laufen gespeicherte Meldungen nicht ab. Sie werden gespeichert, bis sie ersetzt oder gelöscht werden. In MQTT 5 laufen gespeicherte Nachrichten nach dem von Ihnen festgelegten Nachrichtenablaufintervall ab. Weitere Informationen finden Sie unter [Message templates](#mqtt5) (Meldungsvorlagen). | Persistente Sitzungen laufen ab, wenn der Client innerhalb des Timeout-Zeitraums keine erneute Verbindung herstellt. Nach Ablauf einer dauerhaften Sitzung werden die Abonnements und gespeicherten Meldungen des Clients gelöscht, die mit einem QOS = 1 veröffentlicht und mit einem QOS =1 abonniert wurden, während das Gerät getrennt wurde. Abgelaufene Meldungen werden nicht zugestellt. Weitere Hinweise zum Ablauf von Sitzungen mit persistenten Sitzungen finden Sie unter [Persistente MQTT-Sitzungen](#mqtt-persistent-sessions). |
Informationen zu persistentem Speicher siehe [Persistente MQTT-Sitzungen](#mqtt-persistent-sessions).
Bei Retained Messages bestimmt der Publishing-Client, ob eine Meldung aufbewahrt und an ein Gerät gesendet werden soll, nachdem das Gerät eine Verbindung hergestellt hat, unabhängig davon, ob es eine vorherige Sitzung hatte oder nicht. Die Entscheidung, eine Nachricht zu speichern, wird vom Herausgeber getroffen, und die gespeicherte Nachricht wird an alle aktuellen und future Clients zugestellt, die QoS 0- oder QoS 1-Abonnements abonnieren. Bei gespeicherten Meldungen wird jeweils nur eine Meldung zu einem bestimmten Thema gespeichert.
Wenn ein Konto die maximale Anzahl an gespeicherten Meldungen gespeichert hat, wird AWS IoT Core eine gedrosselte Antwort auf Meldungen zurückgeben, bei denen RETAIN aktiviert war, und Nutzlasten von mehr als 0 Byte, bis einige beibehaltene Meldungen gelöscht wurden und die Anzahl der gespeicherten Meldungen unter den Grenzwert fällt.
### MQTT hat Nachrichten und Device Shadows gespeichert AWS IoT
Sowohl bei gespeicherten Meldungen als auch bei Geräteschatten werden Daten von einem Gerät gespeichert, sie verhalten sich jedoch unterschiedlich und dienen unterschiedlichen Zwecken. In diesem Abschnitt werden ihre Ähnlichkeiten und Unterschiede beschrieben.
| | Beibehaltene Meldungen | Geräteschatten |
| --- | --- | --- |
| **Die Meldungsnutzlast hat eine vordefinierte Struktur oder ein vordefiniertes Schema**. | Wie in der Implementierung definiert. MQTT spezifiziert keine Struktur oder kein Schema für seine Meldungsnutzlast. | AWS IoT unterstützt eine bestimmte Datenstruktur. |
| **Durch die Aktualisierung der Meldungsnutzlast werden Ereignismeldungen generiert**. | Durch das Veröffentlichen einer gespeicherten Meldung wird die Meldung an abonnierte Clients gesendet, es werden jedoch keine zusätzlichen Aktualisierungsnachrichten generiert. | Beim Aktualisieren eines Geräteschattens werden [Aktualisierungsmeldungen angezeigt, die die Änderung beschreiben](https://docs.aws.amazon.com//iot/latest/developerguide/device-shadow-mqtt.html#update-delta-pub-sub-topic). |
| **Meldungsaktualisierungen sind nummeriert**. | Aufbewahrte Meldungen werden nicht automatisch nummeriert. | Geräteschatten-Dokumente haben automatische Versionsnummern und Zeitstempel. |
| **Die Meldungen-Payload ist an eine Ding-Ressource angehängt**. | Beibehaltene Meldungen sind nicht an eine Ding-Ressource angehängt. | Geräteschatten sind an eine Ding-Ressource angehängt. |
| **Einzelne Elemente der Meldungs-Payload werden aktualisiert**. | Einzelne Elemente der Meldung können nicht geändert werden, ohne die gesamte Meldungsnutzlast zu aktualisieren. | Einzelne Elemente eines Geräteschatten-Dokuments können aktualisiert werden, ohne dass das gesamte Geräteschatten-Dokument aktualisiert werden muss. |
| **Der Kunde erhält Meldungsdaten bei Abschluss des Abonnements**. | Der Client erhält automatisch eine gespeicherte Nachricht, nachdem er ein Thema mit einer gespeicherten Nachricht abonniert hat. | Clients können Geräteschatten-Updates abonnieren, müssen den aktuellen Status jedoch bewusst anfordern. |
| **Indizierung und Durchsuchbarkeit** | Zurückbehaltene Meldungen werden nicht für die Suche indexiert. | Flottenindizierung indexiert Geräteschatten-Daten für die Suche und Aggregation. |
## MQTT-Meldungen des letzten Willens und Testaments (LWT)
Last Will and Testament (LWT) ist ein Feature in MQTT. Mit LWT können Kunden eine Meldung angeben, die der Broker zu einem vom Kunden definierten Thema veröffentlicht und an alle Clients sendet, die das Thema abonniert haben, wenn eine uninitiierte Verbindungsunterbrechung auftritt. Die von den Clients angegebene Meldung wird als LWT-Meldung oder Will-Meldung bezeichnet, und das von den Clients definierte Thema wird Will-Thema genannt. Sie können eine LWT-Meldung angeben, wenn ein Gerät eine Verbindung zum Broker herstellt. Diese Meldungen können beibehalten werden, indem während der Verbindung die `Will Retain` Markierung im `Connect Flag bits` Feld gesetzt wird. Wenn die `Will Retain` Markierung beispielsweise auf `1` gesetzt ist, wird eine Will-Meldung im Broker im zugehörigen Testament-Thema gespeichert. Weitere Informationen finden Sie unter [Meldungsvorlagen](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc479576982).
Bei der Verwaltung von Client-Verbindungen können Sie steuern, ob LWT-Nachrichten veröffentlicht werden, wenn Sie die Verbindung zu einem Client trennen. Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
Der Broker speichert die Will-Meldungen, bis es zu einer uninitiierten Verbindungsunterbrechung kommt. In diesem Fall veröffentlicht der Broker die Meldungen an alle Clients, die das Will-Thema abonniert haben, um den Verbindungsabbruch zu melden. Wenn der Client die Verbindung zum Broker mit einer vom Client initiierten Verbindungsunterbrechung mithilfe der MQTT DISCONNECT-Meldung trennt, veröffentlicht der Broker die gespeicherten LWT-Meldungen nicht. In allen anderen Fällen werden die LWT-Meldungen versendet. Aufgrund der asynchronen Verarbeitung von Verbindungsabbrüchen kann nicht garantiert werden, dass LWT-Nachrichten bei der Wiederherstellung der Verbindung in der richtigen Reihenfolge versendet werden. Es wird empfohlen, [Lebenszyklusereignisse](life-cycle-events.md) zu verwenden, um die Genauigkeit der Erkennung des Verbindungsstatus zu verbessern, da diese Ereignisse Attribute wie Zeitstempel und Versionsnummern zur Verwaltung von Ereignissen bereitstellen. out-of-order Eine vollständige Liste der Verbindungsszenarien, in denen der Broker die LWT-Meldungen sendet, finden Sie unter [Connect/Disconnect events](https://docs.aws.amazon.com//iot/latest/developerguide/life-cycle-events.html#connect-disconnect).
## ConnectAttributes verwenden
`ConnectAttributes` ermöglichen es Ihnen, in Ihren IAM-Richtlinien anzugeben, welche Attribute Sie in Ihrer Connect-Meldung verwenden möchten, z. B. `PersistentConnect` und `LastWill` Mit `ConnectAttributes` können Sie Richtlinien erstellen, die Geräten standardmäßig keinen Zugriff auf neue Funktionen gewähren. Dies kann hilfreich sein, wenn ein Gerät kompromittiert wurde.
`connectAttributes` unterstützt die folgenden Funktionen:
`PersistentConnect`
Verwenden Sie die `PersistentConnect` Funktion, um alle Abonnements zu speichern, die der Client während der Verbindung abschließt, wenn die Verbindung zwischen dem Client und dem Broker unterbrochen wird.
`LastWill`
Verwenden Sie die `LastWill` Funktion, um eine Meldung an `LastWillTopic` zu veröffentlichen, wenn ein Client unerwartet die Verbindung trennt.
Standardmäßig hat Ihre Richtlinie eine nicht persistente Verbindung, und für diese Verbindung werden keine Attribute übergeben. Sie müssen in Ihrer IAM-Richtlinie eine persistente Verbindung angeben, wenn Sie eine haben möchten.
Bei der Verwaltung von Clientverbindungen können Sie die Verbindungsattribute und die Sitzungskonfiguration für verbundene Clients einsehen. Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
`ConnectAttributes`Beispiele finden Sie unter Beispiele für [Connect-Richtlinien](connect-policy.md).
## Von MQTT 5 unterstützte Funktionen
AWS IoT Core Die Unterstützung für MQTT 5 basiert auf der [MQTT v5.0-Spezifikation](http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html) mit einigen Unterschieden, die unter dokumentiert sind. [AWS IoT Unterschiede zu den MQTT-Spezifikationen](#mqtt-differences)
**Topics**
+ [
### Geteilte Abonnements
](#mqtt5-shared-subscription)
+ [
### Clean Start und Ablauf der Sitzung
](#mqtt5-clean-start)
+ [
### Ursachencode für alle ACKs
](#mqtt5-reason-code)
+ [
### Aliase für Themen
](#mqtt5-topic-alias)
+ [
### Nachrichtablauf
](#mqtt5-message-expiry)
+ [
### Weitere Funktionen von MQTT 5
](#mqtt5-other-features)
### Geteilte Abonnements
AWS IoT Core unterstützt gemeinsame Abonnements sowohl für MQTT 3.1.1 als auch für MQTT 5. Geteilte Abonnements ermöglichen es mehreren Clients, ein Abonnement für ein Thema gemeinsam zu nutzen, und nur ein Client erhält Nachrichten, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. Mit geteilten Abonnements können MQTT-Nachrichten effektiv auf mehrere Abonnenten verteilt werden. Nehmen wir zum Beispiel an, Sie haben 1.000 Geräte, die zum gleichen Thema veröffentlichen, und 10 Backend-Anwendungen, die diese Meldungen verarbeiten. In diesem Fall können die Backend-Anwendungen dasselbe Thema abonnieren und jede Anwendung würde nach dem Zufallsprinzip Nachrichten empfangen, die von den Geräten zum gemeinsamen Thema veröffentlicht wurden. Auf diese Weise wird die Menge dieser Meldungen quasi „geteilt“. Geteilte Abonnements ermöglichen auch eine bessere Ausfallsicherheit. Wenn eine Back-End-Anwendung die Verbindung trennt, verteilt der Broker die Last auf die verbleibenden Abonnenten in der Gruppe. Wenn alle Abonnenten die Verbindung trennen, werden die Nachrichten in die Warteschlange gestellt.
Message Queuing-Funktionen sind für gemeinsame Abonnements sowohl für MQTT 3.1.1- als auch für MQTT 5-Verbindungen verfügbar, um die Zuverlässigkeit der Nachrichtenzustellung zu erhöhen.
Um gemeinsame Abonnements zu verwenden, abonnieren Kunden den [Themenfilter](https://docs.aws.amazon.com//iot/latest/developerguide/topics.html#topicfilters) eines gemeinsamen Abonnements wie folgt:
```
$share/{ShareName}/{TopicFilter}
```
+ `$share` ist eine wörtliche Zeichenfolge, die den Themenfilter eines geteilten Abonnements angibt, der mit `$share` beginnen muss.
+ `{ShareName}` ist eine Zeichenfolge zur Angabe des gemeinsamen Namens, der von einer Gruppe von Abonnenten verwendet wird. Der Themenfilter eines geteilten Abonnements muss ein `ShareName` und gefolgt vom `/` Zeichen enthalten. `{ShareName}` darf die folgenden Zeichen nicht enthalten: `/`,`+` oder`#`. Die maximale Größe für `{ShareName}` beträgt 128 UTF-8-Zeichen.
+ `{TopicFilter}`folgt derselben [Themenfiltersyntax](https://docs.aws.amazon.com//iot/latest/developerguide/topics.html#topicfilters) wie ein Abonnement, das nicht gemeinsam genutzt wird. Die maximale Größe für `{TopicFilter}` beträgt 256 UTF-8-Zeichen.
+ Die beiden erforderlichen Schrägstriche (`/`) für `$share/{ShareName}/{TopicFilter}` sind nicht in den Grenzwerten [„Maximale Anzahl von Schrägstrichen im Thema“ und „Themenfilter“](https://console.aws.amazon.com/servicequotas/home/services/iotcore/quotas/L-AD5A8D4F) enthalten.
Abonnements, die dasselbe haben, `{ShareName}/{TopicFilter}` gehören derselben gemeinsamen Abonnementgruppe an. Sie können mehrere gemeinsame Abonnementgruppen erstellen und dabei das Limit für [gemeinsame Abonnements pro Gruppe nicht überschreiten](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits). Weitere Informationen finden Sie unter [AWS IoT Core -Endpunkte und -Kontingente](https://docs.aws.amazon.com//general/latest/gr/iot-core.html) in der *AWS Allgemeinen Referenz*.
In den folgenden Tabellen werden nicht gemeinsam genutzte Abonnements und geteilte Abonnements verglichen:
****
| Abonnement | Description | Beispiele für Metrikfilter |
| --- | --- | --- |
| Nicht gemeinsam genutzte Abonnements | Jeder Client erstellt ein separates Abonnement für den Empfang der veröffentlichten Meldungen. Wenn eine Meldung zu einem Thema veröffentlicht wird, erhalten alle Abonnenten dieses Themas eine Kopie der Nachricht. | sports/tennis
sports/#
|
| Geteilte Abonnements | Mehrere Kunden können sich ein Abonnement für ein Thema teilen, und nur ein Kunde erhält Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. | $share/consumer/sports/tennis
$share/consumer/sports/#
|
****
| Es gibt nicht gemeinsam genutzte Abonnements | Ablauf geteilter Abonnements |
| --- | --- |
| ![\[Reguläre Abonnements für MQTT 3 und MQTT 5 in. AWS IoT Core\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/mqtt_regular_subscription.gif) | ![\[Gemeinsame Abonnements für MQTT 3 und MQTT 5 in. AWS IoT Core\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/mqtt_shared_subscription.gif) |
**Wichtige Hinweise zur Verwendung von gemeinsamen Abonnements**
+ Wenn die gemeinsame Abonnentengruppe aus Abonnenten einer dauerhaften Sitzung besteht, wenn alle Abonnenten in der gemeinsam genutzten Gruppe getrennt sind oder wenn Abonnenten das Limit für Veröffentlichungsanfragen pro Sekunde pro Verbindung überschreiten, werden alle nicht bestätigten QoS-1-Nachrichten und nicht zugestellten QoS-1-Nachrichten, die in einer gemeinsam genutzten Abonnementgruppe veröffentlicht wurden, in die Warteschlange gestellt. [Weitere Informationen finden Sie unter Nachrichtenwarteschlange für gemeinsame Abonnements.](#mqtt5-shared-subscription-message-queuing)
+ QoS 0-Nachrichten, die in einer gemeinsam genutzten Abonnementgruppe veröffentlicht wurden, werden bei einem Fehler gelöscht.
+ Geteilte Abonnements erhalten keine [beibehaltenen Nachrichten](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-retain), wenn sie Themenmuster als Teil einer gemeinsamen Abonnentengruppe abonnieren. Nachrichten, die zu Themen veröffentlicht wurden, die gemeinsame Abonnenten haben und bei denen die `RETAIN` Markierung gesetzt ist, werden an gemeinsame Abonnenten wie jede andere Veröffentlichungsnachricht zugestellt.
+ Wenn gemeinsame Abonnements Platzhalterzeichen (\$1 oder \$1) enthalten, gibt es möglicherweise mehrere übereinstimmende gemeinsame Abonnements für ein Thema. In diesem Fall kopiert der Nachrichtenbroker die Veröffentlichungsnachricht und sendet sie in jedem passenden gemeinsamen Abonnement an einen zufälligen Client. Das Platzhalterverhalten von gemeinsamen Abonnements kann in der folgenden Abbildung erklärt werden.
![\[Geteilte Abonnements mit Platzhalterzeichen in. AWS IoT Core\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/mqtt_shared_subscriptions_wildcard.gif)
In diesem Beispiel gibt es drei passende gemeinsame Abonnements für das MQTT-Thema zur Veröffentlichung. `sports/tennis` Der Message Broker kopiert die veröffentlichte Meldung und sendet die Meldung an einen zufälligen Client in jeder passenden Gruppe.
Kunde 1 und Kunde 2 teilen sich das Abonnement: `$share/consumer1/sports/tennis`
Kunde 3 und Kunde 4 teilen sich das Abonnement: `$share/consumer1/sports/#`
Kunde 5 und Kunde 6 teilen sich das Abonnement: `$share/consumer2/sports/tennis`
Weitere Informationen zu den Beschränkungen für gemeinsame Abonnements finden Sie unter [AWS IoT Core Endpunkte und Kontingente](https://docs.aws.amazon.com//general/latest/gr/iot-core.html) in der *AWS Allgemeinen* Referenz. Informationen zum Testen gemeinsam genutzter Abonnements mit dem AWS IoT MQTT-Client in der [AWS IoT Konsole](https://console.aws.amazon.com/iot/home) finden Sie unter. [Testen von geteilten Abonnements im MQTT-Client](view-mqtt-messages.md#view-mqtt-shared-subscriptions) Mithilfe der Funktionen zur Verwaltung von Client-Verbindungen können Sie auch sehen, welche Themen verbundene Clients abonniert haben, einschließlich gemeinsam genutzter Abonnements. Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect). Weitere Informationen zu gemeinsamen Abonnements finden Sie unter [Gemeinsame Abonnements](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901250) aus der MQTTv5 2.0-Spezifikation.
#### Nachrichtenwarteschlange für gemeinsame Abonnements
Um die Zuverlässigkeit der Nachrichtenzustellung zu erhöhen, enthalten gemeinsame Abonnements Nachrichtenwarteschlangenfunktionen, mit denen Nachrichten gespeichert werden, wenn keine Online-Abonnenten verfügbar sind. Wenn eine gemeinsam genutzte Abonnementgruppe mindestens ein Mitglied mit einer dauerhaften Sitzung enthält, ist die Warteschlangenfunktion für die Gruppe aktiviert. Beim Verteilen von Nachrichten werden Online-Mitglieder als Empfänger ausgewählt. QoS 1-Nachrichten werden in die Warteschlange gestellt, wenn keine Mitglieder online gefunden werden oder wenn Abonnenten das [https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits)Limit überschreiten. Nachrichten in der Warteschlange werden zugestellt, wenn entweder bestehende Mitglieder ihre ständigen Sitzungen wieder aufnehmen oder neue Mitglieder der Gruppe beitreten. Nachrichten in der Warteschlange werden mit bis zu 20 Nachrichten pro Sekunde pro aktivem Gruppenabonnenten zugestellt, zusammen mit allen anderen Nachrichten, die dem Abonnenten gemäß den Abonnements zugestellt werden.
Standardmäßig entspricht die Aufbewahrung von Nachrichten in der Warteschlange dem Kontingent. [https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits) Wenn jedoch in der eingehenden Veröffentlichungsnachricht ein Nachrichtenablaufintervall (MEI) festgelegt ist, hat das MEI Vorrang. Wenn MEI vorhanden ist, bestimmt es den Aufbewahrungszeitraum für Nachrichten, unabhängig von der Ablaufzeit der persistenten Sitzung.
Die Anzahl der Nachrichtenwarteschlangen ist entsprechend dem [https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits)Kontingent begrenzt, und die Anzahl der Nachrichten ist durch das [https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits)Kontingent begrenzt. Rufen Sie die [Service Quotas-Konsole auf, um Ihre Kontingente](https://console.aws.amazon.com/servicequotas/home) einzusehen und zu verwalten.
Sie können die Warteschlange überwachen, CloudWatch indem Sie `ApproximateQueueDepth` im `AWS/Usage` Namespace nach suchen, oder Sie können den folgenden CLI-Befehl verwenden, um die Metriken aufzulisten, die der Warteschlangentiefe jeder gemeinsam genutzten Abonnementgruppe zugeordnet sind.
```
aws cloudwatch list-metrics --namespace "AWS/Usage" --dimensions Name=Resource,Value='ApproximateQueueDepth'
```
Wenn diese Grenzwerte überschritten werden, werden nur die Nachrichten beibehalten, die sich bereits in der Warteschlange befanden, bevor das Limit erreicht wurde. Neue eingehende Nachrichten, die die Grenzwerte überschreiten würden, werden gelöscht. Das System ersetzt ältere Nachrichten in der Warteschlange nicht durch neuere.
Das Einreihen von Nachrichten in die Warteschlange wird in CloudWatch Metriken und CloudWatch Protokollen aufgezeichnet. Informationen zu den Einträgen, in die geschrieben wurde, CloudWatch und zu den CloudWatch Protokollen finden Sie unter [Message Broker-Metriken](metrics_dimensions.md#message-broker-metrics) und[Protokolleintrag in der Warteschlange](cwl-format.md#log-mb-queued). Nachrichten in der Warteschlange werden weiterhin zum Standardnachrichtentarif abgerechnet. Weitere Informationen zu Preisen erhalten Sie unter [AWS IoT Core Preise](https://aws.amazon.com/iot-core/pricing).
**Sitzungslebenszyklus in einer gemeinsam genutzten Abonnementgruppe**
Wenn eine saubere Sitzung eine Gruppe abonniert, wird sie zu einem Online-Mitglied der Gruppe. Wenn sie sich abmeldet oder die Verbindung trennt, verlässt die saubere Sitzung die Gruppe.
Wenn eine persistente Sitzung eine Gruppe abonniert, wird sie zu einem Online-Mitglied der Gruppe. Wenn die Verbindung getrennt wird, verbleibt sie weiterhin in der Gruppe, wird aber zu einem Offline-Mitglied der Gruppe. Wenn die Verbindung wieder hergestellt wird, wird sie wieder zu einem Online-Mitglied. Die persistente Sitzung verlässt die Gruppe, wenn sie sich explizit abmeldet oder wenn sie nach der Trennung abläuft.
### Clean Start und Ablauf der Sitzung
Sie können Clean Start und Session Expiry verwenden, um Ihre persistenten Sitzungen flexibler zu handhaben. Ein Clean Start-Flag gibt an, ob die Sitzung gestartet werden soll, ohne eine bestehende Sitzung zu verwenden. Ein Sitzungsablaufintervall gibt an, wie lange die Sitzung nach einer Unterbrechung beibehalten werden soll. Das Ablaufintervall für die Sitzung kann bei der Trennung geändert werden. Weitere Informationen finden Sie unter [Persistente MQTT-Sitzungen](#mqtt-persistent-sessions).
### Ursachencode für alle ACKs
Mithilfe der Ursachencodes können Sie Fehlermeldungen einfacher debuggen oder verarbeiten. Ursachencodes werden vom Message Broker auf der Grundlage der Art der Interaktion mit dem Broker zurückgegeben (Abonnieren, Veröffentlichen, Bestätigen). Weitere Informationen finden Sie unter [MQTT](#mqtt5-reason-codes). Eine vollständige Liste der MQTT-Ursachencodes finden Sie in der [MQTT v5-Spezifikation](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901031).
### Aliase für Themen
Sie können einen Themennamen durch einen Themenalias ersetzen, bei dem es sich um eine Zwei-Byte-Ganzzahl handelt. Durch die Verwendung von Themenaliasnamen kann die Übertragung von Themennamen optimiert werden, wodurch die Datenkosten für Dienste mit gebührenpflichtigen Daten potenziell gesenkt werden können. AWS IoT Core hat eine Standardbeschränkung von 8 Themenaliasnamen. Weitere Informationen finden Sie unter [AWS IoT Core -Endpunkte und -Kontingente](https://docs.aws.amazon.com//general/latest/gr/iot-core.html) in der *AWS Allgemeinen Referenz*.
### Nachrichtablauf
Sie können veröffentlichten Meldungen Werte für den Ablauf von Meldungen hinzufügen. Diese Werte stellen das Nachrichtenablaufintervall (MEI) in Sekunden dar. Wenn die Meldungen innerhalb dieses Intervalls nicht an die Abonnenten gesendet wurden, läuft die Meldung ab und wird entfernt. Wenn Sie den Wert für das Verfallsdatum der Meldung nicht festlegen, läuft die Meldung nicht ab.
Beim ausgehenden Versand erhält der Abonnent eine Meldung mit der verbleibenden Restzeit des Ablaufintervalls. Wenn beispielsweise eine eingehende Veröffentlichungsnachricht einen Meldungsablauf von 30 Sekunden hat und sie nach 20 Sekunden an den Abonnenten weitergeleitet wird, wird das Feld für den Ablauf der Meldung auf 10 aktualisiert. Es ist möglich, dass die vom Abonnenten empfangene Meldung einen aktualisierten MEI von 0 hat. Dies liegt daran, dass sie auf 0 aktualisiert wird, sobald die verbleibende Zeit 999 ms oder weniger beträgt.
In AWS IoT Core ist der Mindest-MEI 1. Wenn das Intervall auf der Clientseite auf 0 gesetzt ist, wird es auf 1 eingestellt. Das maximale Verfallsintervall für Meldungen beträgt 604800 (7 Tage). Alle Werte, die über diesem Wert liegen, werden an den Maximalwert angepasst.
Bei der versionsübergreifenden Kommunikation wird das Verhalten des Meldungsablaufs durch die MQTT-Version der eingehenden Veröffentlichungsnachricht bestimmt. Beispielsweise MQTT5 kann eine Nachricht mit Ablauf der Nachricht, die von einer Sitzung gesendet wurde, über die eine Verbindung hergestellt wurde, für Geräte, die über Sitzungen angemeldet wurden, ablaufen. MQTT3 In der folgenden Tabelle ist aufgeführt, wie der Ablauf von Meldungen die folgenden Arten von Veröffentlichungsnachrichten unterstützt:
****
| Veröffentlichen eines Meldungstyps | Ablaufintervall für Meldungen |
| --- | --- |
| Reguläres Veröffentlichen | Wenn ein Server die Meldung nicht innerhalb der angegebenen Zeit zustellt, wird die abgelaufene Meldung entfernt und der Abonnent erhält sie nicht. Dies schließt Situationen ein, z. B. wenn ein Gerät seine QoS 1-Meldungen nicht veröffentlicht. |
| Beibehalten | Wenn eine gespeicherte Meldung abläuft und ein neuer Kunde das Thema abonniert, erhält der Client die Meldung nach Abschluss des Abonnements nicht. |
| Letzter Wille | Das Intervall für Meldungen des letzten Willens beginnt, nachdem der Client die Verbindung getrennt hat und der Server versucht, seinen Abonnenten die letzte Willensnachricht zuzustellen. |
| In die Warteschlange eingestellte Meldungen | Wenn eine ausgehende QoS 1-Verbindung mit Nachrichtenablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der [persistenten Sitzung](#mqtt-persistent-sessions) die abgelaufene Nachricht nicht. |
### Weitere Funktionen von MQTT 5
**Verbindung zum Server trennen**
Wenn eine Verbindung unterbrochen wird, kann der Server dem Client proaktiv eine DISCONNECT-Meldung senden, um den Verbindungsabbruch mit einem Ursachencode für die Trennung zu benachrichtigen.
**Request Response (Antwort anfordern)**
Verlage können verlangen, dass der Empfänger nach Erhalt eine Antwort auf ein vom Verlag spezifiziertes Thema sendet.
**Maximale Teilegröße**
Client und Server können unabhängig voneinander die maximale Paketgröße angeben, die sie unterstützen.
**Payload-Format und Inhaltstyp**
Sie können das Payload-Format (Binär, Text) und den Inhaltstyp angeben, wenn eine Meldung veröffentlicht wird. Diese werden an den Empfänger der Meldung weitergeleitet.
## MQTT 5 Eigenschaften
MQTT 5-Eigenschaften sind wichtige Ergänzungen des MQTT-Standards zur Unterstützung neuer MQTT 5-Funktionen wie Session Expiry und Pattern. Request/Response In können Sie [Regeln](https://docs.aws.amazon.com//iot/latest/developerguide/republish-rule-action.html) erstellen AWS IoT Core, die die Eigenschaften in ausgehenden Nachrichten weiterleiten können, oder [HTTP Publish](https://docs.aws.amazon.com//iot/latest/apireference/API_iotdata_Publish.html) verwenden, um MQTT-Nachrichten mit einigen der neuen Eigenschaften zu veröffentlichen.
In der folgenden Tabelle sind alle MQTT 5-Eigenschaften aufgeführt, die unterstützt werden. AWS IoT Core
| Property (Eigenschaft) | Description (Beschreibung) | Eingabetyp | packets |
| --- | --- | --- | --- |
| Nutzlastformatindikator Nutzlastnutzlast | Ein boolescher Wert, der angibt, ob die Payload als UTF-8 formatiert ist. | Byte | VERÖFFENTLICHEN, VERBINDEN |
| Inhaltstyp | Eine UTF-8-Zeichenfolge, die den Inhalt der Nutzlast beschreibt. | UTF-8-Zeichenfolge | VERÖFFENTLICHEN, VERBINDEN |
| Thema der Antwort | Eine UTF-8-Zeichenfolge, die das Thema beschreibt, zu dem der Empfänger im Rahmen des Anfrage-Antwort-Ablaufs etwas veröffentlichen sollte. Das Thema darf keine Platzhalterzeichen enthalten. | UTF-8-Zeichenfolge | VERÖFFENTLICHEN, VERBINDEN |
| Korrelationsdaten | Binärdaten, die vom Absender der Anforderungsnachricht verwendet werden, um zu identifizieren, für welche Anfrage die Antwortnachricht bestimmt ist. | Binär | VERÖFFENTLICHEN, VERBINDEN |
| Benutzereigenschaften | Ein UTF-8-Stringpaar. Diese Eigenschaft kann in einem Paket mehrfach vorkommen. Die Empfänger empfangen die Schlüssel-Wert-Paare in derselben Reihenfolge, in der sie gesendet wurden. | UTF-8-String-Paar | VERBINDEN, VERÖFFENTLICHEN, Will-Eigenschaften, ABONNIEREN, TRENNEN, ABBESTELLEN |
| Ablaufintervall für Meldungen | Eine 4-Byte-Ganzzahl, die das Nachrichtenablaufintervall in Sekunden darstellt. Wenn nicht vorhanden, läuft die Meldung nicht ab. | 4-Byte-Ganzzahl | VERÖFFENTLICHEN, VERBINDEN |
| Ablaufintervall der Sitzung | Eine 4-Byte-Ganzzahl, die das Ablaufintervall der Sitzung in Sekunden darstellt. AWS IoT Core unterstützt maximal 7 Tage, mit einem standardmäßigen Maximum von einer Stunde. Wenn der von Ihnen festgelegte Wert das Maximum Ihres Kontos überschreitet, AWS IoT Core wird der angepasste Wert im CONNACK zurückgegeben. | 4-Byte-Ganzzahl | VERBINDEN, VERBINDEN, TRENNEN |
| Zugewiesene Client-ID | Eine zufällige Client-ID, die generiert wird AWS IoT Core , wenn eine Client-ID nicht von Geräten angegeben wird. Bei der zufälligen Client-ID muss es sich um eine neue Client-ID handeln, die von keiner anderen Sitzung verwendet wird, die derzeit vom Broker verwaltet wird. | UTF-8-Zeichenfolge | CONNACK |
| Server Keep Alive | Eine 2-Byte-Ganzzahl, die die vom Server zugewiesene Keep-Alive-Zeit darstellt. Der Server trennt die Verbindung zum Client, wenn der Client länger als die Keep-Alive-Zeit inaktiv ist. | 2-Byte-Ganzzahl | CONNACK |
| Probleminformationen anfordern | Ein boolescher Wert, der angibt, ob die Ursachenzeichenfolge oder die Benutzereigenschaften im Falle eines Fehlers gesendet werden. | Byte | CONNECT |
| Maximal empfangen | Eine 2-Byte-Ganzzahl, die die maximale Anzahl von PUBLISH QOS > 0-Paketen darstellt, die gesendet werden können, ohne dass ein PUBACK empfangen wird. | 2-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Thema Alias Maximum | Dieser Wert gibt den höchsten Wert an, der als Themen-Alias akzeptiert wird. Standard = 0. | 2-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Maximale QoS | Der maximale Wert von QoS, der AWS IoT Core unterstützt wird. Die Standardeinstellung ist 1. AWS IoT Core unterstützt QoS 2 nicht. | Byte | CONNACK |
| Beibehaltung verfügbar | Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker gespeicherte Nachrichten unterstützt. Der Standardwert ist 1. | Byte | CONNACK |
| Maximale Teilegröße | Die maximale Paketgröße, die AWS IoT Core akzeptiert und gesendet wird. Kann 128 KB nicht überschreiten. | 4-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Wildcard-Abonnement verfügbar | Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Wildcard Subscription Available unterstützt. Der Standardwert ist 1. | Byte | CONNACK |
| Abonnement-ID verfügbar | Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Subscription Identifier Available unterstützt. Der Standardwert ist 0. | Byte | CONNACK |
## MQTT-Ursachencodes
MQTT 5 führt eine verbesserte Fehlerberichterstattung mit Antworten auf Ursachencodes ein. AWS IoT Core kann Ursachencodes zurückgeben, einschließlich, aber nicht beschränkt auf die folgenden, gruppiert nach Paketen. Eine vollständige Liste der von MQTT 5 unterstützten Ursachencodes finden Sie in den [MQTT 5-Spezifikationen](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901031).
**CONNACK-Ursachencodes**
| Wert | HEX() | Name des Grundcodes | Description |
| --- | --- | --- | --- |
| 0 | 0x00 | Herzlichen Glückwunsch | Die Verbindung wurde akzeptiert. |
| 128 | 0x80 | Unbekannter Fehler | Der Server möchte den Grund für den Fehler nicht preisgeben, oder keiner der anderen Ursachencodes trifft zu. |
| 133 | 0x85 | Die Client-ID ist nicht gültig. | Die Client-ID ist eine gültige Zeichenfolge, die jedoch vom Server nicht zugelassen wird. |
| 134 | 0x86 | Falscher Benutzername oder falsches Passwort | Der Server akzeptiert den vom Client angegebenen Benutzernamen oder das Passwort nicht. |
| 135 | 0x87 | Nicht autorisiert. | Der Client ist nicht autorisiert, eine Verbindung herzustellen. |
| 144 | 0x90 | Themenname ungültig | Der Name des Will-Themas ist korrekt formatiert, wird aber vom Server nicht akzeptiert. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| 155 | 0 x 9 B | QoS nicht unterstützt | Der Server unterstützt die in Will QoS eingestellte QoS nicht. |
**PUBACK-Ursachencodes**
| Wert | HEX() | Name des Grundcodes | Description |
| --- | --- | --- | --- |
| 0 | 0x00 | Herzlichen Glückwunsch | Die Meldung wurde akzeptiert. Die Veröffentlichung der QoS 1-Meldung wird fortgesetzt. |
| 128 | 0x80 | Unbekannter Fehler | Der Empfänger akzeptiert die Veröffentlichung nicht, möchte aber entweder den Grund nicht preisgeben, oder er entspricht keinem der anderen Werte. |
| 135 | 0x87 | Nicht autorisiert. | Die Veröffentlichung ist nicht autorisiert. |
| 144 | 0x90 | Themenname ungültig | Der Themenname ist nicht falsch formatiert, wird aber vom Client oder Server nicht akzeptiert. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die Paket-ID wird bereits verwendet. Dies könnte auf eine Nichtübereinstimmung des Sitzungsstatus zwischen Client und Server hinweisen. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
**Disconnect – Ursachencodes**
| Wert | HEX() | Name des Grundcodes | Description |
| --- | --- | --- | --- |
| 129 | 0x81 | Fehlerhaftes Paket | Das empfangene Paket entspricht nicht dieser Spezifikation. |
| 130 | 0x82 | Protokollfehler | Ein unerwartetes Paket oder ein Paket, das nicht in der richtigen Reihenfolge ist, wurde empfangen. |
| 135 | 0x87 | Nicht autorisiert. | Die Anfrage ist nicht autorisiert. |
| 139 | 0x8B | Server wird heruntergefahren. | Der Server wird heruntergefahren. |
| 141 | 0x8D | Keep Alive Timeout | Die Verbindung wurde geschlossen, weil seit dem 1,5-fachen der Keep-Alive-Zeit kein Paket mehr empfangen wurde. |
| 142 | 0x8E | Sitzung übernommen | Eine andere Verbindung, die dieselbe Client-ID verwendet, hat eine Verbindung hergestellt, wodurch diese Verbindung geschlossen wurde. |
| 143 | 0x8F | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, wird aber vom Server nicht akzeptiert. |
| 144 | 0x90 | Themenname ungültig | Der Themenname ist korrekt formatiert, wird aber von diesem Client oder Server nicht akzeptiert. |
| 147 | 0 x 93 | Empfangsmaximum überschritten | Der Client oder Server hat mehr als die Empfangsmaximum-Publikation erhalten, für die er weder PUBACK noch PUBCOMP gesendet hat. |
| 148 | 0 x 94 | Ungültiges Thema-Alias | Der Client oder Server hat ein PUBLISH-Paket erhalten, das einen Themen-Alias enthält, der größer ist als die maximale Anzahl an Themen-Alias, die er im CONNECT- oder CONNACK-Paket gesendet hat. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| 152 | 0x98 | Administrative Maßnahmen | Die Verbindung wurde aufgrund einer Verwaltungsmaßnahme geschlossen. |
| 155 | 0 x 9 B | QoS nicht unterstützt | Der Client hat eine QoS angegeben, die höher ist als die QoS, die in einem Maximum QoS im CONNACK angegeben ist. |
| 161 | 0 x A1 | Abonnement-Identifikatoren werden nicht unterstützt. | Der Server unterstützt keine Abonnement-IDs. Das Abonnement wird nicht akzeptiert. |
**SUBACK-Ursachencodes**
| Wert | HEX() | Name des Grundcodes | Description |
| --- | --- | --- | --- |
| 0 | 0x00 | QoS gewährt 0 | Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 0. Dies könnte eine niedrigere QoS sein als gewünscht. |
| 1 | 0x01 | QoS 1 gewährt 1 | Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 1. Dies könnte eine niedrigere QoS sein als gewünscht. |
| 128 | 0x80 | Unbekannter Fehler | Das Abonnement wurde nicht akzeptiert, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu. |
| 135 | 0x87 | Nicht autorisiert. | Der Kunde ist nicht berechtigt, dieses Abonnement abzuschließen. |
| 143 | 0x8F | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die angegebene Paket-ID wird bereits verwendet. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
**UNSUBACK-Ursachencodes**
| Wert | HEX() | Name des Grundcodes | Description |
| --- | --- | --- | --- |
| 0 | 0x00 | Herzlichen Glückwunsch | Das Abonnement wird gelöscht. |
| 128 | 0x80 | Unbekannter Fehler | Die Abmeldung konnte nicht abgeschlossen werden, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu. |
| 143 | 0x8F | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die angegebene Paket-ID wird bereits verwendet. |
## AWS IoT Unterschiede zu den MQTT-Spezifikationen
Die Message-Broker-Implementierung basiert auf der [MQTT-Spezifikation v3.1.1](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) und der [MQTT-Spezifikation v5.0, unterscheidet sich jedoch in folgenden Punkten von den Spezifikationen](http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html):
+ AWS IoT unterstützt die folgenden Pakete für MQTT 3 nicht: PUBREC, PUBREL und PUBCOMP.
+ AWS IoT unterstützt die folgenden Pakete für MQTT 5 nicht: PUBREC, PUBREL, PUBCOMP und AUTH.
+ AWS IoT unterstützt keine MQTT 5-Serverumleitung.
+ AWS IoT unterstützt nur die MQTT Quality of Service (QoS) Stufen 0 und 1. AWS IoT unterstützt das Veröffentlichen oder Abonnieren mit QoS Level 2 nicht. Bei Abfragen über QoS-Ebene 2 sendet der Message Broker kein PUBACK oder SUBACK.
+ In AWS IoT bedeutet das Abonnieren eines Themas mit QoS-Stufe 0, dass eine Nachricht null Mal oder öfter zugestellt wird. Meldungen können mehr als einmal übertragen werden. Meldungen, die mehrmals übertragen werden, können mit unterschiedlicher Paket-ID gesendet werden. In diesem Fall wird das DUP-Flag nicht festgelegt.
+ Der Message Broker sendet als Antwort auf eine Verbindungsanfrage eine CONNACK-Nachricht. Diese enthält ein Flag, das angibt, ob eine frühere Sitzung wieder aufgenommen wird.
+ Bevor der Client zusätzliche Steuerpakete oder eine Anfrage zum Trennen der Verbindung sendet, muss er warten, bis die CONNACK-Meldung vom Message Broker auf seinem Gerät empfangen wird. AWS IoT
+ Wenn ein Client ein Thema abonniert, kann es zwischen dem Zeitpunkt, an dem der Message Broker eine SUBACK-Meldung sendet, und den ersten eingehenden passenden Meldungen eine Verzögerung geben.
+ Wenn ein Client das Platzhalterzeichen `#` im Themenfilter verwendet, um ein Thema zu abonnieren, werden alle Zeichenfolgen auf und unter seiner Ebene in der Themenhierarchie abgeglichen. Das übergeordnete Thema stimmt jedoch nicht überein. Wenn Sie beispielsweise das Thema `sensor/#` abonnieren, erhalten Sie Meldungen, die für `sensor/`, `sensor/temperature` oder `sensor/temperature/room1` veröffentlicht werden, nicht jedoch Meldungen, die für `sensor` veröffentlicht werden. Weitere Informationen zu Platzhaltern unter [Filter für Themennamen](topics.md#topicfilters).
+ Der Message Broker verwendet die Client-ID, um die einzelnen Clients zu identifizieren. Die Client-ID wird vom Client im Rahmen der MQTT-Nutzlast an den Message Broker übermittelt. Zwei Clients mit identischen Client-IDs können nicht gleichzeitig mit dem Message Broker verbunden sein. Stellt ein Client eine Verbindung zum Message Broker über eine Client-ID her, die bereits von einem anderen Client verwendet wird, wird die neue Client-Verbindung akzeptiert und die Verbindung des früher verbundenen Clients getrennt. Sie können Clients auch manuell trennen mit. APIs Weitere Informationen finden Sie unter [Verwaltung von MQTT-Verbindungen](#mqtt-client-disconnect).
+ In seltenen Fällen kann der Message Broker die gleiche logische PUBLISH Meldung mit einer anderen Paket-ID erneut senden.
+ Wenn Sie Themenfilter abonnieren, die ein Platzhalterzeichen enthalten, können keine beibehaltenen Meldungen empfangen werden. Um eine gespeicherte Meldung zu erhalten, muss die Anforderung einen Themenfilter enthalten, der genau dem Thema der gespeicherten Meldung entspricht.
+ Die Reihenfolge, in der Meldungen und ACK empfangen werden, kann vom Message Broker nicht garantiert werden.
+ AWS IoT kann Grenzwerte haben, die von den Spezifikationen abweichen. Weitere Informationen zu den Grenzwerten von [AWS IoT Core Message Broker finden Sie im ](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits) *AWS IoT Referenzhandbuch*.
+ Das MQTT DUP-Flag wird nicht unterstützt.
## Verwaltung von MQTT-Verbindungen
AWS IoT Core unterstützt APIs Sie bei der Verwaltung von MQTT-Verbindungen, einschließlich der Möglichkeit, Clients zu trennen und ihre Sitzungen zu verwalten. Diese Funktionen geben Ihnen mehr Kontrolle über Ihre AWS IoT Kundenflotte und helfen Ihnen bei der Behebung von Verbindungsproblemen.
### DeleteConnection API
Verwenden Sie die `DeleteConnection` API, um die Verbindung zu MQTT-Geräten zu trennen, AWS IoT Core indem Sie ihren Client IDs angeben. Wenn Sie die AWS IoT Core Verbindung zu einem Client trennen, wird der Client vom AWS IoT Core Message Broker getrennt. Sie können optional den Sitzungsstatus bereinigen und die Last Will and Testament (LWT) -Nachricht unterdrücken.
AWS IoT Core Führt beim Aufrufen der `DeleteConnection` API mehrere Aktionen aus, um sicherzustellen, dass die Verbindung ordnungsgemäß unterbrochen wird. AWS IoT Core sendet zunächst eine MQTT-Verbindungsnachricht an den Client, um die MQTT-Sitzung zu beenden. Der Dienst schließt dann den zugrunde TCP/TLS liegenden Socket.
Der Message Broker sendet ein `DISCONNECT` Paket an das Gerät und veröffentlicht ein [Lebenszyklusereignis](life-cycle-events.md) mit dem Grund für die Unterbrechung der Verbindung`API_INITIATED_DISCONNECT`. Auf diese Weise können Sie feststellen, wann eine Verbindungsunterbrechung über die API und nicht durch den Client oder aufgrund von Netzwerkproblemen initiiert wurde. Sie können diese Ereignisse aus Gründen der Transparenz, Problembehandlung und Prüfung überwachen. Sie können beispielsweise AWS IoT Regeln verwenden, um diese Ereignisse zu verarbeiten, um nachzuverfolgen, wann und warum die Verbindung der Clients unterbrochen wurde.
Wenn Sie den `cleanSession` Parameter auf setzen`true`, AWS IoT Core wird der Sitzungsstatus des Clients gelöscht, einschließlich aller Abonnements und Nachrichten in der Warteschlange. Wenn Sie eine Sitzung bereinigen, wird die persistente Sitzung beendet. Wenn es sich bei dem Client um eine persistente Sitzung handelte und der `preventWillMessage` Parameter auf gesetzt ist`false`, sendet der Dienst die LWT-Nachricht, sofern verfügbar, was bei geplanten Wartungsarbeiten nützlich ist.
Wenn Sie die `DeleteConnection` API aufrufen, beginnt der Verbindungsabbruch sofort. Der genaue Zeitpunkt, zu dem der Client die Unterbrechung erkennt, kann jedoch je nach Netzwerkbedingungen und Client-Implementierung variieren. Die meisten Clients erkennen die Unterbrechung innerhalb weniger Sekunden. In einigen Fällen kann es jedoch bei schlechter Netzwerkkonnektivität länger dauern, bis der Client erkennt, dass die Verbindung unterbrochen wurde.
**Anmerkung**
Wird eine Unterbrechung erzwungen, muss sich ein Client erneut authentifizieren und mit einem neuen Sitzungsstatus erneut autorisieren. Der API-Aufruf selbst verhindert nicht die Wiederverbindung von Clients. Wenn dies gewünscht wird, müssen zusätzlich die Anmeldeinformationen oder die Richtlinie eines Kunden geändert werden, bevor der `DeleteConnection` API-Aufruf ausgeführt wird.
Informationen zu Preisen finden Sie unter [AWS IoT Core -Preise](https://aws.amazon.com/iot-core/pricing/).
#### Anwendungsfälle
Die `DeleteConnection` API ist nützlich, um sich schlecht benehmende Clients zu verwalten, die ein problematisches Verhalten zeigen oder übermäßig viele Ressourcen verbrauchen. Indem Sie eine Unterbrechung erzwingen, können Sie sicherstellen, dass die Clients ihre Verbindungen mit der richtigen Authentifizierung und Autorisierung wiederherstellen, was zur Lösung von Problemen mit dem Ressourcenverbrauch beitragen kann.
Szenarien mit Client-Umleitung profitieren ebenfalls von dieser API. Wenn Sie Clients zu anderen Endpunkten umleiten müssen oder AWS-Regionen können Sie sie programmgesteuert trennen und sie durch Ändern der DNS-Einstellungen erneut eine Verbindung zu einem anderen AWS IoT Core Endpunkt herstellen lassen. Diese API kann dabei helfen, festgefahrene Verbindungen zu lösen oder problematische Sitzungszustände zu löschen, die den normalen Betrieb möglicherweise verhindern.
#### API-Parameter
Die `DeleteConnection` API akzeptiert die folgenden Parameter:
clientId (erforderlich)
Die eindeutige Kennung des MQTT-Clients, für den die Verbindung getrennt werden soll. Dies ist im URL-Pfad angegeben. Die Client-ID darf nicht mit einem Dollarzeichen (\$1) beginnen.
Der MQTT-Client IDs kann Zeichen enthalten, die in HTTP-Anfragen nicht gültig sind. Wenn Sie die `DeleteConnection` API verwenden, müssen Sie alle Zeichen in der Client-ID, die in MQTT, aber nicht in HTTP gültig sind, URL-kodieren (prozentual kodieren). Dazu gehören Sonderzeichen wie Leerzeichen, Schrägstriche (/) und UTF-8-Zeichen. Ein Leerzeichen wird beispielsweise zu %20, ein Schrägstrich wird zu %2F und das UTF-8-Zeichen ü wird zu %C 3% BC. Durch die richtige Kodierung wird sichergestellt, dass die MQTT-Clients beim HTTP-basierten IDs API-Aufruf korrekt übertragen werden.
CleanSession (optional)
Gibt an, ob der Sitzungsstatus des Clients beim Trennen der Verbindung entfernt werden soll. Legt fest, `true` dass alle Sitzungsinformationen, einschließlich Abonnements und Nachrichten in der Warteschlange, gelöscht werden. Wird auf gesetzt`false`, um den Sitzungsstatus beizubehalten. Standardmäßig ist dies auf `false` (behält den Sitzungsstatus bei) gesetzt. Bei sauberen Sitzungen wird dieser Parameter ignoriert.
preventWillMessage (Optional)
Steuert, ob AWS IoT Core die Nachricht Last Will and Testament (LWT) gesendet wird, falls diese beim Trennen der Verbindung verfügbar ist. Wird auf gesetzt, `true` um das Versenden der LWT-Nachricht zu verhindern. Wird auf gesetzt, um das `false` Versenden zu ermöglichen. Standardmäßig ist dies auf `false` (sendet LWT, falls verfügbar) gesetzt.
#### API-Syntax
Die `DeleteConnection` API verwendet das folgende HTTP-Anforderungsformat:
```
DELETE /connections/?cleanSession=&preventWillMessage= HTTP/1.1
```
Beispielanfragen:
```
// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1
// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1
// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1
```
Erfolgreiche Anfragen geben HTTP 200 OK ohne Antworttext zurück.
**Anmerkung**
Der von [AWS Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) zum Signieren von Anfragen verwendete Dienstname lautet: *iotdevicegateway*. Sie können Ihren Endpunkt finden, indem Sie den Befehl verwenden. `aws iot describe-endpoint --endpoint-type iot:Data-ATS`
#### Erforderliche Berechtigungen
Um die `DeleteConnection` API verwenden zu können, benötigen Sie die folgende IAM-Berechtigung:
```
iot:DeleteConnection
```
Sie können diese Berechtigung IDs mithilfe ressourcenbasierter Richtlinien auf bestimmte Clients beschränken. Beispiel:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:DeleteConnection",
"Resource": "arn:aws:iot:region:account:client/myDevice*"
}
]
}
```
#### Wichtige Überlegungen
Getrennte Clients können sofort versuchen, die Verbindung wiederherzustellen, sofern Sie keine zusätzliche Logik implementiert haben, um eine Wiederverbindung zu verhindern. Der Trennvorgang beendet nur die aktuelle Verbindung und verhindert nicht, dass eine Verbindung wieder hergestellt wird. Wenn Sie eine Wiederverbindung verhindern möchten, sollten Sie eine clientseitige Logik implementieren oder die Anmeldeinformationen eines Geräts deaktivieren.
Für die API gelten im Rahmen der standardmäßigen API-Ratenbegrenzung Ratenbegrenzungen. AWS IoT Core Achten Sie bei der Planung von Massentrennungen darauf, dass Sie diese Grenzwerte berücksichtigen und geeignete Wiederholungslogik und Batching-Strategien implementieren, um Drosselungen zu vermeiden. Weitere Informationen finden Sie unter [AWS IoT Core -Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits).
#### Fehlermeldungen
Die `DeleteConnection` API kann die folgenden Fehlerantworten zurückgeben:
InvalidRequestException
Die Anforderung ist ungültig. Dies kann auftreten, wenn das Client-ID-Format ungültig ist, ein Dollarzeichen-Präfix (\$1) enthält oder wenn erforderliche Parameter fehlen.
ResourceNotFoundException
Die angegebene Client-ID existiert nicht oder ist derzeit nicht verbunden und es besteht keine permanente Sitzung.
UnauthorizedException
Sie sind zur Ausführung dieser Operation nicht autorisiert. Stellen Sie sicher, dass Sie über die erforderliche `iot:DeleteConnection` Berechtigung verfügen.
ForbiddenException
Der Anrufer ist nicht berechtigt, die Anfrage zu stellen. Dies kann auf unzureichende IAM-Berechtigungen oder ressourcenbasierte Richtlinieneinschränkungen zurückzuführen sein.
ThrottlingException
Die Rate überschreitet den Grenzwert. Reduzieren Sie die Häufigkeit Ihrer API-Aufrufe und implementieren Sie eine entsprechende Wiederholungslogik mit exponentiellem Backoff.
InternalFailureException
Ein unerwarteter Fehler ist aufgetreten. Versuchen Sie die Anfrage nach einer kurzen Verzögerung erneut.
ServiceUnavailableException
Der Service ist vorübergehend nicht verfügbar. Versuchen Sie die Anfrage nach einer kurzen Verzögerung erneut.
# HTTPS veröffentlichen
Clients können Nachrichten veröffentlichen, indem sie Anforderungen an die REST-API mit den Protokollen HTTP 1.0 oder 1.1 stellen. Informationen zu den Authentifizierungs- und Portzuordnungen, die von HTTP-Anforderungen verwendet werden, finden Sie unter [Protokolle, Port-Zuweisungen und Authentifizierung](protocols.md#protocol-mapping).
**Anmerkung**
HTTPS unterstützt keinen `clientId`-Wert wie MQTT. `clientId` ist verfügbar, wenn MQTT verwendet wird, aber es ist nicht verfügbar, wenn HTTPS verwendet wird.
## HTTPS-Nachrichten-URL
Geräte und CLients veröffentlichen ihre Nachrichten, indem sie POST-Anfragen an einen clientspezifischen Endpunkt und eine themenspezifische URL stellen:
```
https://IoT_data_endpoint/topics/url_encoded_topic_name?qos=1
```
+ *IoT\$1data\$1endpoint*ist der [Endpunkt der AWS IoT Gerätedaten](iot-connect-devices.md#iot-connect-device-endpoints). Sie finden den Endpunkt in der AWS IoT Konsole auf der Detailseite der Sache oder auf dem Client mit dem AWS CLI folgenden Befehl:
```
aws iot describe-endpoint --endpoint-type iot:Data-ATS
```
Der Endpunkt sollte etwa so aussehen: `a3qjEXAMPLEffp-ats.iot.us-west-2.amazonaws.com`
+ *url\$1encoded\$1topic\$1name*ist der vollständige [Themenname](topics.md#topicnames) der gesendeten Nachricht.
## Beispiele für HTTPS-Nachrichtencodes
Dies sind einige Beispiele dafür, wie Sie eine HTTPS-Nachricht an AWS IoT senden können.
------
#### [ Python (port 8443) ]
```
import requests
import argparse
# define command-line parameters
parser = argparse.ArgumentParser(description="Send messages through an HTTPS connection.")
parser.add_argument('--endpoint', required=True, help="Your AWS IoT data custom endpoint, not including a port. " +
"Ex: \"abcdEXAMPLExyz-ats.iot.us-east-1.amazonaws.com\"")
parser.add_argument('--cert', required=True, help="File path to your client certificate, in PEM format.")
parser.add_argument('--key', required=True, help="File path to your private key, in PEM format.")
parser.add_argument('--topic', required=True, default="test/topic", help="Topic to publish messages to.")
parser.add_argument('--message', default="Hello World!", help="Message to publish. " +
"Specify empty string to publish nothing.")
# parse and load command-line parameter values
args = parser.parse_args()
# create and format values for HTTPS request
publish_url = 'https://' + args.endpoint + ':8443/topics/' + args.topic + '?qos=1'
publish_msg = args.message.encode('utf-8')
# make request
publish = requests.request('POST',
publish_url,
data=publish_msg,
cert=[args.cert, args.key])
# print results
print("Response status: ", str(publish.status_code))
if publish.status_code == 200:
print("Response body:", publish.text)
```
------
#### [ Python (port 443) ]
```
import requests
import http.client
import json
import ssl
ssl_context = ssl.SSLContext(protocol=ssl.PROTOCOL_TLS_CLIENT)
ssl_context.minimum_version = ssl.TLSVersion.TLSv1_2
# note the use of ALPN
ssl_context.set_alpn_protocols(["x-amzn-http-ca"])
ssl_context.load_verify_locations(cafile="./")
# update the certificate and the AWS endpoint
ssl_context.load_cert_chain("./", "")
connection = http.client.HTTPSConnection('', 443, context=ssl_context)
message = {'data': 'Hello, I'm using TLS Client authentication!'}
json_data = json.dumps(message)
connection.request('POST', '/topics/device%2Fmessage?qos=1', json_data)
# make request
response = connection.getresponse()
# print results
print(response.read().decode())
```
------
#### [ CURL ]
So verwenden Sie [curl](https://curl.haxx.se) zum Senden einer Nachricht an das AWS IoT.
**Um Curl zu verwenden, um eine Nachricht von einem AWS IoT Client-Gerät aus zu senden**
1. Überprüfen Sie die **curl**-Version.
1. Führen Sie diesen Befehl auf Ihrem Client an einer Eingabeaufforderung aus.
**curl --help**
Suchen Sie im Hilfetext nach den TLS-Optionen. Sie sollten die `--tlsv1.2`-Option sehen.
1. Wenn die `--tlsv1.2`-Option angezeigt wird, fahren Sie fort.
1. Wenn die `--tlsv1.2`-Option nicht angezeigt wird oder Sie einen `command not found`-Fehler angezeigt bekommen, müssen Sie vor dem Fortfahren gegebenenfalls curl auf Ihrem Client aktualisieren oder `openssl` installieren.
1. Installieren Sie die Zertifikate auf Ihrem Client.
Kopieren Sie die Zertifikatsdateien, die Sie erstellt haben, als Sie Ihren Client (Ihr Ding) in der AWS IoT Konsole registriert haben. Stellen Sie sicher, dass sich diese drei Zertifikatdateien auf Ihrem Client befinden, bevor Sie fortfahren.
+ Die CA-Zertifikatdatei (*Amazon-root-CA-1.pem* in diesem Beispiel).
+ Die Zertifikatdatei des Clients (*device.pem.crt* in diesem Beispiel).
+ Die private Schlüsseldatei des Clients (*private.pem.key* in diesem Beispiel).
1. Erstellen Sie die **curl**-Befehlszeile und ersetzen Sie die ersetzbaren Werte gegen die Werte Ihres Kontos und Systems.
```
curl --tlsv1.2 \
--cacert Amazon-root-CA-1.pem \
--cert device.pem.crt \
--key private.pem.key \
--request POST \
--data "{ \"message\": \"Hello, world\" }" \
"https://IoT_data_endpoint:8443/topics/topic?qos=1"
```
--tlsv1.2
Verwenden Sie TLS 1.2 (SSL).
--cacert *Amazon-root-CA-1.pem*
Der Dateiname und Pfad, falls erforderlich, des CA-Zertifikats für die Verifizierung des Peers.
--Zertifikat *device.pem.crt*
Der Dateiname und Pfad der Clientzertifikatdatei, falls erforderlich.
--Schlüssel *private.pem.key*
Der Dateiname und Pfad des privaten Schlüssels des Clients, falls erforderlich.
--request POST
Die Art der HTTP-Anfrage (in diesem Fall POST).
--daten "“ *\$1 \$1"message\$1": \$1"Hello, world\$1" \$1*
Die HTTP POST-Daten, die Sie veröffentlichen möchten. In diesem Fall handelt es sich um eine JSON-Zeichenfolge, wobei die internen Anführungszeichen mit dem umgekehrten Schrägstrich (\$1) als Escape-Zeichen markiert sind.
„https: //:8443/topics/? *IoT\$1data\$1endpoint* *topic* qos=1"
Die URL des AWS IoT Gerätedatenendpunkts Ihres Clients, gefolgt vom HTTPS-Port`:8443`, gefolgt vom Schlüsselwort `/topics/` und dem Themennamen`topic`, in diesem Fall. Geben Sie die Servicequalität als Abfrageparameter an, `?qos=1`, an.
1. Öffnen Sie den MQTT-Testclient in der AWS IoT Konsole.
Folgen Sie den Anweisungen unter [MQTT-Nachrichten mit dem AWS IoT MQTT-Client anzeigen](view-mqtt-messages.md) und konfigurieren Sie die Konsole so, dass sie Nachrichten mit dem Themennamen abonniert, der in Ihrem **curl** Befehl *topic* verwendet wurde, oder verwenden Sie den Themenfilter mit Platzhaltern für. `#`
1. Testen Sie den Befehl.
Während Sie das Thema im Testclient der AWS IoT -Konsole überwachen, rufen Sie im Client die in Schritt 3 erstellte curl-Befehlszeile auf. Sie sollten die Nachrichten Ihres Clients in der Konsole sehen.
------