Is MQTT TCP or UDP? The MQTT Transport Layer Explained

Is MQTT TCP or UDP? MQTT runs over TCP: either directly, wrapped in TLS, or carried inside a WebSocket connection, which itself runs over TCP. This article explains why MQTT depends on TCP's guarantees, where UDP-based variants such as MQTT-SN and experimental MQTT over QUIC fit, and exactly which ports to open in your firewall for a cloud broker.

Is MQTT TCP or UDP? The Short Answer

The MQTT 3.1.1 and 5.0 specifications require an underlying transport that delivers an ordered, lossless, bidirectional byte stream. TCP/IP provides exactly that, so it is the standard transport. TLS over TCP and WebSocket over TCP also qualify because they preserve those properties. Plain UDP does not, so standard MQTT never runs directly over UDP.

Where MQTT Sits in the Network Stack

MQTT is an application-layer protocol. Picture the stack from the top:

1. Application: your sensor code, dashboard or backend service.
2. MQTT: CONNECT, PUBLISH, SUBSCRIBE and acknowledgement packets.
3. Optional WebSocket framing: used by browsers and some proxied environments.
4. Optional TLS: encryption and broker authentication.
5. TCP: reliable, ordered delivery with retransmission and flow control.
6. IP and the link layer: Wi-Fi, Ethernet, cellular.

Because MQTT sits above TCP, it can stay simple. It does not need its own sequence numbers for ordering or its own retransmission timers for lost segments; TCP handles that hop by hop between client and broker.

Why MQTT Chose TCP

Ordering and completeness

MQTT packets have a variable-length header and can be split across multiple TCP segments. The parser expects bytes to arrive complete and in order. With UDP, packets can arrive out of order, duplicated or not at all, and the protocol would have to reinvent reassembly.

Connection state

MQTT is connection-oriented. The CONNECT/CONNACK exchange authenticates the client, and the broker associates the open connection with a session. Keep-alive, Last Will and session takeover all depend on a clear notion of "this connection is open" or "this connection broke", which TCP provides.

QoS builds on a reliable link

QoS 1 and 2 add guarantees across connection failures and between client and broker, not packet-level reliability. They assume the link is reliable while it is up and only handle what happens when it breaks. The MQTT QoS levels guide shows those flows.

Firewalls and NAT

TCP connections initiated outbound by a device are well understood by routers and firewalls. The broker can push messages back over the same connection, so devices never need an open inbound port.

The Costs of TCP

TCP is not free, and it is fair to know the trade-offs:

• Connection setup: TCP needs a three-way handshake, and TLS adds its own on top. Devices that wake, connect, publish and sleep pay this every time.
• Head-of-line blocking: a lost segment delays everything behind it on the same connection until it is retransmitted.
• Memory: a TCP/IP stack and TLS library take RAM and flash that the smallest microcontrollers do not have.
• Idle timeouts: NAT devices drop idle TCP mappings, so MQTT keep-alive must be shorter than those timeouts.

For most Wi-Fi, Ethernet and cellular devices these costs are small compared to the benefits, especially when connections stay open for hours. The MQTT latency guide shows how to measure the effect on your own network.

Where UDP Fits: MQTT-SN

For devices without TCP, such as Zigbee nodes or sensors on simple radio networks, there is MQTT-SN (MQTT for Sensor Networks). It keeps the publish/subscribe model but uses compact packets, numeric topic IDs and sleeping-client support, and it runs over UDP or other datagram transports. MQTT-SN clients talk to a gateway, which converts their traffic to normal MQTT over TCP for the broker. Read MQTT-SN explained for gateway setup and topic IDs.

The important point: MQTT-SN is a different wire protocol. A standard broker accepts it only through a gateway.

What About MQTT over QUIC?

QUIC is a modern transport built on UDP that provides reliable, encrypted streams with faster connection setup and less head-of-line blocking than TCP plus TLS. Some broker vendors have experimented with carrying MQTT over QUIC, which can help mobile clients that switch networks often. As of today it is not part of the OASIS MQTT standard, client library support is limited, and it is not something to plan a fleet around unless your broker and libraries explicitly support it. Notice that even here MQTT sits on a reliable, ordered stream; QUIC simply provides that stream on top of UDP.

Which Ports to Open for Your Broker

Since every standard MQTT transport is TCP, firewall rules are all outbound TCP. For broker.connectmq.com and private ConnectMQ brokers:

1. TCP 8883 for devices, gateways and services using MQTT over TLS. This is the one to request first.
2. TCP 8084 for browsers and web apps using secure WebSocket at path /mqtt.
3. TCP 1883 only for testing or isolated networks; it is unencrypted.
4. TCP 8083 only for local WebSocket experiments.
5. No UDP ports are needed for standard MQTT.

Details and troubleshooting are in MQTT ports explained.

Verify It Yourself

You can confirm that MQTT is TCP with the tools you already have. First, check TCP reachability:

nc -vz broker.connectmq.com 8883

Then open an MQTT session over TLS on the public MQTT test broker with debug output, which prints each MQTT packet sent over the TCP connection:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i tcp-check-62ab -t "connectmq/demo/62ab/#" -v -d

While it runs, list the connection from another terminal:

# Linux
ss -tnp | grep 8883
# macOS
netstat -an -p tcp | grep 8883

You will see an ESTABLISHED TCP connection to port 8883 and, every keep-alive interval, PINGREQ and PINGRESP in the debug output. If you capture traffic in Wireshark, the packets appear as TCP, then TLS, with MQTT inside.

From code, the choice of transport is just a URL scheme. In MQTT.js, mqtts://broker.connectmq.com:8883 uses TLS over TCP and wss://broker.connectmq.com:8084/mqtt uses secure WebSocket over TCP; the rest of your code is identical.

const mqtt = require("mqtt");

// Same MQTT session semantics, two TCP-based transports
const url = process.env.USE_WSS
  ? "wss://broker.connectmq.com:8084/mqtt"
  : "mqtts://broker.connectmq.com:8883";

const client = mqtt.connect(url, { clientId: "tcp-js-62ab", protocolVersion: 5 });

client.on("connect", () => {
  console.log("Connected via", url);
  client.publish("connectmq/demo/62ab/transport", url, { qos: 1 }, () => client.end());
});

Production Considerations

When you move beyond the public broker, the transport choice stays the same but security tightens: TLS everywhere, unique credentials per device, and keep-alive tuned to your network. A hosted MQTT broker such as ConnectMQ exposes exactly these TCP endpoints with a Let's Encrypt certificate already in place, so your devices only need outbound access to 8883 (and 8084 for web clients). For a full protocol walkthrough, see the MQTT tutorial.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required, open outbound TCP 8883 on your network, and connect with the generated credentials. ConnectMQ's in-browser client lets you confirm connectivity before deploying any device.

Frequently Asked Questions

Is MQTT TCP or UDP?

Standard MQTT uses TCP, directly or through TLS or WebSocket. UDP is used only by the separate MQTT-SN protocol and by experimental MQTT over QUIC.

Can I send MQTT over UDP to save power?

Not to a standard broker. Use MQTT-SN with a gateway, or keep a long-lived TCP connection and publish only when values change.

Does MQTT over WebSocket still use TCP?

Yes. WebSocket starts as an HTTP request over TCP and then carries MQTT packets on that same TCP connection.

Which layer of the OSI model is MQTT?

MQTT is an application-layer protocol that relies on TCP at the transport layer.