一、官網介紹

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.

二、內容譯文

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傳輸消息：

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

三、協議介紹

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

1、AMQP 協議 (互操作性) 　　

　　AMQP，即 Advanced Message Queuing Protocol, 一個提供統一消息服務的應用層標準高級消息隊列協議, 是應用層協議的一個開放標準, 為面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端 / 中間件不同產品，不同的開發語言等條件的限制。Erlang 中的實現有 RabbitMQ 等。 　　

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

　　AMQP 通常被劃分為三層：

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

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

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

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

　　AMQP 協議最早應用於金融系統之間的交易消息傳遞，在物聯網應用中，主要適用於移動手持設備與後臺數據中心的通信和分析。

2、STOMP 協議

　　STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，簡單(流)文本定向消息協議，它提供了一個可互操作的連接格式，允許STOMP客戶端與任意STOMP消息代理（Broker）進行交互。STOMP協議由於設計簡單，易於開發客戶端，因此在多種語言和多種平臺上得到廣泛地應用。

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

　　STOMP是一個非常簡單和容易實現的協議，其設計靈感源自於HTTP的簡單性。盡管STOMP協議在服務器端的實現可能有一定的難度，但客戶端的實現卻很容易。例如，可以使用Telnet登錄到任何的STOMP代理，並與STOMP代理進行交互。

　　STOMP協議與2012年10月22日發布了最新的STOMP 1.2規範。

3、MQTT 協議 (低帶寬) 　　

　　MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸協議)，是一種基於發布 / 訂閱 (publish/subscribe) 模式的 “輕量級” 通訊協議，該協議構建於 TCP/IP 協議上，由 IBM 在 1999 年發布。MQTT 最大優點在於，可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。做為一種低開銷、低帶寬占用的即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。 　　

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

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

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

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

　　　　最少一次，即：>=1

　　　　最多一次，這一級別會發生消息丟失或重復，消息發布依賴於底層 TCP/IP 網絡。即：<=1

　　　　只有一次，確保消息只有一次到達。即：=1。在一些要求比較嚴格的計費系統中，可以使用此級別 　　

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

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

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

　　協議實現方式 　　

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

　　　　MQTT 協議中有三種身份：發布者 (Publish)、代理 (Broker)(服務器)、訂閱者 (Subscribe)。其中，消息的發布者和訂閱者都是客戶端，消息代理是服務器，消息發布者可以同時是訂閱者。 　　

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

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

　　　　payload，可以理解為消息的內容，是指訂閱者具體要使用的內容 　　

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

4、HTTP協議

　　超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議。

RabbitMQ各協議異同詳解