一些中间件本身支持websockets，例如HiveMQ: http://www.hivemq.com/mqtt-over-websockets-with-hivemq/。使用websockets API作为中间件的第一类客户端，而不是通过支持特定语言API的中间服务器来路由请求，对开发人员有什么好处?
Client -> Middleware
和
客户端->服务器->中间件
例如，我们可以争辩说跳过中间服务器会减少带宽成本，不需要开发人员编写额外的层，本地SSL websockets支持?
通过为中间件提供websockets支持，除了开发人员，还可以为任何一方提供哪些其他优势?
您获得的主要优势是简单性和在HiveMQ的情况下，可伸缩性。
让我解释一下这些优点:
简单在HiveMQ的情况下，您只需启动服务器，就可以开始了。所有通过websockets使用MQTT库的web应用程序都可以连接到服务器，甚至不知道使用了websockets作为传输。对于HiveMQ本身，它只是另一个MQTT客户机。因此，无论客户端是通过websockets连接还是通过经典TCP连接都无关紧要。我想你已经在你的问题中提到了其他的论点。当然，最后但并非最不重要的是，如果运营人员可以少维护一个系统(在您的情况下是"服务器")，他们会感谢您的。
像HiveMQ这样的软件是非常可扩展的，它可以处理多达数十万并发连接的客户端。附加层(在您的示例中是"服务器")很有可能引入瓶颈。此外，如果您可以丢弃不需要的层，那么使用硬件或软件负载平衡器进行负载平衡会变得容易得多。一般来说，如果你不需要这些额外的层(它们是而不是服务，它们可以被其他应用程序重用，就像微服务一样)，你的系统架构会变得容易得多。
最后但并非最不重要的是值得注意的是，HiveMQ本身经常与经典中间件/esb集成。这意味着，人们编写自定义插件来将HiveMQ集成到他们现有的中间件中。通常使用JMS或web服务调用(REST、SOAP)来完成此操作。
对这个答案持保留态度，因为我参与了开发HiveMQ:-)