Una de las primeras decisiones técnicas en un proyecto IoT es elegir el protocolo de comunicación. MQTT y HTTP son los dos candidatos principales, pero tienen filosofías completamente diferentes. Elegir mal puede significar baterías que se agotan en semanas en lugar de años, datos que se pierden sin que nadie se entere o arquitecturas que no escalan.
Esta guía te ayuda a tomar la decisión correcta basándote en criterios técnicos objetivos y experiencia real implementando ambos protocolos en producción.
MQTT: diseñado para IoT
MQTT (Message Queuing Telemetry Transport) fue creado en 1999 por IBM para monitorizar oleoductos via satélite. El contexto original lo dice todo: ancho de banda limitado, alta latencia, conexiones inestables y dispositivos con recursos muy limitados.
Características clave de MQTT
Modelo Pub/Sub: Los dispositivos publican mensajes en topics. Los consumidores se suscriben a los topics que les interesan. No hay conexión directa entre productor y consumidor: el broker gestiona toda la distribución.
Overhead mínimo: El header fijo de MQTT ocupa solo 2 bytes. Un mensaje típico con topic y payload ocupa 10-50 bytes. Compara con los 300-800 bytes de una petición HTTP equivalente.
Tres niveles de QoS:
- QoS 0: Fire and forget (máxima eficiencia, sin garantía)
- QoS 1: At least once (garantía de entrega, posibles duplicados)
- QoS 2: Exactly once (máxima fiabilidad, mayor overhead)
Sesiones persistentes: El broker almacena mensajes para dispositivos desconectados y los entrega cuando se reconectan.
Last Will and Testament (LWT): El broker publica un mensaje predefinido si detecta que un dispositivo se ha desconectado inesperadamente. Perfecto para detección de fallos.
Keep-alive eficiente: Pings periódicos de pocos bytes para mantener la conexión viva a través de NATs y firewalls.
Cuándo usar MQTT
- Dispositivos alimentados por batería (cada byte cuenta)
- Conectividad móvil/LoRaWAN/NB-IoT con latencia variable
- Datos que deben llegar en tiempo real (monitorización, alertas)
- Comunicación bidireccional (enviar comandos al dispositivo)
- Miles de dispositivos publicando datos al mismo broker
- Dispositivos que se conectan y desconectan frecuentemente
HTTP: el protocolo universal
HTTP es el protocolo de la web. Todos los desarrolladores lo conocen, todas las herramientas lo soportan, todos los firewalls lo dejan pasar. Pero no fue diseñado para IoT.
Características clave de HTTP para IoT
Modelo Request/Response: El cliente inicia siempre la comunicación. El servidor no puede enviar datos al dispositivo de forma proactiva (sin WebSocket o SSE).
Overhead significativo: Headers HTTP típicos ocupan 300-800 bytes. Para un sensor que envía 10 bytes de datos, eso es un 98% de overhead.
Sin estado: Cada request es independiente. No hay concepto de sesión persistente ni de mensajes pendientes. Si el servidor quiere enviar algo al dispositivo, tiene que esperar a que el dispositivo haga polling.
Ecosistema maduro: APIs REST bien documentadas, autenticación OAuth2, herramientas de debugging, SDKs en todos los lenguajes, integración trivial con cualquier sistema.
TLS estándar: HTTPS funciona en todas partes. Certificados Let’s Encrypt gratuitos. No requiere configuración especial.
Cuándo usar HTTP
- Dispositivos con alimentación constante y WiFi/Ethernet
- Envío de datos infrecuente (una vez al día, cada hora)
- Payloads grandes (imágenes, logs, archivos de configuración)
- Integración con APIs REST existentes
- Actualizaciones de firmware OTA
- Gateways y dispositivos edge con recursos abundantes
Comparación técnica detallada
Overhead de red
| Métrica | MQTT | HTTP |
|---|---|---|
| Header mínimo | 2 bytes | ~300 bytes |
| Conexión | Una vez (persistente) | Cada request (o keep-alive) |
| TLS handshake | Una vez | Cada conexión (sin keep-alive) |
| Mensaje típico (10 bytes payload) | ~20 bytes total | ~350 bytes total |
| Ratio payload/overhead | 50% | 3% |
Para un sensor que envía una lectura cada 5 minutos durante un mes:
- MQTT: ~20 bytes * 8.640 mensajes = 173 KB
- HTTP: ~350 bytes * 8.640 requests = 3 MB
Eso es 17x más datos con HTTP. En redes con coste por MB (NB-IoT, LTE-M), la diferencia es real en la factura.
Consumo de batería
El consumo de radio es el principal drenaje de batería en dispositivos IoT. Menos bytes = menos tiempo de radio activa = más vida de batería.
| Escenario | MQTT QoS 0 | HTTP POST |
|---|---|---|
| Envío cada 5 min | ~3 años batería | ~6 meses batería |
| Envío cada hora | ~5 años batería | ~2 años batería |
| Envío 1x día | ~7 años batería | ~5 años batería |
Estos son valores aproximados para un dispositivo típico con batería de 3.600 mAh y radio LoRaWAN/NB-IoT.
Latencia
| Escenario | MQTT | HTTP |
|---|---|---|
| Dispositivo al broker/server | 10-50 ms | 100-500 ms |
| Broker a suscriptor | <10 ms | N/A (polling) |
| Comando al dispositivo | <100 ms | Esperar al próximo poll |
| Notificación de desconexión | Inmediata (LWT) | Solo por timeout |
MQTT gana claramente en escenarios bidireccionales. Si necesitas enviar un comando a un dispositivo y recibir confirmación en menos de un segundo, HTTP con polling no es viable.
Fiabilidad
| Característica | MQTT | HTTP |
|---|---|---|
| Entrega garantizada | QoS 1/2 | Retry manual |
| Mensajes pendientes | Sesión persistente | No nativo |
| Detección desconexión | LWT (segundos) | Timeout (minutos) |
| Duplicados | QoS 2 los elimina | Idempotencia manual |
| Orden de mensajes | Garantizado por QoS | No garantizado |
Escalabilidad
| Métrica | MQTT (AWS IoT Core) | HTTP (API Gateway) |
|---|---|---|
| Conexiones simultáneas | Millones | N/A (stateless) |
| Mensajes/segundo | Millones | Miles-Millones (con auto-scaling) |
| Fan-out (1 mensaje a N suscriptores) | Nativo | Requiere implementación |
| Coste por mensaje | $1 por millón | ~$3.50 por millón (API Gateway) |
Arquitectura híbrida: lo mejor de ambos mundos
En la práctica, la mayoría de proyectos IoT industriales usan ambos protocolos:
Dispositivos → MQTT → Broker → Procesamiento
↓
API REST (HTTP)
↓
Dashboards / Apps / Integraciones- MQTT para la comunicación dispositivo-cloud: eficiente, bidireccional, tolerante a desconexiones
- HTTP/REST para la API del backend: dashboards, apps móviles, integraciones con sistemas de terceros
Esta es exactamente la arquitectura que implementamos en Spherag: dispositivos publican via MQTT a AWS IoT Core, el procesamiento ocurre en Lambda/Kinesis, y los datos se exponen via API REST + WebSocket para el dashboard.
Casos donde MQTT es claramente mejor
1. Telemetría de alta frecuencia
Un sensor industrial enviando vibración a 100 Hz (100 mensajes/segundo). Con HTTP, cada mensaje necesitaría un round-trip completo. Con MQTT, los mensajes fluyen por la conexión persistente con overhead mínimo.
2. Redes de sensores con batería
Dispositivos LoRaWAN o NB-IoT que deben funcionar años con una batería. Cada byte extra reduce la vida útil. MQTT con QoS 0 minimiza el consumo.
3. Comandos remotos a dispositivos
Necesitas abrir una válvula, cambiar la configuración de un sensor o actualizar un parámetro. Con MQTT, el dispositivo está suscrito a un topic de comandos y recibe la instrucción inmediatamente. Con HTTP, tendrías que esperar a que el dispositivo haga polling.
4. Detección de desconexiones
En monitorización de infraestructura crítica, necesitas saber en segundos si un dispositivo se ha desconectado. El LWT de MQTT lo hace automáticamente. Con HTTP, solo te enterarías cuando el siguiente poll no llega (que puede ser minutos u horas después).
Casos donde HTTP es mejor o igual
1. Dispositivos con conectividad WiFi estable
Un gateway con WiFi/Ethernet y alimentación constante puede usar HTTP sin penalización significativa. Si solo envía datos cada minuto, el overhead extra es irrelevante.
2. Envío de archivos grandes
Firmware updates, logs comprimidos, imágenes de cámaras. HTTP con chunked transfer o multipart es más adecuado que MQTT para payloads de KB o MB.
3. Integración con sistemas legacy
Si tu sistema destino solo acepta HTTP/REST, un gateway que traduce MQTT a HTTP es la solución más pragmática.
4. Prototipado rápido
Para un MVP rápido con pocos dispositivos, HTTP puede ser más sencillo de implementar si el equipo ya tiene experiencia con APIs REST.
MQTT sobre WebSocket: el bridge perfecto
Un caso especial: MQTT sobre WebSocket permite que navegadores web se suscriban directamente a topics MQTT. Esto es ideal para dashboards en tiempo real que necesitan recibir datos del broker sin un backend intermedio.
Dispositivo → MQTT → Broker
↓
Browser → MQTT over WebSocket → BrokerAWS IoT Core soporta MQTT sobre WebSocket nativamente, lo que permite que un dashboard React se suscriba a los mismos topics que el backend sin código adicional en el servidor.
Recomendaciones prácticas
- Si tienes dispositivos con batería: MQTT, sin discusión
- Si necesitas bidireccionalidad: MQTT
- Si envías datos cada pocos segundos: MQTT
- Si solo envías datos 1x al día con WiFi: HTTP está bien
- Si son archivos grandes: HTTP para los archivos, MQTT para la señalización
- Si no sabes qué elegir: MQTT. Es más versátil y no tendrás que migrar cuando los requisitos crezcan
Implementación con Soamee
En Soamee implementamos arquitecturas MQTT y AWS IoT para proyectos de IoT industrial. Si necesitas ayuda para elegir y diseñar la arquitectura de comunicación de tu proyecto IoT, agenda una consultoría gratuita.