为什么 HTTP + Websockets 不适合作为消息传递协议？

Question

我在几个地方读到 HTTP 不适合作为消息传递协议，例如 here 参考 RabbitMQ。

我认为这是有技术原因的，而且这不仅仅是一种意见。例如，我查看了 AMQP spec 并看不出 HTTP + Web 套接字无法工作的任何原因。事实上，works 中似乎有一些东西用于 AMQP over Web Sockets。此外，我查看了确实使用 HTTP + Web 套接字的STOMP 协议，并且看不到任何重大限制（除了小的性能损失）。

HTTP + Web Sockets 缺少什么技术特性使其不适合作为消息传递协议？

更新： 这就是我要找的东西：Crossbar.IO - 一个 WAMP 消息代理。我需要一个可以从浏览器轻松连接的消息代理，并且对 RabbitMQ（通过 STOMP）或 HiveMQ（MQTT）不满意。

Answer 1

HTTP 是基于请求/响应的，这使得以发布者/订阅者的方式工作变得困难。基本上，您可以轮询消息源以获取新消息，也可以创建另一个本地端点，另一端将消息推送给您。

WebSocket 是不同的。尽管从 HTTP 请求开始，但它直接切换到持久的全双工连接，两端都可以推送数据。基本上，在这种情况下，HTTP 仅用作协商连接的协议，一旦协商，WebSocket 使用自己的协议来传输数据。

更新：我们很清楚 HTTP 不是消息传递协议，因为它是请求/响应。 WebSockets，虽然它允许从两端推送数据，但它也不是一个消息传递协议。它定义了一种构建数据的方式，但没有定义语义或语法来订阅主题或任何有关消息传递的操作。例如，WAMP 是 websocket 的实际消息传递协议。