MQTT 傳訊

MQTT 是一種開放式標準，由 OASIS 標準組織管理，並由 ISO 所辨識，而且是裝置及應用程式用來與 IoT 工具進行通訊的主要通訊協定。

附註: 在 8.10 和 8.11中，您可以將 HTTP 傳訊用於低量實務範例。 對於每秒大於 1000 則訊息的訊息速率，請勿使用 HTTP 傳訊。 HTTP 傳訊需要對所發佈的每一則訊息進行 TLS 信號交換及鑑別，且鑑別需要對裝置鑑別記號進行資料庫查閱。 這些需求會對鑑別服務及 IoT 工具資料庫造成壓力。 MQTT 傳訊吸收率比 HTTP 傳訊快 2-3 個數量級。

MQTT 是一種發佈及訂閱傳訊傳輸通訊協定，專門設計用來在感應器與行動式裝置之間有效率地交換近即時資料。 如需相關資訊，請參閱 OASIS 訊息佇列作業遙測傳輸。

MQTT 透過 TCP/IP 執行，雖然可以直接將程式碼編寫為 TCP/IP，您也可以選擇使用程式庫來為您處理 MQTT 通訊協定的詳細資料。 有很多種 MQTT 用戶端程式庫可供您使用。 IBM 協助開發及支援數種用戶端程式庫，包括可從下列網站取得的用戶端程式庫：

標準和需求

如需 IoT 工具所支援 MQTT 版本的相關資訊，請參閱 標準與需求。

限制

如需連接至 IoT 工具時適用於 MQTT 用戶端之限制的相關資訊，請參閱 限制。

埠安全

裝置、閘道及應用程式使用 MQTT 或 HTTP 通訊協定連接至 IoT 工具。

連線類型 通訊協定 埠號
安全 (TLS) MQTT 及 HTTPS 443

MQTT 是透過 TCP 及 WebSockets 所支援。 MQTT 用戶端會使用適當的認證來連接，例如適用於裝置的裝置鑑別記號，以及適用於應用程式的 API 金鑰和記號。 透過安全埠傳送時，一律加密 TLS 認證。

當您在埠 443 上使用安全 MQTT 傳訊時，較新的用戶端程式庫會自動信任 IoT 工具所提供的預設憑證。 如果您的用戶端環境沒有這種情況，您可以從 messaging.pem下載並使用完整憑證鏈。 如果您上傳自訂憑證，則可能需要確保將適當的信任鏈新增至用戶端環境。

TLS

您必須在應用程式中啟用 TLS ，以避免不安全地傳送資料。

如需相關資訊，請參閱下列主題：

公平使用原則

在 8.10 和 8.11中，公平使用節流控制會暫停超出連線限制之連線上的讀取作業。 IoT 工具的節流控制限制是根據裝置，並以裝置類別 (例如裝置、閘道或應用程式) 為基礎。 這些限制是用來防止來自裝置的「阻斷服務 (DoS)」攻擊。 節流控制限制不會隨著 IoT 工具部署大小而調整。 節流控制不適用於傳送一些訊息的短期連線，例如 HTTP 傳訊用戶端的連線。 如需相關資訊，請參閱 配額。

若要將訊息速率最大化，請確保 IoT 工具資料吸收應用程式會將負載分散到許多 MQTT 裝置或應用程式。 IoT 工具 MQTT 服務設計為管理與每一個裝置以低速率發佈的許多裝置連線。

MQTT 用戶端鑑別

每一個 MQTT 用戶端都需要唯一的用戶端 ID。 如果您嘗試使用已連接的用戶端 ID 來連接組織中的用戶端，則第一個連線會中斷。

直接連接至 IoT 工具的裝置及閘道會在儀表板上顯示狀態圖示，以指出它們已連接。 透過閘道間接連接的裝置會顯示為中斷連線，因為儀表板無法感知透過閘道連接的裝置。

傳訊服務品質 (QoS) 層次

MQTT 通訊協定提供三種服務品質等級，可在用戶端與伺服器之間遞送訊息。 發佈 MQTT 訊息時指定的傳訊 QoS 會直接影響傳訊速率。 下表說明 QoS 層次:
表 1. QoS 水準
層次 說明
最多一次 (QoS 0)

服務品質等級 0 (QoS 0) 是最快的傳送模式。 訊息最多遞送一次，或是根本不遞送。 透過網路遞送不會進行確認，而且不會儲存訊息。 如果用戶端中斷連線，或是伺服器失敗，訊息可能會遺失。

MQTT 通訊協定不需要伺服器將服務品質等級 0 的發佈轉遞至用戶端。 如果用戶端在伺服器收到發佈項目時斷線，根據伺服器的實作，可能會捨棄該發佈項目。

以間隔傳送近即時資料時，請使用服務品質等級 0。 如果是單一訊息遺失，則不重要，因為稍後就會傳送另一個包含較新資料的訊息。 在此情況下，使用較高服務品質的額外成本，並不會產生任何實質的好處。
至少一次 (QoS 1)

使用服務品質等級 1 (QoS 1) ，訊息一律至少遞送一次。 如果在傳送者收到確認通知之前，發生失敗的狀況，可以多次遞送訊息。 訊息必須儲存在傳送者本端，直到傳送者收到該訊息是由接收端發佈的確認通知。 訊息會儲存起來，以防必須重新傳送訊息。 將訊息可靠遞送至 MQTT 分配管理系統，並不表示 Maximo® Monitor 將處理該訊息。
正好一次 (QoS 2)

服務品質等級 2 (QoS 2) 提供最可靠的訊息遞送，但也具有最慢的傳送模式。 訊息一律遞送正好一次，而且也必須儲存在傳送者本端，直到傳送者收到該訊息已由接收端發佈的確認通知。 訊息會儲存起來，以防必須重新傳送訊息。 若使用服務品質水準 2，所使用的信號交換和確認通知順序會比水準 1 更準確，以確保訊息不重複。 將訊息可靠遞送至 MQTT 分配管理系統並不表示 Maximo Monitor 將處理該訊息。

當您傳送指令時，如果您想要確認只會處理指定的指令，且只會處理一次，請使用服務品質等級 2。 在此範例中，層次 2 的額外開銷可能比其他層次更有利。
在使用 QoS 1 和 QoS 2 之前，請檢閱下列效能考量:
  • 磁碟 I/O 效能對 QoS 1 和 QoS 2 而言很重要，因為這些層次需要 IoT 工具傳訊元件中的磁碟持續性。
  • MQTT 規格提供用戶端與伺服器之間的通訊協定層次流程控制協議。 用戶端及伺服器會協議階段作業上容許的未確認訊息數。 如果用戶端沒有任何可用的訊息 ID ，用戶端必須暫停發佈，直到有可用的 ID 為止。 當收到訊息確認通知 (ACK) 時，可以使用訊息 ID。 如需相關資訊，請參閱 OASIS 標準 MQTT 規格。

資料吸收率

若要達到較高的資料吸收速率，請使用 MQTT 傳訊通訊協定，並在發佈訊息時保持裝置連線開啟。

下列 MQTT 傳訊型樣會保持裝置連線開啟，直到發佈所有訊息為止:
MQTT CONNECT
MQTT PUBLISH
MQTT PUBLISH
MQTT PUBLISH
...
下列 MQTT 傳訊型樣會在發佈訊息之間導致裝置斷線。 請勿使用這種類型的型樣。 使用此類型的型樣會導致較低的資料吸收率。
MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
...

下列因素會影響資料吸收率:

  • 傳訊通訊協定。 MQTT 是大量通訊協定。 HTTP 是低容量通訊協定。
  • 傳訊型樣。 若要提高資料吸收率，請不要在發佈每一個訊息之後關閉 MQTT 階段作業。 保持連線開啟。
  • 裝置數目。 若要改善資料吸收及訊息速率，請透過更多連線來配送負載。
  • 裝置類別。 公平使用配額 基於裝置類別。
  • QoS。 高層次傳訊可靠性需要更高的成本。