選擇裝置通訊協定
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、透過 WebSocket 的 AMQP 或 HTTPS 的 MQTT。
承載大小。 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 中樞通訊。