MQTT vs CoAP: pub/sub sobre TCP frente a petición/respuesta sobre UDP

MQTT vs CoAP es una elección entre dos protocolos creados para el mismo tipo de hardware, pequeños dispositivos alimentados por batería en redes con pérdidas, que sin embargo funcionan de formas opuestas. MQTT es publish/subscribe sobre TCP a través de un broker; CoAP es petición/respuesta RESTful sobre UDP, directamente entre endpoints. Esta guía compara transportes, cabeceras, seguridad, multicast y flujo de datos para que decidas cuál encaja con tus dispositivos y tu backend.

La versión corta

Si tus dispositivos pueden mantener una conexión TCP y tus datos tienen que llegar a varios consumidores en la nube, MQTT con un broker suele ser el camino más sencillo. Si tus dispositivos están en una red IPv6 limitada como 6LoWPAN o Thread, duermen la mayor parte del tiempo y se direccionan como diminutos servidores web, CoAP encaja de forma natural. Muchos despliegues grandes usan CoAP en la red local limitada y MQTT desde un gateway hacia la nube.

Cómo funciona CoAP

CoAP (Constrained Application Protocol, RFC 7252) lleva el modelo REST a los microcontroladores. Cada dispositivo expone recursos como /sensors/temp, y los clientes usan GET, POST, PUT y DELETE sobre ellos, igual que en HTTP pero en un formato binario compacto sobre UDP. Las respuestas llevan códigos inspirados en los códigos de estado HTTP, por ejemplo 2.05 Content o 4.04 Not Found.

Como UDP no garantiza la entrega, CoAP añade su propia fiabilidad ligera: un mensaje puede ser Confirmable (CON), que el receptor debe confirmar, o Non-confirmable (NON), que se envía y se olvida. Las retransmisiones usan backoff exponencial.

CoAP también tiene una opción Observe (RFC 7641). Un cliente registra su interés en un recurso y el servidor envía una notificación cada vez que cambia. Es lo más parecido que tiene CoAP al subscribe de MQTT, pero es punto a punto entre un cliente y un único servidor.

Cómo funciona MQTT

Los clientes MQTT abren una conexión TCP (opcionalmente TLS) con un broker y luego publican mensajes en topics y se suscriben a filtros de topic. Los dispositivos nunca hablan directamente entre sí; el broker se encarga del fan-out, los últimos valores conocidos retenidos, las sesiones persistentes para suscriptores offline y los mensajes Last Will ante desconexiones abruptas. Si el concepto de broker es nuevo para ti, empieza por qué es un broker MQTT, y para una introducción paso a paso consulta el tutorial de MQTT.

MQTT vs CoAP de un vistazo

Transporte: TCP frente a UDP

El transporte es la raíz de la mayoría de diferencias. TCP da a MQTT flujos de bytes ordenados y fiables, pero cuesta un handshake de tres pasos para conectar y mantiene estado en ambos extremos. En un enlace de radio con pérdidas, las retransmisiones de TCP y el bloqueo de cabeza de línea pueden añadir latencia. Para saber más sobre la cuestión del transporte, consulta ¿MQTT usa TCP o UDP?.

UDP permite a CoAP enviar una lectura en un solo datagrama sin establecer conexión, lo que encaja con dispositivos que se despiertan un momento, transmiten y vuelven a dormir. La contrapartida es que la aplicación, en este caso CoAP, debe encargarse ella misma de la fiabilidad, la eliminación de duplicados y el control de congestión, y que los dispositivos detrás de NAT se vuelven difíciles de alcanzar porque las asignaciones UDP caducan rápido.

Tamaño de cabecera y sobrecarga

Ambos protocolos son compactos. Un PUBLISH de MQTT puede ser muy pequeño, pero la cadena del topic viaja con cada mensaje salvo que uses los topic aliases de MQTT 5. CoAP usa una cabecera de 4 bytes, un token corto y opciones codificadas como deltas, así que la ruta URI también es compacta. En la práctica, la sobrecarga por mensaje está en el mismo rango reducido para ambos; la diferencia mayor está en la sobrecarga de conexión (TCP y TLS en MQTT frente a ninguna o DTLS en CoAP).

Seguridad: TLS frente a DTLS

MQTT usa TLS sobre TCP, la misma pila bien conocida que protege HTTPS, con un soporte maduro en SDKs de dispositivos, gateways y brokers en la nube. Un broker MQTT gestionado suele encargarse de los certificados por ti; ConnectMQ, por ejemplo, sirve un certificado de Let's Encrypt en el puerto 8883 para TLS y en el 8084 para WebSocket seguro.

CoAP usa DTLS, la versión de TLS para datagramas. Funciona, pero el estado de sesión, la retransmisión del handshake en enlaces con pérdidas y el cambio de asignaciones NAT añaden complejidad, y las herramientas están menos extendidas. OSCORE (RFC 8613) ofrece seguridad de extremo a extremo a nivel de objeto que sobrevive a los proxies, algo atractivo en redes limitadas de varios saltos, pero añade su propia gestión de claves.

Para cualquiera de los dos protocolos, la regla práctica es la misma: cifra cada tramo que sale del dispositivo y nunca confíes solo en el aislamiento de la red. La guía de buenas prácticas de seguridad MQTT cubre credenciales, TLS y diseño de topics para despliegues MQTT.

Observe frente a subscribe

CoAP Observe y el subscribe de MQTT entregan actualizaciones sin sondeo, pero la topología es distinta. Con Observe, cada cliente interesado se registra en el propio dispositivo. Diez dashboards significan diez observadores en un microcontrolador que puede tener unos pocos kilobytes de RAM. Con MQTT, el dispositivo publica una vez en el broker y el broker gestiona cualquier número de suscriptores. Por eso MQTT escala mejor cuando los datos tienen muchos consumidores, mientras que CoAP funciona bien cuando un controlador habla con muchos dispositivos pequeños.

Multicast y descubrimiento local

Esta es la ventaja clara de CoAP. Un cliente puede enviar una petición a un grupo multicast IP, por ejemplo para apagar todas las luces de una planta, y todos los miembros responden. Junto con el descubrimiento de recursos en /.well-known/core, CoAP encaja en redes locales de automatización de edificios y hogares, donde los dispositivos se encuentran entre sí sin un servidor central. MQTT no tiene multicast; cada mensaje pasa por el broker.

Un patrón híbrido habitual

Las redes mesh limitadas y la nube tienen necesidades distintas, así que muchos sistemas colocan un gateway entre ambas:

1. Los sensores de una malla Thread o 6LoWPAN exponen recursos CoAP.
2. Un gateway de frontera observa esos recursos o recibe POST CoAP.
3. El gateway publica cada actualización por MQTT con TLS en un broker MQTT en la nube, por ejemplo en site1/floor2/room14/temperature.
4. Los dashboards, historians y servicios de alertas se suscriben al broker.

Este es el lado de la nube de ese gateway en Python. La gestión de CoAP depende de tu biblioteca, así que se representa con una función que recibe una lectura; la parte MQTT está completa.

import json
import ssl
import time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set("site1/gateway1/status", "offline", qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish("site1/gateway1/status", "online", qos=1, retain=True)

client.on_connect = on_connect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_start()

def forward_coap_reading(resource_path, value):
    """Llama a esta función desde tu callback de observe de CoAP."""
    topic = "site1/" + resource_path.strip("/").replace("sensors/", "")
    payload = json.dumps({"value": value, "ts": int(time.time())})
    client.publish(topic, payload, qos=1, retain=True)

# Ejemplo: una lectura observada desde coap://[fd00::12]/sensors/floor2/room14/temperature
forward_coap_reading("/sensors/floor2/room14/temperature", 21.6)
time.sleep(2)

Para experimentar sin cuenta, cambia la conexión por client.connect("broker.connectmq.com", 1883) con cualquier client ID único y un prefijo de topic como connectmq/demo/<random-id>/, pero ten en cuenta que el servidor MQTT público gratuito es legible por cualquiera.

Cuándo elegir cada uno

Elige MQTT cuando:

• Los dispositivos están en Wi-Fi, Ethernet o red celular y pueden mantener una conexión TCP saliente.
• Los datos tienen que llegar a varios consumidores en la nube.
• Quieres estado retenido, estado online mediante Last Will y buffer para suscriptores offline.
• Prefieres bibliotecas cliente maduras y ampliamente disponibles y un broker MQTT gestionado.

Elige CoAP cuando:

• Los dispositivos funcionan en mallas IPv6 limitadas con muy poca RAM y energía.
• Necesitas comandos multicast o descubrimiento local sin servidor central.
• La interacción es de forma natural petición/respuesta, como leer o escribir un ajuste del dispositivo.

Si tu proyecto está más cerca del lado de MQTT pero los dispositivos son extremadamente limitados o no tienen TCP, echa también un vistazo a MQTT-SN, que lleva la semántica de MQTT a UDP y otros transportes de datagramas.

Empieza con ConnectMQ

Tanto si tus dispositivos hablan MQTT de forma nativa como a través de un gateway CoAP, el lado de la nube necesita un broker fiable. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, TLS en el 8883 y un explorador de topics en vivo para comprobar cada gateway en cuanto se conecta. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta tu primer gateway en minutos.

Preguntas frecuentes

¿CoAP es mejor que MQTT para dispositivos con batería?

Puede serlo para dispositivos que se despiertan rara vez y envían un solo datagrama, porque UDP evita establecer conexión. Para dispositivos que informan a menudo o deben recibir comandos, la conexión persistente de MQTT suele ser igual de eficiente y más sencilla de operar.

¿CoAP necesita un broker?

No. Los clientes CoAP hablan directamente con los endpoints de los dispositivos. Los proxies pueden añadir caché y traducción de protocolos, pero no hay un broker central como en MQTT.

¿CoAP y MQTT pueden funcionar juntos?

Sí. Es habitual que un gateway observe recursos CoAP en una malla local y publique los valores en un broker MQTT en la nube, lo que te da eficiencia local y fan-out en la nube.

¿MQTT admite UDP?

MQTT estándar funciona sobre TCP o WebSocket. MQTT-SN es un protocolo relacionado diseñado para UDP y otras redes de datagramas, que normalmente se conecta a un broker MQTT normal a través de un gateway.