為什么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的實際消息傳遞協議。