HTTP es el protocolo más utilizado y popular. Pero MQTT ha ganado terreno rápidamente en los últimos años. Al discutir el desarrollo de IoT, los desarrolladores deben elegir entre estos dos.
MQTT se enfoca en los datos mientras que HTTP se enfoca en los documentos. HTTP es un protocolo de solicitud-respuesta para la informática 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 que los clientes sean independientes entre sí, lo que aumenta la confiabilidad del sistema en general. En caso de falla del cliente, todo el sistema continúa funcionando normalmente.
Todavía hay muchas ventajas de MQTT, como sigue:
1. Sobrecarga de protocolo baja, MQTT es único en el sentido de que su encabezado por mensaje puede ser tan corto como 2 bytes. Tanto MQ como HTTP tienen una sobrecarga por mensaje mucho mayor. Para 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 más requisitos de código. 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 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 servidor de montaje en bastidor único 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 automáticas, debe poder enviar notificaciones a los clientes de manera oportuna. Para esto, se debe emplear algún tipo de sondeo periódico o impulso; el impulso 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 usa solicitudes HTTP persistentes para realizar inserciones. Este enfoque es costoso tanto desde la perspectiva del cliente como del servidor. Tanto MQ como MQTT admiten push como una característica fundamental de ellos.
6. Diferencias en la plataforma del cliente, tanto los clientes HTTP como los 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 envolver en una conexión WebSockets, apareciendo 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 de servicio:
A. 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 es ampliamente utilizado. 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 de MQTT en sí mismo, cada vez más empresas tienden a elegir MQTT como el 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 que sea comercializado a gran escala. Por ejemplo:
1. No existe un SDK completo, y diferentes terminales heterogéneos necesitan paquetes 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, es posible que la información que se transmite no se limite 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 aún ocupan el mercado principal, por lo que estos servidores deben realizar la interconexión con el MQTT. El protocolo para reducir las actualizaciones El costo también es fundamental.
4. No es compatible con el balanceo de carga Para evitar una alta concurrencia y ataques maliciosos, también es esencial un servidor de balanceo de carga.
5. No es compatible con la interfaz de administración de usuarios. Es particularmente importante que los usuarios analicen los datos de comportamiento del dispositivo, lo cual es un requisito inevitable de la Industria 4.0 y la era de los grandes datos.
6. No admite mensajes fuera de línea 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 MQTT estándar. En teoría, la comunicación punto a punto se puede realizar a través de una 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 es compatible con la comunicación grupal y la administración grupal, y realiza la administración de los miembros del grupo, y los miembros del grupo pueden comunicarse entre sí. En el escenario donde un dispositivo es controlado por varias personas, o múltiples dispositivos son controlados por una persona, Especialmente útil