Azure 事件方格 MQTT 訊息代理程式功能支援的 MQTT 功能

  • 發行項

MQTT 是一種發佈-訂閱傳訊傳輸通訊協定，專為受限制的環境所設計。 它是有效率、可調整且可靠的，因此成為IoT案例中通訊的黃金標準。 MQTT 訊息代理程式支援透過 MQTT v3.1.1、透過 WebSocket 發行和訂閱 MQTT v3.1.1、MQTT v5 和 MQTT v5 的用戶端。 MQTT 訊息代理程式也支援跨 MQTT 版本 （MQTT 3.1.1 和 MQTT 5） 通訊。

MQTT v5 引進了 MQTT v3.1.1 的許多改進功能，以提供更順暢、透明且有效率的通訊。 它已新增：

  • 更好的錯誤報告。
  • 透過使用者屬性和內容類型等功能，更透明的通訊用戶端。
  • 透過訊息和會話到期等功能，更能控制客戶端的通訊。
  • 標準的重要模式，例如要求-回應模式。

連線 流程：

MQTT 用戶端 必須 透過 TLS 1.2 或 TLS 1.3 連線。 嘗試略過此步驟失敗，但連線失敗。

線上到 MQTT 訊息代理程式時，透過 MQTT 進行通訊時，請使用下列埠：

  • TCP 連接埠 8883 上的 MQTT v3.1.1 和 MQTT v5
  • MQTT v3.1.1 over WebSocket 和 MQTTv5 over WebSocket on TCP 連接埠 443。

CONNECT 封包應該包含下列屬性：

  • [ClientId] 字段是必要的，而且它應該包含用戶端的會話名稱。 會話名稱在整個命名空間中必須是唯一的。 如果每個用戶端使用每個用戶端一個工作階段，您可以使用客戶端驗證名稱作為工作階段名稱。 如果一個用戶端使用多個會話，它必須針對每個會話使用不同的 ClientId 值。
  • 如果您在命名空間建立期間未選取alternativeAuthenticationNameSources中的值，則需要 [用戶名稱] 字段。 在此情況下，您必須在 [用戶名稱] 字段中提供客戶端的驗證名稱。 該名稱必須符合提供的驗證名稱，以及客戶端憑證欄位中在客戶端資源建立期間指定的值。

深入瞭解 客戶端驗證。

多會話支援

多會話支援可讓應用程式 MQTT 用戶端同時連線到具有多個作用中會話的 MQTT 訊息代理程式，以擁有更可調整且可靠的實作。

命名空間組態

使用這項功能之前，您必須設定 命名空間，以允許每個用戶端的多個會話。 使用下列步驟，在 Azure 入口網站 中設定每個用戶端的多個工作階段：

  • 移至 Azure 入口網站 中的命名空間。
  • 在 [組態] 下，將 [每個驗證名稱的用戶端會話上限] 的值變更為每個用戶端所需的會話數目。
  • 選取 [套用] 。

注意

針對 Azure CLI 組態，使用所需的值更新 命名空間承載中的 MaxClientSessionsPerAuthenticationName 屬性。

連線 流量：

每個工作階段的 CONNECT 封包應該包含下列屬性：

  • 在 CONNECT 封包中提供 Username 屬性，以表示客戶端驗證名稱。
  • 在 CONNECT 封包中提供 ClientID 屬性，以表示會話名稱，例如每個 Username 的 ClientID 有一或多個值。

例如，CONNECT 封包中的下列 Username 和 ClientId 組合可讓用戶端 “Mgmt-application” 透過三個獨立會話聯機到 MQTT 訊息代理程式：

  • 第一個會話：
    • 用戶名稱：Mgmt-application
    • ClientId：Mgmt-Session1
  • 第二個會話：
    • 用戶名稱：Mgmt-application
    • ClientId：Mgmt-Session2
  • 第三個會話：
    • 用戶名稱：Mgmt-application
    • ClientId：Mgmt-Session3

多會話範例的圖表。

如需詳細資訊，請參閱 如何為單一用戶端建立多個會話。

處理工作階段：

  • 如果客戶端嘗試以不同的驗證名稱呈現其會話名稱來接管另一個用戶端的作用中會話，則會拒絕其連線要求，並出現未經授權的錯誤。 例如，如果用戶端 B 嘗試連線到用戶端 A 當時指派的會話 123，用戶端 B 的連線要求就會遭到拒絕。 也就是說，如果相同的客戶端嘗試使用相同的會話名稱和相同的驗證名稱重新連線，就可以接管其現有的會話。
  • 如果刪除客戶端資源而不結束其會話，其他用戶端將無法使用其會話名稱，直到會話到期為止。 例如，如果用戶端 B 建立會話名稱為 123 的工作階段，用戶端 B 就會被刪除，用戶端 A 在到期前無法連線到會話 123。
  • 每個用戶端的會話數目限制適用於任何時間點的在線和脫機會話。 例如，假設每個驗證名稱具有最大用戶端會話的命名空間設定為1。 如果用戶端 A 與持續性會話 123 連線，則用戶端 A 將無法連線到新的會話 456，因為其會話 123 仍然處於作用中狀態，即使它已離線也一樣。 因此，我們建議相同的用戶端一律使用相同的靜態會話名稱重新連線，而不是使用每次重新連線產生新的會話名稱。

MQTT 功能

Azure 事件方格 的 MQTT 訊息代理程式功能支援下列 MQTT 功能：

服務品質（QoS）

MQTT 訊息代理程式支援 QoS 0 和 1，其定義用戶端與 MQTT 訊息代理程式之間發佈和訂閱封包的保證。 QoS 0 保證最多一次傳遞;訂閱者不會認可具有 QoS 0 的訊息，也不會由發行者重新傳輸。 QoS 1 保證至少一次傳遞;如果訊息未獲得認可，則訂閱者會認可訊息，並由發行者重新傳輸。 QoS 可讓用戶端控制通訊的效率和可靠性。

持續性會話

MQTT 訊息代理程式支援 MQTT v3.1.1 的持續性會話，讓 MQTT 訊息代理程式在中斷連線時保留用戶端會話的相關信息，以確保通訊的可靠性。 此資訊包括客戶端的訂用帳戶，以及遺漏/未認可 QoS 1 訊息。 用戶端可以透過將 CONNECT 封包中的 cleanSession 旗標設定為 false 來設定持續性會話。

清除啟動和會話到期

MQTT v5 引進了全新開始和會話到期功能，以改進處理會話持續性的 MQTT v3.1.1。 Clean Start 是一項功能，可讓用戶端使用 MQTT 訊息代理程序啟動新的工作階段，捨棄任何先前的工作階段資料。 會話到期可讓用戶端在非使用中會話視為已過期並自動移除時通知 MQTT 訊息代理程式。 在 CONNECT 封包中，用戶端可以基於安全性考慮，將 [清除開始] 旗標設定為 true 和/或短會話到期間隔，或避免在上一個會話期間可能發生的任何潛在數據衝突。 用戶端也可以將全新開始設定為 false 和/或長時間會話到期間隔，以確保持續性會話的可靠性與效率。

會話到期間隔設定上限

您可以設定連線到事件方格命名空間的所有用戶端允許的最大工作階段到期間隔。 針對 MQTT v3.1.1 用戶端，設定的限制會套用為所有持續性會話的預設會話到期間隔。 針對 MQTT v5 用戶端，設定的限制會套用為 CONNECT 封包中會話到期間隔屬性的最大值;任何超過限制的值都已調整。 這個命名空間屬性的預設值為1小時，最多可以擴充8小時。 使用下列步驟，在 Azure 入口網站 中設定會話到期間隔上限：

  • 移至 Azure 入口網站 中的命名空間。
  • 在 [組態] 下，將 [最大會話到期間隔] 的值變更為所需的限制。
  • 選取套用。

最大會話到期間隔設定的螢幕快照。

會話溢位

MQTT 訊息代理程式會針對未連線的每個作用中 MQTT 會話維護訊息佇列，直到用戶端再次與 MQTT 訊息代理程式連線，以接收佇列中的訊息。 如果用戶端未連線到接收佇列 QOS1 訊息，會話佇列就會開始累積訊息，直到達到其限制為止：100 則訊息或 1 MB。 一旦佇列在會話的存續期間達到其限制，會話就會終止。

最後遺囑和約 （LWT） 訊息 （預覽）

最後遺囑和約 （LWT） 會以突然中斷其他 MQTT 用戶端的中斷通知 MQTT 用戶端。 您可以使用 LWT 來確保 MQTT 用戶端在非預期的中斷連線期間可預測且可靠的通訊流程，這對於即時通訊、系統可靠性和協調動作很重要的案例相當重要。 共同作業以執行複雜工作的用戶端可以藉由調整其行為、轉散發工作，或接管特定責任來維持系統的效能和穩定性，以回應彼此的 LWT 訊息。 若要使用 LWT，用戶端可以指定will訊息、將主題，以及連線期間 CONNECT 封包中其餘的will屬性。 當用戶端突然中斷連線時，MQTT 訊息代理程式會將 訊息發佈給訂閱will主題的所有用戶端。

使用者屬性

MQTT 訊息代理程式支援 MQTT v5 PUBLISH 封包上的使用者屬性，可讓您在訊息標頭中新增自定義索引鍵/值組，以提供更多訊息內容。 用戶屬性的使用案例是多用途的。 您可以使用這項功能來包含訊息的用途或來源，讓接收者可以處理訊息，而不需要剖析承載、節省計算資源。 例如，具有用戶屬性，指出其用途為「警告」的訊息，可能會觸發與具有「資訊」目的不同的處理邏輯。

要求-回應模式

MQTTv5 引進 MQTT PUBLISH 封包標頭中的欄位，可在要求-回應模式中提供回應訊息的內容。 這些欄位包括回應主題，以及回應者可在回應中使用且不需要先前設定的相互關聯標識符。 回應資訊可為命令和控制案例中使用的標準要求-回應模式啟用更有效率的通訊。

要求-回應模式範例的圖表。

訊息到期間隔：

在 MQTT v5 中，訊息到期間隔可讓訊息具有可設定的壽命。 訊息到期間隔定義為訊息發佈至 MQTT 訊息代理程式的時間與 MQTT 訊息代理程式捨棄未傳遞訊息的時間之間的時間間隔。 這項功能適用於只有特定時間有效訊息的案例，例如區分時間的命令、實時數據串流或安全性警示。 透過設定訊息到期間隔，MQTT 訊息代理程式可以自動移除過期的訊息，確保只有相關信息可供訂閱者使用。 如果訊息的到期間隔設定為零，表示訊息不應該過期。

主題別名：

在 MQTT v5 中，主題別名可讓用戶端使用較短的別名來取代已發佈訊息中的完整主題名稱。 MQTT 訊息代理程式會維護主題別名與實際主題名稱之間的對應。 這項功能可以節省網路頻寬，並減少訊息標頭的大小，特別是針對具有長名稱的主題。 在多個訊息中重複發佈相同主題的案例中，例如在感測器網路中，這非常有用。 MQTT 訊息代理程式最多支援10個主題別名。 用戶端可以使用 PUBLISH 封包中的 [主題別名] 字段，將完整主題名稱取代為對應的別名。

主題別名範例的圖表。

流程控制

在 MQTT v5 中，流量控制是指管理用戶端可處理的訊息速率和大小的機制。 您可以在 CONNECT 封包中設定 [封包大小上限] 和 [接收上限] 參數，以設定流程控制。 Receive Maximum 參數可讓用戶端將訊息代理程式所傳送的訊息數目限制為客戶端能夠處理的訊息數目。 [封包大小上限] 參數會定義用戶端可接收的封包大小上限。 MQTT 訊息代理程式有 512 KiB 的訊息大小限制。 這項功能可確保受限裝置的通訊可靠性和穩定性，且處理速度或儲存功能有限。

負面通知和伺服器起始的中斷連線封包

針對 MQTT v5，MQTT 訊息代理程式能夠傳送負通知（NACK）和伺服器起始的中斷連線封包，以提供用戶端訊息傳遞或連線失敗的詳細資訊。 這些功能可協助客戶端診斷失敗背後的原因，並採取適當的緩和動作。 MQTT 訊息代理程式會使用 MQTT v5 規格中 定義的原因代碼。

目前的限制

MQTT 訊息代理程式會在未來新增更多 MQTT v5 和 MQTT v3.1.1 功能，以配合 MQTT 規格的更多功能。 下列清單詳細說明 MQTT 訊息代理程式和 MQTT 規格所支援之功能之間的目前差異：

MQTTv5 目前的限制

MQTT v5 目前與 MQTT v5 規格 不同，方式如下：

  • 尚不支援共用訂閱。
  • 尚不支援保留旗標。
  • 目前不支援延遲間隔。
  • 最大 QoS 為 1。
  • 封包大小上限為 512 KiB
  • 不保證訊息順序。
  • 不支援訂用帳戶標識碼。
  • 尚未支援指派的用戶端識別碼。
  • 主題別名最大值為 10。 伺服器目前不會為傳出訊息指派任何主題別名。 用戶端可以在設定限制內指派和使用主題別名。
  • 即使 CONNECT 要求包含要求響應資訊屬性，CONNACK 也不會傳回回應資訊屬性。
  • 服務不會使用 CONNECT、SUBSCRIBE、DISCONNECT、PUBACK、AUTH 封包上的用戶屬性，因此不受支援。 如果其中任何一個要求包含用戶屬性，要求就會失敗。
  • 如果伺服器從具有非成功回應碼的用戶端收到 PUBACK，則會終止連線。
  • 保持運作上限為 1,160 秒。

MQTTv3.1.1 目前的限制

MQTT v5 目前與 MQTT v3.1.1 規格 不同，方式如下：

  • 尚不支援 QoS2 和保留旗標。 具有保留旗標或 QoS2 的發行要求會失敗並關閉連線。
  • 不保證訊息順序。
  • 保持運作上限為 1,160 秒。

程式代碼範例：

此存放庫 包含 C#、C 和 Python 程式代碼範例，示範如何傳送遙測、傳送命令和廣播警示。 透過範例建立的憑證適合用於測試，但不適合生產環境。

後續步驟：

深入瞭解 MQTT：

深入瞭解 MQTT 訊息代理程式：