¿MQTT usa TCP o UDP? MQTT funciona sobre TCP: directamente, envuelto en TLS o transportado dentro de una conexión WebSocket, que a su vez funciona sobre TCP. Este artículo explica por qué MQTT depende de las garantías de TCP, dónde encajan las variantes basadas en UDP como MQTT-SN y el experimental MQTT sobre QUIC, y qué puertos exactos debes abrir en tu firewall para un broker en la nube.
¿MQTT usa TCP o UDP? La respuesta corta
Las especificaciones MQTT 3.1.1 y 5.0 exigen un transporte subyacente que entregue un flujo de bytes ordenado, sin pérdidas y bidireccional. TCP/IP proporciona exactamente eso, así que es el transporte estándar. TLS sobre TCP y WebSocket sobre TCP también cumplen, porque conservan esas propiedades. UDP sin más no lo hace, así que MQTT estándar nunca funciona directamente sobre UDP.
| Transporte | Protocolo subyacente | Puerto típico | ¿MQTT estándar? |
|---|---|---|---|
| MQTT sobre TCP | TCP | 1883 | Sí |
| MQTT sobre TLS | TLS sobre TCP | 8883 | Sí |
| MQTT sobre WebSocket | Upgrade HTTP sobre TCP | 8083 (ws) |
Sí |
| MQTT sobre WebSocket seguro | TLS sobre TCP | 8084 (wss) |
Sí |
| MQTT-SN | UDP u otras redes de datagramas | Depende del gateway | Protocolo distinto |
| MQTT sobre QUIC | QUIC sobre UDP | Depende del broker | No forma parte del estándar OASIS |
Dónde se sitúa MQTT en la pila de red
MQTT es un protocolo de la capa de aplicación. Imagina la pila de arriba abajo:
- Aplicación: el código de tu sensor, tu dashboard o tu servicio backend.
- MQTT: paquetes CONNECT, PUBLISH, SUBSCRIBE y de confirmación.
- Encapsulado WebSocket opcional: lo usan los navegadores y algunos entornos con proxy.
- TLS opcional: cifrado y autenticación del broker.
- TCP: entrega fiable y ordenada con retransmisión y control de flujo.
- IP y capa de enlace: Wi-Fi, Ethernet, celular.
Como MQTT está por encima de TCP, puede ser sencillo. No necesita sus propios números de secuencia para ordenar ni sus propios temporizadores de retransmisión para segmentos perdidos; TCP se encarga de ello en cada tramo entre cliente y broker.
Por qué MQTT eligió TCP
Orden e integridad
Los paquetes MQTT tienen una cabecera de longitud variable y pueden repartirse entre varios segmentos TCP. El parser espera que los bytes lleguen completos y en orden. Con UDP, los paquetes pueden llegar desordenados, duplicados o no llegar, y el protocolo tendría que reinventar el reensamblado.
Estado de la conexión
MQTT está orientado a conexión. El intercambio CONNECT/CONNACK autentica al cliente, y el broker asocia la conexión abierta con una sesión. El keep-alive, el Last Will y la toma de control de sesiones dependen de una noción clara de "esta conexión está abierta" o "esta conexión se ha roto", que es lo que proporciona TCP.
El QoS se construye sobre un enlace fiable
QoS 1 y 2 añaden garantías ante fallos de conexión y entre cliente y broker, no fiabilidad a nivel de paquete. Presuponen que el enlace es fiable mientras está activo y solo gestionan lo que ocurre cuando se rompe. La guía de niveles de QoS de MQTT muestra esos flujos.
Firewalls y NAT
Los routers y firewalls entienden bien las conexiones TCP iniciadas hacia fuera por un dispositivo. El broker puede devolver mensajes por esa misma conexión, así que los dispositivos nunca necesitan un puerto entrante abierto.
Los costes de TCP
TCP no sale gratis, y conviene conocer las contrapartidas:
- Establecimiento de conexión: TCP necesita un handshake de tres pasos, y TLS añade el suyo encima. Los dispositivos que se despiertan, se conectan, publican y duermen lo pagan cada vez.
- Bloqueo de cabeza de línea: un segmento perdido retrasa todo lo que va detrás en la misma conexión hasta que se retransmite.
- Memoria: una pila TCP/IP y una biblioteca TLS ocupan RAM y flash que los microcontroladores más pequeños no tienen.
- Timeouts de inactividad: los dispositivos NAT eliminan las asignaciones TCP inactivas, así que el keep-alive de MQTT debe ser más corto que esos timeouts.
Para la mayoría de dispositivos Wi-Fi, Ethernet y celulares, estos costes son pequeños comparados con los beneficios, sobre todo cuando las conexiones permanecen abiertas durante horas. La guía de latencia MQTT muestra cómo medir el efecto en tu propia red.
Dónde encaja UDP: MQTT-SN
Para dispositivos sin TCP, como nodos Zigbee o sensores en redes de radio sencillas, existe MQTT-SN (MQTT for Sensor Networks). Mantiene el modelo publish/subscribe, pero usa paquetes compactos, topic IDs numéricos y soporte para clientes dormidos, y funciona sobre UDP u otros transportes de datagramas. Los clientes MQTT-SN hablan con un gateway, que convierte su tráfico en MQTT normal sobre TCP para el broker. Lee MQTT-SN explicado para ver la configuración del gateway y los topic IDs.
Lo importante: MQTT-SN es un protocolo de red distinto. Un broker estándar solo lo acepta a través de un gateway.
¿Y MQTT sobre QUIC?
QUIC es un transporte moderno construido sobre UDP que ofrece flujos fiables y cifrados con un establecimiento de conexión más rápido y menos bloqueo de cabeza de línea que TCP más TLS. Algunos fabricantes de brokers han experimentado con transportar MQTT sobre QUIC, lo que puede ayudar a clientes móviles que cambian de red a menudo. A día de hoy no forma parte del estándar MQTT de OASIS, el soporte en bibliotecas cliente es limitado y no es algo sobre lo que planificar una flota salvo que tu broker y tus bibliotecas lo admitan explícitamente. Fíjate en que incluso aquí MQTT se apoya en un flujo fiable y ordenado; QUIC simplemente proporciona ese flujo sobre UDP.
Qué puertos abrir para tu broker
Como todos los transportes MQTT estándar son TCP, todas las reglas de firewall son TCP saliente. Para broker.connectmq.com y los brokers privados de ConnectMQ:
- TCP 8883 para dispositivos, gateways y servicios que usan MQTT sobre TLS. Es el primero que debes solicitar.
- TCP 8084 para navegadores y aplicaciones web que usan WebSocket seguro en la ruta
/mqtt. - TCP 1883 solo para pruebas o redes aisladas; no está cifrado.
- TCP 8083 solo para experimentos locales con WebSocket.
- No se necesita ningún puerto UDP para MQTT estándar.
Los detalles y la solución de problemas están en puertos MQTT explicados.
Compruébalo tú mismo
Puedes confirmar que MQTT es TCP con las herramientas que ya tienes. Primero, comprueba la accesibilidad TCP:
nc -vz broker.connectmq.com 8883
Después, abre una sesión MQTT sobre TLS en el servidor MQTT público gratuito con salida de depuración, que imprime cada paquete MQTT enviado por la conexión TCP:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i tcp-check-62ab -t "connectmq/demo/62ab/#" -v -d
Mientras se ejecuta, lista la conexión desde otra terminal:
# Linux
ss -tnp | grep 8883
# macOS
netstat -an -p tcp | grep 8883
Verás una conexión TCP ESTABLISHED al puerto 8883 y, en cada intervalo de keep-alive, PINGREQ y PINGRESP en la salida de depuración. Si capturas el tráfico con Wireshark, los paquetes aparecen como TCP, luego TLS, con MQTT dentro.
Desde el código, la elección del transporte es solo un esquema de URL. En MQTT.js, mqtts://broker.connectmq.com:8883 usa TLS sobre TCP y wss://broker.connectmq.com:8084/mqtt usa WebSocket seguro sobre TCP; el resto del código es idéntico.
const mqtt = require("mqtt");
// La misma semántica de sesión MQTT, dos transportes basados en TCP
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());
});
Consideraciones para producción
Cuando vas más allá del broker público, la elección del transporte no cambia, pero la seguridad se endurece: TLS en todas partes, credenciales únicas por dispositivo y un keep-alive ajustado a tu red. Un broker MQTT gestionado como ConnectMQ expone exactamente estos endpoints TCP con un certificado de Let's Encrypt ya configurado, así que tus dispositivos solo necesitan acceso saliente al 8883 (y al 8084 para los clientes web). Para un recorrido completo por el protocolo, consulta el tutorial de MQTT.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, abre el TCP 8883 saliente en tu red y conéctate con las credenciales generadas. El cliente integrado en el navegador de ConnectMQ te permite confirmar la conectividad antes de desplegar ningún dispositivo.
Preguntas frecuentes
¿MQTT usa TCP o UDP?
MQTT estándar usa TCP, directamente o a través de TLS o WebSocket. UDP solo lo usan el protocolo independiente MQTT-SN y el experimental MQTT sobre QUIC.
¿Puedo enviar MQTT por UDP para ahorrar energía?
No a un broker estándar. Usa MQTT-SN con un gateway, o mantén una conexión TCP de larga duración y publica solo cuando cambien los valores.
¿MQTT sobre WebSocket sigue usando TCP?
Sí. WebSocket empieza como una petición HTTP sobre TCP y después transporta los paquetes MQTT por esa misma conexión TCP.
¿En qué capa del modelo OSI está MQTT?
MQTT es un protocolo de la capa de aplicación que se apoya en TCP en la capa de transporte.
