MQTT

MQTT （訊息佇列遙測傳輸） 是一種輕量且廣泛採用的訊息通訊協定，專為受限的裝置而設計。 的 AWS IoT Core 支援MQTT是以 MQTT v3.1.1 規格和 MQTT v5.0 規格為基礎，並有一些差異，如 所述AWS IoT 與MQTT規格的差異。作為標準的最新版本， 5 MQTT 引入了多項主要功能，這些功能可讓 MQTT型系統更強大，包括新的可擴展性增強功能、改善了錯誤報告，其中包含原因碼回應、訊息和工作階段過期計時器，以及自訂使用者訊息標頭。如需 5 MQTT 個 AWS IoT Core 支援功能的詳細資訊，請參閱 MQTT 5 個支援的功能。 AWS IoT Core 也支援跨MQTT版本 （MQTT 3 和 MQTT 5） 通訊。MQTT 3 個發佈者可以傳送 MQTT 3 個訊息給 5 MQTT 個訂閱者，該訂閱者會收到 MQTT 5 個發佈訊息，反之亦然。

AWS IoT Core 支援使用MQTT通訊協定和MQTT透過WSS通訊協定的裝置連線，並由用戶端 ID 識別。AWS IoT 裝置 SDKs 支援這兩種通訊協定，並且是將裝置連接至 AWS IoT Core的建議方式。 AWS IoT 裝置SDKs支援裝置和用戶端連線至 和存取 AWS IoT 服務所需的功能。裝置SDKs支援 AWS IoT 服務所需的身分驗證通訊協定，以及MQTT通訊協定和MQTT通訊協定WSS所需的連線 ID 需求。如需如何使用 AWS IoT AWS 裝置和支援語言 AWS IoT 中 的範例SDKs連結來連線至 的資訊，請參閱 MQTT 使用 AWS IoT 裝置與 連線 SDKs。如需身分驗證方法和MQTT訊息連接埠映射的詳細資訊，請參閱 通訊協定、連接埠映射和身分驗證。

雖然我們建議使用 AWS IoT 裝置SDKs連線至 AWS IoT，但不需要。不過SDKs，如果您不使用 AWS IoT 裝置 ，則必須提供必要的連線和通訊安全性。用戶端必須在連線請求中傳送伺服器名稱指示 （SNI） TLS延伸。未包含 的連線嘗試SNI會遭到拒絕。如需詳細資訊，請參閱 中的 Transport Security AWS IoT。使用IAM使用者和 AWS 憑證來驗證用戶端的用戶端必須提供正確的 Signature 第 4 版身分驗證。

MQTT 使用 AWS IoT 裝置與 連線 SDKs

本節包含 AWS IoT 裝置SDKs和範例程式原始程式碼的連結，說明如何將裝置連線至 AWS IoT。此處連結的範例應用程式示範如何使用 AWS IoT MQTT通訊協定和 MQTT 連線到 WSS。

注意

AWS IoT 裝置SDKs已發行 5 MQTT 個用戶端。

C++

使用 AWS IoT C++ 裝置SDK連接裝置

• 範例應用程式的原始程式碼，顯示 C++ 中的MQTT連線範例

• AWS IoT C++ 裝置 SDK v2 on GitHub

Python

使用 AWS IoT Device SDK for Python 連接裝置

• 在 Python 中顯示MQTT連線範例的範例應用程式的原始程式碼

• AWS IoT 上的 Python v2 SDK 裝置 GitHub

JavaScript

使用 AWS IoT 裝置 SDK JavaScript 來連接裝置

• 顯示 中MQTT連線範例的範例應用程式的原始程式碼 JavaScript

• AWS IoT JavaScript v2 on SDK的裝置 GitHub

Java

使用 AWS IoT Device SDK for Java 連接裝置

注意

AWS IoT Device SDK for Java v2 現在支援 Android 開發。如需詳細資訊，請參閱 AWS IoT Device SDK for Android 。

• 在 Java 中顯示MQTT連線範例的範例應用程式的原始程式碼

• AWS IoT 上的 Java v2 SDK 裝置 GitHub

Embedded C

使用 AWS IoT Device SDK for Embedded C 連接裝置

重要

這是SDK供經驗豐富的嵌入式軟體開發人員使用。

• 範例應用程式的原始程式碼，顯示 Embedded C 中的MQTT連線範例

• AWS IoT 上的內嵌式 C SDK 裝置 GitHub

MQTT 服務品質 （QoS選項

AWS IoT 和 AWS IoT 裝置SDKs支援MQTT服務品質 QoS） 層級 0和 1。MQTT 通訊協定會定義第三個 QoS 層級 2，但 AWS IoT 不支援。只有MQTT通訊協定支援 QoS 功能。HTTPS 透過傳遞查詢字串參數來支援 QoS，?qos=qos其中的值可以是 0 或 1。

此表格說明各個 QoS 層級如何影響訊息發佈至代理程式的方式，以及訊息代理程式發佈訊息的方式。

具有 QoS 層級…	訊息為…	說明
QoS 層級 0	傳送零次或更多次	此層級應用於透過可靠通訊連結傳送的訊息，或者可能會錯過沒有問題的訊息。
QoS 層級 1	至少傳送一次，然後重複，直到接收到 PUBACK 回應	在寄件者收到 PUBACK 回應以表示成功傳遞之後，才會將訊息視為完整的。

MQTT 持久性工作階段

持久性工作階段會存放用戶端的訂閱和訊息，服務品質 (QoS) 為 1，而這些用戶端尚未確認此服務品質。該裝置重新連線至持久性工作階段時，工作階段會繼續執行，訂閱會復原，且在重新連線之前接收和儲存的未確認的訂閱訊息皆會傳送至用戶端。

儲存訊息的處理會記錄在 CloudWatch 和 CloudWatch Logs 中。如需寫入 CloudWatch 和 CloudWatch Logs 的項目資訊，請參閱 訊息代理程式指標和 佇列日誌項目。

建立持久性工作階段

在 MQTT 3 中，您可以透過傳送訊息CONNECT並將cleanSession旗標設定為 來建立MQTT持久性工作階段0。如果傳送 CONNECT 訊息的用戶端沒有工作階段，則會建立新的持久性工作階段。如果用戶端的工作階段已經存在，用戶端會繼續現有的工作階段。若要建立全新工作階段，請傳送 CONNECT 訊息並將 cleanSession 旗標設定為 1，當用戶端中斷連線時，代理程式將不會儲存任何工作階段狀態。

在 MQTT 5 中，您可以透過設定Clean Start旗標 和 來處理持久性工作階段Session Expiry Interval。「全新啟動」可控制連線工作階段的開始和前一個工作階段的結束。當您設定 Clean Start = 1 時，系統會建立新的工作階段，任何既有的先前工作階段都會終止。當您設定Clean Start = 0 時，連線工作階段會繼續先前的工作階段 (若有)。工作階段過期間隔控制了連線工作階段的結束。工作階段過期間隔指定了工作階段在中斷連線後維持的時間 (以秒為單位的 4 位元組整數)。如果設定 Session Expiry interval =0，系統會在中斷連線時立即終止工作階段。如果CONNECT未在訊息中指定工作階段到期間隔，則預設為 0。

MQTT 5 清除開始和工作階段過期

屬性值	描述
Clean Start= 1	建立一個新的工作階段，並終止先前的工作階段 (若有)。
Clean Start= 0	若有先前的工作階段，則恢復工作階段。
Session Expiry Interval> 0	維持工作階段。
Session Expiry interval= 0	不維持工作階段。

在 MQTT 5 中，如果您設定 Clean Start = 1和 Session Expiry Interval = 0，這相當於 MQTT 3 個清除工作階段。如果您設定 Clean Start = 0和 Session Expiry Interval> 0，這相當於 MQTT 3 個持久性工作階段。

注意

不支援跨MQTT版本 （MQTT 3 和 MQTT 5） 持續性工作階段。3 MQTT 個持久性工作階段無法繼續為 MQTT 5 個工作階段，反之亦然。

持久性工作階段期間的操作

用戶端使用連線認可 (CONNACK) 訊息中的 sessionPresent 屬性，以判斷持久性工作階段是否存在。如果 sessionPresent 是 1，表示存在持久性工作階段，且用戶端的任何已儲存訊息會在用戶端收到 CONNACK 後傳遞至用戶端，如重新連線至持久性工作階段後的訊息流量所述。如果 sessionPresent 是 1，則用戶端不需要重新訂閱。但是，如果 sessionPresent 是 0，表示不存在持久性工作階段，而且用戶端必須重新訂閱其主題篩選條件。

在用戶端加入持久性工作階段之後，它可以繼續發佈訊息並訂閱主題篩選條件，各個操作上無需任何額外的旗標。

重新連線至持久性工作階段後的訊息流量

持久性工作階段代表用戶端與MQTT訊息代理程式之間的持續連線。當用戶端使用持久性工作階段連接至訊息代理程式時，訊息代理程式會儲存用戶端在連線期間所進行的所有訂閱。當用戶端中斷連線時，訊息代理程式會存放未認可的 QoS 1 訊息，以及發佈到用戶端所訂閱之主題的新 QoS 1 訊息。系統會根據帳戶限制儲存訊息。將捨棄超出上限的訊息將。如需持久性訊息限制的詳細資訊，請參閱 AWS IoT Core 端點和配額。當用戶端重新連線至持久性工作階段時，所有訂閱都會恢復，而且所有存放的訊息都會傳送至用戶端，其傳送速率為每秒最多 10 則訊息。在 MQTT 5 中，如果具有訊息過期間隔的傳出 QoS1 在用戶端離線時過期，則在連線恢復後，用戶端將不會收到過期的訊息。

重新連線之後，存放的訊息會以每秒 10 個存放訊息為限的速率傳送至用戶端，以及任何目前的訊息流量，直到達到 Publish requests per second per connection 限制為止。由於已存放訊息的傳遞速率有限，如果工作階段有 10 個以上的存放訊息要在重新連線後傳遞，將需要數秒鐘才能傳遞所有存放訊息。

結束持久性工作階段

持久性工作階段可透過下列方式結束：

• 當持久性工作階段過期時間經過時。當訊息代理程式偵測到用戶端已中斷連線時 (包括用戶端中斷連線或連線逾時)，持久性工作階段過期計時器將會啟動。

• 用戶端傳送將 cleanSession 旗標設定為 1 的 CONNECT 訊息。

在 MQTT 3 中，持久性工作階段過期時間的預設值為一小時，這適用於帳戶中的所有工作階段。

在 MQTT 5 中，您可以為 上的每個工作階段CONNECT和DISCONNECT封包設定工作階段到期間隔。

對於DISCONNECT封包上的工作階段到期間隔：

• 如果目前的工作階段的工作階段到期間隔為 0，則您無法在DISCONNECT封包上將工作階段到期間隔設定為大於 0。

• 如果目前工作階段的工作階段到期間隔大於 0，且您在DISCONNECT封包上將工作階段到期間隔設定為 0，則工作階段將在 結束DISCONNECT。

• 否則，DISCONNECT封包上的工作階段到期間隔將更新目前工作階段的工作階段到期間隔。

注意

當工作階段結束時，等待傳送給用戶端的存放訊息會被捨棄；但即使無法傳送，仍會依照標準的簡訊費率計費。如需訊息定價的詳細資訊，請參閱 AWS IoT Core 定價。您可以設定過期時間間隔。

持久性工作階段過期後重新連線

如果用戶端在過期之前沒有重新連接至其持久性工作階段，工作階段將會結束並捨棄其存放的訊息。當用戶端在工作階段過期後重新連線，並將 cleanSession 旗標設為 0 時，服務會建立新的持久性工作階段。這個工作階段無法使用先前工作階段的任何訂閱或訊息，因為上一個工作階段過期時，這些訂閱或訊息將被捨棄。

持久性工作階段訊息費用

當訊息代理程式傳送訊息至用戶端或離線持久性工作階段 AWS 帳戶 時，訊息會向您的 收費。當具有持久性工作階段的離線裝置重新連線並繼續其工作階段時，存放的訊息會傳遞至裝置，並再次向您的帳戶收費。如需訊息定價的詳細資訊，請參閱 AWS IoT Core 定價：簡訊。

使用標準限制增加程序，可以增加預設的持久性工作階段一小時過期時間。請注意，增加工作階段到期時間可能會增加您的訊息費用，因為額外的時間可能允許離線裝置存放更多訊息，而且將會按照標準簡訊速率向您的帳戶收取這些額外的訊息費用。工作階段過期時間為近似值，工作階段最多可以比帳戶限制長 30 分鐘；不過，工作階段不會短於帳戶限制。如需工作階段限制的詳細資訊，請參閱 AWS Service Quotas。

MQTT 保留的訊息

AWS IoT Core 支援MQTT通訊協定中所述的RETAIN旗標。當用戶端在其發佈MQTT的訊息上設定RETAIN旗標時， AWS IoT Core 會儲存訊息。然後可以將其傳送給新訂閱者，透過呼叫 GetRetainedMessage 操作對其進行檢索，並在 AWS IoT 主控台內予以檢視。

使用MQTT保留訊息的範例

• 作為初始組態訊息

  MQTT 保留的訊息會在用戶端訂閱主題後傳送至用戶端。如果您希望訂閱主題的所有用戶端在訂閱後立即收到MQTT保留的訊息，則可以發佈具有RETAIN旗標集的組態訊息。只要發佈新的組態訊息，訂閱用戶端也會收到該組態的更新。

• 作為最後一個已知的狀態訊息

  裝置可以在目前狀態訊息上設定RETAIN旗標，以便 AWS IoT Core 儲存它們。當應用程式連線或重新連線時，他們可以訂閱此主題，並在訂閱保留的訊息主題後立即取得上次報告的狀態。透過這種方式，可以避免等到來自裝置的下一個訊息才能查看目前狀態。

在本節中：

• 在 中MQTT保留訊息的常見任務 AWS IoT Core
• 計費和保留訊息
• 比較MQTT保留的訊息和MQTT持久性工作階段
• MQTT 保留的訊息和 AWS IoT 裝置影子

在 中MQTT保留訊息的常見任務 AWS IoT Core

AWS IoT Core 會使用RETAIN旗標集儲存MQTT訊息。這些保留的訊息會以一般MQTT訊息的形式傳送至已訂閱主題的所有用戶端，也會儲存為傳送至主題的新訂閱者。

MQTT 保留的訊息需要特定的政策動作，才能授權用戶端存取它們。如需保留訊息政策的使用範例，請參閱 保留訊息政策範例。

本節說明與保留訊息有關的常見操作。

• 建立保留訊息

  用戶端會在訊息發佈時決定是否保留MQTT訊息。用戶端可以在發佈訊息時使用裝置 SDK設定RETAIN旗標。應用程式和服務可以在使用 Publish動作發佈MQTT訊息時設定RETAIN旗標。

  每個主題名稱只會保留一則訊息。發佈至主題的具有RETAIN旗標集的新訊息會取代先前傳送至主題的任何現有保留訊息。

  NOTE：您無法發佈至具有RETAIN旗標集的預留主題。

• 訂閱保留訊息主題

  用戶端訂閱保留的訊息主題，就像訂閱任何其他MQTT訊息主題一樣。訂閱保留訊息主題收到的保留訊息具有RETAIN旗標集。

  當用戶端將具有 0 位元組訊息承載的保留訊息發佈至保留訊息主題 AWS IoT Core 時，保留的訊息會從 中刪除。訂閱保留訊息主題的用戶端也會收到 0 個位元組訊息。

  訂閱內含保留訊息主題的萬用字元主題篩選條件，可讓用戶端接收向保留訊息主題發佈的後續訊息，但不會在訂閱時即傳遞保留訊息。

  NOTE：若要在訂閱時收到保留的訊息，訂閱請求中的主題篩選條件必須完全符合保留的訊息主題。

  訂閱保留訊息主題時收到的保留訊息會設定RETAIN旗標。訂閱用戶端在訂閱後接收的保留訊息未設定 RETAIN 旗標。

• 擷取保留訊息

  當用戶端訂閱帶有保留訊息的主題時，系統就會自動將保留訊息傳遞給用戶端。若要讓用戶端在訂閱時即接收保留訊息，則必須訂閱保留訊息的確切主題名稱。訂閱內含保留訊息主題的萬用字元主題篩選條件，可讓用戶端接收向保留訊息主題發佈的後續訊息，但不會在訂閱時即傳遞保留訊息。

  服務和應用程式可以透過呼叫 ListRetainedMessages 和 GetRetainedMessage 來列出和擷取保留訊息。

  在沒有設定RETAIN旗標的情況下，不會阻止用戶端將訊息發佈到保留的訊息主題。這可能會導致非預期的結果，例如保留訊息與訂閱主題接收到的訊息不相符。

  使用 MQTT 5，如果保留的訊息已設定訊息過期間隔，且保留的訊息過期，訂閱該主題的新訂閱者在成功訂閱後將不會收到保留的訊息。

• 列出保留訊息主題

  您可以透過呼叫 ListRetainedMessages 列出保留訊息，且可以在 AWS IoT 主控台中檢視保留訊息。

• 取得保留訊息的詳細資訊

  您可以透過呼叫 GetRetainedMessage 取得保留訊息的詳細資訊，且可以在 AWS IoT 主控台中檢視這些資訊。

• 保留「Will」訊息

  MQTT 裝置連線時建立的訊息是否可以透過在 Connect Flag bits 欄位中設定Will Retain旗標來保留。

• 刪除保留訊息

  裝置、應用程式和服務可以透過將具有RETAIN旗標集和空白 （0 位元組） 訊息承載的訊息發佈到要刪除之保留訊息的主題名稱來刪除保留訊息。這類訊息從 刪除保留的訊息 AWS IoT Core，會傳送至訂閱主題的用戶端，但不會由 保留 AWS IoT Core。

  您也可以透過在 AWS IoT 主控台中存取保留訊息，來刪除保留訊息。使用 AWS IoT 主控台刪除的保留訊息，也會將 0 個位元組的訊息傳送給已訂閱保留訊息主題的用戶端。

  保留訊息遭刪除後即無法還原。用戶端需要發佈新的保留訊息，以取代已刪除的訊息。

• 對保留訊息進行偵錯和疑難排解

  此 AWS IoT 主控台提供多種工具，可協助您針對保留訊息進行疑難排解：

  • Retained messages (保留訊息) 頁面

    AWS IoT 主控台中的 Retained messages (保留訊息) 頁面會提供分頁清單，列出由您帳戶在目前區域存放的保留訊息。在此頁面上，您可以：

    • 查看每則保留訊息的詳細資訊，例如訊息承載、QoS，以及保留訊息的接收時間。

    • 更新保留訊息的內容。

    • 刪除保留訊息。

  • MQTT 測試用戶端

    主控台中的 AWS IoT MQTT測試用戶端頁面可以訂閱和發佈至MQTT主題。發佈選項可讓您在發佈的訊息上設定RETAIN旗標，以模擬裝置的行為方式。

  有些非預期的結果可能是保留訊息在 中實作方式的這些層面的結果 AWS IoT Core。

  • 保留訊息限制

    當帳戶儲存了保留訊息的最大數量時， 會針對以 RETAIN 設定發佈且承載大於 0 位元組的訊息 AWS IoT Core 傳回限流回應，直到刪除某些保留訊息且保留訊息計數低於限制為止。

  • 保留訊息的傳遞順序

    我們不能保證保留訊息和訂閱訊息的傳遞順序。

計費和保留訊息

透過使用 AWS IoT 主控台或呼叫 發佈具有從用戶端設定之RETAIN旗標的訊息Publish，會產生定價中所述AWS IoT Core 的其他訊息費用 - 訊息 。

除了正常API用量費用之外，透過用戶端、使用 AWS IoT 主控台或呼叫 來擷取保留的訊息GetRetainedMessage會產生訊息費用。AWS IoT Core 定價：簡訊中說明了額外費用。

MQTT 當裝置意外中斷連線時發佈的訊息是否會產生定價中所述AWS IoT Core 的訊息費用 - 訊息 。

如需簡訊成本的詳細資訊，請參閱 AWS IoT Core 定價：簡訊。

比較MQTT保留的訊息和MQTT持久性工作階段

保留的訊息和持久性工作階段是 的標準功能MQTT，可讓裝置接收離線時發佈的訊息。可以透過持久性工作階段發佈的保留訊息。本節說明這些功能的主要特色及其運作方式。

	保留訊息	持久性工作階段
主要功能	保留訊息可用於在連線後對大型裝置群組進行設定或通知。 若您希望裝置在重新連線後，僅接收發佈至主題之最後一則訊息時，即可使用保留訊息。	對於具有間歇性連線且可能會遺漏數則重要訊息的裝置，持久性工作階段能發揮重要作用。 裝置可以與持久性工作階段連線，以便接收在離線時傳送的訊息。
範例	保留訊息可以在裝置上線時提供與其環境有關的組態資訊。初始組態可能包含其應訂閱的其他訊息主題清單，或是應該如何設定其本機時區的相關資訊。	透過行動網路連線且具有間歇性連線的裝置，可能會使用持久性工作階段，以避免在裝置超出網路覆蓋範圍或需要關閉行動無線電時遺失所傳送的重要訊息。
在主題的初始訂閱時收到的訊息	訂閱含有保留訊息的主題後，就會收到最近保留訊息。	若訂閱的主題沒有保留訊息，在有發佈至該主題的訊息前，不會收到任何訊息。
重新連線後的訂閱主題	如果沒有持久性工作階段，用戶端必須在重新連線後訂閱主題。	已訂閱的主題會在重新連線後還原。
重新連線後收到的訊息	訂閱含有保留訊息的主題後，就會收到最近保留訊息。	在裝置中斷連線時，所有以 QOS = 1 發佈且以 QOS = 1 訂閱的訊息都會在裝置重新連線後傳送。
資料/工作階段過期	在 MQTT 3 中，保留的訊息不會過期。這些訊息在遭取代或刪除前都會存放起來。在 MQTT 5 中，保留的訊息會在您設定的訊息到期間隔後過期。如需詳細資訊，請參閱訊息過期。	如果用戶端未在逾時期間內重新連線，則持久性工作階段會過期。持久性工作階段過期後，當裝置中斷連線時，用戶端的訂閱和儲存的訊息會以 QOS = 1 發佈，並以 QOS = 1 訂閱。過期的訊息將不會傳遞。如需持久性工作階段之工作階段過期的詳細資訊，請參閱 MQTT 持久性工作階段。

如需持久性工作階段的相關資訊，請參閱 MQTT 持久性工作階段。

發佈用戶端會透過「保留訊息」判斷是否要在連線後保留訊息並將其傳遞至裝置，以及先前是否有工作階段。發佈者可選擇是否存放訊息，而所存放的訊息會傳遞至透過 QoS 0 或 QoS 1 訂閱進行訂閱的所有現有和未來用戶端。保留訊息一次只會保留一則指定主題的相關訊息。

當帳戶儲存了保留訊息的最大數量時， AWS IoT Core 會針對以 RETAIN 集發佈且承載大於 0 位元組的訊息傳回限流回應，直到刪除某些保留訊息，且保留的訊息計數低於限制。

MQTT 保留的訊息和 AWS IoT 裝置影子

保留訊息和 Device Shadow 都會保留裝置中的資料，但它們的行為不同，用途也不同。本節說明其異同。

	保留訊息	Device Shadow
訊息承載具有預先定義的結構或結構描述	如實作所定義。MQTT 不會為其訊息承載指定結構或結構描述。	AWS IoT 支援特定資料結構。
更新訊息承載會產生事件訊息	發佈保留訊息會將訊息傳送至訂閱的用戶端，但不會產生其他更新訊息。	更新 Device Shadow 會產生更新訊息，其中會描述變更。
已將訊息更新進行編號	不會自動將保留訊息進行編號。	Device Shadow 文件具有自動版本號碼和時間戳記。
訊息承載會連接至物件資源	保留訊息不會連接至物件資源。	Device Shadow 會連接至物件資源。
更新訊息承載的個別元素	如果不更新整個訊息承載，則無法變更訊息的個別元素。	您可以更新 Device Shadow 文件的個別元素，無需更新整個 Device Shadow 文件。
用戶端在訂閱時收到訊息資料	用戶端在訂閱含有保留訊息的主題後，會自動收到保留訊息。	用戶端可以訂閱 Device Shadow 更新，但必須特意請求目前狀態。
索引和可搜尋性	不會為保留訊息建立可供搜尋的索引。	機群索引製作會建立 Device Shadow 資料的索引，以供搜尋和彙總。

MQTT 上次遺囑和遺囑 （LWT） 訊息

Last Will and Testament （LWT） 是 中的功能MQTT。透過 LWT，用戶端可以指定訊息，代理程式將發佈到用戶端定義主題，並在發生未啟動的中斷連線時，傳送給訂閱主題的所有用戶端。用戶端指定的訊息稱為LWT訊息或 Will Message，而用戶端定義的主題稱為 Will Topic。您可以在裝置連線至代理程式時指定LWT訊息。這些訊息可藉由在連線期間，於 Connect Flag bits 欄位中設定 Will Retain 旗標的方式加以保留。例如，如果 Will Retain 旗標設定為 1，Will 訊息將會儲存在代理程式中相關聯的 Will 主題中。如需詳細資訊，請參閱 Will 訊息。

代理程式會儲存 Will 訊息，直到發生意外中斷連線。發生這種情況時，代理程式會將訊息發佈到訂閱 Will 主題的所有用戶端，以通知發生中斷連線。如果用戶端使用MQTTDISCONNECT訊息從代理程式中斷連線，且用戶端啟動中斷連線，代理程式不會發佈儲存LWT的訊息。在所有其他情況下，LWT訊息將發送。如需代理程式傳送訊息時中斷連線案例的完整清單LWT，請參閱連線/中斷連線事件 。

使用 connectAttributes

ConnectAttributes 可讓您指定要在IAM政策中連線訊息中使用的屬性，例如 PersistentConnect和 LastWill。透過 ConnectAttributes，您可以建置預設不允許裝置存取新功能的政策，如果裝置遭到入侵，這會很有幫助。

connectAttributes 支援下列功能：

PersistentConnect

當用戶端和代理程式之間的連線中斷時，使用 PersistentConnect 功能可儲存用戶端在連線期間進行的所有訂閱。

LastWill

當用戶端意外中斷連線時，使用 LastWill 功能可將訊息發佈至 LastWillTopic。

根據預設，您的政策具有非持久性連線，而且沒有傳遞此連線的屬性。如果您想要具有持久性連線，您必須在IAM政策中指定持久性連線。

如需 ConnectAttributes 範例，請參閱連線政策範例。

MQTT 5 個支援的功能

AWS IoT Core 對 MQTT 5 的支援是以 MQTT v5.0 規格為基礎，其中有一些差異，如 中所述AWS IoT 與MQTT規格的差異。

AWS IoT Core 支援下列 MQTT 5 個功能：

• 共享訂閱
• 全新啟動和工作階段過期
• 所有 的原因代碼 ACKs
• 主題別名
• 訊息過期
• 其他 MQTT 5 個功能

共享訂閱

AWS IoT Core 支援 3 MQTT 和 5 MQTT 的共用訂閱。共享訂閱允許多個用戶端共享一個主題的訂閱，而且只有一個用戶端會使用隨機分佈接收發佈至該主題的訊息。共用訂閱可以有效地載入多個訂閱者的平衡MQTT訊息。例如，假設您有 1,000 部裝置發佈至相同主題，而 10 個後端應用程式則處理這些訊息。於此種情況下，後端應用程式可訂閱相同的主題，且每個應用程式將隨機接收由裝置發佈至共享主題的訊息。這實際上是「共享」這些訊息的負載。共享訂閱還可提供更好的彈性。當任何後端應用程式中斷連線時，代理程式會將負載分配給群組中剩餘的訂閱用戶。

如要使用共享訂閱，用戶端訂閱共享訂閱的主題篩選條件，如下所示：

$share/{ShareName}/{TopicFilter}

• $share 是個常值字串，表示共享訂閱的主題篩選條件，必須以 $share 開頭。

• {ShareName} 是個字元字串，用來指定一組訂閱用戶使用的共享名稱。共享訂閱的主題篩選條件必須包含 ShareName，且後面接著 / 字元。{ShareName} 不得包含下列字元：/、+、或 #。{ShareName} 的大小上限為 128 個位元組。

• {TopicFilter} 會遵循與非共享訂閱相同的主題篩選條件語法。{TopicFilter} 的大小上限為 256 個位元組。

• $share/{ShareName}/{TopicFilter} 所需的兩個斜線 (/) 不包含於主題和主題篩選條件中最大斜線數目限制中。

具有相同 {ShareName}/{TopicFilter} 的訂閱屬於相同的共享訂閱群組。您可以建立多個共享訂閱群組，且不超過每個群組的共享訂閱限制。如需詳細資訊，請參閱《AWS 一般參考》中的 AWS IoT Core 端點和配額。

下表對非共享訂閱與共享訂閱進行了比較：

訂閱	描述	主題篩選條件範例
非共享訂閱	每個用戶端都會建立個別訂閱以接收已發佈的訊息。將訊息發佈至某個主題時，該主題的所有訂閱用戶都會收到該訊息的副本。	sports/tennis sports/#
共享訂閱	多個用戶端可共享一個主題的訂閱，且只有一個用戶端會使用隨機分佈接收發佈至該主題的訊息。	$share/consumer/sports/tennis $share/consumer/sports/#

非共享訂閱流程	共享訂閱流程

使用共享訂閱的重要注意事項

• 當發佈至 QoS0 訂閱用戶的嘗試失敗時，不會發生重試嘗試，且會捨棄該訊息。

• 當對具有全新工作階段的 QoS1 訂閱用戶嘗試發佈失敗時，該訊息將會傳送至群組中的另一個訂閱用戶以進行多次重試。在所有重試嘗試之後無法傳遞的訊息將遭捨棄。

• 當對具有持續性工作階段的 QoS1 訂閱用戶嘗試發佈因為訂閱用戶離線而失敗時，該訊息將不會排入佇列，且會嘗試傳送至群組中的另一個訂閱用戶。在所有重試嘗試之後無法傳遞的訊息將遭捨棄。

• 共享訂閱不會收到保留的訊息。

• 當共享訂閱包含萬用字元 (# 或 +) 時，可能會有多個與主題相符的共享訂閱。若發生這種情況，訊息代理程式會複製發佈訊息，並將其傳送至每個相符之共享訂閱中的隨機用戶端。共享訂閱的萬用字元行為可說明於下圖中。

  

  在此範例中，有三個符合發佈MQTT主題 的共用訂閱sports/tennis。訊息代理程式會複製已發佈的訊息，並將該訊息傳送至每個相符群組中的隨機用戶端。

  用戶端 1 和用戶端 2 共享訂閱：$share/consumer1/sports/tennis

  用戶端 3 和用戶端 4 共享訂閱：$share/consumer1/sports/#

  用戶端 5 和用戶端 6 共享訂閱：$share/consumer2/sports/tennis

如需有關共享訂閱限制的詳細資訊，請參閱《AWS 一般參考》中的 AWS IoT Core 端點和配額。若要使用AWS IoT 主控台 AWS IoT MQTT中的用戶端測試共用訂閱，請參閱 在MQTT用戶端中測試共用訂閱。如需共用訂閱的詳細資訊，請參閱 MQTTv5.0 規格中的共用訂閱。

全新啟動和工作階段過期

您可以使用「全新啟動」和「工作階段過期」，以更具彈性的方式處理持久性工作階段。「全新啟動」旗標指出工作階段是否應在不使用現有工作階段的情況下啟動。「工作階段過期」間隔指出中斷連線後保留工作階段的時間長度。可在中斷連線時修改工作階段過期間隔。如需詳細資訊，請參閱MQTT 持久性工作階段。

所有 的原因代碼 ACKs

您可以使用原因代碼更輕鬆地偵錯或處理錯誤訊息。訊息代理程式會根據與代理程式的互動類型 (「訂閱」、「發佈」、「確認」) 傳回原因代碼。如需詳細資訊，請參閱MQTT原因代碼 。如需MQTT原因代碼的完整清單，請參閱 MQTT v5 規格 。

主題別名

主題別名是一種雙位元組整數，可用來取代主題名稱。使用主題別名可以最佳化主題名稱的傳輸，以降低計量資料服務的資料成本。預設限制 AWS IoT Core 為 8 個主題別名。如需詳細資訊，請參閱《AWS 一般參考》中的 AWS IoT Core 端點和配額。

訊息過期

您可以對已發佈的訊息新增訊息過期值。這些值表示訊息過期間隔 (以秒為單位)。如果訊息尚未在該間隔內傳送給訂閱者，則訊息將會過期並予以移除。如果未設定訊息過期值，訊息就不會過期。

在傳出流量中，訂閱者會收到一條訊息，告知過期間隔的剩餘時間。例如，如果傳入發佈訊息的訊息過期時間為 30 秒，且在 20 秒後路由給訂閱者，則訊息過期欄位會更新為 10。訂閱者收到的訊息有可能更新為 MEI 0。這是因為在剩餘時間達到 999 毫秒以下，它將更新為 0。

在 中 AWS IoT Core，最小訊息到期間隔為 1。如果從用戶端將間隔設定為 0，則系統會將其調整為 1。訊息過期間隔上限為 604800 (7 天)。任何較高的值都將調整為最大值。

在跨版本通訊中，訊息過期的行為取決於傳入發佈訊息的MQTT版本。例如，透過 連線之工作階段所傳送的訊息過期訊息，對於訂閱MQTT3工作階段的裝置MQTT5可能會過期。下表列出訊息過期功能如何支援下列類型的發佈訊息：

發佈訊息類型	訊息過期間隔
常規發佈	如果伺服器無法在指定的時間內傳遞訊息，則過期的訊息將遭移除，而訂閱者將不會收到這些訊息。這包括裝置未發佈其 QoS 1 訊息等情況。
保留	如果保留的訊息到期，而新用戶端訂閱了該主題，則該用戶端將不會在訂閱時收到訊息。
遺言	遺言訊息的間隔會在用戶端中斷連線之後啟動，而伺服器會嘗試將遺言訊息傳遞給其訂閱者。
佇列訊息	如果具有訊息過期間隔的傳出 QoS1 在用戶端離線時過期，則用戶端在持久性工作階段恢復後將不會收到過期的訊息。

其他 MQTT 5 個功能

伺服器中斷連線

發生中斷連線時，伺服器可以主動傳送用戶端 DISCONNECT，以使用中斷連線的原因代碼來通知連線關閉。

請求/回應

發佈者可以請求接收者在接收時將回應傳送至發佈者指定的主題。

封包大小上限

用戶端和伺服器可以分別指定其支援的最大封包大小。

承載格式和內容類型

您可以在發佈訊息時指定承載格式 (二進位、文字) 和內容類型。這些會轉發給訊息接收者。

MQTT 5 個屬性

MQTT 5 個屬性是MQTT標準的重要補充，以支援新的 MQTT 5 個功能，例如工作階段過期和請求/回應模式。在 中 AWS IoT Core，您可以建立規則，以轉送傳出訊息中的屬性，或使用HTTP發佈來發佈具有某些新屬性MQTT的訊息。

下表列出 AWS IoT Core 支援的所有 MQTT 5 個屬性。

屬性	描述	輸入類型	封包
承載格式指示器	布林值，指出承載的格式是否為 UTF-8。	位元組	PUBLISH, CONNECT
內容類型	描述承載內容的 UTF-8 字串。	UTF-8 字串	PUBLISH, CONNECT
回應主題	描述接收者應發佈作為請求回應流程一部分的主題的 UTF-8 字串。主題不得包含萬用字元。	UTF-8 字串	PUBLISH, CONNECT
相互關聯資料	請求訊息的傳送者使用的二進位資料，用以識別回應訊息所對應的請求。	二進位	PUBLISH, CONNECT
使用者屬性	UTF-8 字串對。這個屬性可能在單一封包中出現多次。接收者將以與傳送索引鍵值對相同的順序來接收索引鍵。	UTF-8 字串對	CONNECT、PUBLISH、Will Properties、SUBSCRIBE、DISCONNECT、 UNSUBSCRIBE
訊息過期間隔時間	4 位元組整數，代表訊息過期間隔時間 (以秒為單位)。如果不存在，則訊息不會到期。	4 位元組整數	PUBLISH, CONNECT
工作階段過期間隔時間	代表工作階段到期間隔的 4 位元組整數，以秒為單位。 AWS IoT Core 支援最長 7 天，預設最長 1 小時。如果您設定的值超過帳戶上限， AWS IoT Core 會在 中傳回調整後的值CONNACK。	4 位元組整數	CONNECT, CONNACK, DISCONNECT
已指派的用戶端識別碼	裝置未指定用戶端 ID AWS IoT Core 時，由 產生的隨機用戶端 ID。隨機用戶端 ID 必須是新的用戶端識別碼，且目前由代理程式管理的任何其他工作階段都未予以使用。	UTF-8 字串	CONNACK
伺服器保持連線	2 位元組整數，代表伺服器指派的保持連線時間。如果用戶端離線的時間超過保持連線時間，伺服器將中斷用戶端的連線。	2 位元組整數	CONNACK
請求問題資訊	此布林值指出發生失敗時是否傳送原因字串或使用者屬性。	位元組	CONNECT
接收上限	2 位元組整數，代表 > PUBLISH QOS 0 個封包的最大數量，可在不接收 的情況下傳送PUBACK。	2 位元組整數	CONNECT, CONNACK
主題別名上限	此值表示將接受為主題別名的最高值。預設值為 0。	2 位元組整數	CONNECT, CONNACK
QoS 上限	AWS IoT Core 支援的 QoS 最大值。預設為 1。 AWS IoT Core 不支援 QoS2。	位元組	CONNACK
保留可用	布林值，指出 AWS IoT Core 訊息代理程式是否支援保留的訊息。預設為 1。	位元組	CONNACK
封包大小上限	AWS IoT Core 接受和傳送的最大封包大小。不能超過 128 KB。	4 位元組整數	CONNECT, CONNACK
可用的萬用字元訂閱	指出 AWS IoT Core 訊息代理程式是否支援可用萬用字元訂閱的布林值。預設為 1。	位元組	CONNACK
可用的訂閱識別碼	布林值，指出 AWS IoT Core 訊息代理程式是否支援可用的訂閱識別碼。預設值為 0。	位元組	CONNACK

MQTT 原因代碼

MQTT 5 引入了改進的錯誤報告，其中包含原因碼回應。 AWS IoT Core 可能會傳回原因碼，包括但不限於下列依封包分組的代碼。如需 5 MQTT 支援的原因代碼完整清單，請參閱 MQTT 5 規格 。

CONNACK 原因代碼

Value	Hex	原因代碼名稱	描述
0	0x00	Success (成功)	已接受連線。
128	0x80	未指定的錯誤	伺服器不願揭露失敗原因，或者沒有其他適用的原因代碼。
133	0x85	用戶端識別碼無效	用戶端識別碼是有效字串，但未獲伺服器允許。
134	0x86	使用者名稱或密碼錯誤	伺服器不接受用戶端指定的使用者名稱或密碼。
135	0x87	未獲授權	用戶端未獲得連線的授權。
144	0x90	主題名稱無效	遺言主題名稱已正確產生，但未獲伺服器接受。
151	0x97	超過配額	已超出實作或管理施加的限制。
155	0x9B	不支援 QoS。	伺服器不支援遺言 QoS 中的 QoS 集。

PUBACK 原因代碼

Value	Hex	原因代碼名稱	描述
0	0x00	Success (成功)	已接受訊息。QoS 1 訊息的發佈作業繼續進行。
128	0x80	未指定的錯誤	接收者不接受發佈內容，但不願揭露原因，或不符合其中一個其他值。
135	0x87	未獲授權	PUBLISH 未授權。
144	0x90	主題名稱無效	主題名稱格式不正確，但未獲用戶端或伺服器接受。
145	0x91	使用中的封包識別碼	封包識別碼已在使用中。這可能表示用戶端與伺服器之間的工作階段狀態不相符。
151	0x97	超過配額	已超出實作或管理施加的限制。

DISCONNECT 原因代碼

Value	Hex	原因代碼名稱	描述
129	0x81	格式錯誤的封包	接收到的封包不符合此規格。
130	0x82	協定錯誤	收到非預期或亂序的封包。
135	0x87	未獲授權	請求未獲得授權。
139	0x8B	伺服器關閉	伺服器正在關閉。
141	8D	保持連線逾時	連線已關閉，因為未接收任何封包的時間已達到保持連線時間的 1.5 倍。
142	0x8E	已接管工作階段	系統已連接到使用相同 ClientID 的另一個連線，導致此連線關閉。
143	0x8F	主題篩選條件無效	意願主題名稱格式正確，但未獲伺服器接受。
144	0x90	主題名稱無效	主題名稱格式正確，但未獲此用戶端或伺服器接受。
147	0x93	超過接收上限	用戶端或伺服器已收到超過尚未傳送PUBACK或 的接收上限出版物PUBCOMP。
148	0x94	主題別名無效	用戶端或伺服器已收到封包，其中包含的主題別名大於在 或 PUBLISH 封包中傳送的主題別名上限CONNECTCONNACK。
151	0x97	超過配額	已超出實作或管理施加的限制。
152	0x98	管理動作	由於系統執行管理動作，導致連線關閉。
155	0x9B	不支援 QoS。	用戶端指定的 QoS 大於 中最大 QoS 中指定的 QoSCONNACK。
161	0xA1	不支援訂閱識別碼	伺服器不支援訂閱識別碼；未接受訂閱。

SUBACK 原因代碼

Value	Hex	原因代碼名稱	描述
0	0x00	授予 QoS 0	已接受訂閱，且傳送的 QoS 上限為 QoS 0。這可能是低於請求的 QoS。
1	0x01	授予 QoS 1	已接受訂閱，且傳送的 QoS 上限為 QoS 1。這可能是低於請求的 QoS。
128	0x80	未指定的錯誤	未接受訂閱，伺服器不願揭露原因，或者其他原因代碼均不適用。
135	0x87	未獲授權	用戶端未獲授權進行此訂閱。
143	0x8F	主題篩選條件無效	主題篩選器的格式正確，但不允許此用戶端使用。
145	0x91	使用中的封包識別碼	指定的封包識別碼已在使用中。
151	0x97	超過配額	已超出實作或管理施加的限制。

UNSUBACK 原因代碼

Value	Hex	原因代碼名稱	描述
0	0x00	Success (成功)	訂閱已刪除。
128	0x80	未指定的錯誤	取消訂閱無法完成，伺服器不願揭露原因，或者其他原因代碼均不適用。
143	0x8F	主題篩選條件無效	主題篩選器的格式正確，但不允許此用戶端使用。
145	0x91	使用中的封包識別碼	指定的封包識別碼已在使用中。

AWS IoT 與MQTT規格的差異

訊息代理程式實作是以 MQTT v3.1.1 規格和 MQTT v5.0 規格為基礎，但其與規格的差異在於下列方式：

• AWS IoT 不支援 3 MQTT 的下列封包：PUBREC、 PUBREL和 PUBCOMP。

• AWS IoT 不支援 5 MQTT 的下列封包：PUBREC、PUBCOMP、 PUBREL和 AUTH。

• AWS IoT 不支援 MQTT 5 個伺服器重新導向。

• AWS IoT 僅支援服務MQTT品質 QoS） 層級 0 和 1。 AWS IoT 不支援發佈或使用 QoS 層級 2 訂閱。當請求 QoS 層級 2 時，訊息代理程式不會傳送 PUBACK或 SUBACK。

• 在 中 AWS IoT，訂閱 QoS 層級 0 的主題表示訊息傳遞零次或更多次。一則訊息可能會傳送超過一次。傳送超過一次的訊息在發送時可能會使用不同的封包 ID。在這些情況下，不會設定DUP旗標。

• 回應連線請求時，訊息代理程式會傳送訊息CONNACK。此訊息包含了一個旗標，指出連線是否會恢復先前的工作階段。

• 在傳送其他控制封包或中斷連線請求之前，用戶端必須等待從CONNACK AWS IoT 訊息代理程式在其裝置上接收訊息。

• 當用戶端訂閱主題時，訊息代理程式傳送 的時間SUBACK與用戶端開始接收新的相符訊息的時間之間可能會有延遲。

• 當用戶端在主題篩選條件中使用萬用字元 # 以訂閱主題時，主題階層中位於及低於其層級的所有字串都會相符。不過，父系主題不相符。例如，訂閱主題 sensor/# 會收到向主題 sensor/、sensor/temperature、sensor/temperature/room1 發佈的訊息，但不會收到向 sensor 發佈的訊息。如需萬用字元的詳細使用資訊，請參閱 主題篩選條件。

• 訊息代理程式使用用戶端 ID 來識別每一個用戶端。用戶端 ID 會從用戶端傳入訊息代理程式，作為MQTT承載的一部分。具有相同用戶端 ID 的兩個用戶端，不能同時連線至訊息代理程式。當用戶端使用另一個用戶端正在使用的用戶端 ID 連線至訊息代理程式，系統會接受新的用戶端連線，而先前連線的用戶端會中斷連線。

• 在極少數情況下，訊息代理程式可能會以不同的封包 ID 重新傳送相同的邏輯PUBLISH訊息。

• 包含萬用字元的主題篩選條件訂閱無法接收保留訊息。若要接收保留訊息，訂閱請求必須包含與保留訊息主題完全相符的主題篩選條件。

• 訊息代理程式不保證ACK收到訊息和 的順序。

• AWS IoT 可能有與規格不同的限制。如需詳細資訊，請參閱AWS IoT 參考指南中的 AWS IoT Core 訊息代理程式和通訊協定限制和配額。

• 不支援此MQTTDUP旗標。