IoT 中樞可讓裝置使用下列通訊協定進行裝置端通訊：
- MQTT
- 透過 WebSocket 的 MQTT
- 進階訊息佇列通訊協定 (AMQP)
- 透過 WebSocket 的 AMQP
- HTTPS
注意
IoT Hub 對 MQTT 提供有限的功能支援。 如果您的解決方案需要 MQTT v3.1.1 或 v5 支援，請參閱 Azure Event Grid 中 MQTT 代理功能概述。 欲了解更多資訊，請參閱《使用 MQTT 協定與物聯網樞紐溝通》中「物聯網樞紐中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 程式庫小。 因此，若裝置提供的資源有限（例如少於 1 MB RAM），這些協定可能是唯一可用的協定實作。
網路周遊。 標準 AMQP 通訊協定會使用連接埠 5671，而 MQTT 會在連接埠 8883 上接聽。 使用這些連接埠可能會導致對非 HTTPS 通訊協定關閉的網路發生問題。 在此案例中使用透過 WebSocket 的 MQTT、透過 WebSocket 的 AMQP 或 HTTPS。
承載大小。 MQTT 和 AMQP 是二進位通訊協定，這會導致比 HTTPS 更精簡的承載。
警告
當裝置使用 HTTPS 協定時，每台裝置不應超過每 25 分鐘輪詢一次雲端至裝置訊息。 開發時如有需要，每個裝置可以更頻繁地進行輪詢。
連接埠號碼
裝置可以使用各種通訊協定與 Azure 中的 IoT 中樞通訊。 通常，解決方案的具體需求決定了協議的選擇。 下表列出必須為裝置開啟才能使用特定通訊協定的輸出連接埠：
| 通訊協定 | Port |
|---|---|
| MQTT | 8883 |
| 透過 WebSocket 的 MQTT | 443 |
| AMQP | 5671 |
| 透過 WebSocket 的 AMQP | 443 |
| HTTPS | 443 |
IoT 中樞的 IP 位址可能會變更，不另行通知。 若要了解如何減輕 IoT 中樞 IP 位址變更對 IoT 解決方案和裝置的影響，請參閱 IoT 中樞 IP 位址 的 最佳做法 一節。
下一步
欲了解更多關於 IoT Hub 如何實作 MQTT 協定的資訊，請參閱 使用 MQTT 協定與物聯網樞紐通訊。