MQTT over WebSocket和SSE（服务器发送事件）之间的区别

Question

When publish/subscribe to messages directly from a web server to a web browser or vice versa we can use MQTT over WebSockets. At the same time, SSE(half duplex) can be used to push data from web server to web browser. What are the other major differences? Especially related security and consistency of the application.

Answer 1

WebSocket is a low-level (framing) transport standardized by the IETF and a JavaScript API standardized by the W3C. It is not publish/subscribe. You can have publish/subscribe protocols that sit "on top" of WebSocket. For example, AMQP is a pub/sub protocol that can be implemented with WebSocket. Another example is Java Message Service (JMS); while JMS is an API and not a bit protocol, it can be implemented over a pub/sub protocol that, in turn, is implemented with WS. I mention both AMQP and JMS because both the AMQP protocol and the JMS API provide for "acknowledgements", which will give you a high degree of reliability unlike other mechanisms.

MQTT is a publish/subscribe protocol that can be implemented over a low-level transport. MQTT can run over TCP/IP or WebSocket for example. MQTT has QoS levels which also give you acknowledgements (ie, for reliability). MQTT is not normally native to a browser, so MQTT messages have to be made web-friendly before connecting to a browser... usually WebSocket, since WS is a 'fat pipe' and similar to TCP in a way.

Server-Sent Events (SSE) is a HTML5 formalization of "Comet" (or "reverse AJAX) techniques. "Comet" was a loose collection of informal techniques; different implementations did not work together. SSE is not publish/subscribe. It is an HTTP mechanism to broadcast data from a server to the browser client(s). Essentially its a fire-and-forget technique.

Most modern browsers understand SSE and WS (IE/EDGE does not currently support SSE); they usually all understand Secure WebSocket (WSS) too. Practically all webservers and appservers understand SSE and WS/WSS. If you use WSS, your data will be encrypted in transit. The particular encryption cipher is setup on the connection; you'll have to investigate what ciphers your browser clients and web/app-servers understand.

Answer 2

MQTT offers 3 different QOS levels that control delivery of messages

QOS 0 - Best effort QOS 1 - At least once QOS 2 - Once only

MQTT supports User authentication and topic level ACL so you can ensure users only see what they need to see even when using wildcard subscriptions

MQTT also allows for direct connection to the backend systems without the need for bridging in the WebApp