MQTT vs CoAP: Lightweight IoT Messaging Protocols Compared

Traditional enterprise web protocols like HTTP/1.1 and HTTP/2 were engineered for high-bandwidth networks and powerful computing endpoints [1, 2]. Standard HTTP requests carry significant transport headers (often several hundred bytes per request), mandate heavy connection handshakes, and enforce a rigid client-initiated request/response model [2].

For battery-powered Internet of Things (IoT) sensors operating over lossy, low-bandwidth wireless links, standard HTTP is prohibitively inefficient [1, 2]. To solve this, the engineering community standardized two specialized, lightweight messaging protocols: Message Queuing Telemetry Transport (MQTT) and the Constrained Application Protocol (CoAP) [1, 2]. While both protocols minimize packet overhead, their underlying transport mechanisms and communication paradigms differ fundamentally [1, 2, 3]. In this technical guide, we evaluate MQTT vs CoAP, compare TCP vs UDP transport mechanics, and analyze Quality of Service delivery guarantees [1, 2, 3].

1. Architectural Paradigms: Pub/Sub vs RESTful Client/Server

The primary distinction between MQTT and CoAP lies in their fundamental communication architecture [1, 2]:

MQTT (Publish / Subscribe Broker Model):
[ Publisher: Sensor ] ---> PUBLISH "factory/temp" (24C) ---> [ Central MQTT Broker ]
                                                                     |
                               +-------------------------------------+---------------------------------+
                               |                                                                       |
                               v                                                                       v
                    [ Subscriber: Dashboard ]                                               [ Subscriber: Database ]

CoAP (RESTful Client / Server Request-Response):
[ Client: Controller ] ===== GET coap://sensor.local/temp =====> [ Server: Constrained Sensor Node ]
                       <==== 2.05 Content (Payload: 24C) =======

1. MQTT: The Publish/Subscribe Pattern (OASIS MQTT 5.0)

MQTT is a centralized, broker-centric messaging protocol [1]:

• Sensors (publishers) do not communicate directly with receiving applications (subscribers).
• Instead, publishers connect to a central MQTT Broker (such as Mosquitto or EMQX) and publish messages to hierarchical text topics (e.g., telemetry/building4/floor2/temperature) [1].
• Any number of independent client applications subscribe to topic filters. When a message is published, the broker fans out the message to all matched subscribers [1].
• Decoupling: Publishers and subscribers do not know each other's IP addresses, nor do they need to be online at the identical moment if persistent sessions are configured [1].

2. CoAP: REST for Constrained Devices (RFC 7252)

CoAP is a decentralized, client/server protocol that translates the familiar REST architectural model into a binary, lightweight format [2]:

• Constrained field sensors act as mini CoAP web servers hosting discrete URI resources (e.g., coap://192.168.1.50/sensors/light) [2].
• Clients interact using standard HTTP-like verbs: GET, POST, PUT, and DELETE [2].
• RFC 7641 (Observe Extension): Clients can register an Observe flag on a resource. When sensor state changes, the CoAP server pushes updated state notifications back to the observer, emulating publish/subscribe behavior over UDP [3].

2. Transport Layer Mechanics: TCP vs UDP

The most critical engineering trade-off between MQTT and CoAP resides at the transport layer [1, 2]:

MQTT Relies on TCP (Connection-Oriented)

• MQTT operates strictly over TCP (default port 1883, or port 8883 with TLS encryption) [1].
• Advantage: TCP handles packet retransmissions, in-order packet delivery, and connection state tracking automatically at the OS kernel level [1].
• Drawback: Maintaining persistent TCP connections requires periodic Keep-Alive "heartbeat" packets (PINGREQ / PINGRESP), draining batteries on devices that sleep for hours between readings [1].

CoAP Relies on UDP (Connectionless)

• CoAP operates strictly over UDP (default port 5683, or port 5684 with DTLS encryption) [2].
• Advantage: Stateless execution. A battery-powered environmental sensor can wake from deep sleep, transmit a single 4-byte UDP datagram containing sensor data, and return to deep sleep in under 20 milliseconds, preserving battery life for years [2].
• Drawback: Because UDP provides zero native reliability, CoAP implements its own lightweight reliability layer directly within the application header using Confirmable (CON) and Non-Confirmable (NON) message flags [2].

3. Reliability and Delivery Guarantees: Quality of Service (QoS)

Both protocols provide mechanisms to guarantee that critical telemetry or commands reach their destination [1, 2]:

MQTT Quality of Service Levels (QoS 0, 1, 2)

MQTT provides three distinct delivery guarantees standardized in OASIS MQTT 5.0 [1]:

• QoS 0 (At most once - Fire & Forget): Messages are delivered according to standard best-effort TCP delivery with no acknowledgment at the application layer. Messages may be lost if the broker disconnects [1].
• QoS 1 (At least once): The receiver must respond with a PUBACK packet. If no acknowledgment arrives within a timeout window, the sender retransmits. Messages are guaranteed to arrive, but duplicate packets may occur [1].
• QoS 2 (Exactly once): A four-step cryptographic handshake (PUBLISH $\rightarrow$ PUBREC $\rightarrow$ PUBREL $\rightarrow$ PUBCOMP) guarantees that messages arrive exactly once with zero duplicates. Required for billing, financial metering, or irreversible actuation commands [1].

CoAP Message Reliability (RFC 7252)

CoAP implements lightweight binary reliability [2]:

• Non-Confirmable (NON): Sent without acknowledgment (equivalent to QoS 0) [2].
• Confirmable (CON): The receiver must acknowledge receipt with an Acknowledgment (ACK) packet carrying the matching 16-bit Message ID. If no ACK arrives, the sender retransmits using exponential backoff (equivalent to QoS 1) [2].

Technical Protocol Comparison Matrix

Practical Architectural Selection Criteria

To select the optimal protocol for an enterprise IoT deployment:

Choose MQTT When:

• Telemetry data must be distributed simultaneously to multiple heterogeneous consumers (e.g., a central database, a real-time web dashboard, and a mobile app) [1].
• Endpoints have access to mains electrical power or rechargeable battery banks that tolerate persistent TCP connections [1].
• Applications require strictly enforced QoS 2 (Exactly Once) delivery semantics [1].

Choose CoAP When:

• Field sensors operate on tiny coin-cell batteries or energy harvesting, requiring devices to sleep 99% of the time [2].
• The network infrastructure utilizes lossy low-power wide-area links (LPWAN, LoRaWAN, 6LoWPAN) where TCP connection overhead causes excessive packet drops [2].
• The application architecture requires direct RESTful query integration without operating an intermediary message broker [2].

For enterprise IoT software architecture, secure messaging pipelines, and systems integration, explore our capabilities on our Web & Software Development page.

Key Takeaways

• MQTT is a broker-centric publish/subscribe protocol operating over connection-oriented TCP.
• CoAP is a lightweight, binary RESTful protocol operating over connectionless UDP.
• MQTT provides QoS 0, 1, and 2 delivery guarantees; CoAP uses Confirmable (CON) message acknowledgments.
• Use MQTT for multi-subscriber enterprise streaming; use CoAP for deep-sleep, battery-constrained field sensors.

Need help with this? Contact us.

Sources

[1] OASIS Open, "MQTT Version 5.0 OASIS Standard", 2019. URL: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html (The authoritative international standard specification defining the MQTT publish/subscribe messaging protocol).

[2] IETF, "RFC 7252: The Constrained Application Protocol (CoAP)", 2014. URL: https://www.rfc-editor.org/rfc/rfc7252.html (Standards-track specification for the RESTful machine-to-machine Constrained Application Protocol).

[3] IETF, "RFC 7641: Observing Resources in the Constrained Application Protocol (CoAP)", 2015. URL: https://www.rfc-editor.org/rfc/rfc7641.html (Standards-track RFC defining asynchronous state change observation and push telemetry in CoAP).

Last reviewed: October 2026