4 CoAP and MQTT: Brokers and Selection Evidence

CoAP and MQTT are often compared byte for byte, but their real difference is architectural. MQTT is broker-mediated publish and subscribe over a persistent TCP connection: clients connect to a broker, publish to topics, and subscribe to receive pushes. CoAP is a RESTful request and response over connectionless UDP, with an Observe option that adds a lightweight push. One keeps a standing connection to an intermediary; the other exchanges independent datagrams end to end.

That distinction drives everything else. TCP gives MQTT ordered, reliable byte delivery but requires a connection handshake and keepalive traffic to maintain. UDP lets CoAP send a single request as a single datagram with no connection to set up or hold open, at the cost of handling reliability per message when it needs it. Neither is universally better; they fit different traffic patterns.

For a smart-parking sensor that wakes once every ten minutes, measures occupancy, and reports through a nearby gateway, CoAP can send one confirmable message and let the radio sleep again. The gateway can expose a resource such as `/spaces/17/occupancy`, return a response code, and retry only that observation if no acknowledgment arrives. For a building platform that streams temperature, humidity, and alarm topics to a dashboard, rules engine, and maintenance app, MQTT's broker gives each consumer its own subscription without making the sensor know every destination.

The decision is therefore a boundary decision. CoAP keeps the endpoint relationship direct: the client asks a resource, the server answers, and any fan-out must be built elsewhere. MQTT centralizes fan-out: publishers do not know subscribers, but the broker becomes infrastructure that must be operated, secured, and monitored. A gateway may use both when constrained field devices speak CoAP locally and the site gateway republishes normalized events to MQTT for cloud consumers.

Where They Differ

Overview Knowledge Check

For a constrained, infrequent reporter, the deciding cost is often not the payload but the connection. MQTT pays a TCP handshake to open a connection and keepalive traffic to hold it; CoAP pays neither, sending each request as an independent datagram.

Worked Example: A Sensor Reporting Every 5 Minutes

The device sends one small reading every 300 s.

• CoAP: each report is one confirmable request datagram plus one acknowledgment datagram - about one round trip, no connection to set up or keep. Between reports the radio can be fully off.
• MQTT, reconnecting each time: every report first pays a TCP three-way handshake, then an MQTT CONNECT/CONNACK, and a TLS handshake if secured - several round trips of setup before the one-message payload.
• MQTT, persistent connection: avoids re-handshaking but must send keepalive pings to hold the connection. With a 60 s keepalive, the device wakes roughly five times between reports just to say "still here," doing no useful work.

For this infrequent, battery-powered pattern CoAP avoids both the per-report handshake and the keepalive tax, so it is usually the lighter choice. If instead the device needed a broker to push commands down to it at any moment, MQTT's standing connection would be the feature, not the cost.

Make the estimate explicit before choosing. A CoAP confirmable exchange on IPv4 might carry a 4-byte CoAP header, 8-byte UDP header, 20-byte IPv4 header, and the link-layer frame. An MQTT report over a cold connection pays TCP SYN/SYN-ACK/ACK, TLS setup if enabled, MQTT CONNECT/CONNACK, PUBLISH, and DISCONNECT unless it holds the socket open. A persistent MQTT client avoids repeated setup but then the keepalive interval becomes part of the battery budget. For a five-minute report interval, a 60-second keepalive can create several radio wakes between useful payloads.

The practical worksheet should record report interval, payload size, expected packet loss, security handshake choice, broker requirement, NAT direction, and whether downlink commands are time-critical. If the device only reports and can tolerate direct request/response, CoAP usually wins. If the device needs asynchronous command delivery, retained state, or several subscribers, MQTT may justify the connection cost.

Overhead Comparison Ledger

Practitioner Knowledge Check

The reliability models differ in a way that decides which protocol fits. MQTT's delivery behavior runs through the broker: with a higher QoS and a persistent session, the broker stores messages and delivers them to a subscriber that was offline, and retained messages give a late joiner the last known value. That store-and-forward behavior is exactly what a device behind a network address translator needs, since it initiates the connection outward and the broker pushes down to it. CoAP has no broker in the middle. A confirmable message is retransmitted with backoff until the far endpoint acknowledges, but if that endpoint is offline there is no intermediary holding the data - reliability is end to end, with no built-in offline queue.

Transport choice adds a second effect on lossy links. TCP delivers bytes in order, so a single lost segment blocks everything behind it until it is retransmitted - head-of-line blocking that can stall an MQTT stream on a flaky radio. CoAP's independent UDP datagrams have no such coupling: losing one message does not delay the others, which suits high-loss networks. The honest conclusion is that there is no universal winner. Favor MQTT for push to many subscribers, offline delivery, and NAT traversal; favor CoAP for infrequent constrained request/response, lossy links, and designs with no broker to run. Match the protocol to the traffic pattern rather than to a benchmark of header bytes.

Under the hood, the broker changes failure ownership. With MQTT persistent sessions, the broker must track client id, session expiry, subscriptions, queued QoS 1 or QoS 2 messages, retained values, and Last Will state. That helps a sleeping or disconnected client resume, but it also means broker storage, access control, topic hygiene, and expiry policy are part of the protocol decision. A poorly chosen session expiry can either drop needed commands too early or retain stale commands that should no longer run.

CoAP moves that responsibility to the endpoints. Message IDs, tokens, ACK timeouts, retransmission counters, and Observe sequence numbers tell a client whether a specific exchange completed. There is no central place to queue work for an offline device, so the application must decide whether to retry later, store the command elsewhere, or mark the endpoint unavailable. That makes CoAP simpler for local constrained exchanges and less suitable for cloud-to-device command fan-out when devices sleep behind NAT.

Model Differences That Decide The Choice

Under-the-Hood Knowledge Check

Use this checkpoint to connect transport mechanics to delivery ownership. The scenario combines an offline device with network address translation, so test the complete path: who retains the command while the device is absent, how the device re-establishes reachability, and which component resumes delivery. Begin at disconnection. An MQTT persistent session can leave the broker holding eligible queued messages for the returning client, subject to the chosen QoS and session-expiry policy. The device later opens an outbound TCP connection, re-establishes its MQTT session, and receives work through that broker-managed path. A CoAP confirmable exchange solves a different problem: it retransmits toward a reachable endpoint and matches the resulting acknowledgement, but it does not create an intermediary that stores a command throughout an arbitrary offline interval. NAT reinforces the distinction because an outbound client connection is normally easier to maintain than unsolicited delivery to a constrained server behind the boundary. A correct choice must therefore explain both persistence and connection direction. Comparing UDP and TCP header size alone cannot resolve the operational requirement, and neither protocol removes the need to reject obsolete or unsafe commands after a long disconnection.