Q20Internet of Things

Different IoT scenarios require different application layer protocols, since standard HTTP's verbose headers and connection overhead are poorly suited to battery-powered devices with kilobytes of RAM. Four protocols dominate the IoT landscape, each optimized for a different trade-off.

MQTT (Message Queuing Telemetry Transport)

A Publish/Subscribe model running over TCP, with all clients connecting through a central broker. Extremely lightweight, with a minimal 2-byte fixed header, and supports three Quality of Service levels for reliability. Ideal for constrained devices and unreliable networks, such as remote sensor logging or smart home telemetry, and is the most widely adopted IoT protocol today.

CoAP (Constrained Application Protocol)

A Request/Response model running over UDP rather than TCP, deliberately designed to be the 'HTTP of the IoT world', mirroring RESTful methods (GET, POST, PUT, DELETE) but in a compact binary format. Suitable for extremely constrained nodes where even a TCP handshake is too costly, such as a battery sensor that wakes briefly once an hour to report a reading.

XMPP (Extensible Messaging and Presence Protocol)

Based on XML and originally designed for instant messaging (it underlies Jabber). Excellent for real-time human-to-machine communication and 'presence' detection, such as knowing instantly when a smart TV comes online, but its XML parsing overhead makes it heavier than MQTT or CoAP, restricting its use to less constrained devices.

AMQP (Advanced Message Queuing Protocol)

A robust, secure messaging protocol built for enterprise-level queuing and routing, offering strong delivery guarantees, transactions, and interoperability across different messaging vendors. Common in financial and industrial back-end systems that need guaranteed message delivery, but its complexity and resource requirements make it impractical to run directly on constrained edge devices; it typically operates between gateways and cloud services rather than on the sensor itself.

In practice, a well-designed IoT system often uses more than one: MQTT or CoAP at the constrained edge to talk to sensors, and AMQP or XMPP further up the stack for enterprise integration or human-facing messaging, selecting each protocol based on the resource constraints and reliability requirements at that specific point in the architecture.

• Transport: MQTT and AMQP run over TCP; CoAP runs over UDP; XMPP typically runs over TCP as well.
• Model: MQTT is Publish/Subscribe; CoAP is Request/Response (RESTful); XMPP uses an extensible messaging model with presence; AMQP is a full queuing and routing protocol.
• Overhead: MQTT and CoAP are extremely lightweight; XMPP is heavier due to XML; AMQP is the heaviest due to its enterprise feature set.
• Typical Deployment Point: MQTT and CoAP run directly on constrained sensors; XMPP suits consumer devices with more resources; AMQP typically runs between gateways, brokers, and cloud services.

Understanding these trade-offs matters in practice: choosing AMQP for a battery-powered soil sensor would drain its battery in days rather than years, while choosing CoAP for a high-value financial transaction queue would sacrifice the delivery guarantees the application actually needs. Matching the protocol to the specific constraints of each part of the system, rather than picking a single protocol for the entire architecture, is what allows large IoT deployments to remain both efficient at the edge and reliable at the core.