「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
MQTT
MQTT
AWS IoT Core supports device connections that use the MQTT protocol and MQTT over WSS protocol. The AWS IoTDevice SDKs support both protocols and are the recommended ways to connect devices to AWS IoT. The AWS IoT Device SDKs support the functions necessary for devices and clients to connect to and access AWS IoT Core services and they support the authentication protocols that the AWS IoT services require. For information about how to connect to AWS IoT using the AWS Device SDKs and links to examples of AWS IoT in the supported languages, see Connecting with MQTT using the AWS IoT Device SDKs. For more information about authentication methods and the port mappings for MQTT messages, see プロトコル、ポートマッピング、認証.
While we recommend using the AWS IoT Device SDKs to connect to AWS IoT, they are not
required. If you do not use the AWS IoT Device SDKs, however, you must provide the
necessary connection and communication security. Clients must send the Server Name Indication (SNI) TLS extension
Connecting with MQTT using the AWS IoT Device SDKs
This section contains links to the AWS IoT Device SDKs and to the source code of sample programs that illustrate how to connect a device to AWS IoT. The sample apps linked here show how to connect to AWS IoT using the MQTT protocol and MQTT over WSS.
MQTT Quality of Service (QoS) options
AWS IoT and the AWS IoT Device SDKs support the MQTT Quality of Service (QoS) levels 0
and 1
2
, but AWS IoT does not support it. Only the MQTT protocol supports the QoS feature.
HTTPS does not support QoS.
This table describes how each QoS level affects messages published to and by the message broker.
With a QoS level of... |
The message is... |
コメント |
---|---|---|
QoS level 0 |
Sent zero or more times |
This level should be used for messages that are sent over reliable communication links or that can be missed without a problem. |
QoS level 1 |
Sent at least one time, and then repeatedly until a |
The message is not considered complete until the sender receives a |
Using MQTT persistent sessions
Persistent sessions store a client’s subscriptions and messages, with a quality of service (QoS) of 1, that have not been acknowledged by the client. When a disconnected device reconnects to a persistent session, the session resumes, its subscriptions are reinstated, and subscribed messages received prior to the reconnection and that have not been acknowledged by the client are sent to the client.
Creating a persistent session
You create an MQTT persistent session by sending a CONNECT
message and setting the cleanSession
flag to 0
. If no session exists for the client sending the CONNECT
message, a new persistent session is created. If a session already exists for the
client, the client resumes the existing session.
Operations during a persistent session
Clients use the sessionPresent
attribute in the connection acknowledged (CONNACK
) message to determine if a persistent session is present. If sessionPresent
is 1
, a persistent session is present and any stored messages for the client are delivered
to the client immediately after the client receives the CONNACK
, as described in Message traffic after reconnection to a persistent session. If sessionPresent
is 1
, there is no need for the client to resubscribe. However, if sessionPresent
is 0
, no persistent session is present and the client must resubscribe to its topic filters.
After the client joins a persistent session, it can publish messages and subscribe to topic filters without any additional flags on each operation.
Message traffic after reconnection to a persistent session
A persistent session represents an ongoing connection between a client and an MQTT message broker. When a client connects to the message broker using a persistent session, the message broker saves all subscriptions that the client makes during the connection. クライアントの接続が切断されると、クライアントがサブスクライブしているトピックにパブリッシュされた未確認の QoS 1 メッセージと新しい QoS 1 メッセージが保存されます。Messages are stored according to account limit, messages that exceed that limit will be dropped. For more information about persistent message limits, see AWS IoT Core endpoints and quotas. When the client reconnects to its persistent session, all subscriptions are reinstated and all stored messages are sent to the client at a maximum rate of 10 messages per second.
After reconnection, the stored messages are sent to the client, at a rate that is
limited to 10 stored messages per second, along with any current message traffic until
the Publish requests per second per connection
limit is reached. Because the delivery rate of the stored messages is limited it
will take several seconds to deliver all stored messages if a session has more than
10 stored messages to deliver after reconnection.
Ending a persistent session
The following conditions describe how persistent sessions can end.
-
When the persistent session expiration time elapses. The persistent session expiration timer starts when the message broker detects that a client has disconnected, either by the client disconnecting or the connection timing out.
-
When the client sends a
CONNECT
message that sets thecleanSession
flag to1
.
The stored messages waiting to be sent to the client when a session ends are discarded;
however, they are still billed at the standard messaging rate, even though they could
not be sent. For more information about message pricing, see AWS IoT Core Pricing
Reconnection after a persistent session has expired
If a client doesn't reconnect to its persistent session before it expires, the session
ends and its stored messages are discarded. When a client reconnects after the session
has expired with a cleanSession
flag to 0
, the service creates a new persistent session. Any subscriptions or messages from
the previous session are not available to this session because they were discarded
when the previous session expired.
Persistent session message charges
Messages are charged to your AWS account when the message broker sends a message to
a client or an offline persistent session. When an offline device with a persistent
session reconnects and resumes its session, the stored messages are delivered to the
device and charged to your account again. For more information about message pricing,
see AWS IoT Core pricing - Messaging
The default persistent session expiration time of one hour can be increased by using the standard limit increase process. Note that increasing the session expiration time might increase your message charges because the additional time could allow for more messages to be stored for the offline device and those additional messages would be charged to your account at the standard messaging rate. The session expiration time is approximate and a session could persist for up to 30 minutes longer than the account limit; however, a session will not be shorter than the account limit. For more information about session limits, see AWS Service Quotas.
Using connectAttributes
ConnectAttributes
allow you to specify what attributes you want to use in your connect message in your
IAM policies such as PersistentConnect
and LastWill
. With ConnectAttributes
, you can build policies that don't give devices access to new features by default,
which can be helpful if a device is compromised.
connectAttributes
でサポートされる機能は以下のとおりです。
PersistentConnect
-
Use the
PersistentConnect
feature to save all subscriptions the client makes during the connection when the connection between the client and broker is interrupted. LastWill
-
Use the
LastWill
feature to publish a message to theLastWillTopic
when a client unexpectedly disconnects.
By default, your policy has non-persistent connection and there are no attributes passed for this connection. You must specify a persistent connection in your IAM policy if you want to have one.
For ConnectAttributes
examples, see Connect Policy Examples.
AWS IoT differences from MQTT version 3.1.1 specification
The message broker implementation is based on the MQTT v3.1.1 specification
-
AWS IoT supports MQTT quality of service (QoS) levels 0 and 1 only. AWS IoT doesn't support publishing or subscribing with QoS level 2. When QoS level 2 is requested, the message broker doesn't send a PUBACK or SUBACK.
-
AWS IoT では、QoS レベル 0 でトピックにサブスクライブすると、メッセージが 0 回以上配信されます。メッセージは複数回配信される場合があります。複数回配信されるメッセージは、異なるパケット ID を使用して送信される場合があります。これらの場合、DUP フラグは設定されません。
-
接続リクエストに応答するとき、メッセージブローカーは CONNACK メッセージを送信します。このメッセージには、接続で前のセッションを再開するかどうかを示すフラグが含まれます。
-
クライアントがトピックにサブスクライブすると、メッセージブローカーは SUBACK を送信してから、クライアントが新しい一致するメッセージの受信を開始するまでに、遅延が生じる場合があります。
-
The MQTT specification provides a provision for the publisher to request that the broker retain the last message sent to a topic and send it to all future topic subscribers. AWS IoT doesn't support retained messages. ブローカーがメッセージを保持するようにリクエストされた場合、接続は切断されます。
-
メッセージブローカーは、クライアント ID を使用して、各クライアントを識別します。クライアント ID は MQTT ペイロードの一部としてクライアントからメッセージブローカーに渡されます。Two clients with the same client ID can't be connected concurrently to the message broker. あるクライアントが別のクライアントのクライアント ID を使用してメッセージブローカーに接続すると、新しいクライアント接続が受け入れられ、以前に接続されたクライアントは切断されます。
-
まれに、メッセージブローカーは、パケット ID が異なる同じ論理 PUBLISH メッセージを再送信する場合があります。
-
The message broker doesn't guarantee the order in which messages and ACK are received.