Protocolos IoT: MQTT, CoAP y HTTP para comunicación IoT

Conoce los principales protocolos IoT y compara MQTT, CoAP y HTTP según comunicación, transporte, recursos y casos de uso.

Los protocolos IoT permiten que dispositivos, gateways, plataformas y aplicaciones intercambien información siguiendo reglas que cada componente de la arquitectura puede interpretar.

En un proyecto de Internet de las Cosas no basta con seleccionar sensores, microcontroladores o tecnologías de conectividad. También es necesario definir cómo se enviarán los datos, cómo se recibirán respuestas, qué nivel de confiabilidad necesita cada mensaje y cómo se integrará la información con otros sistemas.

MQTT, CoAP y HTTP son tres protocolos IoT utilizados en distintos escenarios, pero no funcionan de la misma manera ni responden a los mismos requerimientos.

La elección puede depender de factores como:

• recursos disponibles en el dispositivo;
• frecuencia de comunicación;
• tamaño de los mensajes;
• necesidad de recibir comandos;
• condiciones de la red;
• integración con APIs;
• consumo energético;
• requisitos de entrega;
• arquitectura general del proyecto.

No existe un protocolo universalmente superior. Lo importante es elegir el mecanismo de comunicación adecuado para cada capa y necesidad de la solución.

¿Qué son los protocolos IoT?

Los protocolos IoT son conjuntos de reglas que permiten estructurar e intercambiar información entre diferentes componentes de una solución conectada.

Por ejemplo, un sensor puede medir temperatura, presión, caudal o corriente eléctrica, pero todavía debe definirse cómo esa lectura llegará a un gateway, servidor o plataforma.

Una arquitectura simplificada puede representarse así:

sensor → red → gateway → protocolo de aplicación → plataforma → sistema externo

También es importante diferenciar entre conectividad y protocolo de aplicación.

• Wi-Fi, Ethernet, redes celulares o LoRaWAN proporcionan diferentes mecanismos para transportar información.
• MQTT, CoAP y HTTP, en cambio, definen cómo las aplicaciones intercambian datos utilizando esa infraestructura.

Por esta razón, no sería correcto comparar directamente MQTT con LoRaWAN como si fueran tecnologías equivalentes: cumplen funciones distintas dentro de la arquitectura.

Si necesitas revisar primero las alternativas de conectividad, consulta nuestra guía sobre tecnologías inalámbricas IoT.

Protocolos de comunicación IoT: ¿qué debemos comparar?

Al evaluar protocolos de comunicación IoT, no conviene analizar únicamente cuánto ocupa cada mensaje. Existen varios criterios que pueden afectar el comportamiento final de la solución.

Modelo de comunicación

• Algunos protocolos trabajan principalmente mediante petición y respuesta, mientras otros utilizan modelos de publicación y suscripción.
• La elección afecta la manera en que los dispositivos, servidores y aplicaciones intercambian información.

Transporte

• Dependiendo del protocolo y de su implementación, la comunicación puede utilizar TCP, UDP u otros mecanismos de transporte.
• Esto influye en la forma en que se gestionan conexiones, entrega, orden, retransmisiones y otros aspectos de la comunicación.

Sobrecarga

• Los encabezados, confirmaciones, establecimiento de conexiones y mecanismos de seguridad aumentan la cantidad total de información transmitida.
• Esto puede ser especialmente relevante cuando existen dispositivos con recursos limitados o comunicaciones frecuentes con payloads pequeños.

Confiabilidad

• No todos los datos necesitan el mismo nivel de garantía.
• Una medición periódica puede tolerar la pérdida ocasional de una lectura, mientras que una alarma o evento importante puede necesitar confirmación.

Recursos del dispositivo

• Memoria, capacidad de procesamiento, batería y conectividad disponible pueden limitar qué protocolos IoT resultan adecuados.

Integración

• También debe evaluarse qué protocolos acepta la plataforma, gateway, API o sistema empresarial al que finalmente llegarán los datos.

MQTT en IoT

MQTT utiliza un modelo publish/subscribe.

En lugar de enviar directamente cada mensaje a un consumidor específico, los clientes normalmente se conectan a un servidor denominado broker.

La estructura básica puede representarse así:

publisher → broker → subscriber

Por ejemplo, un dispositivo puede publicar una medición en:

fabrica/linea1/motor2/temperatura

Las aplicaciones autorizadas que estén suscritas a ese topic podrán recibir la información.

MQTT está estandarizado por OASIS y utiliza un modelo de mensajería ligero que puede aplicarse en entornos M2M e IoT.

• Broker: Administra conexiones, suscripciones y distribución de mensajes entre los diferentes clientes.
• Topics: permiten organizar la información de manera jerárquica.

Una instalación puede utilizar estructuras diferentes para áreas, máquinas, variables o ubicaciones.

Publish/Subscribe

Este modelo permite desacoplar al productor de la información de quienes consumen los datos.

El dispositivo que publica una lectura no necesita conocer directamente qué aplicaciones terminarán utilizándola.

QoS en MQTT

MQTT establece tres niveles de Quality of Service:

• QoS 0: at most once;
• QoS 1: at least once;
• QoS 2: exactly once dentro del flujo definido por MQTT.

Estos niveles permiten ajustar el intercambio adicional y los mecanismos de entrega según la importancia del mensaje y las necesidades de la aplicación.

¿Cuándo puede utilizarse MQTT?

MQTT puede resultar adecuado para:

• telemetría frecuente;
• múltiples sensores;
• dashboards;
• alarmas;
• distribución de eventos;
• comunicación entre gateways y plataformas;
• sistemas donde varios consumidores necesitan recibir los mismos datos.

Esto no significa que MQTT sea automáticamente el mejor de los protocolos IoT para cualquier proyecto. Su implementación requiere una arquitectura de mensajería y un broker que también deben configurarse, protegerse, administrarse y monitorearse.

Para profundizar específicamente en las diferencias entre MQTT y HTTP, consulta nuestra guía sobre MQTT vs HTTP.

CoAP: protocolo para dispositivos y redes restringidas

CoAP —Constrained Application Protocol— fue diseñado específicamente para nodos y redes con recursos limitados.

La especificación RFC 7252 lo define como un protocolo especializado de transferencia web para dispositivos restringidos y redes de bajo consumo o con pérdidas.

CoAP mantiene conceptos familiares de la Web como:

• recursos;
• URI;
• GET;
• POST;
• PUT;
• DELETE.

Su versión base utiliza principalmente UDP y contempla mecanismos adaptados a entornos IoT restringidos.

CoAP no significa simplemente “UDP sin confiabilidad”

Aunque UDP no proporciona por sí mismo las mismas garantías de entrega que TCP, CoAP incorpora mecanismos propios de mensajería.

Puede trabajar, por ejemplo, con:

• Confirmable (CON)
• Non-confirmable (NON)

Los mensajes confirmables permiten utilizar reconocimientos y retransmisiones cuando corresponda. Por eso no sería correcto resumir CoAP como un protocolo en el que “si el paquete se pierde, se pierde”.

El comportamiento dependerá del tipo de mensaje y de las necesidades de la aplicación.

CoAP Observe

CoAP también dispone de un mecanismo denominado Observe.

Con este mecanismo, un cliente puede registrar interés sobre un recurso y recibir actualizaciones cuando su estado cambia, evitando tener que ejecutar constantemente nuevas solicitudes GET.

Esto hace que CoAP no deba interpretarse simplemente como un “HTTP más pequeño”. Incorpora mecanismos específicos para determinados escenarios de comunicación restringida.

CoAP vs MQTT: diferencias principales

La comparación CoAP vs MQTT es especialmente relevante porque ambos pueden utilizarse en soluciones IoT, pero siguen modelos de comunicación diferentes.

1. MQTT

Trabaja principalmente mediante:

publisher → broker → subscribers

El broker desempeña un papel central en la distribución de mensajes.

2. CoAP

Mantiene una arquitectura orientada a recursos:

cliente → recurso en servidor CoAP

y utiliza conceptos similares a los encontrados en arquitecturas REST.

3. Modelo de comunicación

MQTT resulta natural cuando múltiples productores y consumidores necesitan intercambiar eventos mediante topics.

CoAP puede resultar adecuado cuando un dispositivo o servicio expone recursos que deben consultarse o modificarse mediante una interfaz compacta orientada a recursos.

4. Transporte

MQTT normalmente utiliza un transporte que proporciona un flujo de bytes ordenado y confiable. TCP es una opción habitual.

El CoAP base está diseñado principalmente alrededor de UDP, aunque existen extensiones para otros transportes.

5. Arquitectura

MQTT generalmente requiere un broker.

CoAP puede permitir interacción directa entre endpoints y también utilizar proxies.

CoAP vs MQTT: ¿cuál consume menos?

No existe una respuesta válida para todos los proyectos.

CoAP fue diseñado para nodos y redes restringidas y utiliza una estructura compacta.

MQTT también es ligero y puede mantener conexiones persistentes que resultan convenientes para determinadas aplicaciones.

El consumo final depende además de factores como:

• tecnología de radio;
• frecuencia de transmisión;
• tiempo activo del dispositivo;
• número de reintentos;
• mecanismos de seguridad;
• tamaño del payload;
• calidad de señal;
• comportamiento de la aplicación.

Por eso no conviene seleccionar CoAP simplemente porque supuestamente “consume menos batería”, ni MQTT porque se considere automáticamente “más confiable”.

Los protocolos IoT deben evaluarse dentro del comportamiento completo del sistema.

CoAP vs MQTT: ¿cuándo considerar cada uno?

MQTT puede tener sentido cuando:

• existen múltiples productores y consumidores;
• se necesita organizar información mediante topics;
• la arquitectura dispone de un broker;
• los dispositivos publican telemetría con frecuencia;
• varios sistemas necesitan recibir el mismo evento.

CoAP puede tener sentido cuando:

• existen dispositivos con recursos restringidos;
• la comunicación está orientada a recursos;
• se necesita un modelo REST compacto;
• el entorno requiere comunicaciones ligeras;
• se necesita descubrimiento de recursos.

No son tecnologías que necesariamente deban excluirse entre sí. En determinadas arquitecturas pueden coexistir.

HTTP dentro de una arquitectura IoT

Además de MQTT y CoAP, HTTP también puede formar parte de una arquitectura IoT, especialmente cuando los dispositivos, gateways o plataformas necesitan intercambiar información con APIs, servicios Cloud o sistemas empresariales.

Su modelo se basa principalmente en request/response: un cliente realiza una solicitud y un servidor devuelve una respuesta.

En proyectos IoT puede resultar conveniente cuando ya existe infraestructura HTTP/HTTPS o cuando la prioridad es facilitar la integración con aplicaciones web, ERP u otros sistemas. La elección dependerá de los recursos disponibles, frecuencia de comunicación, tamaño de los mensajes y características de la arquitectura.

Esta guía no profundiza en las diferencias entre MQTT y HTTP, ya que esa comparación se desarrolla específicamente en nuestro artículo sobre MQTT vs HTTP.

CoAP vs HTTP

La comparación CoAP vs HTTP resulta relevante porque ambos utilizan un paradigma orientado a recursos y comparten conceptos como:

• URI;
• GET;
• POST;
• PUT;
• DELETE;
• request/response.

Sin embargo, fueron diseñados considerando contextos diferentes.

HTTP es utilizado ampliamente en sistemas web de propósito general, mientras CoAP está específicamente orientado a nodos y redes restringidas.

Por eso CoAP utiliza una representación más compacta y mecanismos adaptados a escenarios donde la capacidad de procesamiento, comunicación o energía puede ser limitada.

¿Cuándo considerar HTTP en lugar de CoAP?

HTTP puede ser conveniente cuando:

• existe una API REST consolidada;
• la integración web es prioritaria;
• los dispositivos cuentan con recursos suficientes;
• el entorno ya utiliza infraestructura HTTP/HTTPS;
• las restricciones de tráfico y procesamiento no son críticas.

CoAP puede resultar más adecuado cuando las limitaciones del dispositivo o de la red son considerablemente mayores.

MQTT vs HTTP dentro de los protocolos IoT

MQTT y HTTP también forman parte de los protocolos de comunicación IoT, pero esta guía no necesita repetir toda la comparación existente entre ambos.

En términos generales:

• MQTT → publish/subscribe mediante broker
• HTTP → request/response orientado a recursos y APIs

Si la decisión de tu proyecto se encuentra específicamente entre estas dos alternativas, consulta la guía especializada sobre MQTT vs HTTP.

De esta manera mantenemos claramente separada la intención de ambas páginas.

TCP y UDP: ¿por qué importan en los protocolos IoT?

TCP y UDP pertenecen a una capa diferente a MQTT, CoAP y HTTP, pero influyen directamente en el comportamiento de las comunicaciones.

TCP

• TCP proporciona un flujo de información ordenado y confiable.
• MQTT utiliza habitualmente TCP.

UDP

• UDP utiliza una estructura más simple y no incorpora por sí mismo las mismas garantías de entrega y orden que TCP.
• CoAP base utiliza UDP, pero añade mecanismos propios para confirmación, retransmisión y correlación cuando son necesarios.

Por eso no debería concluirse que TCP es siempre mejor por ofrecer confiabilidad o que UDP es automáticamente superior porque utiliza una estructura más ligera. La elección depende del protocolo, arquitectura y aplicación.

Tabla comparativa: MQTT vs CoAP vs HTTP

Esta tabla funciona como orientación general. El comportamiento final depende de la versión utilizada, implementación, mecanismos de seguridad, infraestructura y requerimientos de cada proyecto.

¿Qué protocolo IoT elegir?

No existe una respuesta única. Antes de comparar protocolos IoT, conviene responder algunas preguntas sobre el comportamiento esperado de la solución.

1. ¿El sistema necesita publish/subscribe?

Cuando múltiples aplicaciones necesitan recibir eventos producidos por dispositivos, MQTT puede resultar una alternativa natural.

2. ¿El dispositivo expone recursos en un entorno restringido?

CoAP puede ser una alternativa adecuada cuando se necesita trabajar con recursos utilizando un modelo compacto.

3. ¿La prioridad es integrar APIs o servicios web existentes?

HTTP puede simplificar considerablemente esa integración.

¿Qué limitaciones tiene la red?

Es necesario evaluar:

• tamaño de los mensajes;
• frecuencia de transmisión;
• disponibilidad;
• reintentos;
• latencia;
• calidad de señal.

¿Se necesitan confirmaciones?

MQTT y CoAP proporcionan mecanismos diferentes para abordar requisitos de entrega y confiabilidad.

¿Los dispositivos necesitan recibir información?

También debe analizarse cómo se enviarán comandos, cambios de configuración u otras instrucciones desde el servidor o plataforma. La elección de los protocolos IoT debe considerar todos estos factores en conjunto.

No siempre hay que elegir un único protocolo

Una arquitectura IoT puede utilizar diferentes protocolos en distintas etapas.

Por ejemplo:

• dispositivo restringido → CoAP → gateway

Después:

• gateway → MQTT → plataforma IoT

Y finalmente:

• plataforma → HTTP/REST → ERP o aplicación empresarial

En esta arquitectura, cada protocolo resuelve una necesidad concreta.

Utilizar diferentes protocolos IoT según la capa puede resultar más coherente que intentar que todos los componentes de la solución utilicen exactamente el mismo mecanismo de comunicación.

Protocolos IoT dentro de una arquitectura industrial

En una operación industrial pueden existir todavía más capas de comunicación.

Un ejemplo sería:

• sensor → Modbus → gateway → MQTT → plataforma → HTTP API → ERP

Aquí Modbus cumple una función diferente a MQTT y HTTP.

El protocolo utilizado para leer una máquina, medidor o instrumento no necesariamente debe ser el mismo que transporta la información hacia una plataforma. Por eso los protocolos IoT deben analizarse dentro de la arquitectura completa y no de manera aislada.

Relación entre protocolos IoT y plataforma IoT

Una plataforma puede recibir información mediante MQTT, HTTP, CoAP u otros mecanismos compatibles con la arquitectura.

Posteriormente puede utilizar esos datos para:

• almacenar históricos;
• generar alertas;
• mostrar dashboards;
• calcular indicadores;
• ejecutar reglas;
• identificar desviaciones;
• intercambiar información con otros sistemas.

El protocolo se encarga principalmente del intercambio de información. La plataforma se encarga de almacenar, procesar, visualizar y utilizar esos datos.

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

Seguridad en los protocolos de comunicación IoT

La seguridad no depende únicamente del nombre del protocolo elegido.

Una implementación debe evaluar aspectos como:

• autenticación;
• autorización;
• cifrado;
• certificados y credenciales;
• actualización de firmware;
• protección de brokers;
• protección de APIs;
• permisos de acceso;
• segmentación de red.

MQTT puede trabajar utilizando TLS.

HTTP puede proteger la comunicación mediante HTTPS.

CoAP dispone de mecanismos de seguridad adaptados a diferentes escenarios restringidos.

Por lo tanto, ninguno de estos protocolos IoT debería clasificarse simplemente como “seguro” o “inseguro” sin analizar la implementación completa.

Protocolos IoT: MQTT, CoAP o HTTP

MQTT, CoAP y HTTP pueden formar parte de una arquitectura IoT correctamente diseñada.

• MQTT resulta especialmente útil para modelos publish/subscribe, telemetría y distribución de eventos mediante brokers.
• CoAP está orientado a dispositivos y redes restringidas y mantiene un modelo ligero basado en recursos.
• HTTP sigue siendo una alternativa importante para APIs, servicios web, Cloud e integración con sistemas empresariales.

La elección de los protocolos IoT debe considerar los recursos del dispositivo, modelo de comunicación, conectividad disponible, seguridad, integración y comportamiento esperado de los datos.

En Smelpro desarrollamos soluciones IoT industriales integrando sensores, gateways, conectividad, protocolos IoT y plataformas de acuerdo con los requerimientos técnicos de cada operación.