我在多个地方了解到 HTTP 不适合作为消息传递协议(protocol)，例如 here引用 RabbitMQ。
我认为这是有技术原因的，而且这不仅仅是一个意见。我查看了 AMQP spec例如，看不到 HTTP + Web Sockets 无法工作的任何原因。事实上，works 中似乎有一些东西。用于基于 Web 套接字的 AMQP。此外，我还查看了 STOMP协议(protocol)确实使用 HTTP + Web 套接字，并且看不到任何重大限制(除了小的性能影响之外)。
HTTP + Web Sockets 缺乏哪些技术特征使其不适合作为消息传递协议(protocol)？
更新: 这就是我正在寻找的:Crossbar.IO - WAMP 消息代理。我需要一个可以通过浏览器轻松连接的消息代理，但对 RabbitMQ(通过 STOMP)或 HiveMQ (MQTT) 不满意。
最佳答案
HTTP 是基于请求/响应的，这使得它很难以发布者/订阅者的方式工作。基本上，您可以轮询消息源以获取新消息，也可以创建另一个本地端点，另一端将消息推送给您。
WebSocket 是不同的。尽管以 HTTP 请求启动，但它会直接切换到持久的全双工连接，两端都可以推送数据。基本上，在这种情况下，HTTP 仅用作协商连接的协议(protocol)，一旦协商完成，WebSocket 将使用自己的协议(protocol)来传输数据。
更新:我们很清楚 HTTP 不是消息传递协议(protocol)，因为它是请求/响应。 WebSockets，虽然它允许从两端推送数据，但它也不是消息传递协议(protocol)。它定义了一种构建数据的方式，但没有定义订阅主题或任何有关消息传递的操作的语义或语法。例如WAMP是 Websocket 的实际消息传递协议(protocol)。
关于websocket - 为什么 HTTP + Websockets 不适合作为消息传递协议(protocol)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32338401/