当直接从Web服务器向Web浏览器发布/订阅消息时，反之亦然，我们可以在WebSockets上使用MQTT。同时，SSE（半双工）可用于将数据从Web服务器推送到Web浏览器。其他主要差异是什么？特别是应用程序的安全性和一致性。
答案 0 :(得分：4)
WebSocket是由IETF标准化的低级（框架）传输和由W3C标准化的JavaScript API。它不是发布/订阅。您可以拥有位于WebSocket“顶部”的发布/订阅协议。例如，AMQP是可以使用WebSocket实现的发布/订阅协议。另一个例子是Java消息服务（JMS）;虽然JMS是API而不是位协议，但它可以通过pub / sub协议实现，而pub / sub协议又通过WS实现。我提到了AMQP和JMS，因为AMQP协议和JMS API都提供了“确认”，与其他机制不同，它将为您提供高度的可靠性。
MQTT是一种发布/订阅协议，可以通过低级传输实现。例如，MQTT可以在TCP / IP或WebSocket上运行。 MQTT具有QoS级别，也可以为您提供确认（即可靠性）。 MQTT通常不是浏览器的原生，因此MQTT消息在连接到浏览器之前必须是Web友好的...通常是WebSocket，因为WS在某种程度上是一个“胖管”并且类似于TCP。
服务器发送事件（SSE）是“Comet”（或“反向AJAX”）技术的HTML5形式化。“Comet”是非正式技术的松散集合;不同的实现不能一起工作.SSE不是发布/订阅它是一种HTTP服务器，用于将数据从服务器广播到浏览器客户端。基本上它是一种即发即弃的技术。
大多数现代浏览器都了解SSE和WS（IE / EDGE目前不支持SSE）;他们通常都了解Secure WebSocket（WSS）。实际上，所有Web服务器和应用程序服务器都了解SSE和WS / WSS。如果您使用WSS，您的数据将在传输过程中加密。在连接上设置特定的加密密码;您将不得不调查您的浏览器客户端和Web /应用服务器所了解的密码。
答案 1 :(得分：2)
MQTT提供3种不同的QOS级别来控制消息的传递
QOS 0 - 尽力而为 QOS 1 - 至少一次 QOS 2 - 仅一次
MQTT支持用户身份验证和主题级ACL，因此您可以确保用户只看到他们在使用通配符订阅时需要查看的内容
MQTT还允许直接连接到后端系统，而无需在WebApp中进行桥接