共用方式為


選擇裝置通訊協定

IoT 中樞可讓裝置使用下列通訊協定進行裝置端通訊:

注意

IoT 中樞對於 MQTT 的功能支援有限。 如果您的解決方案需要 MQTT v3.1.1 或 v5 支援,建議使用 Azure 事件方格中的 MQTT 支援。 如需詳細資訊,請參閱 比較 IoT 中樞和事件方格中的 MQTT 支援

如需這些通訊協定如何支援特定 IoT 中樞功能的資訊,請參閱裝置到雲端的通訊指引雲端到裝置的通訊指引

下表提供您所選擇通訊協定的高階建議:

通訊協定 應選擇此通訊協定的情況
MQTT
透過 WebSocket 的 MQTT
在不需要連線到多個裝置的所有裝置上使用,每個裝置都會透過相同的 TLS 連線,使用自己的個別裝置認證。
AMQP
透過 WebSocket 的 AMQP
在現場和雲端閘道上使用,利用跨裝置的連線多工。
HTTPS 用於不支援其他通訊協定的裝置。

當您針對裝置端通訊選擇通訊協定時,請考慮下列幾點:

  • 雲端到裝置的模式。 HTTPS 沒有可實作伺服器推送的有效方式。 因此,當您使用 HTTPS 時,裝置會輪詢IoT 中樞以了解是否有從雲端到裝置的訊息。 這種方法對裝置和 IoT 中樞皆效率不佳。 根據目前的 HTTPS 指導方針,每個裝置應該每隔 25 分鐘以上輪詢訊息一次。 發出更多 HTTPS 接收會導致「IoT 中樞」對要求進行節流。 MQTT 和 AMQP 支援接收雲端到裝置的訊息時的伺服器推送。 它們可立即將訊息從 IoT 中樞推送至裝置。 如果傳遞延遲是問題,MQTT 或 AMQP 是要使用的最佳通訊協定。 對於很少連線的裝置,HTTPS 也能運作。

  • 現場閘道器。 MQTT 和 HTTPS 僅支援每一 TLS 連線一個裝置身分識別 (裝置識別碼及認證)。 基於這個理由,這些通訊協定不支援在單一連線或 IoT 中樞上游連線集區之間,使用多個裝置身分識別來要求多任務訊息的現場閘道案例。 這類閘道可以使用每一連線支援多個裝置身分識別的通訊協定 (例如 AMQP) 來處理其上游流量。

  • 低資源裝置。 MQTT 和 HTTPS 程式庫的使用量比 AMQP 程式庫小。 因此,如果裝置的資源有限 (例如 RAM 小於 1 MB),這些通訊協定可能會是唯一可用的通訊協定實作。

  • 網路周遊。 標準 AMQP 通訊協定會使用連接埠 5671,而 MQTT 會在連接埠 8883 上接聽。 使用這些連接埠可能會導致對非 HTTPS 通訊協定關閉的網路發生問題。 在此案例中使用透過 WebSocket 的 MQTT、透過 WebSocket 的 AMQP 或 HTTPS。

  • 承載大小。 MQTT 和 AMQP 是二進位通訊協定,這會導致比 HTTPS 更精簡的承載。

警告

使用 HTTPS 時,每個裝置每隔 25 分鐘不應輪詢雲端到裝置訊息超過一次。 開發時如有需要,每個裝置可以更頻繁地進行輪詢。

重要

在使用 X.509 憑證授權單位 (CA) 驗證的裝置上,下列功能尚未正式推出,務必啟用預覽模式

  • HTTPS、透過 WebSocket 的 MQTT,以及透過 WebSocket 的 AMQP 通訊協定。
  • 檔案上傳 (所有通訊協定)。

這些功能已在使用 X.509 指紋驗證的裝置上正式推出。 若要深入了解使用 IoT 中樞的 X.509 驗證,請參閱支援的 X.509 憑證

連接埠號碼

裝置可以使用各種通訊協定與 Azure 中的 IoT 中樞通訊。 一般而言,通訊協定的選擇是由解決方案的特定需求所驅動。 下表列出必須為裝置開啟才能使用特定通訊協定的輸出連接埠:

通訊協定 Port
MQTT 8883
透過 WebSocket 的 MQTT 443
AMQP 5671
透過 WebSocket 的 AMQP 443
HTTPS 443

IoT 中樞的 IP 位址可能會變更,不另行通知。 若要了解如何減輕 IoT 中樞 IP 位址變更對 IoT 解決方案和裝置的影響,請參閱 IoT 中樞 IP 位址最佳做法 一節。

下一步

若要深入了解 IoT 中樞如何實作 MQTT 通訊協定,請參閱 使用 MQTT 通訊協定與 IoT 中樞通訊