MQTT vs HTTP: cómo elegir el protocolo IoT adecuado

Compara MQTT vs HTTP para IoT: modelo de comunicación, broker, QoS, consumo, APIs y casos de uso para elegir el protocolo adecuado.

Elegir entre MQTT vs HTTP es una decisión importante al diseñar una solución IoT. Ambos protocolos permiten intercambiar información sobre redes IP, pero utilizan modelos de comunicación diferentes y responden mejor a escenarios distintos.

MQTT trabaja principalmente con un modelo publish/subscribe mediante un broker, mientras que HTTP utiliza un modelo request/response ampliamente extendido en aplicaciones web, APIs y servicios distribuidos.

Por eso, la elección no debería basarse en cuál protocolo es “mejor” de forma general. Conviene evaluar la frecuencia de transmisión, el tamaño de los mensajes, la cantidad de dispositivos, la necesidad de recibir comandos, la conectividad disponible, el consumo energético y la arquitectura de la plataforma.

En muchos proyectos IoT, además, MQTT y HTTP pueden utilizarse dentro de una misma solución.

MQTT vs HTTP: dos modelos de comunicación diferentes

La diferencia principal está en la forma en que cada protocolo organiza el intercambio de información.

HTTP: modelo request/response

HTTP utiliza un modelo de petición y respuesta. De forma simplificada:

• un cliente realiza una petición;
• identifica un recurso mediante una URI;
• utiliza un método como GET, POST, PUT, PATCH o DELETE;
• el servidor procesa la solicitud;
• devuelve una respuesta con un código de estado y, cuando corresponde, contenido.

HTTP es un protocolo de aplicación sin estado basado en request/response. Esto no significa que cada solicitud tenga que abrir y cerrar obligatoriamente una nueva conexión: las implementaciones modernas pueden reutilizar conexiones y mantener estado a nivel de aplicación mediante otros mecanismos.

En IoT, HTTP puede resultar práctico para:

• APIs REST;
• integración entre sistemas;
• configuración de dispositivos;
• envío ocasional de datos;
• consulta de recursos;
• comunicación con servicios web existentes.

MQTT: arquitectura publish/subscribe

MQTT utiliza un modelo diferente. Los clientes no necesitan comunicarse directamente entre sí, sino que se conectan a un broker MQTT, encargado de recibir y distribuir los mensajes.

Sus elementos principales son:

• Publisher: cliente que publica información.

Ejemplo:

sensor/planta1/temperatura

• Subscriber: cliente que se suscribe a uno o varios topics para recibir los mensajes asociados.
• Broker: servidor que recibe mensajes, evalúa sus topics y los distribuye a los clientes suscritos.
• Topic: estructura lógica utilizada para organizar los mensajes.

Ejemplo:

planta1/motor3/vibracion

Este modelo desacopla a productores y consumidores: un dispositivo puede publicar información sin conocer directamente qué aplicación la utilizará.

¿Qué es MQTT y por qué se utiliza en IoT?

MQTT es un protocolo de mensajería ligero basado en un modelo cliente-servidor publish/subscribe. Su estructura resulta útil cuando una solución necesita intercambiar mensajes pequeños de forma frecuente o distribuir una misma información hacia diferentes consumidores.

Puede transportar variables como:

• temperatura;
• humedad;
• corriente;
• estado de una máquina;
• alarmas;
• ubicación;
• nivel;
• consumo;
• otras variables operativas.

El protocolo no define qué representa cada dato. Define cómo se transportan y distribuyen los mensajes.

Una arquitectura puede incluir:

dispositivos → gateways → broker MQTT → plataforma → aplicaciones

dependiendo de cómo se haya diseñado la solución.

MQTT fue estandarizado por OASIS. Para una referencia técnica del protocolo, puede consultarse la especificación MQTT 5.0 de OASIS.

También es importante separar el protocolo de aplicación de la conectividad física. MQTT no sustituye a Wi-Fi, Ethernet, redes celulares o LoRaWAN.

Si necesitas revisar las tecnologías empleadas para transportar datos entre dispositivos, consulta nuestra guía sobre tecnologías inalámbricas IoT.

¿Qué es HTTP en IoT?

HTTP no fue diseñado exclusivamente para IoT, pero su nivel de adopción lo convierte en una alternativa útil para integrar dispositivos, plataformas y sistemas empresariales.

Una plataforma, backend o servicio Cloud puede exponer o consumir una API HTTP. Por ejemplo, un dispositivo puede realizar:

POST /api/mediciones

para enviar una lectura a un servidor.

HTTP puede ser suficiente cuando:

• las transmisiones son relativamente ocasionales;
• ya existe una API web;
• el equipo dispone de recursos adecuados;
• no se necesita una arquitectura permanente de mensajería;
• la integración con otros sistemas es prioritaria.

En este punto, MQTT vs HTTP no significa mensajería ligera frente a una tecnología “incorrecta” para IoT. Son modelos distintos que pueden responder bien a necesidades diferentes.

MQTT vs HTTP: diferencias principales

1. Publish/subscribe frente a request/response

En MQTT, un dispositivo publica datos en un topic y el broker los distribuye a los clientes suscritos.

MQTT:

Sensor → Broker → uno o varios suscriptores

En HTTP, el cliente realiza una petición hacia un servidor o API y espera una respuesta.

HTTP:

Cliente → Servidor/API → Respuesta

MQTT puede ser conveniente cuando varios sistemas necesitan recibir el mismo evento. HTTP resulta natural cuando el objetivo es consultar, crear, modificar o enviar información asociada a un recurso.

2. Broker MQTT frente a servidor HTTP

MQTT utiliza normalmente un broker para administrar conexiones, suscripciones, topics y distribución de mensajes.

Esto incorpora un componente adicional a la arquitectura, pero permite desacoplar dispositivos y aplicaciones.

HTTP no necesita un broker equivalente. Un dispositivo puede comunicarse directamente con:

• una API;
• un servidor web;
• una plataforma;
• un microservicio.

Por eso, la elección entre MQTT vs HTTP también depende de la infraestructura que la organización ya tenga disponible.

3. Sobrecarga de comunicación

• MQTT fue diseñado con una estructura compacta. Su encabezado fijo puede comenzar con 2 bytes, aunque el tamaño real de cada paquete depende del tipo de mensaje y de los campos utilizados.
• HTTP incorpora encabezados y metadatos asociados a las solicitudes y respuestas. Esto no significa que HTTP sea siempre ineficiente, ya que las versiones modernas pueden reutilizar conexiones y optimizar el intercambio.

Sin embargo, cuando un equipo necesita enviar muchos mensajes pequeños y frecuentes, la estructura ligera de MQTT puede resultar ventajosa.

Un sensor que publica una lectura cada pocos segundos puede beneficiarse de una sesión MQTT establecida. Un dispositivo que envía un reporte una vez al día puede no obtener la misma ventaja.

4. Conexiones persistentes

• MQTT normalmente mantiene una conexión entre el cliente y el broker. Esto permite que el broker entregue mensajes al dispositivo cuando corresponda, siempre que el cliente se encuentre conectado y la arquitectura lo permita.
• HTTP también puede reutilizar conexiones. Por tanto, no es correcto asumir que cada petición HTTP abre y cierra necesariamente una conexión nueva.

Para comparar MQTT vs HTTP, conviene evaluar cómo se comportará realmente el dispositivo: si estará conectado de forma continua, si trabajará por intervalos o si permanecerá en suspensión durante largos periodos.

5. MQTT QoS: niveles de entrega

MQTT define tres niveles de Quality of Service (QoS):

• QoS 0 — At most once

El mensaje se envía sin un proceso MQTT adicional de confirmación. Prioriza simplicidad y menor intercambio.

• QoS 1 — At least once

Busca que el mensaje llegue al menos una vez. Pueden producirse duplicados, por lo que la aplicación debe poder manejarlos cuando sea necesario.

• QoS 2 — Exactly once

Utiliza un intercambio adicional para asegurar que el mensaje sea entregado exactamente una vez dentro de la semántica del protocolo MQTT.

No existe un nivel universalmente mejor. El QoS adecuado depende del valor del mensaje, la red, el costo de retransmisión y los requisitos de la aplicación.

6. Confiabilidad en HTTP

HTTP no utiliza los niveles QoS 0, 1 y 2 de MQTT.

La confiabilidad puede construirse mediante mecanismos como:

• códigos de estado HTTP;
• reintentos;
• identificadores de operación;
• idempotencia;
• almacenamiento temporal;
• colas internas;
• lógica de aplicación.

Por eso, no sería correcto reducir MQTT vs HTTP a “fiable” frente a “no fiable”. Ambos pueden implementar mecanismos de entrega y recuperación, aunque lo hagan de manera diferente.

7. Comunicación hacia dispositivos

MQTT facilita arquitecturas donde un dispositivo necesita recibir información o comandos.

Por ejemplo:

• maquina3/comando

Un sistema puede publicar un mensaje en ese topic y un dispositivo suscrito puede recibirlo.

Esto puede emplearse para:

• actualizar parámetros;
• enviar configuraciones;
• cambiar determinados estados;
• activar funciones;
• responder a eventos.

En el modelo HTTP tradicional, la comunicación se inicia normalmente mediante una solicitud del cliente. Existen otros patrones y tecnologías para habilitar comunicación iniciada desde el servidor, pero no forman parte del modelo request/response básico de HTTP.

8. Topics MQTT

Los topics permiten organizar mensajes de forma jerárquica.

Por ejemplo:

• planta1/linea2/motor4/temperatura
• planta1/linea2/motor4/vibracion

Así, diferentes consumidores pueden suscribirse únicamente a la información que necesitan.

La estructura debe diseñarse correctamente desde el inicio, porque puede afectar permisos, mantenimiento, escalabilidad y procesamiento posterior.

9. Mensajes retained

MQTT permite marcar mensajes como retained. En ese caso, el broker puede conservar el último mensaje retenido correspondiente a un topic para entregarlo a nuevos suscriptores.

Puede resultar útil para representar:

• estados actuales;
• configuraciones;
• última medición relevante;
• disponibilidad de determinados recursos.

Un mensaje retained no convierte al broker en una base de datos ni sustituye el almacenamiento histórico de una plataforma IoT.

10. Last Will and Testament

MQTT también contempla el mecanismo Last Will and Testament.

Un cliente puede configurar previamente un mensaje que el broker publique cuando detecte una desconexión inesperada de acuerdo con las condiciones del protocolo.

Por ejemplo:

dispositivo/estado = offline

Esta función puede apoyar la supervisión de equipos distribuidos y la detección de pérdidas de conectividad.

MQTT vs HTTP y consumo energético

El consumo energético no depende exclusivamente del protocolo.

También intervienen factores como:

• tecnología de radio;
• calidad de señal;
• frecuencia de transmisión;
• tamaño del payload;
• tiempo conectado;
• negociación TLS;
• reintentos;
• hardware;
• estrategia de suspensión.

MQTT puede reducir parte del intercambio adicional en aplicaciones con mensajes pequeños y frecuentes, pero no debe asumirse que siempre consumirá menos energía.

Un sensor que permanece conectado y publica información constantemente tiene un perfil diferente al de un equipo que despierta una vez al día, transmite una lectura y vuelve a suspensión.

Por eso, la eficiencia energética debe evaluarse sobre el comportamiento real de la aplicación.

MQTT vs HTTP y latencia

Una conexión MQTT ya establecida puede distribuir mensajes rápidamente a través del broker, lo que puede ser útil para telemetría frecuente, alarmas, dashboards, notificaciones o determinados comandos.

Sin embargo, utilizar MQTT no garantiza por sí solo “tiempo real”.

La latencia depende de:

• red;
• broker;
• servidor;
• dispositivo;
• QoS;
• carga del sistema;
• calidad de conectividad.

MQTT puede ser adecuado para aplicaciones que requieren baja latencia, pero no sustituye protocolos determinísticos empleados en sistemas de control industrial crítico.

Escalabilidad en MQTT vs HTTP

MQTT puede facilitar arquitecturas con numerosos productores y consumidores porque los clientes quedan desacoplados mediante el broker.

Un publisher no necesita conocer todos los sistemas que utilizarán sus datos.

Sin embargo, la capacidad real depende de:

• infraestructura;
• implementación del broker;
• cantidad de conexiones;
• frecuencia de publicación;
• tamaño de mensajes;
• QoS;
• persistencia;
• hardware;
• distribución de carga.

HTTP también puede escalar mediante APIs distribuidas, balanceadores, microservicios y arquitecturas Cloud.

Por eso, en una comparación MQTT vs HTTP, no conviene afirmar que uno supera universalmente al otro en escalabilidad. El diseño completo de la solución es lo que determina su capacidad.

Seguridad en MQTT vs HTTP

Ni MQTT ni HTTP deberían evaluarse sin considerar seguridad.

Seguridad en MQTT

MQTT puede utilizar TLS para proteger la comunicación. Además, un broker o plataforma puede implementar mecanismos como:

• usuario y contraseña;
• certificados;
• listas de control de acceso;
• autenticación externa;
• autorización por topics.

Esto no significa que una implementación MQTT sea segura de forma automática. La seguridad depende de la configuración del broker, credenciales, certificados, permisos y dispositivos.

Seguridad en HTTP

Cuando HTTP se utiliza sobre TLS hablamos habitualmente de HTTPS.

A nivel de aplicación pueden utilizarse:

• tokens;
• OAuth;
• claves API;
• certificados;
• sesiones;
• controles de autorización.

Por tanto, la seguridad no debería utilizarse como argumento para declarar un ganador entre MQTT vs HTTP. Ambos pueden implementarse de forma segura o insegura.

MQTT vs HTTPS: ¿es la misma comparación?

No exactamente.

MQTT vs HTTP compara principalmente modelos de comunicación.

En cambio, al hablar de MQTT vs HTTPS, se está comparando MQTT con HTTP protegido mediante TLS.

MQTT también puede utilizar TLS, por lo que HTTPS no debe presentarse simplemente como la alternativa “segura” frente a MQTT.

Una arquitectura MQTT puede proteger sus comunicaciones mediante TLS, mientras que una arquitectura HTTP puede utilizar HTTPS.

Tabla comparativa MQTT vs HTTP

La tabla permite identificar las principales diferencias entre ambos protocolos, pero no debería utilizarse para declarar un ganador universal.

¿Cuándo elegir MQTT?

MQTT puede ser especialmente útil cuando:

1. Los datos se transmiten con frecuencia

Por ejemplo, sensores o gateways que reportan variables varias veces por minuto.

2. Existen múltiples productores y consumidores

El broker permite distribuir mensajes sin que cada dispositivo tenga que conocer directamente a todos los sistemas receptores.

3. Varios sistemas necesitan la misma información

Una publicación puede ser consumida por diferentes suscriptores.

4. Los dispositivos necesitan recibir comandos

Las suscripciones permiten entregar información hacia clientes conectados.

5. Se necesita organizar información mediante topics

La jerarquía facilita separar dispositivos, áreas, variables o tipos de mensaje.

6. Se requieren distintos niveles de entrega

Los niveles QoS permiten adaptar la mensajería a los requisitos de cada dato.

¿Cuándo elegir HTTP?

HTTP puede ser una buena alternativa cuando:

• Se necesita consumir o exponer una API REST

Es uno de sus escenarios más naturales.

• Las transmisiones son ocasionales

Un equipo que envía información esporádicamente puede realizar una petición HTTP sin requerir una arquitectura permanente de mensajería.

• Ya existe infraestructura web

Puede ser más sencillo integrar el dispositivo directamente con un backend o servicio existente.

• Se trabaja con recursos

Métodos como GET, POST, PUT, PATCH y DELETE permiten construir interfaces ampliamente conocidas.

• Se busca reducir componentes operativos

Incorporar un broker MQTT implica instalarlo o contratarlo, protegerlo, monitorearlo y mantenerlo.

MQTT y HTTP pueden utilizarse juntos

Una de las conclusiones más importantes de MQTT vs HTTP es que no siempre es necesario elegir exclusivamente uno.

Una solución puede utilizar:

sensores o gateways → MQTT → broker → plataforma

y después:

plataforma → HTTP/REST → ERP, aplicación u otros sistemas

Por ejemplo, un gateway puede publicar telemetría mediante MQTT mientras una aplicación empresarial consulta datos históricos mediante una API HTTPS.

En este escenario, cada protocolo cumple una función diferente:

• MQTT gestiona mensajería y distribución de eventos.
• HTTP facilita integración y acceso a recursos mediante APIs.

MQTT dentro de una plataforma IoT

Una plataforma IoT puede consumir información desde un broker MQTT y luego:

• almacenar históricos;
• generar alertas;
• actualizar dashboards;
• ejecutar reglas;
• procesar datos;
• integrar información con otros sistemas.

MQTT no debe confundirse con una plataforma IoT completa.

El broker recibe y distribuye mensajes; la plataforma utiliza esos datos para generar funcionalidades para el usuario.

Si quieres profundizar en esa capa, revisa nuestra guía sobre plataforma IoT.

MQTT dentro de una integración industrial

En una instalación industrial también pueden existir varias capas.

Por ejemplo:

sensor → PLC o gateway → MQTT → plataforma

• El sensor no necesariamente utiliza MQTT directamente.
• Un gateway puede adquirir variables mediante Modbus, entradas digitales, señales analógicas u otros protocolos y posteriormente publicar esos datos mediante MQTT.

Esta diferencia evita confundir el protocolo del equipo de campo con el protocolo utilizado para transportar información hacia una plataforma.

Para revisar cómo se conectan sensores, equipos y gateways, consulta nuestra guía sobre integración de sensores industriales.

MQTT y LoRaWAN trabajan en capas diferentes

MQTT y LoRaWAN no son tecnologías equivalentes.

Un dispositivo LoRaWAN no necesita ejecutar MQTT directamente. Una arquitectura puede ser:

dispositivo LoRaWAN → gateway → servidor de red → aplicación → MQTT o API

En este escenario, LoRaWAN se utiliza para la comunicación de los dispositivos dentro de la red, mientras MQTT o HTTP pueden emplearse posteriormente para llevar la información hacia aplicaciones y plataformas.

Si necesitas conocer la arquitectura de esta tecnología, revisa nuestra guía sobre LoRaWAN.

¿Qué protocolo elegir para un proyecto IoT?

Antes de decidir entre MQTT vs HTTP, conviene responder:

• ¿Con qué frecuencia se enviarán datos?
• ¿Cuántos dispositivos existirán?
• ¿Qué tamaño tendrán los mensajes?
• ¿Los dispositivos necesitan recibir comandos?
• ¿Varios sistemas necesitan consumir el mismo dato?
• ¿La solución ya dispone de APIs REST?
• ¿Tiene sentido incorporar y administrar un broker?
• ¿Qué debe ocurrir cuando se pierde conectividad?
• ¿Qué garantías de entrega necesita cada mensaje?
• ¿Cómo se autenticarán dispositivos y aplicaciones?

Estas preguntas permiten seleccionar el protocolo desde los requisitos reales del proyecto y no desde una comparación genérica.

MQTT vs HTTP: ¿cuál es mejor para IoT?

La respuesta depende de la arquitectura.

• MQTT puede ser una alternativa adecuada cuando la solución necesita mensajería frecuente, publish/subscribe, distribución de eventos, múltiples consumidores o comunicación hacia dispositivos conectados.
• HTTP puede resultar más conveniente cuando se necesitan APIs REST, integraciones web, operaciones sobre recursos o transmisiones relativamente ocasionales.

Y en muchos proyectos, ambos pueden coexistir.

Por eso, al evaluar MQTT vs HTTP, el criterio principal debería ser cómo cada protocolo encaja con los dispositivos, la conectividad, la plataforma y los requisitos operativos de la solución.

En Smelpro desarrollamos soluciones IoT industriales integrando sensores, gateways, conectividad, protocolos y plataformas de acuerdo con las necesidades de cada operación.