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äte Connect mit AWS IoT
Geräte stellen eine Verbindung AWS IoT zu anderen Diensten her AWS IoT Core. Über AWS IoT Core: Geräte senden und empfangen Nachrichten über Geräteendpunkte, die für Ihr Konto spezifisch sind. Die [AWS IoT Gerät SDKs](#iot-connect-device-sdks) unterstützen die Gerätekommunikation mithilfe der MQTT- und WSS-Protokolle. Weitere Informationen zu von Geräten unterstützten Protokollen finden Sie unter [Gerätekommunikationsprotokolle](protocols.md).
**Der Message Broker**
AWS IoT verwaltet die Gerätekommunikation über einen Nachrichtenbroker. Geräte und Kunden veröffentlichen Nachrichten im Message Broker und abonnieren auch Nachrichten, die der Message Broker veröffentlicht. Nachrichten werden durch ein anwendungsdefiniertes [*Thema*](topics.md) identifiziert. Wenn der Message Broker eine Nachricht empfängt, die von einem Gerät oder Kunden veröffentlicht wurde, veröffentlicht er diese Nachricht an die Geräte und Kunden, die das Nachrichtenthema abonniert haben. Der Message Broker leitet Nachrichten auch an die AWS IoT [Rules](iot-rules.md) Engine weiter, die auf den Inhalt der Nachricht reagieren kann.
**AWS IoT Nachrichtensicherheit**
Zu AWS IoT verwendende Geräteverbindungen [X.509-Clientzertifikate](x509-client-certs.md) und [AWS Signatur V4](https://docs.aws.amazon.com//general/latest/gr/signing_aws_api_requests.html) für die Authentifizierung. Die Gerätekommunikation ist durch TLS Version 1.3 gesichert und AWS IoT erfordert, dass Geräte bei der Verbindung die [Server Name Indication (SNI) -Erweiterung](https://tools.ietf.org/html/rfc3546#section-3.1) senden. Weitere Informationen finden Sie unter [Transportsicherheit in AWS IoT](transport-security.html).
## AWS IoT Gerätedaten und Dienstendpunkte
**Wichtig**
Sie können die Endpunkte auf Ihrem Gerät zwischenspeichern oder speichern. Das bedeutet, dass Sie die `DescribeEndpoint` API nicht jedes Mal abfragen müssen, wenn ein neues Gerät angeschlossen wird. Die Endpunkte ändern sich nicht, nachdem sie für Ihr Konto AWS IoT Core erstellt wurden.
Jedes Konto hat mehrere Geräteendpunkte, die für das Konto einzigartig sind und bestimmte IoT-Funktionen unterstützen. Die AWS IoT Gerätedatenendpunkte unterstützen ein publish/subscribe Protokoll, das für die Kommunikationsanforderungen von IoT-Geräten konzipiert ist. Andere Clients, wie Apps und Dienste, können diese Schnittstelle jedoch auch verwenden, wenn ihre Anwendung die speziellen Funktionen benötigt, die diese Endpunkte bieten. Die AWS IoT Gerätedienst-Endpunkte unterstützen den geräteorientierten Zugriff auf Sicherheits- und Verwaltungsdienste.
Den Gerätedaten-Endpunkt Ihres Accounts finden Sie auf der [https://console.aws.amazon.com//iot/home#/settings](https://console.aws.amazon.com//iot/home#/settings) Ihrer Konsole. AWS IoT Core
Um den Geräteendpunkt Ihres Kontos für einen bestimmten Zweck zu ermitteln, einschließlich des Gerätedatenendpunkts, verwenden Sie den hier gezeigten CLI-Befehl **describe-endpoint** oder die REST-API `DescribeEndpoint` und geben Sie den Parameterwert `endpointType` aus der folgenden Tabelle an.
```
aws iot describe-endpoint --endpoint-type endpointType
```
Dieser Befehl gibt ein *iot-endpoint* im folgenden Format zurück:`account-specific-prefix.iot.aws-region.amazonaws.com`.
Jeder Kunde verfügt über einen `iot:Data-ATS` und einen `iot:Data`-Endpunkt. Jeder Endpunkt verwendet ein X.509-Zertifikat, um den Client zu authentifizieren. Wir empfehlen dringend, dass Kunden den neueren `iot:Data-ATS`-Endpunkttyp verwenden, um Probleme im Zusammenhang mit dem weit verbreiteten Misstrauen gegenüber Symantec-Zertifizierungsstellen zu vermeiden. Wir stellen den `iot:Data` Endpunkt für Geräte bereit, um Daten von alten Endpunkten abzurufen, die VeriSign Zertifikate aus Gründen der Abwärtskompatibilität verwenden. Weitere Informationen finden Sie unter [Server-Authentifizierung](server-authentication.html).
**AWS IoT Endpunkte für Geräte**
| Zweck des Endpunkts | `endpointType` Wert | Description |
| --- | --- | --- |
| AWS IoT Core – Operationen auf Datenebene | `iot:Data-ATS` | Wird zum Senden und Empfangen von Daten an und von den Message Broker-, [Geräteschatten](iot-device-shadows.md)- und [Regel-Engine](iot-rules.md)-Komponenten von AWS IoT verwendet. `iot:Data-ATS` gibt einen ATS-signierten Datenendpunkt zurück |
| AWS IoT Core – Operationen auf Datenebene (veraltet) | `iot:Data` | iot:Datagibt einen VeriSign signierten Datenendpunkt zurück, der aus Gründen der Abwärtskompatibilität bereitgestellt wird. MQTT 5 wird auf Symantec (iot:Data)-Endpunkten nicht unterstützt. |
| AWS IoT Core Zugriff auf Anmeldeinformationen | `iot:CredentialProvider` | Wird verwendet, um das integrierte X.509-Zertifikat eines Geräts gegen temporäre Anmeldeinformationen auszutauschen, um eine direkte Verbindung mit anderen AWS -Diensten herzustellen. Weitere Informationen zum Herstellen einer Verbindung mit anderen AWS Diensten finden Sie unter [Autorisieren von direkten Aufrufen](authorizing-direct-aws.md) von Diensten. AWS |
| AWS IoT Device Management – Jobdaten-Operationen | `iot:Jobs` | Wird verwendet, um Geräten die Interaktion mit dem AWS IoT Jobs-Dienst über das [Jobs-Gerät HTTPS APIs](jobs-mqtt-api.md) zu ermöglichen. `iot:Jobs`kann IPv4 nur für verwendet werden. Wenn Sie Dual-Stack-Endpunkte (IPv4 und IPv6) verwenden, verwenden Sie den `iot:Data-ATS` Endpunkttyp. |
| AWS IoT Device Advisor-Operationen | `iot:DeviceAdvisor` | Ein Testendpunkttyp, der zum Testen von Geräten mit Device Advisor verwendet wird. Weitere Informationen finden Sie unter [Device Advisor](device-advisor.md). |
| AWS IoT Core Daten-Beta (Vorschau) | `iot:Data-Beta` | Ein Endpunkttyp, der Betaversionen vorbehalten ist. Informationen zu seiner aktuellen Verwendung finden Sie unter [Domain-Konfigurationen](iot-custom-endpoints-configurable.md). |
Sie können auch Ihren eigenen vollqualifizierten Domainnamen (FQDN) und das zugehörige Serverzertifikat verwenden*example.com*, mit dem Sie Geräte verbinden können AWS IoT . [Domain-Konfigurationen](iot-custom-endpoints-configurable.md)
## AWS IoT Gerät SDKs
Das AWS IoT Gerät SDKs hilft Ihnen dabei, Ihre IoT-Geräte mit den AWS IoT Core Protokollen MQTT und MQTT über WSS zu verbinden.
Das AWS IoT Gerät SDKs unterscheidet sich von dem AWS SDKs darin, dass das AWS IoT Gerät die speziellen Kommunikationsanforderungen von IoT-Geräten SDKs unterstützt, aber nicht alle von dem unterstützten Dienste unterstützt AWS SDKs. Die AWS IoT Geräte SDKs sind mit denen kompatibel AWS SDKs , die alle AWS Dienste unterstützen. Sie verwenden jedoch unterschiedliche Authentifizierungsmethoden und stellen eine Verbindung zu verschiedenen Endpunkten her, was die Verwendung auf einem IoT-Gerät AWS SDKs unpraktisch machen könnte.
**Mobilgeräte**
Sie [AWS Mobil SDKs](iot-connect-service.md#iot-connect-mobile-sdks) unterstützen sowohl die MQTT-Gerätekommunikation, einen Teil des AWS IoT Dienstes APIs als auch die APIs anderer Dienste. AWS Wenn Sie auf einem unterstützten Mobilgerät entwickeln, überprüfen Sie dieses SDK, um festzustellen, ob es die beste Option für die Entwicklung Ihrer IoT-Lösung ist.
------
#### [ C\$1\$1 ]
**AWS IoT C\$1\$1-Geräte-SDK**
Das AWS IoT C\$1\$1-Geräte-SDK ermöglicht es Entwicklern, verbundene Anwendungen mithilfe AWS und APIs der AWS IoT Core Dienste zu erstellen. Dieses SDK wurde speziell für Geräte entwickelt, die nicht ressourcenbeschränkt sind und die erweiterte Funktionen benötigen, wie beispielsweise Nachrichtenwarteschlangen, Multithreading-Support und die aktuellen Sprachfunktionen. Weitere Informationen finden Sie hier:
+ [AWS IoT Geräte-SDK C\$1\$1 v2 aktiviert GitHub](https://github.com/aws/aws-iot-device-sdk-cpp-v2)
+ [AWS IoT Readme für das Geräte-SDK C\$1\$1 v2](https://github.com/aws/aws-iot-device-sdk-cpp-v2#aws-iot-device-sdk-for-c-v2)
+ [AWS IoT C\$1\$1 v2-Beispiele für das Geräte-SDK](https://github.com/aws/aws-iot-device-sdk-cpp-v2/tree/main/samples#sample-apps-for-the-aws-iot-device-sdk-for-c-v2)
+ [AWS IoT C\$1\$1 v2-API-Dokumentation für das Geräte-SDK](https://aws.github.io/aws-iot-device-sdk-cpp-v2/)
------
#### [ Python ]
**AWS IoT Geräte-SDK für Python**
Das AWS IoT Device SDK für Python ermöglicht es Entwicklern, Python-Skripte zu schreiben, um ihre Geräte für den Zugriff auf die AWS IoT Plattform über MQTT oder MQTT über das WebSocket Secure (WSS) -Protokoll zu verwenden. Durch die Verbindung ihrer Geräte mit den APIs AWS IoT Core Diensten können Benutzer sicher mit dem Message Broker, den Regeln und dem Device Shadow-Service arbeiten, AWS IoT Core der sie bereitstellen AWS Lambda, und mit anderen AWS Diensten wie Amazon Kinesis und Amazon S3 und mehr.
+ [AWS IoT Geräte-SDK für Python v2 auf GitHub](https://github.com/aws/aws-iot-device-sdk-python-v2)
+ [AWS IoT Readme zum Geräte-SDK für Python v2](https://github.com/aws/aws-iot-device-sdk-python-v2#aws-iot-device-sdk-v2-for-python)
+ [AWS IoT Geräte-SDK für Python v2-Beispiele](https://github.com/aws/aws-iot-device-sdk-python-v2/tree/main/samples#sample-apps-for-the-aws-iot-device-sdk-v2-for-python)
+ [AWS IoT API-Dokumentation zum Geräte-SDK für Python v2](https://aws.github.io/aws-iot-device-sdk-python-v2/)
------
#### [ JavaScript ]
**AWS IoT Geräte-SDK für JavaScript**
Das AWS IoT Geräte-SDK für JavaScript ermöglicht es Entwicklern, JavaScript Anwendungen zu schreiben, die über das APIs Protokoll auf MQTT oder MQTT zugreifen. AWS IoT Core WebSocket Das Paket kann in Node.js-Umgebungen und Browser-Anwendungen verwendet werden. Weitere Informationen finden Sie hier:
+ [AWS IoT Geräte-SDK für Version 2 aktiviert JavaScript GitHub](https://github.com/aws/aws-iot-device-sdk-js-v2)
+ [AWS IoT Readme für das Geräte-SDK JavaScript für Version 2](https://github.com/aws/aws-iot-device-sdk-js-v2#aws-iot-device-sdk-for-javascript-v2)
+ [AWS IoT Geräte-SDK für JavaScript v2-Beispiele](https://github.com/aws/aws-iot-device-sdk-js-v2/tree/main/samples#sample-apps-for-the-aws-iot-device-sdk-for-javascript-v2)
+ [AWS IoT Geräte-SDK für JavaScript v2-API-Dokumentation](https://aws.github.io/aws-iot-device-sdk-js-v2/index.html)
------
#### [ Java ]
**AWS IoT Geräte-SDK SDK for Java**
Das AWS IoT Device SDK for Java ermöglicht es Java-Entwicklern, AWS IoT Core über MQTT oder MQTT über das Protokoll auf das APIs WebSocket of zuzugreifen. Das SDK unterstützt den Geräteschatten-Dienst. Sie können über die HTTP-Methoden wie ABRUFEN, AKTUALISIEREN und LÖSCHEN auf Schattengeräte zugreifen. Das SDK unterstützt auch ein vereinfachtes Zugangsmodell für Schattengeräte, sodass Entwickler mithilfe der Methoden „Getter” und „Setter” Daten mit den Schattengeräten austauschen können, ohne JSON-Dokumente serialisieren oder deserialisieren zu müssen. Weitere Informationen finden Sie hier:
+ [AWS IoT Geräte-SDK SDK for Java v2 auf GitHub](https://github.com/aws/aws-iot-device-sdk-java-v2)
+ [AWS IoT Readme zum Geräte-SDK für Java v2](https://github.com/aws/aws-iot-device-sdk-java-v2#aws-iot-device-sdk-for-java-v2)
+ [AWS IoT Geräte-SDK SDK for Java v2-Beispiele](https://github.com/aws/aws-iot-device-sdk-java-v2/tree/main/samples#sample-apps-for-the-aws-iot-device-sdk-for-java-v2)
+ [AWS IoT API-Dokumentation zum Geräte-SDK für Java v2](https://aws.github.io/aws-iot-device-sdk-java-v2/)
------
#### [ Embedded C ]
**AWS IoT Geräte-SDK für Embedded C**
**Wichtig**
Dieses SDK ist für die Verwendung durch erfahrene Entwickler eingebetteter Software vorgesehen.
Das AWS IoT Device SDK for Embedded C (C-SDK) ist eine Sammlung von C-Quelldateien unter der MIT-Open-Source-Lizenz, die in eingebetteten Anwendungen verwendet werden können, um IoT-Geräte sicher mit AWS IoT Core zu verbinden. Es umfasst MQTT-, JSON Parser- und AWS IoT Device Shadow-Bibliotheken und andere. Es wird als Quellcode verteilt und soll zusammen mit einem Anwendungscode, anderen Bibliotheken und optional einem RTOS (Real Time Operating System) in die Kunden-Firmware integriert werden.
Das AWS IoT Device SDK for Embedded C richtet sich im Allgemeinen an Geräte mit eingeschränkten Ressourcen, die eine optimierte Laufzeit in C-Sprache benötigen. Sie können das SDK auf jedem Betriebssystem verwenden und es auf jedem Prozessortyp hosten (z. B. MCUs und MPUs). Wenn auf Ihrem Gerät genügend Speicher- und Verarbeitungsressourcen verfügbar sind, empfehlen wir Ihnen, eines der anderen AWS IoT Geräte- und Mobilgeräte zu verwenden SDKs, z. B. das AWS IoT Geräte-SDK SDK for C\$1\$1 JavaScript, Java oder Python.
Weitere Informationen finden Sie hier:
+ [AWS IoT Geräte-SDK für Embedded C auf GitHub](https://github.com/aws/aws-iot-device-sdk-embedded-C)
+ [AWS IoT Readme-Datei zum Geräte-SDK für Embedded C](https://github.com/aws/aws-iot-device-sdk-embedded-C#aws-iot-device-sdk-for-embedded-c)
+ [AWS IoT Geräte-SDK für eingebettete C-Beispiele](https://docs.aws.amazon.com/embedded-csdk/latest/lib-ref/docs/doxygen/output/html/demos_main.html)
------
# 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.
------
# MQTT-Themen
MQTT-Themen identifizieren AWS IoT Nachrichten. AWS IoT Clients identifizieren die Nachrichten, die sie veröffentlichen, indem sie den Nachrichten Themennamen geben. Clients identifizieren die Nachrichten, die sie abonnieren (empfangen) möchten, indem sie einen Themenfilter bei AWS IoT Core registrieren. Der Message Broker verwendet Themennamen und Themenfilter, um Nachrichten von veröffentlichenden Clients an abonnierende Clients zu senden.
Der Message Broker verwendet Topics, um Nachrichten zu identifizieren, die über MQTT und über HTTP an die [HTTPS-Nachrichten-URL](http.md#httpurl) gesendet wurden.
AWS IoT Unterstützt zwar einige [reservierte Systemthemen](reserved-topics.md), die meisten MQTT-Themen werden jedoch von Ihnen, dem Systemdesigner, erstellt und verwaltet. AWS IoT verwendet Themen, um Nachrichten zu identifizieren, die von Publishing-Clients empfangen wurden, und um Nachrichten auszuwählen, die an abonnierte Clients gesendet werden sollen, wie in den folgenden Abschnitten beschrieben. Bevor Sie einen Themen-Namespace für Ihr System erstellen, überprüfen Sie die Merkmale von MQTT-Themen, um die Hierarchie der Themennamen zu erstellen, die für Ihr IoT-System am besten geeignet ist.
## Themennamen
Themennamen und Themenfilter sind UTF-8-codierte Zeichenfolgen. Sie können eine Hierarchie von Informationen darstellen, indem Sie den Schrägstrich (/) verwenden, um die Ebenen der Hierarchie zu trennen. Dieser Themenname könnte sich beispielsweise auf einen Temperatursensor in Raum 1 beziehen:
+ `sensor/temperature/room1`
In diesem Beispiel kann es auch andere Arten von Sensoren in anderen Räumen mit Themennamen geben, z. B.:
+ `sensor/temperature/room2`
+ `sensor/humidity/room1`
+ `sensor/humidity/room2`
**Anmerkung**
Beachten Sie bei der Betrachtung von Themennamen für die Nachrichten in Ihrem System Folgendes:
Themennamen und Themenfilter berücksichtigen Groß- und Kleinschreibung.
Themennamen dürfen keine personenbezogenen Informationen enthalten.
Themennamen, die mit einem "\$1" beginnen, sind [reservierte Themen](reserved-topics.md), die nur von AWS IoT Core verwendet werden können.
AWS IoT Core kann keine Nachrichten zwischen AWS-Konto s oder Regionen senden oder empfangen.
Weitere Informationen zum Entwurf von Themennamen und Ihres Namespaces finden Sie in unserem Whitepaper [Entwerfen von MQTT-Themen für AWS IoT Core](https://docs.aws.amazon.com/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.html).
Beispiele dafür, wie Apps Nachrichten veröffentlichen und abonnieren können, finden Sie am Anfang mit [Erste Schritte mit AWS IoT Core Tutorials](iot-gs.md) und [AWS IoT Geräte SDKs - SDKs, Mobil- und AWS IoT Geräteclient](iot-sdks.md).
**Wichtig**
Der Themennamespace ist auf eine Region AWS-Konto und beschränkt. Beispielsweise unterscheidet sich das von einem AWS-Konto in einer Region verwendete `sensor/temp/room1` Thema von dem `sensor/temp/room1` Thema, das von demselben AWS Konto in einer anderen Region oder von einem anderen AWS-Konto in einer anderen Region verwendet wird.
## Thema-ARN
Alle Themen ARNs (Amazon-Ressourcennamen) haben die folgende Form:
```
arn:aws:iot:aws-region:AWS-account-ID:topic/Topic
```
Zum Beispiel ist `arn:aws:iot:us-west-2:123EXAMPLE456:topic/application/topic/device/sensor` ein ARN für das Thema ` application/topic/device/sensor`.
## Filter für Themennamen
Abonnierende Clients registrieren Themennamenfilter beim Message Broker, um die Nachrichtenthemen anzugeben, die der Message Broker an sie senden soll. Ein Themennamenfilter kann ein einzelner Themenname sein, um einen einzelnen Themennamen zu abonnieren, oder er kann Platzhalterzeichen enthalten, um mehrere Themennamen gleichzeitig zu abonnieren.
Veröffentlichende Clients können keine Platzhalterzeichen in den von ihnen veröffentlichten Themennamen verwenden.
In der folgenden Tabelle sind die Platzhalterzeichen aufgeführt, die in einem Themenfilter verwendet werden können.
**Themenplatzhalter**
| Platzhalterzeichen | Entspricht | Hinweise |
| --- | --- | --- |
| \$1 | Alle Zeichenfolgen auf und unter seiner Ebene in der Themenhierarchie. | Muss das letzte Zeichen im Themenfilter sein. Muss das einzige Zeichen auf seiner Ebene der Themenhierarchie sein. Kann in einem Themenfilter verwendet werden, der auch das Platzhalterzeichen "\$1" enthält. |
| \$1 | Jede Zeichenfolge in der Ebene, die das Zeichen enthält. | Muss das einzige Zeichen auf seiner Ebene der Themenhierarchie sein. Kann in mehreren Ebenen eines Themenfilters verwendet werden. |
Verwenden von Platzhaltern mit den vorherigen Beispielen der Sensor-Themennamen:
+ Ein Abonnement für `sensor/#` empfängt Nachrichten, die für `sensor/`, `sensor/temperature` oder `sensor/temperature/room1` veröffentlicht werden, nicht jedoch Nachrichten, die für `sensor` veröffentlicht werden.
+ Ein Abonnement für `sensor/+/room1` empfängt Nachrichten, die für `sensor/temperature/room1` und `sensor/humidity/room1` veröffentlicht wurden, aber keine Nachrichten, die an `sensor/temperature/room2` oder `sensor/humidity/room2` gesendet wurden.
### Themenfilter-ARN
Alle Themenfilter ARNs (Amazon-Ressourcennamen) haben die folgende Form:
```
arn:aws:iot:aws-region:AWS-account-ID:topicfilter/TopicFilter
```
`arn:aws:iot:us-west-2:123EXAMPLE456:topicfilter/application/topic/+/sensor` ist beispielsweise ein ARN für den Themenfilter` application/topic/+/sensor`.
# Nutzlast von MQTT-Nachrichten
Die Nachrichten-Payload, die in Ihren MQTT-Nachrichten gesendet wird, ist nicht spezifiziert von AWS IoT, es sei denn, sie bezieht sich auf eine der [Reservierte Themen](reserved-topics.md) Um den Anforderungen Ihrer Anwendung gerecht zu werden, empfehlen wir Ihnen, die Nachrichtennutzlast für Ihre Themen innerhalb der Einschränkungen der [AWS IoT Core Service Quotas für Protokolle](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#iot-protocol-limits) zu definieren.
Die Verwendung eines JSON-Formats für Ihre Nachrichtennutzdaten ermöglicht es der AWS IoT Regel-Engine, Ihre Nachrichten zu analysieren und SQL-Abfragen darauf anzuwenden. Wenn Ihre Anwendung die Regel-Engine nicht benötigt, um SQL-Abfragen auf Ihre Nachrichtennutzlasten anzuwenden, können Sie jedes Datenformat verwenden, das Ihre Anwendung benötigt. Hinweise zu Einschränkungen und reservierten Zeichen in einem JSON-Dokument, das in SQL-Abfragen verwendet wird, finden Sie unter [JSON-Erweiterungen](iot-sql-json.md).
Weitere Informationen zum Entwerfen Ihrer MQTT-Themen und der entsprechenden Nachrichtennutzlasten finden Sie unter [Entwurf von MQTT-Themen für AWS IoT Core](https://docs.aws.amazon.com/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.html).
Überschreitet eine Nachricht das Größenlimit des Dienstes, führt dies zu einem `CLIENT_ERROR` mit dem Grund `PAYLOAD_LIMIT_EXCEEDED` und "Die Nutzlast der Nachricht überschreitet das Größenlimit für den Nachrichtentyp". Weitere Informationen zur Größenbeschränkung für Nachrichten finden Sie unter [AWS IoT Core Grenzwerte und Kontingente für Message Broker](https://docs.aws.amazon.com//general/latest/gr/iot-core.html#message-broker-limits.html).
# Reservierte Themen
Themen, die mit einem Dollarzeichen (\$1) beginnen, sind für die Nutzung durch reserviert AWS IoT. Sie können diese reservierten Themen abonnieren und veröffentlichen, wenn sie dies zulassen. Sie können jedoch keine neuen Themen erstellen, die mit einem Dollarzeichen beginnen. Nicht unterstützte Veröffentlichungs- oder Abonnementvorgänge für reservierte Themen können zu einer abgebrochenen Verbindung führen.
## Komponentenmodell-Themen
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1 aws/sitewise/asset -models/ /assets/ /properties/ *assetModelId* *assetId* *propertyId* | Abonnieren | AWS IoT SiteWise veröffentlicht Benachrichtigungen zu Vermögenswerten zu diesem Thema. Weitere Informationen finden Sie im *AWS IoT SiteWise Benutzerhandbuch* unter [Interaktion mit anderen AWS Diensten](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/interact-with-other-services.html). |
## AWS IoT Device Defender Themen
Diese Nachrichten unterstützen je nach Thema Antwortpuffer im Format Concise Binary JavaScript Object Representation (CBOR) und Object Notation (JSON). *payload-format* AWS IoT Device Defender Themen unterstützen nur MQTT-Veröffentlichungen.
| *payload-format* | Datentyp des Antwortformats |
| --- | --- |
| cbor | Concise Binary Object Representation (CBOR) |
| json | JavaScript Objektnotation (JSON) |
Weitere Informationen finden Sie unter [Metriken von Geräten senden](https://docs.aws.amazon.com/iot-device-defender/latest/devguide/detect-device-side-metrics.html#DetectMetricsMessages).
| Thema | Zulässige Operationen | Description |
| --- | --- | --- |
| \$1aws/things/ /defender/metrics/ *thingName* *payload-format* | Veröffentlichen | AWS IoT Device Defender Agenten veröffentlichen Metriken zu diesem Thema. Weitere Informationen finden Sie unter [Metriken von Geräten senden](https://docs.aws.amazon.com/iot-device-defender/latest/devguide/detect-device-side-metrics.html#DetectMetricsMessages). |
| \$1aws/things/ /defender/metrics/ /accepted *thingName* *payload-format* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, nachdem ein Agent eine erfolgreiche Nachricht in \$1aws/things/ /defender/metrics/ veröffentlicht hat. AWS IoT Device Defender *thingName* *payload-format* Weitere Informationen [finden Sie](https://docs.aws.amazon.com/iot-device-defender/latest/devguide/detect-device-side-metrics.html#DetectMetricsMessages) unter Metriken von Geräten senden. |
| \$1aws/things/ /defender/metrics/ /rejected *thingName* *payload-format* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, nachdem ein Agent eine erfolglose Nachricht in \$1aws/things/ /defender/metrics/ veröffentlicht hat. AWS IoT Device Defender *thingName* *payload-format* Weitere Informationen [finden Sie](https://docs.aws.amazon.com/iot-device-defender/latest/devguide/detect-device-side-metrics.html#DetectMetricsMessages) unter Metriken von Geräten senden. |
## AWS IoT Core Themen zum Gerätestandort
AWS IoT Core Device Location kann die Messdaten von Ihrem Gerät auflösen und einen geschätzten Standort Ihrer IoT-Geräte angeben. Die Messdaten des Geräts können GNSS-, WLAN-, Mobilfunk- und IP-Adressen umfassen. AWS IoT Core Der Gerätestandort wählt dann den Messtyp aus, der die beste Genauigkeit bietet, und berechnet die Standortinformationen des Geräts. Weitere Informationen erhalten Sie unter [AWS IoT Core Standort des Geräts](device-location.md) und [Auflösen des Gerätestandorts mithilfe der AWS IoT Core MQTT-Themen zum Gerätestandort](device-location-reserved-topics.md).
| Thema | Zulässige Operationen | Description |
| --- | --- | --- |
| \$1aws/device\$1location/ /get\$1position\$1estimate *customer\$1device\$1id* | Veröffentlichen | Ein Gerät veröffentlicht zu diesem Thema, um die gescannten Rohmessdaten nach Gerätestandort aufzulösen. AWS IoT Core |
| \$1aws/device\$1location/ /get\$1position\$1estimate/accepted *customer\$1device\$1id* | Abonnieren | AWS IoT Core Device Location veröffentlicht zu diesem Thema, nachdem der Gerätestandort erfolgreich ermittelt wurde. |
| \$1aws/device\$1location/ /get\$1position\$1estimate/rejected *customer\$1device\$1id* | Abonnieren | AWS IoT Core Device Location veröffentlicht zu diesem Thema, wenn der Gerätestandort aufgrund von 4xx-Fehlern nicht erfolgreich ermittelt werden kann. |
## Ereignisthemen
Die Ereignismeldungen werden veröffentlicht, wenn bestimmte Ereignisse eintreten. Beispielsweise werden Ereignisse von der Registry generiert, wenn Geräte hinzugefügt, aktualisiert oder gelöscht werden. Die Tabelle zeigt die verschiedenen AWS IoT Ereignisse und ihre reservierten Themen.
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/events/certificates/registered/*caCertificateId* | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Zertifikat AWS IoT automatisch registriert wird und wenn ein Client ein Zertifikat mit dem `PENDING_ACTIVATION` Status vorlegt. Weitere Informationen finden Sie unter [Konfigurieren der ersten Verbindung durch einen Client für die automatische Registrierung](auto-register-device-cert.md#configure-auto-reg-first-connect). |
| \$1aws/events/job/*jobID*/storniert | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Job storniert wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job/jobID/cancellation\$1in\$1progress | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Job storniert wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job/*jobID*/abgeschlossen | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Job abgeschlossen ist. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job/jobID/gelöscht | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Job gelöscht wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job/jobID/deletion\$1in\$1progress | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn ein Job gelöscht wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/storniert | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn die Ausführung eines Jobs abgebrochen wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/gelöscht | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn eine Jobausführung gelöscht wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/ist fehlgeschlagen | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn die Ausführung eines Jobs fehlgeschlagen ist. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/abgelehnt | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn die Ausführung eines Jobs abgelehnt wurde. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/entfernt | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn eine Jobausführung entfernt wurde. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/war erfolgreich | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn eine Jobausführung erfolgreich war. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/jobID/timed\$1out | Abonnieren | AWS IoT veröffentlicht diese Nachricht, wenn bei der Ausführung eines Jobs das Timeout überschritten wurde. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/presence/connected/*clientId* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein MQTT-Client mit der angegebenen Client-ID eine Verbindung herstellt. AWS IoT Weitere Informationen finden Sie unter [„Verbinden/Verbindung trennen“-Ereignisse](life-cycle-events.md#connect-disconnect). |
| \$1aws/events/presence/disconnected/*clientId* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein MQTT-Client mit der angegebenen Client-ID die Verbindung trennt. AWS IoT Weitere Informationen finden Sie unter [„Verbinden/Verbindung trennen“-Ereignisse](life-cycle-events.md#connect-disconnect). |
| \$1aws/events/subscriptions/subscribed/*clientId* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein MQTT-Client mit der angegebenen Client-ID ein MQTT-Thema abonniert. Weitere Informationen finden Sie unter [„Abonnieren/Abonnement beenden“-Ereignisse](life-cycle-events.md#subscribe-unsubscribe-events). |
| \$1aws/events/subscriptions/unsubscribed/*clientId* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein MQTT-Client mit der angegebenen Client-ID ein MQTT-Thema abbestellt. Weitere Informationen finden Sie unter [„Abonnieren/Abonnement beenden“-Ereignisse](life-cycle-events.md#subscribe-unsubscribe-events). |
| \$1//erstellt aws/events/thing *thingName* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn das *thingName* Ding erstellt wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thing/*thingName*/aktualisiert | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn das *thingName* Ding aktualisiert wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thing/*thingName*/gelöscht | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn das *thingName* Ding gelöscht wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroup/*thingGroupName*/erstellt | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn die Dinggruppe erstellt *thingGroupName* wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroup/*thingGroupName*/aktualisiert | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn die Dinggruppe aktualisiert *thingGroupName* wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroup/*thingGroupName*/gelöscht | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn die Dinggruppe gelöscht *thingGroupName* wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingType/*thingTypeName*/erstellt | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn der *thingTypeName* Dingtyp erstellt wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingType/*thingTypeName*/aktualisiert | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn der *thingTypeName* Dingtyp aktualisiert wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingType/*thingTypeName*/gelöscht | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn der *thingTypeName* Dingtyp gelöscht wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingTypeAssociation/thing/*thingName*/*thingTypeName* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn *thingName* ein Objekt mit einem Dingtyp verknüpft oder vom Dingtyp *thingTypeName* getrennt wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroupMembership/thingGroup/*thingGroupName*/thing/ /hinzugefügt *thingName* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein Objekt zur *thingName* Dinggruppe hinzugefügt wird. *thingGroupName* Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroupMembership/thingGroup/*thingGroupName*/thing/ /removed *thingName* | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn ein Objekt aus der *thingName* Dinggruppe entfernt wird. *thingGroupName* Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroupHierarchy/thingGroup//*parentThingGroupName*childThingGroup/*childThingGroupName*/hinzugefügt | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn die Dinggruppe zur Dinggruppe *parentThingGroupName* hinzugefügt *childThingGroupName* wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
| \$1aws/events/thingGroupHierarchy/thingGroup//*parentThingGroupName*childThingGroup/*childThingGroupName*/wurde entfernt | Abonnieren | AWS IoT veröffentlicht zu diesem Thema, wenn die Dinggruppe aus der Dinggruppe *parentThingGroupName* entfernt *childThingGroupName* wird. Weitere Informationen finden Sie unter [Registry-Ereignisse](registry-events.md). |
## Flottenbereitstellungsthemen
**Anmerkung**
Die Client-Operationen, die in dieser Tabelle als **Empfangen** angegeben sind, weisen auf Themen hin, die direkt auf dem Client AWS IoT veröffentlicht werden, der sie angefordert hat, unabhängig davon, ob der Client das Thema abonniert hat oder nicht. Kunden sollten damit rechnen, diese Antwortnachrichten zu erhalten, auch wenn sie sie nicht abonniert haben. Diese Antwortnachrichten werden nicht über den Message Broker weitergeleitet und können auch nicht von anderen Clients oder Regeln abonniert werden.
Diese Nachrichten unterstützen je nach Thema Antwortpuffer im Format Concise Binary Object Representation (CBOR) und JavaScript Object Notation (JSON). *payload-format*
| *payload-format* | Datentyp des Antwortformats |
| --- | --- |
| cbor | Concise Binary Object Representation (CBOR) |
| json | JavaScript Objektnotation (JSON) |
Weitere Informationen finden Sie unter [MQTT-API für die Gerätebereitstellung](fleet-provision-api.md).
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/certificates/create/*payload-format* | Veröffentlichen | Veröffentlichen Sie in diesem Thema, um ein Zertifikat über eine Zertifikatssignierungsanforderung (Certificate Signing Request, CSR) zu erstellen. |
| \$1aws/certificates/create/*payload-format*/akzeptiert | Abonnieren, Empfangen | AWS IoT veröffentlicht nach einem erfolgreichen Aufruf von \$1aws/certificates/create/*payload-format*zu diesem Thema. |
| \$1aws/certificates/create/*payload-format*/abgelehnt | Abonnieren, Empfangen | AWS IoT veröffentlicht nach einem erfolglosen Aufruf von \$1aws/certificates/create/*payload-format*zu diesem Thema. |
| \$1 aws/certificates/create -from-csr/ *payload-format* | Veröffentlichen | Veröffentlicht in diesem Thema, um ein Zertifikat aus einer CSR zu erstellen. |
| \$1 aws/certificates/create -from-csr/ /akzeptiert *payload-format* | Abonnieren, Empfangen | AWS IoT veröffentlicht zu diesem Thema einen erfolgreichen Aufruf von \$1 -from-csr/. aws/certificates/create *payload-format* |
| \$1 -from-csr/ /abgelehnt aws/certificates/create *payload-format* | Abonnieren, Empfangen | AWS IoT veröffentlicht zu diesem Thema einen erfolglosen Aufruf von \$1 -from-csr/. aws/certificates/create *payload-format* |
| *templateName*\$1aws/provisioning-templates/ /provision/ *payload-format* | Veröffentlichen | Veröffentlichen Sie in diesem Thema, um ein Objekt zu registrieren. |
| \$1aws/provisioning-templates/ *templateName* /provision/ /accepted *payload-format* | Abonnieren, Empfangen | AWS IoT veröffentlicht nach einem erfolgreichen Aufruf von \$1aws/provisioning-templates/ /provision/ zu diesem Thema. *templateName* *payload-format* |
| \$1aws/provisioning-templates/ /provision/ /rejected *templateName* *payload-format* | Abonnieren, Empfangen | AWS IoT veröffentlicht nach einem erfolglosen Aufruf von \$1aws/provisioning-templates/ /provision/ zu diesem Thema. *templateName* *payload-format* |
## Auftragsthemen
**Anmerkung**
Die Client-Operationen, die in dieser Tabelle als **Empfangen** angegeben sind, weisen auf Themen hin, die direkt auf dem Client AWS IoT veröffentlicht werden, der sie angefordert hat, unabhängig davon, ob der Client das Thema abonniert hat oder nicht. Kunden sollten damit rechnen, diese Antwortnachrichten zu erhalten, auch wenn sie sie nicht abonniert haben.
Diese Antwortnachrichten werden nicht über den Message Broker weitergeleitet und können auch nicht von anderen Clients oder Regeln abonniert werden. Verwenden Sie die `notify` und `notify-next` Themen und, um Nachrichten zu Auftragsaktivitäten zu abonnieren.
Wenn Sie die Auftrags- und `jobExecution` Veranstaltungsthemen für Ihre Flottenüberwachungslösung abonnieren, müssen Sie zunächst die [Auftrags- und Auftragsausführungsereignisse](iot-events.md) aktivieren, um alle Ereignisse auf der Cloud-Seite empfangen zu können.
Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md).
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/things/ /jobs/get *thingName* | Veröffentlichen | Geräte veröffentlichen eine Nachricht in diesem Topic, um eine `GetPendingJobExecutions`-Anforderung auszugeben. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| *thingName*\$1aws/things/ jobs/get/accepted | Abonnieren, empfangen | Geräte abonnieren dieses Thema, um Antworten von einer `GetPendingJobExecutions`-Anforderung zu empfangen. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/Dinge/*thingName*/jobs/get/rejected | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um eine Antwort zu erhalten, wenn eine `GetPendingJobExecutions` Anforderung abgelehnt wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ *thingName* /jobs/start-next | Veröffentlichen | Geräte veröffentlichen eine Nachricht in diesem Topic, um eine `StartNextPendingJobExecution`-Anforderung auszugeben. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| *thingName*\$1aws/things/ jobs/start-next/accepted | Abonnieren, Empfangen | Geräte abonnieren dieses Topic, um Antworten an eine `StartNextPendingJobExecution`-Anforderung zu empfangen. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/Dinge/*thingName*/jobs/start-next/rejected | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um eine Antwort zu erhalten, wenn eine `StartNextPendingJobExecution` Anforderung abgelehnt wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/ /get *thingName* *jobId* | Veröffentlichen | Geräte veröffentlichen eine Nachricht in diesem Topic, um eine `DescribeJobExecution`-Anforderung auszugeben. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/ *thingName* /get/accepted *jobId* | Abonnieren, Empfangen | Geräte abonnieren dieses Topic, um Antworten an eine `DescribeJobExecution`-Anforderung zu empfangen. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/ *thingName* /get/rejected *jobId* | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um eine Antwort zu erhalten, wenn eine `DescribeJobExecution` Anforderung abgelehnt wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/ *thingName* /update *jobId* | Veröffentlichen | Geräte veröffentlichen eine Nachricht in diesem Thema, um eine `UpdateJobExecution`-Anforderung auszugeben. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/ *thingName* /update/akzeptiert *jobId* | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um Erfolgsantworten auf eine `UpdateJobExecution`-Anforderung zu empfangen. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). Hinweis Nur das Gerät, das auf \$1aws/things/ /jobs/ /update veröffentlicht, empfängt Nachrichten zu diesem Thema. *thingName* *jobId* |
| \$1aws/things/ /jobs/ /update/rejected *thingName* *jobId* | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um eine Antwort zu erhalten, wenn eine `UpdateJobExecution` Anforderung abgelehnt wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). Hinweis Nur das Gerät, das auf \$1aws/things/ /jobs/ /update veröffentlicht, empfängt Nachrichten zu diesem Thema. *thingName* *jobId* |
| \$1aws/things/ /jobs/notify *thingName* | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um Benachrichtigungen zu empfangen, wenn eine Auftragsausführung der Liste der ausstehenden Ausführungen für ein Objekt hinzugefügt oder aus dieser entfernt wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1aws/things/ /jobs/notify-next *thingName* | Abonnieren, Empfangen | Geräte abonnieren dieses Thema, um Benachrichtigungen zu empfangen, wenn die nächste ausstehende Auftragsausführung für das Objekt geändert wird. Weitere Informationen finden Sie unter [Führt MQTT-API-Operationen auf dem Gerät aus](jobs-mqtt-api.md). |
| \$1//abgeschlossen aws/events/job *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn ein Auftrag abgeschlossen wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job//storniert *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn ein Auftrag abgebrochen wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job//gelöscht *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn ein Auftrag gelöscht wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job//cancellation\$1in\$1progress *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsstornierung beginnt. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/job/*jobId*/deletion\$1in\$1progress | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragslöschung beginnt. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/*jobId*/war erfolgreich | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn der Auftrag erfolgreich ausgeführt wurde. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution/*jobId*/ist fehlgeschlagen | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsausführung fehlschlägt. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution//abgelehnt *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsausführung abgewiesen wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution//storniert *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsausführung storniert wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution//timed\$1out *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Zeitüberschreitung der Auftragsausführung auftritt. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1//wurde entfernt aws/events/jobExecution *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsausführung entfernt wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
| \$1aws/events/jobExecution//gelöscht *jobId* | Abonnieren | Der Jobs-Service veröffentlicht ein Ereignis in diesem Thema, wenn eine Auftragsausführung gelöscht wird. Weitere Informationen finden Sie unter [Auftragsereignisse](events-jobs.md). |
## Themen zu Befehlen
**Anmerkung**
Die in dieser Tabelle als **Empfangen** vermerkten Client-Operationen beziehen sich auf Themen, die direkt auf dem Client AWS IoT veröffentlicht werden, der sie angefordert hat, unabhängig davon, ob der Client das Thema abonniert hat oder nicht. Kunden sollten damit rechnen, diese Antwortnachrichten zu erhalten, auch wenn sie sie nicht abonniert haben.
Diese Antwortnachrichten werden nicht über den Message Broker weitergeleitet und können auch nicht von anderen Clients oder Regeln abonniert werden.
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/commands///executions/ /request/ ** ** ** ** \$1aws/commands//****/executions/ /request ** | Abonnieren, Empfangen | Geräte erhalten eine Nachricht zu diesem Thema, wenn eine Anfrage gestellt wird, eine Befehlsausführung von der Konsole oder über die API zu starten. `StartCommandExecution` In diesem Fall ** kann es sich entweder um IoT-Dings oder um MQTT-Clients handeln und es ** kann sich entweder um den IoT-Dingnamen oder die MQTT-Client-ID handeln. |
| \$1aws/commands/ /executions/ /response/ ** ** ** ** | Veröffentlichen | Geräte verwenden die `UpdateCommandExecution` MQTT-API, um zu diesem Thema eine Nachricht über die Befehlsausführung zu veröffentlichen. Die Nachricht wird als Antwort auf die Anfrage veröffentlicht, eine Befehlsausführung über die Konsole oder über die `StartCommandExecution` API zu starten. Die veröffentlichte Nachricht verwendet JSON oder CBOR als. ** |
| \$1aws/commands///executions/ /response/accepted/ ** ** ** ** \$1aws/commands//****/executions/ /response/accepted ** | Abonnieren, Empfangen | Wenn der Cloud-Dienst das Ergebnis der Befehlsausführung erfolgreich verarbeitet hat, veröffentlicht er eine Antwort auf das Thema /accepted. AWS IoT Device Management |
| \$1aws/commands///executions/ /response/rejected/ ** ** ** ** \$1aws/commands//****/executions/ /response/rejected ** | Veröffentlichen | Wenn der Cloud-Dienst das Ergebnis der Befehlsausführung nicht verarbeiten konnte, veröffentlicht er eine Antwort auf das Thema /rejected. AWS IoT Device Management |
## Regelthemen
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/rules/ *ruleName* | Veröffentlichen | Ein Gerät oder eine Anwendung veröffentlicht in diesem Thema, um Regeln direkt auszulösen. Weitere Informationen finden Sie unter [Senken der Messaging-Kosten mit Basic Ingest](iot-basic-ingest.md). |
## Themen zu Secure Tunneling
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/things/ /tunnels/notify *thing-name* | Abonnieren | AWS IoT veröffentlicht diese Nachricht für einen IoT-Agenten, um einen lokalen Proxy auf dem Remote-Gerät zu starten. Weitere Informationen finden Sie unter [IoT-Agent-Snippet](configure-remote-device.md#agent-snippet). |
## Schatten-Themen
Die Themen in diesem Abschnitt werden von benannten und unbenannten Schatten verwendet. Die jeweils verwendeten Themen unterscheiden sich nur durch das Themenpräfix. In dieser Tabelle wird das Themenpräfix angezeigt, das von jedem Schattentyp verwendet wird.
| *ShadowTopicPrefix* Wert | Schattentyp |
| --- | --- |
| \$1aws/things/ /shadow thingName | Unbenannter (klassischer) Schatten |
| \$1aws/things/ thingName /shadow/name/ shadowName | Benannter Schatten |
Um ein vollständiges Thema zu erstellen, wählen Sie *ShadowTopicPrefix* für den Typ des Schattens, auf den Sie sich beziehen möchten, ersetzen *thingName* und, falls zutreffend, durch die entsprechenden Werte*shadowName*, und fügen Sie diesen dann den Themen-Stub hinzu, wie in der folgenden Tabelle dargestellt. Denken Sie daran, dass bei Themen zwischen Groß- und Kleinschreibung unterschieden wird.
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| *ShadowTopicPrefix*/löschen | Veröffentlichen/Abonnieren | Ein Gerät oder eine Anwendung veröffentlicht in diesem Thema, um ein Schattengerät zu löschen. Weitere Informationen finden Sie unter [/delete](device-shadow-mqtt.md#delete-pub-sub-topic). |
| *ShadowTopicPrefix*/löschen/akzeptiert | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn ein Schattengerät gelöscht wird. Weitere Informationen finden Sie unter [/delete/accepted](device-shadow-mqtt.md#delete-accepted-pub-sub-topic). |
| *ShadowTopicPrefix*/löschen/abgelehnt | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn ein Anfrage zum Löschen eines Schattengeräts abgelehnt wird. Weitere Informationen finden Sie unter [/delete/rejected](device-shadow-mqtt.md#delete-rejected-pub-sub-topic). |
| *ShadowTopicPrefix*/erhalten | Veröffentlichen/Abonnieren | Eine Anwendung oder ein Gerät veröffentlicht eine leere Nachricht für dieses Thema, um ein Schattengerät zugewiesen zu bekommen. Weitere Informationen finden Sie unter [MQTT-Themen für Geräteschatten](device-shadow-mqtt.md). |
| *ShadowTopicPrefix*/get/akzeptiert | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn ein Anfrage für ein Schattengerät erfolgreich war. Weitere Informationen finden Sie unter [/get/accepted](device-shadow-mqtt.md#get-accepted-pub-sub-topic). |
| *ShadowTopicPrefix*/get/abgelehnt | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn ein Anfrage für ein Schattengerät abgelehnt wird. Weitere Informationen finden Sie unter [/get/rejected](device-shadow-mqtt.md#get-rejected-pub-sub-topic). |
| *ShadowTopicPrefix*/aktualisieren | Veröffentlichen/Abonnieren | Ein Gerät oder eine Anwendung veröffentlicht eine Nachricht in diesem Thema, um ein Schattengerät zu aktualisieren. Weitere Informationen finden Sie unter [/update](device-shadow-mqtt.md#update-pub-sub-topic). |
| *ShadowTopicPrefix*/update/akzeptiert | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn ein Schattengerät erfolgreich aktualisiert wurde. Weitere Informationen finden Sie unter [/update/accepted](device-shadow-mqtt.md#update-accepted-pub-sub-topic). |
| *ShadowTopicPrefix*/update/abgelehnt | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn die Aktualisierung eines Schattengeräts abgelehnt wurde. Weitere Informationen finden Sie unter [/update/rejected](device-shadow-mqtt.md#update-rejected-pub-sub-topic). |
| *ShadowTopicPrefix*/update/delta | Abonnieren | Der Device Shadow-Service sendet Nachrichten an dieses Thema, wenn zwischen den gemeldeten und gewünschten Abschnitten eines Schattengeräts Abweichungen auftreten. Weitere Informationen finden Sie unter [/update/delta](device-shadow-mqtt.md#update-delta-pub-sub-topic). |
| *ShadowTopicPrefix*/update/dokumente | Abonnieren | AWS IoT veröffentlicht jedes Mal, wenn eine Aktualisierung des Shadows erfolgreich durchgeführt wurde, ein Statusdokument zu diesem Thema. Weitere Informationen finden Sie unter [/update/documents](device-shadow-mqtt.md#update-documents-pub-sub-topic). |
## Themen der MQTT-basierten Dateiübertragung
**Anmerkung**
Die Client-Operationen, die in dieser Tabelle als **Empfangen** angegeben sind, weisen auf Themen hin, die direkt auf dem Client AWS IoT veröffentlicht werden, der sie angefordert hat, unabhängig davon, ob der Client das Thema abonniert hat oder nicht. Kunden sollten damit rechnen, diese Antwortnachrichten zu erhalten, auch wenn sie sie nicht abonniert haben. Diese Antwortnachrichten werden nicht über den Message Broker weitergeleitet und können auch nicht von anderen Clients oder Regeln abonniert werden.
Diese Nachrichten unterstützen je nach Thema Antwortpuffer im Format Concise Binary Object Representation (CBOR) und JavaScript Object Notation (JSON). *payload-format*
| *payload-format* | Datentyp des Antwortformats |
| --- | --- |
| cbor | Concise Binary Object Representation (CBOR) |
| json | JavaScript Objektnotation (JSON) |
| Thema | Zulässige Client-Operationen | Description |
| --- | --- | --- |
| \$1aws/things/ /streams/ /data/ *ThingName* *StreamId* *payload-format* | Abonnieren, Empfangen | AWS Bei der MQTT-basierten Dateibereitstellung werden Beiträge zu diesem Thema veröffentlicht, wenn die "" -Anforderung von einem Gerät akzeptiert wird. GetStream Die Nutzlast enthält die Stream-Daten. Weitere Informationen finden Sie unter [Verwendung der AWS IoT MQTT-basierten Dateibereitstellung auf Geräten](mqtt-based-file-delivery-in-devices.md). |
| \$1aws/things/ /streams/ /get/ *ThingName* *StreamId* *payload-format* | Veröffentlichen | Ein Gerät veröffentlicht Beiträge zu diesem Thema, um eine "" Anfrage auszuführen. GetStream Weitere Informationen finden Sie unter [Verwendung der AWS IoT MQTT-basierten Dateibereitstellung auf Geräten](mqtt-based-file-delivery-in-devices.md). |
| \$1aws/things/ /streams/ /description/ *ThingName* *StreamId* *payload-format* | Abonnieren, Empfangen | AWS Bei der MQTT-basierten Dateibereitstellung wird zu diesem Thema veröffentlicht, wenn die "" -Anforderung von einem Gerät akzeptiert wird. DescribeStream Die Nutzlast enthält die Stream-Beschreibung. Weitere Informationen finden Sie unter [Verwendung der AWS IoT MQTT-basierten Dateibereitstellung auf Geräten](mqtt-based-file-delivery-in-devices.md). |
| \$1aws/things/ /streams/ /describe/ *ThingName* *StreamId* *payload-format* | Veröffentlichen | Ein Gerät veröffentlicht Beiträge zu diesem Thema, um eine "" Anfrage auszuführen. DescribeStream Weitere Informationen finden Sie unter [Verwendung der AWS IoT MQTT-basierten Dateibereitstellung auf Geräten](mqtt-based-file-delivery-in-devices.md). |
| \$1aws/things/ /streams/ /rejected/ *ThingName* *StreamId* *payload-format* | Abonnieren, Empfangen | AWS Bei der MQTT-basierten Dateibereitstellung werden Beiträge zu diesem Thema veröffentlicht, wenn eine "" - oder "" Anfrage von einem Gerät abgewiesen wird. DescribeStream GetStream Weitere Informationen finden Sie unter [Verwendung der AWS IoT MQTT-basierten Dateibereitstellung auf Geräten](mqtt-based-file-delivery-in-devices.md). |
## Reservierte Themen-ARN
Alle reservierten Themen ARNs (Amazon-Ressourcennamen) haben die folgende Form:
```
arn:aws:iot:aws-region:AWS-account-ID:topic/Topic
```
`arn:aws:iot:us-west-2:123EXAMPLE456:topic/$aws/things/thingName/jobs/get/accepted` ist beispielsweise ein ARN für das reservierte Thema `$aws/things/thingName/jobs/get/accepted`.
# Domain-Konfigurationen
In können Sie Domänenkonfigurationen verwenden AWS IoT Core, um das Verhalten Ihrer Datenendpunkte zu konfigurieren und zu verwalten. Mit Domänenkonfigurationen können Sie mehrere AWS IoT Core Datenendpunkte generieren, sie mit Ihren eigenen vollqualifizierten Domainnamen (FQDN) und zugehörigen Serverzertifikaten anpassen und auch einen benutzerdefinierten Autorisierer zuordnen. Weitere Informationen finden Sie unter [Benutzerspezifische Authentifizierung und Autorisierung](custom-authentication.md).
**Anmerkung**
Diese Funktion ist in nicht verfügbar. AWS GovCloud (US) AWS-Regionen
**Topics**
+ [Was ist eine Domain-Konfiguration?](iot-domain-configuration-what-is.md)
+ [AWS Verwaltete Domänen erstellen und konfigurieren](iot-custom-endpoints-configurable-aws.md)
+ [Vom Kunden verwaltete Domains erstellen und konfigurieren](iot-custom-endpoints-configurable-custom.md)
+ [Verwalten von Domänenkonfigurationen](iot-custom-endpoints-managing.md)
+ [Konfiguration von TLS-Einstellungen in Domänenkonfigurationen](iot-endpoints-tls-config.md)
+ [Konfiguration des Serverzertifikats für OCSP-Stapling](iot-custom-endpoints-cert-config.md)
# Was ist eine Domain-Konfiguration?
In bezieht AWS IoT Core sich eine Domänenkonfiguration auf die Einrichtung und Konfiguration einer Domain (entweder AWS verwaltete Domain oder kundenverwaltete Domain) für Ihre AWS IoT Core Datenendpunkte. AWS IoT Core stellt außerdem einen Standardendpunkt für Ihr AWS Konto (`iot:Data-ATS`) bereit, mit AWS IoT Core dem Geräte kommunizieren können.
**Topics**
+ [Anwendungsfälle](#iot-custom-endpoints-configurable-use-cases)
+ [Die wichtigsten Konzepte](#iot-domain-configuration-key-concepts)
+ [Wichtige Hinweise](#iot-custom-endpoints-configurable-notes)
## Anwendungsfälle
Sie können Domänenkonfigurationen verwenden, um Aufgaben wie die folgenden zu vereinfachen.
+ Migrieren Sie Geräte zu AWS IoT Core.
+ Unterstützung heterogener Geräteflotten durch Beibehaltung separater Domänenkonfigurationen für separate Gerätetypen.
+ Behalten Sie die Markenidentität bei (z. B. durch den Domainnamen) und migrieren Sie gleichzeitig die Anwendungsinfrastruktur zu AWS IoT Core.
## Die wichtigsten Konzepte
Die folgenden Konzepte enthalten Einzelheiten zu Domänenkonfigurationen und verwandten Konzepten.
+ **Domain-Konfiguration**
Die Einrichtung und Konfiguration einer Domain für Ihre AWS IoT Core Endgeräte.
+ **Standard-Endpunktdomäne**
Die Domäne, die den Standardendpunkt AWS IoT bereitstellt, z. `iot:Data-ATS` B. Um den Standardendpunkt zu finden, führen Sie den Befehl [describe-endpoint](https://docs.aws.amazon.com//cli/latest/reference/iot/describe-endpoint.html) oder [describe-domain-configuration](https://docs.aws.amazon.com//cli/latest/reference/iot/describe-domain-configuration.html)CLI aus. Gehen Sie alternativ zur AWS IoT Core Konsole und wählen Sie in der linken Navigationsleiste **Domain-Konfigurationen** aus **Connect** aus. Der Standardendpunkt wird zusammen mit dem Namen aufgeführt`iot:Data-ATS`.
+ **AWS verwaltete Domäne**
Die Domain, die verwaltet AWS wird. Wenn Sie sich für eine AWS verwaltete Domain entscheiden, stellen Ihre Geräte eine Verbindung über einen Datenendpunkt her, der von bereitgestellt wird AWS. AWS verwaltet die Domain und die Zertifikate.
+ **Vom Kunden verwaltete Domain**
Die Domain, die Sie verwalten werden. Wird auch als benutzerdefinierte Domain bezeichnet. Wenn Sie sich für eine vom Kunden verwaltete Domain entscheiden, bedeutet dies, dass Ihre Geräte über einen benutzerdefinierten Domain-Datenendpunkt eine Verbindung herstellen. Sie verwalten die Domain und die Zertifikate. Mit der vom Kunden verwalteten Domain können Sie den Endpunkt URLs an Ihre Bedürfnisse anpassen. Sie können beispielsweise einen benutzerdefinierten Domainnamen (`your-domain-name.com`) verwenden oder bestimmte Zugriffsrichtlinien anwenden.
+ **Authentifizierungstyp**
Der Authentifizierungstyp, mit dem Sie Ihre Geräte authentifizieren möchten, wenn Sie eine Verbindung herstellen AWS IoT Core. Beim Erstellen einer Domänenkonfiguration müssen Sie einen Authentifizierungstyp angeben. Weitere Informationen finden Sie unter [Wählen Sie einen Authentifizierungstyp für Ihre Gerätekommunikation](protocols.md#connection-protocol-auth-mode).
+ **Anwendungsprotokoll**
Die Protokolle auf Anwendungsebene, mit denen Ihre Geräte eine Verbindung herstellen AWS IoT Core. Beim Erstellen einer Domänenkonfiguration müssen Sie ein Anwendungsprotokoll angeben. Weitere Informationen finden Sie unter [Wählen Sie ein Anwendungsprotokoll für Ihre Gerätekommunikation](protocols.md#protocol-selection).
## Wichtige Hinweise
AWS IoT Core verwendet die [TLS-Erweiterung (Server Name Indication, SNI)](https://www.rfc-editor.org/rfc/rfc3546), um Domänenkonfigurationen anzuwenden. [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) Sie müssen des Weiteren einen Servernamen übergeben, der mit dem Domänennamen identisch ist, den Sie in der Domänenkonfiguration angeben. [Um diesen Dienst zu testen, verwenden Sie die Version v2 des Geräts in.AWS IoT SDKs](https://github.com/aws) GitHub
Wenn Sie in Ihrem mehrere Datenendpunkte erstellen AWS-Konto, teilen sich diese AWS IoT Core Ressourcen wie MQTT-Themen, Geräteschatten und Regeln gemeinsam.
Wenn Sie die Serverzertifikate für die AWS IoT Core benutzerdefinierte Domänenkonfiguration bereitstellen, haben die Zertifikate maximal vier Domainnamen. Weitere Informationen finden Sie unter [AWS IoT Core -Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#security-limits).
# AWS Verwaltete Domänen erstellen und konfigurieren
Mithilfe der [CreateDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_CreateDomainConfiguration.html)API erstellen Sie einen konfigurierbaren Endpunkt auf einer AWS verwalteten Domain. Eine Domänenkonfiguration für eine AWS verwaltete Domain besteht aus folgenden Komponenten:
+ `domainConfigurationName`
Ein benutzerdefinierter Name, der die Domänenkonfiguration identifiziert, und der Wert muss für Sie AWS-Region eindeutig sein. Sie können keine Domänenkonfigurationsnamen verwenden, die mit `IoT:` beginnen, da diese Standardendpunkten vorbehalten sind.
+ `defaultAuthorizerName` (optional)
Der Name des benutzerdefinierten Autorisierers, der am Endpunkt verwendet werden soll.
+ `allowAuthorizerOverride` (optional)
Ein boolescher Wert, der angibt, ob Geräte den Standard-Autorisierer überschreiben können, indem sie im HTTP-Header der Anfrage einen anderen Autorisierer angeben. Dieser Wert ist erforderlich, wenn ein Wert für `defaultAuthorizerName` angegeben wird.
+ `serviceType` (optional)
Der Diensttyp, den der Endpunkt bereitstellt. AWS IoT Core unterstützt nur den `DATA` Diensttyp. Wenn Sie `DATA` angeben, gibt AWS IoT Core einen Endpunkt mit dem Endpunkttyp `iot:Data-ATS` zurück. Sie können keinen konfigurierbaren Endpunkt `iot:Data` (VeriSign) erstellen.
+ `TlsConfig` (optional)
Ein Objekt, das die TLS-Konfiguration für eine Domäne spezifiziert. Weitere Informationen finden Sie unter [Konfiguration von TLS-Einstellungen in Domänenkonfigurationen](iot-endpoints-tls-config.md).
Der folgende AWS CLI Beispielbefehl erstellt eine Domänenkonfiguration für einen `Data` Endpunkt.
```
aws iot create-domain-configuration --domain-configuration-name "myDomainConfigurationName" --service-type "DATA"
```
Die Ausgabe des Befehls kann wie folgt aussehen.
```
{
"domainConfigurationName": "myDomainConfigurationName",
"domainConfigurationArn": "arn:aws:iot:us-east-1:123456789012:domainconfiguration/myDomainConfigurationName/itihw"
}
```
# Vom Kunden verwaltete Domains erstellen und konfigurieren
Mit Domänenkonfigurationen können Sie einen benutzerdefinierten vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) angeben, mit dem eine Verbindung zu AWS IoT Core hergestellt werden soll. Die Verwendung von kundenverwalteten Domains (auch als benutzerdefinierte Domains bezeichnet) bietet viele Vorteile: Sie können Ihre eigene Domain oder die Ihres Unternehmens Kunden zu Branding-Zwecken zugänglich machen; Sie können Ihre eigene Domain einfach ändern, sodass sie auf einen neuen Broker verweist; Sie können Multi-Tenancy unterstützen, um Kunden mit unterschiedlichen Domains innerhalb derselben zu bedienen AWS-Konto; und Sie können Ihre eigenen Serverzertifikatsdetails verwalten, z. B. die Root-Zertifizierungsstelle (CA), die zum Signieren des Zertifikats verwendet wurde, den Signaturalgorithmus, Tiefe der Zertifikatskette und der Lebenszyklus der Zertifikat.
Der Workflow zum Einrichten einer Domänenkonfiguration mit einer benutzerdefinierten Domäne besteht aus den folgenden drei Phasen.
1. [Registrierung von Serverzertifikaten in AWS Certificate Manager](#iot-custom-endpoints-configurable-custom-register-certificate)
1. [Erstellen einer Domänenkonfiguration](#iot-custom-endpoints-configurable-custom-domain-config)
1. [Erstellen von DNS-Datensätzen](#iot-custom-endpoints-configurable-custom-dns)
## Registrierung von Serverzertifikaten im AWS Zertifikatsmanager
Bevor Sie eine Domänenkonfiguration mit einer benutzerdefinierten Domäne erstellen, müssen Sie die Serverzertifikatskette in [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) registrieren. Sie können die folgenden drei Serverzertifikattypen verwenden.
+ [In ACM generierte öffentliche Zertifikate](#iot-custom-endpoints-configurable-custom-register-certificate-acm)
+ [Von einer öffentlichen Zertifizierungsstelle signierte externe Zertifikate](#iot-custom-endpoints-configurable-custom-register-certificate-pubext)
+ [Von einer privaten Zertifizierungsstelle signierte externe Zertifikate](#iot-custom-endpoints-configurable-custom-register-certificate-privext)
**Anmerkung**
AWS IoT Core betrachtet ein Zertifikat als von einer öffentlichen Zertifizierungsstelle signiert, wenn es in [Mozillas vertrauenswürdigem CA-Bundle enthalten ist](https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt?raw=1).
### Zertifikatanforderungen
Die Anforderungen für den Import von Zertifikaten in ACM finden Sie unter [Anforderungen an den Import von Zertifikaten](/acm/latest/userguide/import-certificate-prerequisites.html). Zusätzlich zu diesen Anforderungen fügt AWS IoT Core folgende Anforderungen hinzu.
+ Das Leaf-Zertifikat muss die Erweiterung **Extended Key Usage** x509 v3 mit dem Wert **ServerAuth (TLS Web Server Authentication**) enthalten. Wenn Sie das Zertifikat von ACM anfordern, wird diese Erweiterung automatisch hinzugefügt.
+ Die maximale Tiefe der Zertifikatskette beträgt 5 Zertifikate.
+ Die maximale Größe der Zertifikatskette beträgt 16 KB.
+ Zu den unterstützten kryptografischen Algorithmen und Schlüsselgrößen gehören RSA 2048-Bit (RSA\$12048) und ECDSA 256-Bit (EC\$1Prime256V1).
### Verwenden eines Zertifikats für mehrere Domänen
Wenn Sie planen, ein Zertifikat für mehrere Unterdomänen zu verwenden, verwenden Sie eine Platzhalterdomäne im Feld „Common Name (CN)“ oder „Subject Alternative Names (SAN)“. Verwenden Sie zum Beispiel **\$1.iot.example.com** dev.iot.example.com, qa.iot.example.com und prod.iot.example.com. Jeder FQDN erfordert eine eigene Domänenkonfiguration, aber mehr als eine Domänenkonfiguration kann denselben Platzhalterwert verwenden. Der CN oder das SAN muss den FQDN abdecken, den Sie als benutzerdefinierte Domäne verwenden möchten. Falls SANs vorhanden, wird der CN ignoriert und ein SAN muss den FQDN abdecken, den Sie als benutzerdefinierte Domäne verwenden möchten. Hierbei kann es sich um eine exakte Übereinstimmung oder um eine Platzhalterübereinstimmung handeln. Nachdem ein Wildcard-Zertifikat validiert und für ein Konto registriert wurde, werden andere Konten in der Region daran gehindert, benutzerdefinierte Domänen zu erstellen, die sich mit dem Zertifikat überschneiden.
In den folgenden Abschnitten wird beschrieben, wie Sie die einzelnen Zertifikatstypen erhalten. Für jede Zertifikatressource ist ein bei ACM registrierter Amazon-Ressourcenname (ARN) erforderlich, den Sie beim Erstellen Ihrer Domänenkonfiguration verwenden.
### ACM-generierte öffentliche Zertifikate
Mithilfe der [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html)API können Sie ein öffentliches Zertifikat für Ihre benutzerdefinierte Domain generieren. Wenn Sie auf diese Weise ein Zertifikat generieren, überprüft ACM Ihr Eigentum an der benutzerdefinierten Domäne. Weitere Informationen finden Sie unter [Anfordern eines öffentlichen Zertifikats](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) im *AWS Certificate Manager -Benutzerhandbuch*.
### Von einer öffentlichen Zertifizierungsstelle signierte externe Zertifikate
Wenn Sie bereits über ein Serverzertifikat verfügen, das von einer öffentlichen Zertifizierungsstelle signiert wurde (eine Zertifizierungsstelle, die im vertrauenswürdigen CA-Bundle von Mozilla enthalten ist), können Sie die Zertifikatskette mithilfe der [ImportCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_ImportCertificate.html)API direkt in ACM importieren. Weitere Informationen zu dieser Aufgabe und den Voraussetzungen und Anforderungen an das Zertifikatformat finden Sie unter [Importieren von Zertifikaten](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html).
### Von einer privaten Zertifizierungsstelle signierte externe Zertifikate
Wenn Sie bereits über ein Serverzertifikat verfügen, das von einer privaten Zertifizierungsstelle signiert oder selbstsigniert ist, können Sie das Zertifikat zum Erstellen Ihrer Domänenkonfiguration verwenden. Sie müssen jedoch auch ein zusätzliches öffentliches Zertifikat in ACM erstellen, um den Besitz Ihrer Domäne zu überprüfen. Registrieren Sie dazu Ihre Serverzertifikatskette mithilfe der API in ACM. [ImportCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_ImportCertificate.html) Weitere Informationen zu dieser Aufgabe und den Voraussetzungen und Anforderungen an das Zertifikatformat finden Sie unter [Importieren von Zertifikaten](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html).
### Erstellen eines Validierungszertifikats
Nachdem Sie Ihr Zertifikat in ACM importiert haben, generieren Sie mithilfe der API ein öffentliches Zertifikat für Ihre benutzerdefinierte Domain. [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) Wenn Sie auf diese Weise ein Zertifikat generieren, überprüft ACM Ihr Eigentum an der benutzerdefinierten Domäne. Weitere Informationen finden Sie unter [Anfordern eines öffentlichen Zertifikats](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html). Wenn Sie Ihre Domänenkonfiguration erstellen, verwenden Sie dieses öffentliche Zertifikat als Validierungszertifikat.
## Erstellen einer Domänenkonfiguration
Mithilfe der [CreateDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_CreateDomainConfiguration.html)API erstellen Sie einen konfigurierbaren Endpunkt in einer benutzerdefinierten Domain. Eine Domänenkonfiguration für eine benutzerdefinierte Domäne besteht aus folgenden Elementen:
+ `domainConfigurationName`
Ein benutzerdefinierter Name, der die Domänenkonfiguration identifiziert Domänenkonfigurationsnamen, die mit `IoT:` beginnen, sind für Standardendpunkte reserviert und können nicht verwendet werden. Außerdem muss dieser Wert für Sie einzigartig sein AWS-Region.
+ `domainName`
Der FQDN, mit dem Ihre Geräte eine Verbindung herstellen AWS IoT Core. AWS IoT Core nutzt die TLS-Erweiterung (Server Name Indication, SNI), um Domänenkonfigurationen anzuwenden. Geräte müssen diese Erweiterung verwenden, wenn sie eine Verbindung herstellen und einen Servernamen übergeben, der mit dem Domänennamen identisch ist, der in der Domänenkonfiguration angegeben ist.
+ `serverCertificateArns`
Der ARN der Serverzertifikatskette, die Sie bei ACM registriert haben. AWS IoT Core unterstützt derzeit nur ein Serverzertifikat.
+ `validationCertificateArn`
Der ARN des öffentlichen Zertifikats, das von ACM ausgestellt wurde, um das Eigentum an Ihrer benutzerdefinierten Domäne zu validieren. Dieses Argument ist nicht erforderlich, wenn Sie ein öffentlich signiertes oder in ACM generiertes Serverzertifikat verwenden.
+ `defaultAuthorizerName (optional)`
Der Name des benutzerdefinierten Autorisierers, der am Endpunkt verwendet werden soll.
+ `allowAuthorizerOverride`
Ein boolescher Wert, der angibt, ob Geräte den Standard-Autorisierer überschreiben können, indem sie im HTTP-Header der Anfrage einen anderen Autorisierer angeben. Dieser Wert ist erforderlich, wenn ein Wert für `defaultAuthorizerName` angegeben wird.
+ `serviceType`
AWS IoT Core unterstützt derzeit nur den `DATA` Diensttyp. Wenn Sie angeben`DATA`, wird ein Endpunkt mit dem Endpunkttyp AWS IoT zurückgegeben`iot:Data-ATS`.
+ `TlsConfig` (optional)
Ein Objekt, das die TLS-Konfiguration für eine Domäne spezifiziert. Weitere Informationen finden Sie unter [Konfiguration von TLS-Einstellungen in Domänenkonfigurationen](iot-endpoints-tls-config.md).
+ `serverCertificateConfig` (optional)
Ein Objekt, das die Serverzertifikatkonfiguration für eine Domäne angibt. Weitere Informationen finden Sie unter [Konfiguration des Serverzertifikats für OCSP-Stapling](iot-custom-endpoints-cert-config.md).
Der folgende AWS CLI Befehl erstellt eine Domänenkonfiguration für **iot.example.com**.
```
aws iot create-domain-configuration --domain-configuration-name "myDomainConfigurationName" --service-type "DATA"
--domain-name "iot.example.com" --server-certificate-arns serverCertARN --validation-certificate-arn validationCertArn
```
**Anmerkung**
Nachdem Sie Ihre Domänenkonfiguration erstellt haben, kann es bis zu 60 Minuten dauern, bis Ihre benutzerdefinierten Serverzertifikate AWS IoT Core bereitgestellt werden.
Weitere Informationen finden Sie unter [Verwalten von Domänenkonfigurationen](iot-custom-endpoints-managing.md).
## Erstellen von DNS-Datensätzen
Nachdem Sie die Serverzertifikatkette registriert und die Domänenkonfiguration erstellt haben, erstellen Sie einen DNS-Datensatz, damit Ihre benutzerdefinierte Domäne auf eine AWS IoT -Domäne verweist. Dieser Datensatz muss auf einen AWS IoT Endpunkt vom Typ verweisen`iot:Data-ATS`. Sie können Ihren Endpunkt mithilfe der [DescribeEndpoint](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeEndpoint.html)API abrufen.
Der folgende AWS CLI Befehl zeigt, wie Sie Ihren Endpunkt ermitteln.
```
aws iot describe-endpoint --endpoint-type iot:Data-ATS
```
Nachdem Sie Ihren `iot:Data-ATS` Endpunkt erhalten haben, erstellen Sie einen `CNAME` Datensatz von Ihrer benutzerdefinierten Domain zu diesem AWS IoT Endpunkt. Wenn Sie mehrere benutzerdefinierte Domains in derselben Domain erstellen AWS-Konto, geben Sie ihnen einen Alias für denselben `iot:Data-ATS` Endpunkt.
## Fehlerbehebung
Wenn Sie Probleme haben, Geräte mit einer benutzerdefinierten Domain zu verbinden, stellen Sie sicher, dass diese Ihr Serverzertifikat akzeptiert und angewendet AWS IoT Core hat. Sie können überprüfen, ob Ihr Zertifikat akzeptiert AWS IoT Core wurde, indem Sie entweder die AWS IoT Core Konsole oder den verwenden AWS CLI.
Um die AWS IoT Core Konsole zu verwenden, navigieren Sie zur Seite mit den **Domänenkonfigurationen** und wählen Sie den Namen der Domänenkonfiguration aus. Überprüfen Sie im Abschnitt **Serverzertifikatsdetails** den Status und die Statusdetails. Wenn das Zertifikat ungültig ist, ersetzen Sie es in ACM durch ein Zertifikat, das die im vorherigen Abschnitt aufgeführten [Zertifikatsanforderungen](#certificate-requirements) erfüllt. Wenn das Zertifikat denselben ARN hat, AWS IoT Core wird es automatisch abgeholt und angewendet.
Um den Status des Zertifikats mithilfe von zu überprüfen AWS CLI, rufen Sie die [DescribeDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeDomainConfiguration.html)API auf und geben Sie Ihren Domain-Konfigurationsnamen an.
**Anmerkung**
Wenn Ihr Zertifikat ungültig ist, AWS IoT Core wird weiterhin das letzte gültige Zertifikat ausgestellt.
Mit dem folgenden openssl-Befehl können Sie überprüfen, welches Zertifikat auf Ihrem Endpunkt zugestellt wird.
`openssl s_client -connect custom-domain-name:8883 -showcerts -servername custom-domain-name`
# Verwalten von Domänenkonfigurationen
In diesem Thema werden wichtige Operationen behandelt, mit denen Sie Ihre Domänenkonfigurationsressourcen verwalten können. Sie können auch die Lebenszyklen vorhandener Konfigurationen mithilfe der folgenden Methoden verwalten APIs: [ListDomainConfigurations](https://docs.aws.amazon.com/iot/latest/apireference/API_ListDomainConfigurations.html), [DescribeDomainConfiguration[UpdateDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateDomainConfiguration.html)](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeDomainConfiguration.html), und. [DeleteDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_DeleteDomainConfiguration.html)
**Topics**
+ [Anzeigen von Domänenkonfigurationen](#iot-custom-endpoints-managing-view)
+ [Aktualisieren von Domänenkonfigurationen](#iot-custom-endpoints-managing-update)
+ [Löschen von Domänenkonfigurationen](#iot-custom-endpoints-managing-delete)
+ [Rotierende Zertifikate in benutzerdefinierten Domänen](#iot-custom-endpoints-managing-certificates)
## Anzeigen von Domänenkonfigurationen
Verwenden Sie die API, um eine paginierte Liste aller Domainkonfigurationen in Ihrer AWS-Konto zurückzugeben. [ListDomainConfigurations](https://docs.aws.amazon.com/iot/latest/apireference/API_ListDomainConfigurations.html) Sie können die Details einer bestimmten Domain-Konfiguration mithilfe der [DescribeDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeDomainConfiguration.html)API einsehen. Diese API nimmt einen einzelnen `domainConfigurationName`-Parameter und gibt die Details der angegebenen Konfiguration zurück.
**Beispiel**
## Aktualisieren von Domänenkonfigurationen
Verwenden Sie die [UpdateDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateDomainConfiguration.html)API, um den Status oder den benutzerdefinierten Authorizer Ihrer Domain-Konfiguration zu aktualisieren. Sie können den Status auf `ENABLED` oder `DISABLED` setzen. Wenn Sie die Domänenkonfiguration deaktivieren, erhalten Geräte, die mit dieser Domäne verbunden sind, einen Authentifizierungsfehler. Derzeit können Sie das Serverzertifikat in Ihrer Domänenkonfiguration nicht aktualisieren. Um das Zertifikat einer Domänenkonfiguration zu ändern, müssen Sie es löschen und neu erstellen.
**Beispiel**
## Löschen von Domänenkonfigurationen
Bevor Sie eine Domainkonfiguration löschen, verwenden Sie die [UpdateDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateDomainConfiguration.html)API, um den Status auf zu `DISABLED` setzen. Auf diese Weise vermeiden Sie ein versehentliches Löschen des Endpunkts. Nachdem Sie die Domänenkonfiguration deaktiviert haben, löschen Sie sie mithilfe der [DeleteDomainConfiguration](https://docs.aws.amazon.com/iot/latest/apireference/API_DeleteDomainConfiguration.html)API. Sie müssen AWS verwaltete Domains 7 Tage lang in `DISABLED` den Status „-managed“ setzen, bevor Sie sie löschen können. Sie können benutzerdefinierte Domains in `DISABLED` den Status versetzen und sie dann sofort löschen.
**Beispiel**
Nachdem Sie eine Domänenkonfiguration gelöscht haben, wird das Serverzertifikat, das dieser benutzerdefinierten Domain zugeordnet ist, nicht AWS IoT Core mehr bereitgestellt.
## Rotierende Zertifikate in benutzerdefinierten Domänen
Möglicherweise müssen Sie Ihr Serverzertifikat regelmäßig durch ein aktualisiertes Zertifikat ersetzen. Die Häufigkeit, mit der Sie dies tun müssen, ist von der Gültigkeitsdauer Ihres Zertifikats abhängig. Wenn Sie Ihr Serverzertifikat mithilfe von AWS Certificate Manager (ACM) generiert haben, können Sie festlegen, dass das Zertifikat automatisch verlängert wird. Wenn ACM Ihr Zertifikat erneuert, AWS IoT Core wird das neue Zertifikat automatisch übernommen. Sie müssen keine weiteren Aktionen ausführen. Wenn Sie Ihr Serverzertifikat aus einer anderen Quelle importiert haben, können Sie es rotieren, indem Sie es erneut in ACM importieren. Informationen zum erneuten Importieren von Zertifikaten finden Sie unter [Zertifikat erneut importieren](https://docs.aws.amazon.com/acm/latest/userguide/import-reimport.html).
**Anmerkung**
AWS IoT Core nimmt Zertifikatsaktualisierungen nur unter den folgenden Bedingungen entgegen.
Das neue Zertifikat hat denselben ARN wie das alte.
Das neue Zertifikat hat denselben Signaturalgorithmus, denselben generischen Namen oder denselben alternativen Betreffnamen wie das alte.
# Konfiguration von TLS-Einstellungen in Domänenkonfigurationen
AWS IoT Core bietet [vordefinierte Sicherheitsrichtlinien, mit](transport-security.md#tls-policy-table) denen Sie Ihre Transport Layer Security (TLS) -Einstellungen für TLS [1.2 und TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2) [1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) in Domänenkonfigurationen anpassen können. Eine Sicherheitsrichtlinie ist eine Kombination aus TLS-Protokollen und ihren Verschlüsselungen, die die unterstützten Protokolle und Verschlüsselungen bei TLS-Verhandlungen zwischen einem Client und einem Server festlegen. Mit den unterstützten Sicherheitsrichtlinien können Sie die TLS-Einstellungen Ihrer Geräte flexibler verwalten, beim Anschließen neuer Geräte die meisten up-to-date Sicherheitsmaßnahmen anwenden und konsistente TLS-Konfigurationen für vorhandene Geräte beibehalten.
Die folgende Tabelle beschreibt die Sicherheitsrichtlinien, ihre TLS-Versionen sowie die unterstützten Regionen:
****
| Name der Sicherheitsrichtlinie | Unterstützt AWS-Regionen |
| --- | --- |
| TSecurityIo-Richtlinie\$1 \$11\$13\$12022\$110 TLS13 | Alle AWS-Regionen |
| TSecurityIo-Richtlinie\$1 \$11\$12\$12022\$110 TLS13 | Alle AWS-Regionen |
| TSecurityIo-Richtlinie\$1 \$11\$12\$12022\$110 TLS12 | Alle AWS-Regionen |
| TSecurityIo-Richtlinie\$1 \$11\$10\$12016\$101 TLS12 | AP-Ost-1, ap-northeast-2, ap-south-1, ap-southeast-2, ca-central-1, CN-Nord-1, CN-Nordwest-1, EU-Nord-1, EU-West-2, EU-West-3, me-south-1, sa-east-1, us-east-2, US-West-1 |
| TSecurityTLS12Io-Richtlinie\$1 \$11\$10\$12015\$101 | ap-northeast-1, ap-southeast-1, eu-central-1, eu-west-1, us-east-1, us-west-2 |
Die Namen der Sicherheitsrichtlinien AWS IoT Core enthalten Versionsinformationen, die auf dem Jahr und Monat basieren, in dem sie veröffentlicht wurden. Wenn Sie eine neue Domänenkonfiguration erstellen, lautet die Standardeinstellung für die Sicherheitsrichtlinie `IoTSecurityPolicy_TLS13_1_2_2022_10`. Eine vollständige Tabelle der Sicherheitsrichtlinien mit Einzelheiten zu Protokollen, TCP-Ports und Chiffren finden Sie unter [Sicherheitsrichtlinien](transport-security.md#tls-policy-table). AWS IoT Core unterstützt keine benutzerdefinierten Sicherheitsrichtlinien. Weitere Informationen finden Sie unter [Transportsicherheit in AWS IoT Core](transport-security.md).
Um TLS-Einstellungen in Domänenkonfigurationen zu konfigurieren, können Sie die AWS IoT Konsole oder die verwenden AWS CLI.
**Topics**
+ [Konfigurieren von TLS-Einstellungen in den Domänenkonfigurationen (Konsole)](#custom-tls-console)
+ [Konfigurieren von TLS-Einstellungen in Domänenkonfigurationen (CLI)](#custom-tls-cli)
## Konfigurieren von TLS-Einstellungen in den Domänenkonfigurationen (Konsole)
**Um TLS-Einstellungen mit der AWS IoT Konsole zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AWS IoT Konsole](https://console.aws.amazon.com/iot/home).
1. Gehen Sie beim Erstellen einer neuen Domänenkonfiguration folgendermaßen vor, um die TLS-Einstellungen zu konfigurieren.
1. Wählen Sie im linken Navigationsbereich **Domänenkonfigurationen** und anschließend **Domänenkonfiguration erstellen** aus.
1. Wählen Sie auf der Seite **Domänenkonfiguration erstellen** im Abschnitt **Benutzerdefinierte Domäneneinstellungen – *optional*** unter **Sicherheitsrichtlinie auswählen** eine Sicherheitsrichtlinie.
1. Folgen Sie dem Widget, und führen Sie die restlichen Schritte durch. Wählen Sie **Domänenkonfiguration erstellen**.
1. Gehen Sie wie folgt vor, um die TLS-Einstellungen in einer vorhandenen Domänenkonfiguration zu aktualisieren.
1. Wählen Sie im linken Navigationsbereich **Domänenkonfigurationen** und dann eine Domänenkonfiguration aus.
1. Wählen Sie auf der Seite mit den **Details zur Domänenkonfiguration** die Option **Bearbeiten**. Wählen Sie dann im Abschnitt **Benutzerdefinierte Domäneneinstellungen – *optional*** unter **Sicherheitsrichtlinie auswählen** eine Sicherheitsrichtlinie.
1. Wählen Sie **Konfiguration aktualisieren**.
Weitere Informationen finden Sie unter [Eine Domänenkonfiguration erstellen](https://docs.aws.amazon.com//iot/latest/developerguide/iot-custom-endpoints-configurable-custom.html#iot-custom-endpoints-configurable-custom-domain-config) und [Domänenkonfigurationen verwalten](iot-custom-endpoints-managing.md).
## Konfigurieren von TLS-Einstellungen in Domänenkonfigurationen (CLI)
Sie können die CLI-Befehle [https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html) und [https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html) verwenden, um Ihre TLS-Einstellungen in Domänenkonfigurationen zu konfigurieren.
1. So legen Sie die TLS-Einstellungen mit dem [https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html)-CLI-Befehl fest:
```
aws iot create-domain-configuration \
--domain-configuration-name domainConfigurationName \
--tls-config securityPolicy=IoTSecurityPolicy_TLS13_1_2_2022_10
```
Die Ausgabe dieses Befehls kann folgendermaßen aussehen:
```
{
"domainConfigurationName": "test",
"domainConfigurationArn": "arn:aws:iot:us-west-2:123456789012:domainconfiguration/test/34ga9"
}
```
Wenn Sie eine neue Domänenkonfiguration erstellen, ohne die Sicherheitsrichtlinie anzugeben, lautet der Standardwert: `IoTSecurityPolicy_TLS13_1_2_2022_10`.
1. So beschreiben Sie die TLS-Einstellungen mit dem [https://docs.aws.amazon.com//cli/latest/reference/iot/describe-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/describe-domain-configuration.html)-CLI-Befehl:
```
aws iot describe-domain-configuration \
--domain-configuration-name domainConfigurationName
```
Dieser Befehl kann die Domänenkonfigurationsdetails, die die TLS-Einstellungen enthalten, folgendermaßen zurückgeben:
```
{
"tlsConfig": {
"securityPolicy": "IoTSecurityPolicy_TLS13_1_2_2022_10"
},
"domainConfigurationStatus": "ENABLED",
"serviceType": "DATA",
"domainType": "AWS_MANAGED",
"domainName": "d1234567890abcdefghij-ats.iot.us-west-2.amazonaws.com",
"serverCertificates": [],
"lastStatusChangeDate": 1678750928.997,
"domainConfigurationName": "test",
"domainConfigurationArn": "arn:aws:iot:us-west-2:123456789012:domainconfiguration/test/34ga9"
}
```
1. So aktualisieren Sie die TLS-Einstellungen mit dem [https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html)-CLI-Befehl:
```
aws iot update-domain-configuration \
--domain-configuration-name domainConfigurationName \
--tls-config securityPolicy=IoTSecurityPolicy_TLS13_1_2_2022_10
```
Die Ausgabe dieses Befehls kann folgendermaßen aussehen:
```
{
"domainConfigurationName": "test",
"domainConfigurationArn": "arn:aws:iot:us-west-2:123456789012:domainconfiguration/test/34ga9"
}
```
1. Führen Sie den [https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html)-CLI-Befehl aus, um die TLS-Einstellungen für Ihren ATS-Endpunkt zu aktualisieren. Der Domänenkonfigurationsname für Ihren ATS-Endpunkt lautet `iot:Data-ATS`.
```
aws iot update-domain-configuration \
--domain-configuration-name "iot:Data-ATS" \
--tls-config securityPolicy=IoTSecurityPolicy_TLS13_1_2_2022_10
```
Die Ausgabe dieses Befehls kann folgendermaßen aussehen:
```
{
"domainConfigurationName": "iot:Data-ATS",
"domainConfigurationArn": "arn:aws:iot:us-west-2:123456789012:domainconfiguration/iot:Data-ATS"
}
```
Weitere Informationen finden Sie unter [CreateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_CreateDomainConfiguration.html) und [UpdateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_UpdateDomainConfiguration.html) in der *AWS -API-Referenz*.
# Konfiguration des Serverzertifikats für OCSP-Stapling
AWS IoT Core unterstützt das [Online Certificate Status Protocol (OCSP) -Heften](https://www.rfc-editor.org/rfc/rfc6960.html) für Serverzertifikate, auch bekannt als Serverzertifikat-OCSP-Heftung oder OCSP-Heftung. Dabei handelt es sich um einen Sicherheitsmechanismus, der verwendet wird, um den Sperrstatus des Serverzertifikats in einem Transport Layer Security (TLS) -Handshake zu überprüfen. Mit OCSP-Stapling In AWS IoT Core können Sie die Gültigkeit des Serverzertifikats Ihrer benutzerdefinierten Domain um eine zusätzliche Überprüfungsebene erweitern.
Sie können das OCSP-Stapling in für Serverzertifikate aktivieren, um die Gültigkeit des Zertifikats AWS IoT Core zu überprüfen, indem Sie den OCSP-Responder regelmäßig abfragen. Die OCSP-Hefteinstellung ist Teil des Prozesses zum Erstellen oder Aktualisieren einer Domänenkonfiguration mit einer benutzerdefinierten Domäne. OCSP Stapling überprüft kontinuierlich den Sperrstatus des Serverzertifikats. Auf diese Weise können Sie überprüfen, ob alle Zertifikate, die von der Zertifizierungsstelle gesperrt wurden, von den Clients, die eine Verbindung zu Ihren benutzerdefinierten Domänen herstellen, nicht mehr als vertrauenswürdig eingestuft werden. Weitere Informationen finden Sie unter [Aktivierung des Serverzertifikats OCSP in AWS IoT Core](#iot-custom-endpoints-cert-config-ocsp-manage).
Das OCSP-Stapling von Serverzertifikaten ermöglicht die Überprüfung des Sperrstatus in Echtzeit, reduziert die mit der Überprüfung des Sperrstatus verbundene Latenz und verbessert den Datenschutz und die Zuverlässigkeit sicherer Verbindungen. Weitere Informationen zu den Vorteilen der Verwendung von OCSP Stapling finden Sie unter. [Vorteile der Verwendung von OCSP-Stapling im Vergleich zu clientseitigen OCSP-Prüfungen](#iot-custom-endpoints-ocsp-stapling-benefits)
**Anmerkung**
Diese Funktion ist in nicht verfügbar. AWS GovCloud (US) Regions
**Topics**
+ [Was ist OCSP?](#iot-custom-endpoints-cert-config-ocsp-what-is)
+ [Wie funktioniert OCSP Stapling](#iot-custom-endpoints-cert-config-ocsp-stapling-what-is)
+ [Aktivierung des Serverzertifikats OCSP in AWS IoT Core](#iot-custom-endpoints-cert-config-ocsp-manage)
+ [Konfiguration des Serverzertifikats OCSP für private Endpunkte in AWS IoT Core](#iot-custom-endpoints-cert-config-ocsp-private-endpoint)
+ [Wichtige Hinweise zur Verwendung des Serverzertifikats OCSP (Stapling in) AWS IoT Core](#iot-custom-endpoints-cert-config-ocsp-notes)
+ [Problembehandlung beim Einheften des Serverzertifikats OCSP AWS IoT Core](#iot-custom-endpoints-cert-config-ocsp-troubleshooting)
## Was ist OCSP?
Das Online Certificate Status Protocol (OCSP) hilft bei der Bereitstellung des Sperrstatus eines Serverzertifikats für einen Transport Layer Security (TLS) -Handshake.
### Die wichtigsten Konzepte
Die folgenden Schlüsselkonzepte enthalten Einzelheiten zum Online Certificate Status Protocol (OCSP).
**OCSP**
[OCSP](https://www.rfc-editor.org/rfc/rfc6960.html) wird verwendet, um den Zertifikatssperrstatus während des Transport Layer Security (TLS) -Handshakes zu überprüfen. OCSP ermöglicht die Validierung von Zertifikaten in Echtzeit. Dadurch wird bestätigt, dass das Zertifikat seit seiner Ausstellung nicht gesperrt wurde oder abgelaufen ist. OCSP ist im Vergleich zu herkömmlichen Zertifikatssperrlisten () CRLs auch besser skalierbar. OCSP-Antworten sind kleiner und können effizient generiert werden, wodurch sie sich besser für große private Schlüsselinfrastrukturen () PKIs eignen.
**OCSP-Responder**
Ein OCSP-Responder (auch bekannt als OCSP-Server) empfängt und beantwortet OCSP-Anfragen von Clients, die versuchen, den Sperrstatus von Zertifikaten zu überprüfen.
**Clientseitiges OCSP**
Beim clientseitigen OCSP verwendet der Client OCSP, um einen OCSP-Responder zu kontaktieren, um den Sperrstatus des Zertifikats während des TLS-Handshakes zu überprüfen.
**Serverseitiges OCSP**
Beim serverseitigen OCSP (auch bekannt als OCSP-Stapling) ist der Server (und nicht der Client) in der Lage, die Anfrage an den OCSP-Responder zu stellen. Der Server verknüpft die OCSP-Antwort mit dem Zertifikat und sendet sie während des TLS-Handshakes an den Client zurück.
### OCSP-Diagramme
Das folgende Diagramm zeigt, wie clientseitiges OCSP und serverseitiges OCSP funktionieren.
![\[Clientseitige OCSP- und serverseitige OCSP-Diagramme\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/custom-domain-ocsp-uml.png)
**Clientseitiges OCSP**
1. Der Client sendet eine `ClientHello` Nachricht, um den TLS-Handshake mit dem Server zu initiieren.
1. Der Server empfängt die Nachricht und antwortet mit einer `ServerHello` Nachricht. Der Server sendet auch das Serverzertifikat an den Client.
1. Der Client validiert das Serverzertifikat und extrahiert daraus einen OCSP-URI.
1. Der Client sendet eine Anfrage zur Überprüfung des Zertifikatswiderrufs an den OCSP-Responder.
1. Der OCSP-Responder sendet eine OCSP-Antwort.
1. Der Client validiert den Zertifikatsstatus anhand der OCSP-Antwort.
1. Der TLS-Handshake ist abgeschlossen.
**Serverseitiges OCSP**
1. Der Client sendet eine `ClientHello` Nachricht, um den TLS-Handshake mit dem Server zu initiieren.
1. Der Server empfängt die Nachricht und erhält die letzte zwischengespeicherte OCSP-Antwort. Wenn die zwischengespeicherte Antwort fehlt oder abgelaufen ist, ruft der Server den OCSP-Responder auf, um den Zertifikatsstatus abzufragen.
1. Der OCSP-Responder sendet eine OCSP-Antwort an den Server.
1. Der Server sendet eine Nachricht. `ServerHello` Der Server sendet auch das Serverzertifikat und den Zertifikatsstatus an den Client.
1. Der Client validiert den Status des OCSP-Zertifikats.
1. Der TLS-Handshake ist abgeschlossen.
## Wie funktioniert OCSP Stapling
OCSP-Stapling wird während des TLS-Handshakes zwischen dem Client und dem Server verwendet, um den Sperrstatus des Serverzertifikats zu überprüfen. Der Server stellt die OCSP-Anfrage an den OCSP-Responder und heftet die OCSP-Antworten mit den an den Client zurückgegebenen Zertifikaten zusammen. Wenn der Server die Anfrage an den OCSP-Responder stellt, können die Antworten zwischengespeichert und dann für viele Clients mehrfach verwendet werden.
### So funktioniert OCSP-Heftung in AWS IoT Core
Das folgende Diagramm zeigt, wie serverseitiges OCSP-Heften in funktioniert. AWS IoT Core
![\[Dieses Diagramm zeigt, wie serverseitiges OCSP-Heften in funktioniert. AWS IoT Core\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/custom-domain-ocsp-core-uml.png)
1. Das Gerät muss bei benutzerdefinierten Domänen mit aktiviertem OCSP-Stapling registriert sein.
1. AWS IoT Core ruft stündlich den OCSP-Responder auf, um den Status des Zertifikats abzurufen.
1. Der OCSP-Responder empfängt die Anfrage, sendet die neueste OCSP-Antwort und speichert die zwischengespeicherte OCSP-Antwort.
1. Das Gerät sendet eine `ClientHello` Nachricht, mit der der TLS-Handshake initiiert werden soll. AWS IoT Core
1. AWS IoT Core ruft die neueste OCSP-Antwort aus dem Server-Cache ab, der mit einer OCSP-Antwort des Zertifikats antwortet.
1. Der Server sendet eine `ServerHello` Nachricht an das Gerät. Der Server sendet auch das Serverzertifikat und den Zertifikatsstatus an den Client.
1. Das Gerät validiert den Status des OCSP-Zertifikats.
1. Der TLS-Handshake ist abgeschlossen.
### Vorteile der Verwendung von OCSP-Stapling im Vergleich zu clientseitigen OCSP-Prüfungen
Zu den Vorteilen der Verwendung von OCSP Stapling für Serverzertifikate gehören:
**Verbesserter Datenschutz**
Ohne OCSP-Hefting kann das Gerät des Clients Informationen an OCSP-Responder von Drittanbietern weitergeben, wodurch möglicherweise die Privatsphäre der Benutzer gefährdet wird. Durch OCSP-Hefting wird dieses Problem dadurch behoben, dass der Server die OCSP-Antwort erhält und sie direkt an den Client weiterleitet.
**Verbesserte Zuverlässigkeit**
OCSP-Hefting kann die Zuverlässigkeit sicherer Verbindungen verbessern, da dadurch das Risiko von OCSP-Serverausfällen verringert wird. Wenn OCSP-Antworten geheftet werden, fügt der Server dem Zertifikat die neueste Antwort bei. Auf diese Weise haben Clients auch dann Zugriff auf den Sperrstatus, wenn der OCSP-Responder vorübergehend nicht verfügbar ist. OCSP-Hefting trägt zur Behebung dieser Probleme bei, da der Server in regelmäßigen Abständen OCSP-Antworten abruft und die zwischengespeicherten Antworten in den TLS-Handshake aufnimmt. Dadurch wird die Abhängigkeit von der Echtzeitverfügbarkeit von OCSP-Respondern verringert.
**Reduzierte Serverlast**
Mit OCSP-Hefting wird die Last, auf OCSP-Anfragen von OCSP-Respondern zu antworten, auf den Server verlagert. Dies kann dazu beitragen, die Last gleichmäßiger zu verteilen, wodurch der Prozess der Zertifikatsvalidierung effizienter und skalierbarer wird.
**Reduzierte Latenz**
OCSP-Hefting reduziert die Latenz, die mit der Überprüfung des Sperrstatus eines Zertifikats während des TLS-Handshakes verbunden ist. Anstatt dass der Client einen OCSP-Server separat abfragen muss, sendet der Server die Anfrage und hängt die OCSP-Antwort während des Handshakes an das Serverzertifikat an.
## Aktivierung des Serverzertifikats OCSP in AWS IoT Core
Um das Einheften von Serverzertifikaten mit OCSP zu aktivieren AWS IoT Core, erstellen Sie eine Domänenkonfiguration für eine benutzerdefinierte Domäne oder aktualisieren Sie eine bestehende benutzerdefinierte Domänenkonfiguration. Allgemeine Informationen zum Erstellen einer Domänenkonfiguration mit einer benutzerdefinierten Domäne finden Sie unter. [Vom Kunden verwaltete Domains erstellen und konfigurieren](iot-custom-endpoints-configurable-custom.md)
Verwenden Sie die folgenden Anweisungen, um das OCSP-Serverstapling mithilfe von AWS-Managementkonsole oder zu aktivieren. AWS CLI
### Konsole
**So aktivieren Sie das OCSP Stapling für Serverzertifikate mithilfe der Konsole: AWS IoT**
1. Wählen Sie im Navigationsmenü **Einstellungen** und dann **Domainkonfiguration erstellen** aus, oder wählen Sie eine bestehende Domainkonfiguration für eine benutzerdefinierte Domain aus.
1. Wenn Sie sich im vorherigen Schritt dafür entschieden haben, eine neue Domain-Konfiguration zu erstellen, wird die Seite **Domain-Konfiguration erstellen** angezeigt. Wählen Sie im Abschnitt **Eigenschaften der Domänenkonfiguration** die Option **Benutzerdefinierte Domäne** aus. Geben Sie die Informationen ein, um eine Domänenkonfiguration zu erstellen.
Wenn Sie eine bestehende Domainkonfiguration für eine benutzerdefinierte Domain aktualisieren möchten, wird die Seite mit den **Details zur Domain-Konfiguration** angezeigt. Wählen Sie **Bearbeiten** aus.
1. **Um das OCSP-Serverstapling zu aktivieren, wählen Sie im Unterabschnitt **Serverzertifikatkonfigurationen die Option Serverzertifikat-OCSP-Stapling aktivieren** aus.**
1. **Wählen Sie Domänenkonfiguration **erstellen oder Domänenkonfiguration aktualisieren** aus.**
### AWS CLI
**Um das OCSP-Stapling von Serverzertifikaten zu aktivieren, verwenden Sie: AWS CLI**
1. Wenn Sie eine neue Domänenkonfiguration für eine benutzerdefinierte Domäne erstellen, kann der Befehl zum Aktivieren des OCSP-Serverstaplings wie folgt aussehen:
```
aws iot create-domain-configuration --domain-configuration-name "myDomainConfigurationName" \
--server-certificate-arns arn:aws:iot:us-east-1:123456789012:cert/f8c1e5480266caef0fdb1bf97dc1c82d7ba2d3e2642c5f25f5ba364fc6b79ba3 \
--server-certificate-config "enableOCSPCheck=true|false"
```
1. Wenn Sie eine bestehende Domänenkonfiguration für eine benutzerdefinierte Domain aktualisieren, kann der Befehl zum Aktivieren des OCSP-Serverstaplings wie folgt aussehen:
```
aws iot update-domain-configuration --domain-configuration-name "myDomainConfigurationName" \
--server-certificate-arns arn:aws:iot:us-east-1:123456789012:cert/f8c1e5480266caef0fdb1bf97dc1c82d7ba2d3e2642c5f25f5ba364fc6b79ba3 \
--server-certificate-config "enableOCSPCheck=true|false"
```
Weitere Informationen finden Sie unter [CreateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_CreateDomainConfiguration.html)und in [UpdateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_UpdateDomainConfiguration.html)der AWS IoT API-Referenz.
## Konfiguration des Serverzertifikats OCSP für private Endpunkte in AWS IoT Core
Mit OCSP für private Endpoints können Sie Ihre privaten OCSP-Ressourcen innerhalb Ihrer Amazon Virtual Private Cloud (Amazon VPC) für den Betrieb nutzen. AWS IoT Core Der Prozess beinhaltet die Einrichtung einer Lambda-Funktion, die als OCSP-Responder fungiert. Die Lambda-Funktion verwendet möglicherweise Ihre privaten OCSP-Ressourcen, um OCSP-Antworten zu erstellen, AWS IoT Core die verwendet werden.
### Lambda-Funktion
Bevor Sie Server-OCSP für einen privaten Endpunkt konfigurieren, erstellen Sie eine Lambda-Funktion, die als RFC 6960-kompatibler Online Certificate Status Protocol (OCSP) -Responder fungiert und grundlegende OCSP-Antworten unterstützt. Die Lambda-Funktion akzeptiert eine Base64-Kodierung der OCSP-Anfrage im Format Distinguished Encoding Rules (DER). Die Antwort der Lambda-Funktion ist ebenfalls eine Base64-kodierte OCSP-Antwort im DER-Format. Die Antwortgröße darf 4 Kilobyte (KiB) nicht überschreiten. Die Lambda-Funktion muss sich in derselben AWS-Konto und AWS-Region wie die Domänenkonfiguration befinden. Im Folgenden finden Sie Beispiele für Lambda-Funktionen.
#### Beispiele für Lambda-Funktionen
------
#### [ JavaScript ]
```
import * as pkijs from 'pkijs';
console.log('Loading function');
export const handler = async (event, context) => {
const requestBytes = decodeBase64(event);
const ocspRequest = pkijs.OCSPRequest.fromBER(requestBytes);
console.log("Here is a better look at the OCSP request");
console.log(ocspRequest.toJSON());
const ocspResponse = getOcspResponse();
console.log("Here is a better look at the OCSP response");
console.log(ocspResponse.toJSON());
const responseBytes = ocspResponse.toSchema().toBER();
return encodeBase64(responseBytes);
};
function getOcspResponse() {
const responseString = "MIIC/woBAKCCAvgwggL0BgkrBgEFBQcwAQEEggLlMIIC4TCByqFkMGIxJzAlBgNVBAoMHlJpY2hhcmQncyBEaXNjb3VudCBMYW1iZGEgT0NTUDEZMBcGA1UEAwwQcm91bmRhYm91dE5hdGlvbjEPMA0GA1UEBwwGQ2FybWVsMQswCQYDVQQGEwJJThgPMjAyNDA0MjMxODUzMjVaMFEwTzA6MAkGBSsOAwIaBQAEFD2L7Ol/6ieNMaJbwRbxFWFweXGPBBSzSThwzTc3/p5w7WOtPjp3otNtVgIBAYAAGA8yMDI0MDQyMzE4NTMyNVowDQYJKoZIhvcNAQELBQADggIBAJFRyjDAHfazNejo704Ra3FOsGq/+s82R1spDarr3k7Pzkod9jJhwsZ2YgushlS4Npfe4lHCdwFyZR75WXrW55aXFddy03KLz01ZLNYyxkleW3f5dgrUcRU3PMW9TU2gZ0VOV8L5pmxKBoBRFt6EKtyh4CbiuqkTpLdLIMZmTyanhl5GVyU5MBHdbH8YWZoT/DEBiyS7ZsyhKo6igWU/SY7YMSKgwBvFsqSDcOa/hRYQkxWKWJ19gcz8CIkWN7NvfIxCs6VrAdzEJwmE7y3v+jdfhxW9JmI4xStE4K0tAR9vVOOfKs7NvxXj7oc9pCSG60xl96kaEE6PaY1YsfNTsKQ7pyCJ0s7/2q+ieZ4AtNyzw1XBadPzPJNv6E0LvI24yQZqN5wACvtut5prMMRxAHbOy+abLZR58wloFSELtGJ7UD96LFv1GgtC5s+2QlzPc4bEEof7Lo1EISt3j2ibNch8LxhqTQ4ufrbhsMkpSOTFYEJVMJF6aKj/OGXBUUqgc0Jx6jjJXNQd+l5KCY9pQFeb/wVUYC6mYqZOkNNMMJxPbHHbFnqb68yO+g5BE9011N44YXoPVJYoXxBLFX+OpRu9cqPkT9/vlkKd+SYXQknwZ81agKzhf1HsBKabtJwNVMlBKaI8g5UGa7Bxi6ewH3ezdWiERRUK7F56OM53wto/";
const responseBytes = decodeBase64(responseString);
return pkijs.OCSPResponse.fromBER(responseBytes);
}
function decodeBase64(input) {
const binaryString = atob(input);
const byteArray = new Uint8Array(binaryString.length);
for (var i = 0; i < binaryString.length; i++) {
byteArray[i] = binaryString.charCodeAt(i);
}
return byteArray.buffer;
}
function encodeBase64(buffer) {
var binary = '';
const bytes = new Uint8Array( buffer );
const len = bytes.byteLength;
for (var i = 0; i < len; i++) {
binary += String.fromCharCode( bytes[ i ] );
}
return btoa(binary);
}
```
------
#### [ Java ]
```
package com.example.ocsp.responder;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import org.bouncycastle.cert.ocsp.OCSPReq;
import org.bouncycastle.cert.ocsp.OCSPResp;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.Base64;
public class LambdaResponderApplication implements RequestHandler {
@Override
public String handleRequest(final String input, final Context context) {
LambdaLogger logger = context.getLogger();
byte[] decodedInput = Base64.getDecoder().decode(input);
OCSPReq req;
try {
req = new OCSPReq(decodedInput);
} catch (IOException e) {
logger.log("Got an IOException creating the OCSP request: " + e.getMessage());
throw new RuntimeException(e);
}
try {
OCSPResp response = businessLogic.getMyResponse();
String toReturn = Base64.getEncoder().encodeToString(response.getEncoded());
return toReturn;
} catch (Exception e) {
logger.log("Got an exception creating the response: " + e.getMessage());
return "";
}
}
}
```
------
#### Autorisieren AWS IoT zum Aufrufen Ihrer Lambda-Funktion
Bei der Erstellung der Domänenkonfiguration mit einem Lambda-OCSP-Responder müssen Sie die AWS IoT Erlaubnis erteilen, die Lambda-Funktion aufzurufen, nachdem die Funktion erstellt wurde. Um die Berechtigung zu erteilen, können Sie den CLI-Befehl [add-permission](https://docs.aws.amazon.com//cli/latest/reference/lambda/add-permission.html) verwenden.
**Erteilen Sie Ihrer Lambda-Funktion die Erlaubnis mit dem AWS CLI**
1. Geben Sie nach der Eingabe Ihrer Werte den folgenden Befehl ein. Beachten Sie, dass der Wert `statement-id` eindeutig sein muss. `Id-1234`Ersetzen Sie es durch den exakten Wert, den Sie haben, andernfalls wird möglicherweise eine `ResourceConflictException` Fehlermeldung angezeigt.
```
aws lambda add-permission \
--function-name "ocsp-function" \
--principal "iot.amazonaws.com" \
--action "lambda:InvokeFunction" \
--statement-id "Id-1234" \
--source-arn arn:aws:iot:us-east-1:123456789012:domainconfiguration//*
--source-account 123456789012
```
Die IoT-Domänenkonfiguration ARNs folgt dem folgenden Muster. Das vom Dienst generierte Suffix wird vor der Erstellung nicht bekannt sein, daher müssen Sie das Suffix durch ein ersetzen. `*` Sie können die Berechtigung aktualisieren, sobald die Domänenkonfiguration erstellt wurde und der genaue ARN bekannt ist.
`arn:aws:iot:use-east-1:123456789012:domainconfiguration/domain-config-name/service-generated-suffix`
1. Wenn der Befehl erfolgreich ist, gibt er eine Berechtigungsanweisung zurück, wie in diesem Beispiel. Sie können mit dem nächsten Abschnitt fortfahren, um OCSP Stapling für private Endgeräte zu konfigurieren.
```
{
"Statement": "{\"Sid\":\"Id-1234\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"iot.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-1:123456789012:function:ocsp-function\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:iot:us-east-1:123456789012:domainconfiguration/domain-config-name/*\"}}}"
}
```
Wenn der Befehl nicht erfolgreich ist, wird ein Fehler zurückgegeben, wie in diesem Beispiel. Sie müssen den Fehler überprüfen und korrigieren, bevor Sie fortfahren können.
```
An error occurred (AccessDeniedException) when calling the AddPermission operation: User: arn:aws:iam::57EXAMPLE833:user/EXAMPLE-1 is not authorized to perform: lambda:AddPer
mission on resource: arn:aws:lambda:us-east-1:123456789012:function:ocsp-function
```
### Konfiguration von Server-OCSP-Stapling für private Endpunkte
#### Konsole
**So konfigurieren Sie das OCSP-Stapling für Serverzertifikate mithilfe der Konsole: AWS IoT**
1. Wählen Sie im Navigationsmenü **Einstellungen** und dann **Domainkonfiguration erstellen** aus, oder wählen Sie eine bestehende Domänenkonfiguration für eine benutzerdefinierte Domain aus.
1. Wenn Sie sich im vorherigen Schritt dafür entschieden haben, eine neue Domain-Konfiguration zu erstellen, wird die Seite **Domain-Konfiguration erstellen** angezeigt. Wählen Sie im Abschnitt **Eigenschaften der Domänenkonfiguration** die Option **Benutzerdefinierte Domäne** aus. Geben Sie die Informationen ein, um eine Domänenkonfiguration zu erstellen.
Wenn Sie eine bestehende Domainkonfiguration für eine benutzerdefinierte Domain aktualisieren möchten, wird die Seite mit den **Details zur Domain-Konfiguration** angezeigt. Wählen Sie **Bearbeiten** aus.
1. **Um das OCSP-Serverstapling zu aktivieren, wählen Sie im Unterabschnitt **Serverzertifikatkonfigurationen die Option Serverzertifikat-OCSP-Stapling aktivieren** aus.**
1. **Wählen Sie Domänenkonfiguration **erstellen oder Domänenkonfiguration aktualisieren** aus.**
#### AWS CLI
**So konfigurieren Sie das OCSP-Stapling für Serverzertifikate mit: AWS CLI**
1. Wenn Sie eine neue Domänenkonfiguration für eine benutzerdefinierte Domäne erstellen, kann der Befehl zur Konfiguration des Serverzertifikats OCSP für private Endpunkte wie folgt aussehen:
```
aws iot create-domain-configuration --domain-configuration-name "myDomainConfigurationName" \
--server-certificate-arns arn:aws:iot:us-east-1:123456789012:cert/f8c1e5480266caef0fdb1bf97dc1c82d7ba2d3e2642c5f25f5ba364fc6b79ba3 \
--server-certificate-config "enableOCSPCheck=true, ocspAuthorizedResponderArn=arn:aws:acm:us-east-1:123456789012:certificate/certificate_ID, ocspLambdaArn=arn:aws:lambda:us-east-1:123456789012:function:my-function"
```
1. Wenn Sie eine bestehende Domänenkonfiguration für eine benutzerdefinierte Domain aktualisieren, kann der Befehl zur Konfiguration des Serverzertifikats OCSP für private Endpunkte wie folgt aussehen:
```
aws iot update-domain-configuration --domain-configuration-name "myDomainConfigurationName" \
--server-certificate-arns arn:aws:iot:us-east-1:123456789012:cert/f8c1e5480266caef0fdb1bf97dc1c82d7ba2d3e2642c5f25f5ba364fc6b79ba3 \
--server-certificate-config "enableOCSPCheck=true, ocspAuthorizedResponderArn=arn:aws:acm:us-east-1:123456789012:certificate/certificate_ID, ocspLambdaArn=arn:aws:lambda:us-east-1:123456789012:function:my-function"
```
**aktivieren OCSPCheck**
Dies ist ein boolescher Wert, der angibt, ob die OCSP-Heftprüfung auf dem Server aktiviert ist oder nicht. Um das OCSP-Heften für Serverzertifikate zu aktivieren, muss dieser Wert wahr sein.
**ocspAuthorizedResponderARN**
Dies ist ein Zeichenkettenwert des Amazon-Ressourcennamens (ARN) für ein in AWS Certificate Manager (ACM) gespeichertes X.509-Zertifikat. Falls angegeben, AWS IoT Core wird dieses Zertifikat verwendet, um die Signatur der empfangenen OCSP-Antwort zu validieren. Falls nicht angegeben, AWS IoT Core wird das ausstellende Zertifikat verwendet, um die Antworten zu validieren. Das Zertifikat muss sich in derselben AWS-Konto und AWS-Region wie die Domänenkonfiguration befinden. Weitere Informationen zur Registrierung Ihres autorisierten Responder-Zertifikats finden Sie unter [Zertifikate importieren in AWS Certificate Manager](https://docs.aws.amazon.com//acm/latest/userguide/import-certificate.html).
**ocspLambdaArn**
Dies ist ein Zeichenkettenwert des Amazon-Ressourcennamens (ARN) für eine Lambda-Funktion, die als RFC 6960-konformer (OCSP) -Responder (Request for Comments) fungiert und grundlegende OCSP-Antworten unterstützt. Die Lambda-Funktion akzeptiert eine Base64-Kodierung der OCSP-Anfrage, die im DER-Format codiert ist. Die Antwort der Lambda-Funktion ist ebenfalls eine Base64-kodierte OCSP-Antwort im DER-Format. Die Antwortgröße darf 4 Kilobyte (KiB) nicht überschreiten. Die Lambda-Funktion muss sich in derselben AWS-Konto und AWS-Region wie die Domänenkonfiguration befinden.
Weitere Informationen finden Sie in [CreateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_CreateDomainConfiguration.html)und in [UpdateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_UpdateDomainConfiguration.html)der AWS IoT API-Referenz.
## Wichtige Hinweise zur Verwendung des Serverzertifikats OCSP (Stapling in) AWS IoT Core
Beachten Sie bei der Verwendung des Serverzertifikats OCSP in AWS IoT Core Folgendes:
1. AWS IoT Core unterstützt nur die OCSP-Responder, die über öffentliche Adressen erreichbar sind. IPv4
1. Die OCSP-Heftfunktion in unterstützt AWS IoT Core keine autorisierten Responder. Alle OCSP-Antworten müssen von der Zertifizierungsstelle signiert werden, die das Zertifikat signiert hat, und die Zertifizierungsstelle muss Teil der Zertifikatskette der benutzerdefinierten Domäne sein.
1. Die OCSP-Heftfunktion in unterstützt AWS IoT Core keine benutzerdefinierten Domänen, die mit selbstsignierten Zertifikaten erstellt wurden.
1. AWS IoT Core ruft jede Stunde einen OCSP-Responder auf und speichert die Antwort im Cache. Schlägt der Anruf beim Responder fehl, AWS IoT Core wird die letzte gültige Antwort gespeichert.
1. Wenn sie nicht mehr gültig `nextUpdateTime` ist, AWS IoT Core wird die Antwort aus dem Cache entfernt, und der TLS-Handshake enthält die OCSP-Antwortdaten erst beim nächsten erfolgreichen Anruf an den OCSP-Responder. Dies kann passieren, wenn die zwischengespeicherte Antwort abgelaufen ist, bevor der Server eine gültige Antwort vom OCSP-Responder erhält. Der Wert von `nextUpdateTime` deutet darauf hin, dass die OCSP-Antwort bis zu diesem Zeitpunkt gültig sein wird. Mehr über `nextUpdateTime` erfahren Sie unter [OCSP-Protokolleinträge für Serverzertifikate](cwl-format.md#server-ocsp-logs).
1. Manchmal kann die OCSP-Antwort AWS IoT Core nicht empfangen werden oder die vorhandene OCSP-Antwort wird entfernt, weil sie abgelaufen ist. In solchen Situationen AWS IoT Core wird weiterhin das von der benutzerdefinierten Domäne bereitgestellte Serverzertifikat ohne die OCSP-Antwort verwendet.
1. Die Größe der OCSP-Antwort darf 4 KiB nicht überschreiten.
## Problembehandlung beim Einheften des Serverzertifikats OCSP AWS IoT Core
AWS IoT Core gibt die `RetrieveOCSPStapleData.Success` Metrik und die `RetrieveOCSPStapleData` Protokolleinträge an aus. CloudWatch Die Kennzahl und die Protokolleinträge können dabei helfen, Probleme im Zusammenhang mit dem Abrufen von OCSP-Antworten zu erkennen. Weitere Informationen erhalten Sie unter [OCSP Stapling-Metriken für Serverzertifikate](metrics_dimensions.md#server-ocsp-metrics) und [OCSP-Protokolleinträge für Serverzertifikate](cwl-format.md#server-ocsp-logs).