選擇裝置通訊協定
IoT 中樞可讓裝置使用下列通訊協定進行裝置端通訊：
- MQTT
- 透過 WebSocket 的 MQTT
- 進階訊息佇列通訊協定 (AMQP)
- 透過 WebSocket 的 AMQP
- HTTPS
注意
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 中樞通訊。