【发布时间】：2015-08-17 22:43:03
【问题描述】：
MQTT over WebSocket与直接 MQTT 相比有哪些优点？
我正在考虑在我的项目中使用 MQTT，所以我想知道为什么有些人选择 MQTT 而不是 WebSocket 而不是直接的 MQTT。
【问题讨论】：
【发布时间】：2015-08-17 22:43:03
【问题描述】：
MQTT 是一个支持以下协议的协议：
- 提供发布/订阅机制
- 服务质量政策
- 通信开销最小
- 专为窄带通信信道和
受限设备。
根据设备，有一个可用的实现。
浏览器：它使用 websockets。 Websocket 为浏览器提供了建立全双工通信的能力。有实现MQTT功能的Javascript库，见Eclipse Paho JavaScript Client
Android : 他们是一个用 Java 编写的 MQTT 客户端库，用于在 Android 上开发应用程序。见Eclipse Paho Android Service
所以这取决于要使用此功能的设备。标准和规范请访问MQTT Version 5.0
希望这会有所帮助。
干杯！
【讨论】：
如果您打算直接从 webapps（在页面中）发布/订阅消息，您应该只需要在 websockets 上运行 MQTT。
基本上，我会为所有内容运行纯 MQTT，并且仅在您真正需要时才添加 websocket。
对于所有非浏览器语言，MQTT 客户端库仅使用本机 MQTT。对于 Javascript，有一个纯 MQTT 库和使用 websockets 的页面库中的 Paho。
编辑： 防火墙隧道用例是在 websockets 上使用 MQTT 的正当理由，并且自从编写此答案以来，更多的非 web/JavaScript 客户端库增加了支持
【讨论】：
-
user5762813 和 Vasif 概述的企业防火墙案例实际上在许多环境中都非常重要。我希望我的设备能够连接到代理，即使它们只能通过 HTTP 代理访问互联网。
MQTT 代理：
MQTT 客户端的对应物是 MQTT 代理。代理是任何发布/订阅协议的核心。根据实现的不同，代理可以处理多达数千个同时连接的 MQTT 客户端。
MQTT 客户端： 当我们谈论客户端时，我们几乎总是指 MQTT 客户端。发布者和订阅者都是 MQTT 客户端。发布者和订阅者标签是指客户端当前是发布消息还是订阅消息（发布和订阅功能也可以在同一个 MQTT 客户端中实现）。
WebSocket： 我们在 MQTT Essentials 中了解到，MQTT 是受限设备和不可靠网络的理想选择。它也非常适合以非常低的开销发送消息。直接在手机浏览器中或者一般情况下发送和接收 MQTT 消息会很不错。这可以通过 MQTT over WebSockets 实现。
您可以使用第三方协议。 PAHO、EMQTT、VerneMQ。
【讨论】：
如果某个网页是发送或接收 MQTT 客户端，则基于 websockets 的 MQTT 是完美的。
可以在here 上找到有关 MQTT over websockets 功能的一个很好的总结。
【讨论】：
如果应用程序在仅允许 443 和 80 流量的防火墙后面运行，则基于 Web 套接字的 MQTT 也很有帮助。而且，您无法控制防火墙的策略。
【讨论】：
-
MQTT 没有什么可以阻止您使用 443 或 80，或者如果您正在使用 TLS/DTLS（加密），您会遇到什么。我猜防火墙理论上可以阻止端口 80 上的非 HTTP 流量，但如果您使用 TLS，它不会知道它是 HTTP，而且很少有情况是您不想使用 TLS 来保护连接的设备跨度>
使用 MQTT over Websockets 的两个主要原因（这实际上意味着通过 HTTP/HTTPS）：
- Web 应用程序（在浏览器中运行的应用程序 - 例如用 JavaScript 编写的）
- 任何其他不想使用 1883/8883 端口并希望通过 HTTP/HTTPS 代替的应用程序 - 这可能是为了减少被防火墙阻止的机会（例如在公司网络），因为大多数防火墙都会允许 HTTP 流量通过
如果您不需要或担心以上问题，请使用“直接”MQTT：
- 效率更高
- 有更多适用于“直接”MQTT 的各种语言的客户端库
【讨论】：
-
说“这实际上意味着通过 HTTP/HTTPS”并不完全正确。 Websockets 是有利的，因为它们根本不使用 HTTP/HTTPS 和隐含的开销。通读一遍（HTML5 WebSocket：Web 可扩展性的巨大飞跃）[websocket.org/quantum.html] 了解所有详细信息。