为什么HTTP + Web套接字不适合作为消息传递协议？

Question

我已经读到HTTP在许多地方都不适合作为消息传递协议，例如在这里引用RabbitMQ。

我认为这是有技术原因的，并非仅出于意见。 我已经查看了AMQP 规范 ，但看不到HTTP + Web套接字无法正常工作的任何原因。 实际上，基于Web套接字的AMQP似乎正在工作 。 此外，我研究了STOMP协议，该协议的确使用HTTP + Web套接字，并且看不到任何重大限制（除了对性能造成的小影响之外）。

HTTP + Web套接字缺少什么技术特征使其不适合用作消息传递协议？

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

Answer 1

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

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

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