An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
Hello @Dhruvesh Sheladiya ,
Welcome to Microsoft Q&A .Thank you for reaching out to us.
Azure IoT Hub supports multiple device-side protocols for device-to-cloud (D2C) and cloud-to-device (C2D) communication. Selecting the appropriate protocol depends on device capability, network constraints, scalability needs, and required communication patterns.
- Supported Device Protocols
- Azure IoT Hub supports MQTT (including WebSockets), AMQP (including WebSockets), and HTTPS for device communication
- All communication is secured using TLS (minimum TLS 1.2), with authentication provided through SAS tokens or X.509 certificates. It is also important to note that IoT Hub has a bounded MQTT implementation and does not act as a full MQTT broker.
- Protocol Behavior and Selection
- MQTT is generally the preferred default for most IoT devices. It is lightweight, efficient, and maintains a persistent connection per device, enabling low-overhead telemetry and real-time cloud-to-device communication through server push. However, each device requires its own connection, as MQTT does not support multiplexing
- AMQP is better suited for enterprise and gateway-based scenarios. Like MQTT, it uses persistent connections and supports push-based communication, but its key advantage is the ability to multiplex multiple device identities over a single connection, making it highly efficient when many downstream devices communicate via a gateway.
- HTTPS follows a stateless request-response model and does not support server push. Instead, devices must poll IoT Hub to receive cloud-to-device messages. This introduces additional latency and overhead, and to avoid throttling, polling frequency should typically be limited to approximately every 25 minutes or more.
- Latency, Scalability, and Communication Behavior
- MQTT and AMQP support push-based cloud-to-device communication, allowing IoT Hub to deliver messages immediately, which results in low latency and near real-time interaction. In contrast, HTTPS relies on polling, meaning message delivery depends on the device’s polling interval and inherently introduces delay.
- From a scalability perspective, MQTT works efficiently for large fleets of independently connected devices, offering simplicity and low overhead. AMQP is more suitable for gateway architectures where multiple devices are aggregated through fewer connections, improving connection efficiency. HTTPS, due to repeated polling and higher per-request overhead, is less efficient for high-scale or high-frequency communication scenarios.
- Performance and Efficiency Considerations
- MQTT and AMQP use compact binary messaging, which reduces bandwidth consumption and supports efficient, high-frequency telemetry. HTTPS, being stateless, introduces more overhead due to repeated request handling and is therefore less efficient for continuous communication.
- Cost is not directly determined by the protocol itself but is influenced by message volume and usage patterns, with inefficient communication (such as excessive polling) potentially increasing operational overhead.
- Firewall and Network Constraints
- In restricted network environments, the protocol choice is often driven by what outbound traffic is allowed.
- If only port 443 is open, MQTT or AMQP over WebSockets are preferred
- HTTPS should be used only when WebSockets are not supported
- This approach ensures compatibility with enterprise firewalls while still maintaining efficient communication where possible.
Best Practice Recommendations
- In most deployments, MQTT is the default choice due to its lightweight nature and support for real-time communication. AMQP is preferred for gateway or enterprise scenarios where connection multiplexing and structured messaging are required. HTTPS is typically reserved for devices with limited capability or environments where other protocols cannot be used.
- Devices with constrained resources benefit most from MQTT, while gateway or edge systems managing multiple downstream devices benefit from AMQP’s ability to efficiently handle multiple identities over fewer connections
Please check if the troubleshooting steps help-
- When diagnosing connectivity issues, it is important to verify that required outbound ports are open and that TLS 1.2 or higher is enabled. Authentication mechanisms such as SAS tokens or X.509 certificates should also be validated.
- For delayed cloud-to-device communication, check whether HTTPS polling is being used. Switching to MQTT or AMQP can significantly improve responsiveness due to push-based delivery.
- In restricted environments, using WebSocket-based communication on port 443 usually resolves connectivity issues, provided that proxies and firewalls support long-lived connections. Performance issues can often be mitigated by avoiding frequent reconnect attempts and ensuring that SDK retry and keep-alive configurations are correctly applied.
The following references might be helpful , please check them out
- Azure IoT Hub communication protocols and ports | Microsoft Learn
- Use MQTT to communicate with Azure IoT Hub - Azure IoT Hub | Microsoft Learn
- Understand Azure IoT Hub AMQP support | Microsoft Learn
- Azure IoT Hub cloud-to-device options | Microsoft Learn
- Azure IoT Hub device-to-cloud options | Microsoft Learn
Please let us know if the response was helpful
Thank you