MQTT - AWS IoT Core

MQTT

MQTTは、制約のあるデバイス用に設計され、軽量で広く採用されているメッセージングプロトコルです。MQTT の AWS IoT のサポートは、MQTT v3.1.1 の仕様に基づいており、いくつかの違いがあります. AWS IoT が MQTT v3.1.1 仕様とどのように異なるかについては、「AWS IoT と MQTT バージョン 3.1.1 の仕様の違い」を参照してください。

AWS IoT Core は、MQTT プロトコルと MQTT over WSS プロトコルを使用するデバイス接続をサポートしています。AWS IoTDevice SDKs は両方のプロトコルをサポートしており、デバイスを AWS IoT に接続するための推奨される方法です。AWS IoT Device SDK は、デバイスとクライアントが AWS IoT Core サービスに接続してアクセスするために必要な機能をサポートし、AWS IoT サービスが必要とする認証プロトコルをサポートします。AWS Device SDK を使用して AWS IoT に接続する方法と、サポートされている言語での AWS IoT の例へのリンクについては、AWS IoT Device SDK を使用した MQTT との接続 を参照してください。MQTT メッセージの認証メソッドとポートマッピングの詳細については、プロトコル、ポートマッピング、認証 を参照してください。

AWS IoT Device SDK を使用して AWS IoT に接続することをお勧めしますが、必須ではありません。ただし、AWS IoT Device SDK を使用しない場合は、必要な接続と通信のセキュリティを提供する必要があります。クライアントは、接続リクエストで Server Name Indication (SNI) TLS extension を送信する必要があります。SNI を含まない接続試行は拒否されます。詳細については、「AWS IoT のトランスポートセキュリティ」を参照してください。IAM ユーザーと AWS 認証情報を使用してクライアントを認証するクライアントは、正しい署名バージョン 4 認証を提供する必要があります。

AWS IoT Device SDK を使用した MQTT との接続

このセクションには、AWS IoT Device SDK へのリンクと、デバイスを AWS IoT に接続する方法を示すサンプルプログラムのソースコードへのリンクが含まれています。ここでリンクされているサンプルアプリケーションは、MQTT プロトコルと MQTT over WSS を使用して AWS IoT に接続する方法を示しています。

C++

AWS IoT C++ Device SDK を使用したデバイスの接続

Python

AWS IoT Device SDK for Python を使用したデバイスの接続

JavaScript

AWS IoT Device SDK for JavaScript を使用したデバイスの接続

Java

AWS IoT Device SDK for Java を使用したデバイスの接続

Embedded C

AWS IoT Device SDK for Embedded C を使用したデバイスの接続

重要

この SDK は、経験豊富な組み込みソフトウェアデベロッパーによる使用を想定しています。

MQTT Quality of Service (QoS) オプション

AWS IoT と AWS IoT Device SDK は、MQTT サービス品質 (QoS) レベル 01 をサポートしています。MQTT プロトコルは QoS の 3 番目のレベルであるレベル 2 を定義しますが、AWS IoT はそれをサポートしていません。MQTT プロトコルのみが QoS 機能をサポートします。HTTPS では QoS はサポートされません。

この表は、各 QoS レベルが、メッセージブローカーに発行されたメッセージ、およびメッセージブローカーによって発行されたメッセージにどのように影響するかを示しています。

次の QoS レベルを使用...

メッセージは...

コメント

QoS レベル 0

送信回数 0 回以上

このレベルは、信頼できる通信リンクを介して送信されるメッセージや、見逃しても問題がないメッセージに使用する必要があります。

QoS レベル 1

少なくとも 1 回送信され、PUBACK 応答が受信されるまで繰り返し送信されます

送信者が正常に配信されたことを示す PUBACK 応答を受信するまで、メッセージは完了したとはみなされません。

MQTT 永続的セッションの使用

永続セッションは、クライアントによって承認されていない、サービスの品質 (QoS) が 1 のクライアントのサブスクリプションとメッセージを保存します。コネクテッドデバイスが永続セッションに再接続すると、セッションが再開され、そのサブスクリプションが復元され、再接続前に受信され、クライアントによって確認されていないサブスクライブされたメッセージがクライアントに送信されます。

永続セッションの作成

MQTT 永続的セッションを作成するには、CONNECT メッセージを送信して、cleanSession フラグを 0 に設定します。CONNECT メッセージを送信したクライアントのセッションが存在しない場合は、新しい永続セッションが作成されます。クライアントのセッションが既に存在する場合は、クライアントは既存のセッションを再開します。

永続セッション中の操作

クライアントは、connection acknowledged (CONNACK) メッセージの sessionPresent 属性を調べて、永続的セッションが存在するかどうかを確認します。sessionPresent1 の場合、永続セッションが存在し、クライアントの保存済みメッセージは、クライアントが CONNACK を受信した直後にクライアントに配信されます。これについては、永続セッションへの再接続後のメッセージトラフィックを参照してください。sessionPresent1 の場合、クライアントは再サブスクライブする必要はありません。ただし、sessionPresent0 である場合は、永続的セッションが存在しないため、クライアントはそのトピックフィルターに再度サブスクライブする必要があります。

クライアントは永続セッションに参加した後も、各オペレーションにフラグを追加することなく、メッセージの発行とトピックフィルターのサブスクライブを行うことができます。

永続セッションへの再接続後のメッセージトラフィック

永続的セッションは、クライアントと MQTT メッセージブローカーの間の継続的な接続を表します。クライアントが永続的セッションを使用してメッセージブローカーに接続すると、クライアントが接続中に作成するすべてのサブスクリプションがメッセージブローカーによって保存されます。クライアントの接続が切断されると、クライアントがサブスクライブしているトピックにパブリッシュされた未確認の QoS 1 メッセージと新しい QoS 1 メッセージが保存されます。メッセージはアカウントの制限に従って保存され、その制限を超えるメッセージは削除されます。永続的なメッセージの制限の詳細については、「 AWS IoT Core のエンドポイントとクォータ」を参照してください。クライアントが永続的セッションに再接続すると、すべてのサブスクリプションが回復され、保存されているすべてのメッセージがクライアントに送信されます。その際の最大レートは 1 秒あたり 10 メッセージです。

再接続後、保存されたメッセージは、Publish requests per second per connection 制限に達するまで、現在のメッセージトラフィックとともに、1 秒あたり 10 個の保存されたメッセージに制限されたレートでクライアントに送信されます。保存されたメッセージの配信レートは制限されているため、再接続後にセッションに 10 個を超える保存されたメッセージがある場合、すべての保存されたメッセージを配信するには数秒かかります。

永続セッションの終了

次の条件は、永続的セッションの終了方法を記述します。

  • 永続セッションの有効期限が経過したとき。永続セッションの有効期限タイマーは、クライアントの切断または接続のタイムアウトによってクライアントが切断されたことをメッセージブローカーが検出すると開始されます。

  • クライアントが cleanSession フラグを 1 に設定する CONNECT メッセージを送信したとき。

注記

セッションの終了時にクライアントに送信されるのを待機している保存済みメッセージは破棄されます。ただし、送信できなかった場合でも、標準のメッセージングレートで請求されます。メッセージの料金の詳細については、「 AWS IoT Core の料金」を参照してください。有効期限の時間間隔を設定できます。

永続セッションの有効期限が切れた後の再接続

有効期限が切れる前にクライアントが永続セッションに再接続しない場合、セッションは終了し、保存されたメッセージは破棄されます。セッションの有効期限が切れた後に cleanSession フラグを使用してクライアントが 0 に再接続すると、サービスは新しい永続的セッションを作成します。前のセッションのサブスクリプションまたはメッセージは、前のセッションの有効期限が切れたときに破棄されたため、このセッションでは使用できません。

永続セッションのメッセージ料金

メッセージブローカーがクライアントまたはオフラインの永続セッションにメッセージを送信すると、メッセージの課金が発生し、 AWS アカウント に請求されます。永続セッションを持つオフラインデバイスが再接続してセッションを再開すると、保存されたメッセージがデバイスに配信され、アカウントに再び課金されます。メッセージの料金の詳細については、「 AWS IoT Core の料金 - メッセージング」を参照してください。

標準の制限引き上げプロセスを使用すると、デフォルトの永続セッションの有効期間を 1 時間引き上げることができます。セッションの有効期限を延長すると、メッセージ料金が増加する可能性があることに注意してください。これは、時間を延長するとオフラインデバイスに保存されるメッセージが増える可能性があり、標準のメッセージング料金でこれらの追加のメッセージが課金され、アカウントに請求されるためです。セッションの有効期限は概算であり、セッションはアカウントの制限よりも最長で 30 分長く持続する可能性があります。ただし、セッションはアカウントの制限より短くなることはありません。セッションの制限の詳細については、「AWS Service Quotas」を参照してください。

connectAttributes の使用

ConnectAttributes は、PersistentConnectLastWill などの IAM ポリシーの接続メッセージで使用する属性を指定できます。ConnectAttributes を使用すると、デフォルトではデバイスに新機能へのアクセスを許可しないポリシーを構築できます。これは、デバイスが侵害された場合に役立ちます。

connectAttributes でサポートされる機能は以下のとおりです。

PersistentConnect

PersistentConnect 機能を使用して、クライアントとブローカー間の接続が中断されたときに、接続中にクライアントが作成したすべてのサブスクリプションを保存します。

LastWill

LastWill 機能を使用して、クライアントが予期せず切断したときにメッセージを LastWillTopic に発行します。

デフォルトでは、ポリシーには非永続的な接続があり、この接続用に渡される属性はありません。永続的な接続が必要な場合は、IAM ポリシーで永続的な接続を指定する必要があります。

ConnectAttributes 例については、接続ポリシーの例を参照してください。

AWS IoT と MQTT バージョン 3.1.1 の仕様の違い

メッセージブローカーの実装は MQTT v3.1.1 の仕様に基づいていますが、次の点で仕様とは異なります。

  • AWS IoT は MQTT サービス品質 (QoS) レベル 0 と 1 のみをサポートします。AWS IoT は、QoS レベル 2 でのパブリッシュまたはサブスクライブをサポートしていません。QoS 2 レベル 2 がリクエストされると、メッセージブローカーは PUBACK または SUBACK を送信しません。

  • AWS IoT では、QoS レベル 0 でトピックにサブスクライブすると、メッセージが 0 回以上配信されます。メッセージは複数回配信される場合があります。複数回配信されるメッセージは、異なるパケット ID を使用して送信される場合があります。これらの場合、DUP フラグは設定されません。

  • 接続リクエストに応答するとき、メッセージブローカーは CONNACK メッセージを送信します。このメッセージには、接続で前のセッションを再開するかどうかを示すフラグが含まれます。

  • 追加の制御パケットまたは切断リクエストを送信する前に、クライアントは、AWS IoT メッセージブローカーから CONNACK メッセージがデバイスで受信されるのを待機する必要があります。

  • クライアントがトピックにサブスクライブすると、メッセージブローカーは SUBACK を送信してから、クライアントが新しい一致するメッセージの受信を開始するまでに、遅延が生じる場合があります。

  • MQTT の仕様では、ブローカーがトピックに送信された最後のメッセージを保持して以後のすべてのトピックサブスクライバーに送信することをリクエストするように、パブリッシャーをプロビジョニングします。AWS IoT では、メッセージの保持はサポートされていません。ブローカーがメッセージを保持するようにリクエストされた場合、接続は切断されます。

  • メッセージブローカーは、クライアント ID を使用して、各クライアントを識別します。クライアント ID は MQTT ペイロードの一部としてクライアントからメッセージブローカーに渡されます。クライアント ID が同じ 2 つのクライアントがメッセージブローカーに同時に接続することはできません。あるクライアントが別のクライアントのクライアント ID を使用してメッセージブローカーに接続すると、新しいクライアント接続が受け入れられ、以前に接続されたクライアントは切断されます。

  • まれに、メッセージブローカーは、パケット ID が異なる同じ論理 PUBLISH メッセージを再送信する場合があります。

  • メッセージブローカーはメッセージと ACK の正しい受信順序を確保するわけではありません。