MQTT vs HTTP para IoT: ¿qué protocolo deberías usar?

HTTP mueve la web; MQTT se diseñó para máquinas en redes poco fiables. Ambos funcionan sobre TCP, ambos se pueden proteger con TLS y ambos pueden transportar JSON. La diferencia está en el modelo de comunicación, y ese modelo decide cuál encaja con tu caso IoT. Este artículo los compara con honestidad, incluidos los casos en los que HTTP es la mejor opción.

Dos modelos de comunicación distintos

HTTP es petición/respuesta. Un cliente pide a un servidor concreto un recurso concreto y espera la respuesta. El servidor no puede hablar primero: si un dispositivo necesita enterarse de un cambio, tiene que hacer polling, mantener abierta una petición larga o usar un mecanismo adicional como server-sent events o WebSockets.

MQTT es publicación/suscripción. Los clientes se conectan a un broker y mantienen la conexión abierta. Los publicadores envían mensajes a topics; el broker los empuja a todos los suscriptores de ese topic. Emisores y receptores nunca necesitan conocerse. Si el modelo es nuevo para ti, lee primero qué es MQTT.

Comparativa MQTT vs HTTP

Sobrecarga y duración de la batería

Un paquete MQTT mínimo como PINGREQ ocupa solo 2 bytes, y una publicación añade únicamente el nombre del topic y el payload a una cabecera pequeña. Una petición HTTP lleva una línea de método, una cabecera host y a menudo cabeceras user-agent, content-type, authorization y cookies, en texto y en cada petición. Cuando un sensor envía una lectura de 20 bytes cada pocos segundos, ese envoltorio domina el tráfico.

El establecimiento de la conexión importa aún más. Cada nueva conexión HTTPS cuesta un handshake TCP y TLS, lo que significa tiempo de radio y batería en un dispositivo celular. MQTT paga ese coste una vez y después reutiliza la conexión en ambas direcciones. El keep-alive de HTTP y HTTP/2 reducen la diferencia, pero no dan al servidor una forma de empujar datos al dispositivo.

Fiabilidad en redes malas

MQTT incluye semántica de entrega en el protocolo. QoS 1 y 2 confirman y reintentan los mensajes, las sesiones persistentes encolan mensajes para los clientes que se caen, los mensajes retenidos dan al instante el último valor conocido a un nuevo suscriptor y un Last Will avisa a todos cuando un dispositivo desaparece sin despedirse. Con HTTP, cada una de estas cosas la construyes tú: reintentos, claves de idempotencia, un almacén de estado y un endpoint de heartbeat.

Seguridad

Ambos protocolos se apoyan en TLS para el cifrado, así que ninguno es intrínsecamente más seguro. La diferencia está en dónde ocurre la autorización. Una API HTTP autentica cada petición, normalmente con un token, y la autoriza por endpoint. Un broker MQTT autentica una vez en el CONNECT (usuario/contraseña, certificados de cliente o, en MQTT 5, autenticación mejorada) y después autoriza cada publicación y suscripción según reglas de acceso a nivel de topic. Por eso, una jerarquía de topics bien diseñada forma parte de tu modelo de seguridad: una regla como este dispositivo solo puede publicar en su propio subárbol es fácil de expresar cuando los topics incluyen el ID del dispositivo.

Escalado

Los servicios HTTP escalan horizontalmente detrás de un balanceador de carga porque cada petición es independiente. Los brokers MQTT mantienen estado de cada cliente conectado —suscripciones, sesiones, mensajes en vuelo—, así que escalar a grandes flotas implica montar un clúster de brokers o usar un proveedor que lo haga. En el lado del consumidor, las suscripciones compartidas de MQTT 5 reparten los mensajes entre varios workers de backend. Ningún enfoque es más difícil en conjunto; simplemente ponen la complejidad en sitios distintos.

La misma lectura, de dos formas

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

Con HTTP, la API decide quién recibe la lectura después. Con MQTT, un dashboard, un escritor de base de datos y un servicio de alertas pueden suscribirse a testmqtt/+/temp sin que el dispositivo sepa siquiera que existen.

Suscríbete a lecturas en directo en el navegador

Cuándo usar MQTT

• Telemetría frecuente de muchos dispositivos.
• Enviar comandos a dispositivos situados detrás de NAT o firewalls: ellos se conectan hacia fuera y el broker empuja hacia dentro.
• Dashboards y alertas en tiempo real que necesitan push, no polling.
• Hardware limitado, enlaces con tarifa por consumo o dispositivos a batería.
• Un mismo evento consumido por varios servicios independientes.

Cuándo usar HTTP

• Consultar y gestionar recursos (registro de dispositivos, configuración, cuentas de usuario) con una API REST.
• Transferencias de archivos grandes, como imágenes de firmware, logs o capturas de cámara.
• Subidas puntuales y poco frecuentes en las que no compensa mantener una conexión abierta.
• APIs públicas para terceros que esperan las herramientas web estándar, caché y autenticación.

¿Y los navegadores?

Los navegadores no pueden abrir conexiones MQTT directas, pero MQTT funciona sin problemas sobre WebSockets, que empiezan como una petición HTTP de upgrade. Eso da a los dashboards web push en directo con los mismos topics que usan tus dispositivos. Consulta MQTT sobre WebSockets para ver puertos y configuración.

Veredicto

Elige MQTT para comunicación bidireccional, basada en eventos y con muchos dispositivos; elige HTTP para APIs orientadas a recursos y transferencias masivas. Si dudas, crea un prototipo de la parte MQTT en unos minutos con el cliente MQTT online y un broker público de pruebas antes de comprometerte.

Preguntas frecuentes