RabbitMQ各協議異同詳解

1、官網介紹

Which protocols does RabbitMQ support?

RabbitMQ supports several messaging protocols, directly and through the use of plugins. This page describes the supported protocols and helps differentiate between them.

AMQP 0-9-1, 0-9 and 0-8, and extensions

RabbitMQ was originally developed to support AMQP. As such this protocol is the "core" protocol supported by the broker. All of these variants are fairly similar to each other, with later versions tidying up unclear or unhelpful parts of earlier versions. We have extended AMQP 0-9-1 in various ways.

AMQP 0-9-1 is a binary protocol, and defines quite strong messaging semantics. For clients it's a reasonably easy protocol to implement, and as such there are a large number of implementations available for many different programming languages and environments.

If you are just looking to use RabbitMQ, we recommend using AMQP 0-9-1.

STOMP

STOMP is a text-based messaging protocol emphasising (protocol) simplicity. It defines little in the way of messaging semantics, but is easy to implement and very easy to implement partially (it's the only protocol that can be used by hand over telnet).

RabbitMQ supports STOMP (all current versions) via a plugin.

MQTT

MQTT is a binary protocol emphasising lightweight publish / subscribe messaging, targetted towards clients in constrained devices. It has well defined messaging semantics for publish / subscribe, but not for other messaging idioms.

RabbitMQ supports MQTT 3.1 via a plugin.

AMQP 1.0

Despite the name, AMQP 1.0 is a radically different protocol from AMQP 0-9-1 / 0-9 / 0-8, sharing essentially nothing at the wire level. AMQP 1.0 imposes far fewer semantic requirements; it is therefore easier to add support for AMQP 1.0 to existing brokers. The protocol is substantially more complex than AMQP 0-9-1, and there are fewer client implementations.

RabbitMQ supports AMQP 1.0 via a plugin.

HTTP

HTTP is of course not a messaging protocol. However, RabbitMQ can transmit messages over HTTP in three ways:

• The management plugin supports a simple HTTP API to send and receive messages. This is primarily intended for diagnostic purposes but can be used for low volume messaging without reliable delivery.
• The Web-STOMP plugin supports STOMP messaging to the browser, using WebSockets.
• The JSON-RPC channel plugin supports AMQP 0-9-1 messaging over JSON-RPC to the browser. Note that since JSON RPC is a synchronous protocol, some parts of AMQP that depend on aysnchronous delivery to the client are emulated by polling.

 

2、內容譯文

RabbitMQ支持哪些協議？
RabbitMQ直接和經過使用插件支持多種消息傳遞協議。本頁介紹了支持的協議，並幫助區分它們。

AMQP 0-9-1,0-9和0-8，以及擴展
RabbitMQ最初是爲支持AMQP而開發的。所以，該協議是代理支持的「核心」協議。全部這些變體都很是類似，後來的版本整理了早期版本中不清楚或無用的部分。咱們以各類方式擴展了AMQP 0-9-1。

AMQP 0-9-1是一種二進制協議，它定義了很是強大的消息傳遞語義。對於客戶來講，它是一個至關容易實現的協議，所以有許多可用於許多不一樣編程語言和環境的實現。

若是您只是想使用RabbitMQ，咱們建議使用AMQP 0-9-1。

STOMP
STOMP是一種基於文本的消息傳遞協議，強調（協議）簡單性。它對消息傳遞語義的定義不多，但易於實現而且很是容易部分實現（它是惟一能夠經過telnet手動使用的協議）。

RabbitMQ經過插件支持STOMP（全部當前版本）。

MQTT
MQTT是一種二進制協議，強調輕量級發佈/訂閱消息傳遞，針對受限設備中的客戶端。它有明肯定義的發佈/訂閱消息語義，但不適用於其餘消息傳遞習語。

RabbitMQ經過插件支持MQTT 3.1。

AMQP 1.0
儘管名字類似，但AMQP 1.0與AMQP 0-9-1 / 0-9 / 0-8徹底不一樣，在線路級別基本上沒有任何類似之處。 AMQP 1.0強加了不多的語義要求；所以，更容易向現有經紀商添加對AMQP 1.0的支持。該協議比AMQP 0-9-1複雜得多，而且客戶端實現較少。

RabbitMQ經過插件支持AMQP 1.0。

HTTP
HTTP固然不是消息傳遞協議。可是，RabbitMQ能夠經過三種方式利用HTTP傳輸消息：

一、管理插件支持簡單的HTTP API來發送和接收消息。這主要用於診斷目的，但可用於無需可靠傳送的低容量消息傳遞。
二、Web-STOMP插件使用WebSockets，支持向瀏覽器發送STOMP消息。
三、JSON-RPC通道插件支持經過JSON-RPC向瀏覽器發送AMQP 0-9-1消息。請注意，因爲JSON RPC是一種同步協議，AMQP的某些部分依賴於向客戶端的同步傳遞，所以經過輪詢進行模擬。

 

 3、協議介紹

　　參考連接：http://security.asmag.com.cn/news/201710/92374.html

　　　　  　　 http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html

　　　　  　　 https://blog.csdn.net/happytofly/article/details/80123057

 

一、AMQP 協議 (互操做性) 　　

　　AMQP，即 Advanced Message Queuing Protocol, 一個提供統一消息服務的應用層標準高級消息隊列協議, 是應用層協議的一個開放標準, 爲面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端 / 中間件不一樣產品，不一樣的開發語言等條件的限制。Erlang 中的實現有 RabbitMQ 等。AMQP旨在做爲現有專有消息傳遞中間件的開放替代品。使用AMQP的兩個最重要的緣由是可靠性和互操做性。顧名思義，它提供了與消息傳遞相關的各類功能，包括可靠的排隊，基於主題的發佈和訂閱消息傳遞，靈活的路由，事務和安全性。 AMQP直接以扇出形式，按主題和基於標題交換路由消息。 　　

　　AMQP 協議是一個二進制協議，擁有一些現代特色：多信道、協商式、異步、安全、跨平臺、中立、高效。 　

　　AMQP 一般被劃分爲三層：

　　一、模型層定義了一套命令 (按功能分類)，客戶端應用能夠利用這些命令來實現它的業務功能。

　　二、會話層負責將命令從客戶端應用傳遞給服務器，再將服務器的應答傳遞給客戶端應用，會話層爲這個傳遞過程提供可靠性、同步機制和錯誤處理。

　　三、傳輸層提供幀處理、信道複用、錯誤檢測和數據表示。 　　

　　實現者能夠將傳輸層替換成任意傳輸協議，只要不改變 AMQP 協議中與客戶端應用程序相關的功能。實現者還可使用其餘高層協議中的會話層。 　

　　這種豐富的功能集能夠實現許多細粒度控制。您能夠限制對隊列的訪問，管理其深度等。消息屬性，註釋和標題等功能使其很是適合各類企業應用程序。該協議旨在提升許多大型公司的可靠性，這些公司依靠消息傳遞來集成應用程序並在組織中移動數據。在RabbitMQ的狀況下，有許多不一樣的語言實現和可用的大樣本，使其成爲構建大規模，可靠，彈性或羣集消息傳遞基礎結構的良好選擇。　　

　　AMQP是一種二進制有線協議，旨在實現不一樣供應商之間的互操做性。在其餘協議失敗的狀況下，AMQP的採用率很高。AMQP 協議最先應用於金融系統之間的交易消息傳遞，在物聯網應用中，主要適用於移動手持設備與後臺數據中心的通訊和分析。摩根大通等公司天天使用它來處理10億條消息。 NASA將其用於星雲雲計算。 Google將其用於複雜的事件處理。如下是一些其餘AMQP示例和連接：它被用於世界上最大的生物識別數據庫之一，印度的Aadhar項目 —— 擁有12億個身份。它被用於Ocean Observatories Initiative —— 一種天天收集8TB數據的架構。

　　amqp.org提供了更多示例和連接。

 

　下面是AMQP的主要特性：

• 獨立於平臺的底層消息傳遞協議
• 消費者驅動消息傳遞
• 跨語言和平臺的互用性
• 它是底層協議的
• 有5種交換類型direct，fanout，topic，headers，system
• 面向緩存的
• 可實現高性能
• 支持長週期消息傳遞
• 支持經典的消息隊列，循環，存儲和轉發
• 支持事務（跨消息隊列）
• 支持分佈式事務（XA，X/OPEN，MS DTC）
• 使用SASL和TLS確保安全性
• 支持代理安全服務器
• 元數據能夠控制消息流
• 不支持LVQ
• 客戶端和服務端對等
• 可擴展

 

二、STOMP 協議 

　　STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，簡單(流)文本定向消息協議，它提供了一個可互操做的鏈接格式，容許STOMP客戶端與任意STOMP消息中間件（Broker）進行交互。STOMP協議因爲設計簡單，易於開發客戶端，所以在多種語言和多種平臺上獲得普遍地應用。

　　STOMP協議的前身是TTMP協議（一個簡單的基於文本的協議），專爲消息中間件設計。

　　STOMP是一個很是簡單和容易實現的協議，其設計靈感源自於HTTP的簡單性。儘管STOMP協議在服務器端的實現可能有必定的難度，但客戶端的實現卻很容易。

　　STOMP是這三種協議中惟一一種基於文本的協議，所以它更相似於HTTP。與AMQP同樣，STOMP提供帶有屬性的消息（或幀）標頭和幀體。這裏的設計原則是建立一些簡單且可普遍互操做的東西。例如，可使用像telnet客戶端這樣簡單的東西鏈接到STOMP代理，並與STOMP代理進行交互。

　　可是，STOMP不處理隊列和主題 —— 它使用帶有「目標」字符串的SEND語義。消息中間件必須映射到內部能理解的內容，例如主題，隊列或交換。而後消費者訂閱這些目標。因爲規範中沒有強制要求這些目標，所以不一樣的消息中間件可能會支持不一樣的目標風格。所以，在消息中間件之間並不老是能直接移植代碼。

　　然而，STOMP簡單而輕巧（儘管在線上有點冗長），具備普遍的語言綁定。它還提供了一些事務語義。其中一個最有趣的例子是RabbitMQ Web Stomp，它容許您經過websockets在瀏覽器中公開消息。這開闢了一些有趣的可能性 —— 好比使用全部類型的信息實時更新瀏覽器，移動應用程序或機器。

　　有關詳情，請訪問stomp.github.com。

 

三、MQTT 協議 (低帶寬) 　　

　　MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸協議)，是一種基於發佈 / 訂閱 (publish/subscribe) 模式的 「輕量級」 通信協議，該協議構建於 TCP/IP 協議上，由 IBM 在 1999 年發佈。MQTT 最大優勢在於，能夠以極少的代碼和有限的帶寬，爲鏈接遠程設備提供實時可靠的消息服務。作爲一種低開銷、低帶寬佔用的即時通信協議，使其在物聯網、小型設備、移動應用等方面有較普遍的應用。

　　MQTT的設計原則和目標比AMQP更簡單，更集中 —— 它提供了發佈和訂閱消息傳遞（沒有隊列，儘管名稱中含有隊列），專門針對資源受限的設備和低帶寬，高延遲網絡，例如撥號線路和衛星鏈路。基本上，它能夠在嵌入式系統中有效使用。

　　比起那些功能更強大的「企業消息傳遞」中間件，MQTT的優點之一是它有意下降了封裝程度，使其成爲當今移動和開發「物聯網」風格應用程序的理想選擇。事實上，像Facebook這樣的公司正在將它做爲移動應用程序的一部分，由於它具備如此低的功耗，而且網絡帶寬很小。

　　一些基於MQTT的中間件支持數千個併發設備鏈接。它提供三種服務質量：

　　1）「fire-and-forget / unreliable」，這一級別會發生消息丟失或重複，消息發佈依賴於底層 TCP/IP 網絡。

　　2）「at least once」，以確保它至少發送一次（但可能被髮送超過一次）。

　　3）「exactly once」，確保消息只有一次到達。在一些要求比較嚴格的計費系統中，可使用此級別 。

　　MQTT的優勢是簡單（只有五種API方法），一個緊湊的二進制數據包有效負載（沒有消息屬性，壓縮標頭，比基於文本的HTTP更簡潔），它很是適合簡單的消息傳遞方案，如溫度更新，股票價格監測，油壓供應，以及移動通知。它對於將機器鏈接在一塊兒也很是有用，例如使用MQTT將Arduino設備鏈接到Web服務。

　　MQTT 協議運行在 TCP/IP 或其餘網絡協議，提供有序、無損、雙向鏈接。其特色包括： 　　

　　1) 使用的發佈 / 訂閱消息模式，它提供了一對多消息分發，以實現與應用程序的解耦。 　

　　2) 對負載內容屏蔽的消息傳輸機制。 　　

　　3) 對傳輸消息有三種服務質量 (QoS)。　　　　

　　4) 數據傳輸和協議交換的最小化 (協議頭部只有 2 字節)，以減小網絡流量 　　

　　5) 通知機制，異常中斷時通知傳輸雙方 　　

　　　　適用範圍：在低帶寬、不可靠的網絡下提供基於雲平臺的遠程設備的數據傳輸和監控。 　　

　　協議實現方式 　　

　　　　實現 MQTT 協議須要：客戶端和服務器端 　　

　　　　MQTT 協議中有三種身份：發佈者 (Publish)、消息中間件 (Broker)(服務器)、訂閱者 (Subscribe)。其中，消息的發佈者和訂閱者都是客戶端，消息中間件是服務器，消息發佈者能夠同時是訂閱者。 　　

　　　　MQTT 傳輸的消息分爲：主題 (Topic) 和負載 (payload) 兩部分 　　

　　　　Topic，能夠理解爲消息的類型，訂閱者訂閱 (Subscribe) 後，就會收到該主題的消息內容(payload) 　　

　　　　payload，能夠理解爲消息的內容，是指訂閱者具體要使用的內容 　　

　　　　MQTT 協議通常適用於設備數據採集到端 (Device -》Server，Device -》Gateway)，集中星型網絡架構 (hub-and-spoke)，不適用設備與設備之間通訊，設備控制能力弱，另外實時性較差，通常都在秒級。

 

　下面是MQTT的主要特性：

• 面向流，內存佔用低
• 爲小型無聲設備之間經過低帶寬發送短消息而設計
• 不支持長週期存儲和轉發
• 不容許分段消息（很難發送長消息）
• 支持主題發佈-訂閱
• 不支持事務（僅基本確認）
• 消息其實是短暫的（短週期）
• 簡單用戶名和密碼，基於沒有足夠信息熵的安全
• 不支持安全鏈接
• 消息不透明
• Topic是全局的（一個全局的命名空間）
• 支持最新值隊列（Last Value Queue (LVQ) ）
• 客戶端和服務端不對稱
• 不能擴展

　　在mqtt.org瞭解更多信息。

 

4、AMQP，MQTT or STOMP？

　　參考連接：https://blog.csdn.net/qq_19004627/article/details/79802685

 

純消息

　　底層協議（例如 TCP）是被設計用來將一個消息從一個發送者（sender）傳遞給一個接收者（receiver）。他們並不關係消息自己應該如何構建，也不關係消息的請求、獲取、存儲以及如何保證安全可靠。

　　像 WebSockets 這樣在 TCP 之上的協議，添加了一些額外的功能，例如使用頭部（header）傳輸元數據，經過多個數據包分割較大的消息，簡單的身份驗證，以及路由／重定向相關信息。本質上它們仍然是點對點交換數據的方式。

　　當涉及到構建更大，更復雜的系統時，你須要一個更高層次的通訊範式：

發佈－訂閱

 　　發佈－訂閱模式是在大規模系統中被普遍使用的通訊方式，用於多對多無狀態消息傳遞。「訂閱者」（Subscribers）能夠訂閱「消息主題」（topics，channels，events，namespaces）， 「發佈者」（Publishers）能夠將消息發佈到「消息主題」，經過路由，全部的訂閱者都將收到。　　

　　這種範式是很是靈活，高效和可擴展。它將發送者與接收者隔離開，容許訂閱者自由得訂閱主題或取消訂閱。這和咱們平常訂閱報紙是同樣的。

　　有許多支持發佈－訂閱的協議：MQTT，STOMP，WAMP 等等。那麼咱們應該如何選擇呢？

 

MQTT　　

　　MQTT（Message Queue Telemerty Transport）是一種二進制協議，主要用於服務器和那些低功耗的物聯網設備（IoT）之間的通訊。

　　它位於 TCP 協議的上層，除了提供發佈－訂閱這一基本功能外，也提供一些其它特性：不一樣的消息投遞保障（delivery guarantee）。經過存儲最後一個被確認接受的消息來實現重連後的消息恢復。

　　它很是輕量級，而且從設計和實現層面都適合用於不穩定的網絡環境中。

何時應使用它？

　　物聯網（IoT）場景中更適合，支持幾乎全部語言進行開發，而且瀏覽器也可經過 WebSocket 來發送和接收 MQTT 消息。

　　同時，對於MQTT Broker，也有不少選擇，如 Mosquitto 或 VerneMQ 以及基於雲的 MQTT 平臺，如 HiveMQ 或 CloudMQTT。

 

STOMP

　　面向流文本的消息傳輸協議（STOMP，Streaming Text Oriented Messaging Protocol），是 WebSocket 通訊標準。在一般的發佈－訂閱語義之上，它經過 begin/publish/commit 序列以及 acknowledgement 機制來提供消息可靠投遞。

　　因爲協議簡單且易於實現，幾乎全部的編程語言都有 STOMP 的客戶端實現。可是在消息大小和處理速度方面並沒有優點。

何時會使用它？

　　當與 Apache Apollo 這樣的多協議代理（multi-protocol broker）中間件結合使用時，能夠作許多有趣的集成。好比在瀏覽器的圖表中不斷更新 IoT 設備的數據。

 

選擇二進制仍是基於文本？

　　到目前爲止，咱們已經講了兩個協議：一個二進制、另外一個基於文本。讓咱們快速比較一下差別：　　

　　經過控制線纜中光或電的打開或關閉（邏輯開關），或控制 WiFi 信號的波峯或波谷來實現計算機之間的信息交換。從原理上來講，這是基於二進制的形式。所以，從這個層面來講全部協議都是二進制協議。

　　信息一旦發送，接收方有兩個選擇：它能夠將 0/1 流分組成字節序列，進而獲取（解析）信息；或者能夠執行額外的步驟，將其轉換爲文本，而後再解析此文本。

　　前一種方法稱爲（基於）二進制的。它節省了一些昂貴的操做，同時是傳輸任何非文本信息的標準形式。例如，圖像，音頻，視頻或文件。固然它也可用於發送文本信息。例如，經過向每一個消息增長几個字節來表達元信息，好比描述該消息的長度或類型，這樣就只需將實際的消息數據轉換爲文本。

　　然而，因爲在許多發佈－訂閱式的架構中，信息交換是基於文本的，因此許多協議選擇簡單地將整個信息轉化爲文本，從而下降複雜性並提升了可讀性，固然帶來的代價就是須要再消息接受後執行額外的計算任務。

 

隊列

　　有些場景下，簡單的發佈－訂閱模式還不夠。這就是隊列存在的場合：它支持多種不一樣的消息和存儲的模式。

　　經過獲取／確認策略，消費者接收到隊列的一些消息，確認他們的「消費」，處理它們，而後取下一批消息。這是一個強大同時經常使用的方式。

　　想象一下，你正在構建一個相似 Instagram 的產品，它容許用戶上傳圖片並添加各類濾鏡。應用濾鏡的過程是一個計算密集型的操做。所以，不能在上傳時直接進行操做，因此接收圖像的服務器只是記錄下在文件系統中的位置，接着將「什麼圖像須要使用什麼樣的濾鏡」這個任務添加到任務隊列中。

　　另外一臺專門用於處理濾鏡的機器能夠從任務隊列中獲取這個任務，讀取原始圖像文件，應用濾鏡，並確認這個任務已經消費（完成）。以後爲了水平擴展圖像處理的能力，只須要添加更多的消費者（處理濾鏡的機器）來處理任務隊列便可。

　　這種模式很是易於擴展，能夠添加複雜的路由策略，任務分配策略等。

 

AMQP

　　高級消息隊列協議（AMQP，Advanced Message Queuing Protocol）是各類消息隊列協議中的佼佼者。RabbitMQ 和 HornetQ 都是實現該協議的流行中間件。

何時會使用它？

　　當簡單的發佈－訂閱模型不能知足使用要求。AMQP 十分可靠且功能強大。固然它及它的實現並非足夠輕量級。若是你須要一個更輕量級的選擇，那能夠選擇其餘協議。

 

請求/響應

　　有時咱們只須要發送單個請求，並等待收到一個響應，這徹底可使用HTTP請求完成 。 可是既然你已經創建了一個與服務器的持久鏈接 ，那爲何不利用它呢？

　　這種經過持久鏈接進行的請求／響應模式的通訊過程，一般被稱爲遠程過程調用（RPC，Remote Procedure Calls）或遠程方法調用（RMI，Remote Method Invocation）。AMQP 能夠經過響應隊列（response-queue）來實現這種模式。