MQTT vs HTTP: ¿qué protocolo es mejor para IoT?

Éste es un resumen de las principales diferencias entre MQTT y HTTP como protocolos de comunicación para Internet de las Cosas (IoT). Respuesta corta: MQTT es mejor para casi todas las aplicaciones IoT (Internet of Things). Lee el resto para averiguar qué significa esto en términos de arquitectura, complejidad, velocidad, fiabilidad y seguridad.

MQTT son las siglas de «Message Queue Telemetry Transport» y es un protocolo de publicación/suscripción (pub/sub). Se utiliza frecuentemente en comunicaciones máquina-a-máquina (M2M) debido a su eficiencia y bajo consumo.

Diferencias en la arquitectura

• MQTT se enfoca en la transmisión de datos a nivel de byte, mientras que HTTP en la transmisión de documentos.

• Por otra parte HTTP funciona como un modelo cliente-servidor (o petición-respuesta), mientras que MQTT funciona mediante publicaciones y suscripciones a un tema (modelo «pub/sub»), mediante un Broker (agente que gestiona las publicaciones y suscripciones).
• En MQTT se mantiene la conexión y se pueden compartir pings o latidos («heartbeats») para mantenerla abierta. HTTP sólo crea una conexión cuando se necesita enviar una petición.
• En este sentido HTTP establece una conexión TCP half-duplex, mientras que en MQTT es full-duplex.

¿Cuál es más sencillo y ligero?

• MQTT tiene una especificación muy liviana. Para los desarrolladores basta con conocer los tipos CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE y DISCONNECT. Por su parte HTTP es mucho más intrincado, aunque esto lo hace apto para aplicaciones que requieran mayor control de la comunicación.
• La cabecera más pequeña de MQTT sólo tiene 2 Bytes, mientras que la cabecera más pequeña de HTTP es de 26 Bytes.
• En cuanto a la carga (payload), MQTT es capaz de transportar datos crudos en binario, mientras que HTTP requiere una codificación en base 64.
• El aplicaciones industriales, el protocolo MQTT permite propagar configuraciones nuevas de los dispositivos mediante suscripciones. En HTTP las configuraciones nuevas deben solicitarse explícitamente mediante un sondeo periódico (polling): «Dispositivo IoT: Servidor, ¿tienes ya alguna configuración nueva para mí?«

Velocidad: ¿Cuál es más rápido?

• MQTT es más rápido y más eficiente que HTTP:
  • En redes 3G es 93 veces más rápido, usa 8 veces menos tráfico y gasta 170 veces menos energía en los receptores.
  • En otros escenarios como este test de performance MQTT fue al menos 20 veces más rápido, usa 50 veces menos tráfico y energéticamente un 22% más eficiente.

QoS: ¿Cuál es más fiable?

HTTP no implementa por sí mismo calidad de servicio (QoS). En cambio, MQTT puede establecer tres diferentes niveles QoS:

• QoS 0 – at most once: sólo realiza una entrega «best effort», sin garantías frente a fallos. Opción por defecto.
• QoS 1 – at least once: el mensaje será entregado como mínimo una vez y puede proteger frente a pérdidas de conexión (aunque pueden llegar duplicados). Utiliza ACKs (confirmaciones de entrega).
• QoS 2 – exactly once: garantiza que cada mensaje se reciba por la parte receptora sin duplicados.

Esto es importante para garantizar la entrega de confirmaciones después de hacer una actualización remota de un dispositivo. Por ejemplo Google IoT Cloud garantiza con QoS1 el upgrade de la configuración de los dispositivos suscritos.

Especial en MQTT: «Última Voluntad» y Retención de mensajes

• MQTT ofrece además las funciones última voluntad (Last will & Testament, LWT): en caso de una desconexión repentina de un cliente, todos los demás clientes suscritos a ese topic recibirán una notificación por parte del broker.

• Por otra parte la Retención de mensajes permite que un cliente recién suscrito a un tema conseguirá una actualización de estado inmediata sobre el resto de clientes.

• HTTP carece de las funcionalidaes testamento y retención de mensajes.

¿Cuál es más seguro?

• En MQTT la autenticación se puede realizar mediante identificador de cliente, usuario/contraseña o certificados x509.
• Tanto MQTT como HTTP pueden operar sobre TLS ó SSL, ya que esto forma parte del protocolo TCP/IP.
• El broker MQTT puede controlar quién se suscribe y quién publica en qué topics.
• Al igual que los servidores web, los brokers y bridges MQTT soportan autorización mediante JWT (JSON Web Token).
• En este sentido los dos protocolos son igualmente seguros en combinación con SSL y JWT. Y viceversa: HTTP y MQTT son igual de inseguros si no se toma ninguna medida.
• Sin embargo, MQTT puede tener más problemas para pasar a través de los cortafuegos, ya que sus puertos no suelen estar tan aceptados como los de HTTP.
  • Aunque no es lo ideal, si fuera necesario MQTT se podría implementar sobre WebSockets (puerto 80).

Si os interesa el tema de seguridad en IoT háganoslo saber en los comentarios y publicaremos un tutorial más extenso 🙂

Conclusiones

MQTT está mucho más optimizado que HTTP en cuanto a tiempos de respuesta, throughput, consumo de batería y ancho de banda.

HTTP derrocha más energía y capacidad. Pero es un viejo conocido y puede ser más fácil de implementar con respecto a sistemas antiguos que todavía usen HTTP. También es idóneo para enviar bloques grandes de datos de una sentada.

Otra diferencia importante a tener en cuenta es la posibilidad de implementar QoS y las funciones especiales de MQTT: última voluntad y retención de mensajes.

Por tanto MQTT es mejor para casi todas las aplicaciones de Internet de las Cosas (IoT), pero si estás empezando y no sabes cuál elegir, implementa HTTP y cambia a MQTT cuando lo necesites.

En próximos tutoriales describiremos algunos ejemplos de implementación usando NodeMCU y el broker Mosquitto. Asegúrate de suscribirte!