¿Cuál es la diferencia entre MQTT y Websocket?
MQTT poco tiene que ver con WebSocket. No están al mismo nivel.
¿WebSocket? Muchos sitios web utilizan encuestas para implementar tecnología push. El sondeo se produce cuando el navegador envía una solicitud HTTP al servidor en un intervalo de tiempo específico (como 1 segundo) y luego el servidor devuelve los datos más recientes al navegador. Las desventajas del sondeo son obvias: el navegador necesita enviar solicitudes al servidor continuamente, pero el encabezado de la solicitud HTTP es muy largo y los datos reales transmitidos pueden ser muy pequeños, lo que provoca un desperdicio de ancho de banda y recursos del servidor.
Comet utiliza AJAX para mejorar las encuestas y puede lograr una comunicación bidireccional. Pero Comet todavía necesita realizar solicitudes, y en Comet se utilizan comúnmente enlaces largos, lo que también consume mucho ancho de banda y recursos del servidor.
Como resultado, surgió el protocolo WebSocket. El navegador envía una solicitud al servidor para establecer una conexión WebSocket a través de JavaScript. Una vez establecida la conexión, el cliente y el servidor intercambian datos directamente a través de la conexión TCP. Una conexión WebSocket es esencialmente una conexión TCP.
WebSocket tiene grandes ventajas de rendimiento en términos de estabilidad de transmisión de datos y volumen de transmisión de datos. Websocket.org comparó las ventajas de rendimiento del sondeo y WebSocket:
El sondeo HTTP debe devolver 871 bytes cada vez, y websocket solo necesita 2 bytes cada vez
Caso de uso A: 1000 clientes recibir un mensaje por segundo, rendimiento de la red (2*1000) = 2000 bytes = 16 000 bits por segundo
Caso de uso B: 10 000 El cliente recibe un mensaje por segundo, rendimiento de la red (2*10 000) = 20 000 bytes = 160.000 bits por segundo
Caso de uso C: 100.000 clientes reciben por segundo un mensaje, rendimiento de la red (2*100.000) = 200.000 bytes = 1.600.000 bits por segundo
El protocolo MQTT está diseñado para una gran cantidad de computadoras con potencia informática limitada y funciona con ancho de banda bajo y ancho de banda bajo. Un protocolo diseñado para una comunicación de red confiable de sensores remotos y dispositivos de control. Tiene las siguientes características principales:
. Gastos generales de comunicación muy pequeños (el tamaño mínimo del mensaje es de 2 bytes), transmisión pequeña. La sobrecarga es pequeña (el encabezado de longitud fija es de 2 bytes) y la conmutación de protocolo se minimiza para reducir el tráfico de la red.
Un cliente fácil de usar que admite varios lenguajes de programación populares (incluidos C, Java, Ruby, Python, etc.
Utiliza el modelo de mensajería de publicación/suscripción); para proporcionar publicación de mensajes uno a muchos para desacoplar aplicaciones.
Transmisión de mensajes con contenido de carga útil enmascarado.
Proporciona conectividad de red mediante TCP/IP.
Existen tres tipos de calidad del servicio de publicación de mensajes, que permiten que los mensajes lleguen a sus destinos bajo demanda y se adapten a las necesidades de transmisión de redes inestables:
"Como máximo una vez", mensaje La publicación depende completamente de la red TCP/IP de la capa subyacente. Puede producirse pérdida o duplicación de mensajes. Este nivel se puede utilizar en situaciones en las que, para datos de sensores ambientales, no importa si se pierde un registro de lectura porque pronto se enviará un segundo.
"Al menos una vez" garantiza que el mensaje llegue, pero es posible que se duplique el mensaje.
"Sólo una vez" garantiza que el mensaje llegue una vez. Este nivel se puede utilizar en situaciones en las que la duplicación o pérdida de mensajes puede generar resultados incorrectos en un sistema de facturación.