一些中间件本身支持 websockets，例如 HiveMQ：http ://www.hivemq.com/mqtt-over-websockets-with-hivemq/ 。使用 websockets API 作为中间件的一流客户端，而不是通过支持语言特定 API 的中间服务器路由请求，例如
客户端 -> 中间件
对比
客户端 -> 服务器 -> 中间件
例如，我们可以争辩说跳过中间服务器会降低带宽成本，不需要开发人员编写额外的层，原生 SSL websockets 支持？
通过为中间件提供 websockets 支持，不仅可以为开发人员提供其他优势，还可以为任何一方提供哪些优势？
您获得的主要优势是简单性，在 HiveMQ 的情况下，可扩展性。
让我解释一下这些优点：
对于 HiveMQ，您只需启动服务器即可。所有通过 websockets 使用 MQTT 库的 Web 应用程序都可以连接到服务器，甚至不知道使用 websockets 作为传输。对于 HiveMQ 本身，它只是另一个 MQTT 客户端。因此，客户端是通过 websockets 连接还是通过经典 TCP 连接都没有关系。我认为您已经在问题中提到了其他论点。当然，最后但并非最不重要的一点是，如果运营人员有一个系统（在您的情况下是“服务器”）需要维护的少，他们会感谢您。
像 HiveMQ 这样的软件具有很强的可扩展性，它可以处理多达数十万个并发连接的客户端。机会很高，附加层（在您的情况下为“服务器”）可能会引入瓶颈。此外，如果您可以丢弃不需要的层，则使用硬件或软件负载平衡器进行负载平衡之类的事情会变得容易得多。一般来说，如果您不需要这些额外的层（这些层不是可以重用于其他应用程序的服务，例如微服务），您的系统架构会变得容易得多。
最后但同样重要的是，HiveMQ 本身通常与经典中间件/ESB 集成。这意味着，人们编写自定义插件来将 HiveMQ 集成到他们现有的中间件中。JMS 或 Web 服务调用（REST、SOAP）通常用于执行此操作。
由于我参与了 HiveMQ 的开发 :-)