¿Cuáles son las ventajas de MQTT en comparación con el protocolo HTTP tradicional?

HTTP es el protocolo más utilizado y popular. Pero MQTT ha ganado terreno rápidamente en los últimos años. Cuando se habla del desarrollo de IoT, los desarrolladores deben elegir entre estos dos.

MQTT se centra en datos mientras que HTTP se centra en documentos. HTTP es un protocolo de solicitud-respuesta para computación cliente-servidor, que no siempre está optimizado para dispositivos móviles. En estos términos, las principales ventajas de MQTT son: peso ligero (MQTT transfiere datos en forma de matrices de bytes) y modelo de publicación/suscripción, lo que hace que MQTT sea muy adecuado para dispositivos con recursos limitados y ayuda a ahorrar batería. Además, el modelo de publicación/suscripción permite a los clientes ser independientes entre sí, aumentando así la confiabilidad del sistema general. En caso de falla del cliente, todo el sistema continúa funcionando normalmente.

Todavía hay muchas ventajas de MQTT, como las siguientes:

1. Baja sobrecarga de protocolo, MQTT es único porque su encabezado por mensaje puede ser tan corto como 2 bytes. Tanto MQ como HTTP tienen una sobrecarga por mensaje mucho mayor. Con HTTP, restablecer la conexión HTTP para cada nuevo mensaje de solicitud genera una sobrecarga significativa. Las conexiones persistentes utilizadas por MQ y MQTT reducen significativamente esta sobrecarga.

2. Tolerancia a redes inestables, MQTT y MQ pueden recuperarse de fallas como la desconexión y no hay ningún requisito de código adicional. Sin embargo, HTTP no puede hacer esto de forma nativa, lo que requiere que los clientes vuelvan a intentar la codificación, lo que puede aumentar los problemas de idempotencia.

3. Bajo consumo de energía, MQTT está especialmente diseñado para un bajo consumo de energía. HTTP no fue diseñado para tener esto en cuenta, lo que aumenta el consumo de energía.

4. Clientes con millones de conexiones, en la pila HTTP, mantener millones de conexiones simultáneas requiere mucho trabajo para brindar soporte. Si bien este soporte es posible, la mayoría de los productos comerciales están optimizados para manejar conexiones persistentes de este orden de magnitud. IBM ofrece IBM MessageSight, un único servidor de montaje en bastidor probado para manejar hasta 1 millón de dispositivos conectados simultáneamente a través de MQTT. Por el contrario, MQTT no está diseñado para una gran cantidad de clientes simultáneos.

5. Notificaciones push: debe poder enviar notificaciones a los clientes de manera oportuna. Para ello, se debe emplear algún tipo de encuesta o push periódico; push es la mejor solución desde la perspectiva de la batería, la carga del sistema y el ancho de banda.

Es posible que nuestra empresa necesite enviar información confidencial sin la intermediación de un tercero. Esto reduce el valor de las soluciones específicas del sistema operativo (como Apple iOS, notificaciones de Google Play) como mecanismo de transporte principal.

HTTP solo permite un método llamado COMET, que utiliza solicitudes HTTP persistentes para realizar envíos. Este enfoque es costoso tanto desde la perspectiva del cliente como del servidor. Tanto MQ como MQTT admiten el impulso como una característica fundamental de ellos.

6. Diferencias en la plataforma del cliente: tanto los clientes HTTP como MQTT se han implementado en una gran cantidad de plataformas. La simplicidad de MQTT ayuda a implementar MQTT en clientes adicionales con muy poco esfuerzo.

7. Tolerancia a fallas del firewall: algunos firewalls corporativos restringen las conexiones salientes a algunos puertos definidos. Estos puertos suelen estar restringidos a HTTP (puerto 80), HTTPS (puerto 443), etc. Obviamente, HTTP puede funcionar en estas situaciones. MQTT se puede incluir en una conexión WebSockets que aparece como una solicitud de actualización HTTP, lo que permite la operación en estos casos. MQTT no permite este patrón.

En comparación con HTTP, el protocolo MQTT garantiza una alta tasa de transferencia. Hay tres niveles de calidad del servicio:

R. Como máximo una vez: intente garantizar la entrega.

B. Al menos una vez: asegúrese de que el correo electrónico se envíe al menos una vez, pero el mensaje también se puede entregar más de una vez.

C. Solo una vez: asegúrese de que la otra parte reciba cada mensaje solo una vez.

De hecho, MQTT se usa ampliamente. Puede encontrar MQTT en casi cualquier gran empresa de hardware e Internet, como Facebook, BP, alibaba, baidu, etc.

Debido a las diversas ventajas técnicas del propio MQTT, cada vez más empresas tienden a elegir MQTT como protocolo estándar para la comunicación de productos de IoT. Por lo tanto, los ingenieros han descubierto gradualmente que el protocolo MQTT tiene algunas funciones que deben mejorarse si se quiere comercializar a gran escala. Por ejemplo:

1. No existe un SDK completo y diferentes terminales heterogéneos necesitan los paquetes de SDK de software correspondientes para comunicarse con el servidor MQTT. Por ejemplo, para lograr la interconexión entre MCU, Linux, Android, IOS, WEB, etc., se deben requerir diferentes paquetes SDK.

2. No se admiten archivos ni AV. En algunos escenarios de aplicación, la información que se transmitirá puede no limitarse a instrucciones, como señales de audio y señales de video, que deben comunicarse a través de archivos y AV.

3. No admite la integración con HTTP de terceros. Aunque el protocolo MQTT es superior al protocolo HTTP ordinario, los servidores WEB basados en el protocolo HTTP tradicional todavía ocupan el mercado principal, por lo que estos servidores m

Debemos realizar la interconexión con el protocolo MQTT para reducir el costo de las actualizaciones. El costo también es crítico.

4. No admite equilibrio de carga. Para evitar ataques maliciosos y de alta concurrencia, también es esencial un servidor de equilibrio de carga.

5. No es compatible con la interfaz de gestión de usuarios. Es particularmente importante que los usuarios analicen los datos de comportamiento de los dispositivos, lo cual es un requisito inevitable de la Industria 4.0 y la era del big data.

6. No admite mensajes sin conexión y compensa el problema de que el servidor MQTT pierde la información de control del dispositivo después de que el dispositivo está fuera de línea.

7. No se admite la comunicación punto a punto y se adopta el protocolo estándar MQTT. En teoría, la comunicación punto a punto se puede realizar mediante suscripción mutua, pero la lógica es relativamente complicada y existen preocupaciones sobre la seguridad del dispositivo. Cuando el dispositivo B y el dispositivo C están en el mismo tema, el dispositivo A no puede saber si es el dispositivo B o el dispositivo C el que envió el mensaje, y también es posible que el dispositivo D escuche el mensaje.

8. No admite la comunicación ni la gestión de grupos, realiza la gestión de los miembros del grupo y los miembros del grupo pueden comunicarse entre sí. En el escenario en el que un dispositivo está controlado por varias personas, o varios dispositivos están controlados por una persona, es especialmente útil.