一、官网介绍
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
http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html
https://blog.csdn.net/happytofly/article/details/80123057
1、AMQP 协议 (互操作性)
AMQP，即 Advanced Message Queuing Protocol, 一个提供统一消息服务的应用层标准高级消息队列协议, 是应用层协议的一个开放标准, 为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端 / 中间件不同产品，不同的开发语言等条件的限制。Erlang 中的实现有 RabbitMQ 等。AMQP旨在作为现有专有消息传递中间件的开放替代品。使用AMQP的两个最重要的原因是可靠性和互操作性。顾名思义，它提供了与消息传递相关的各种功能，包括可靠的排队，基于主题的发布和订阅消息传递，灵活的路由，事务和安全性。 AMQP直接以扇出形式，按主题和基于标题交换路由消息。
AMQP 协议是一个二进制协议，拥有一些现代特点：多信道、协商式、异步、安全、跨平台、中立、高效。
AMQP 通常被划分为三层：
1、模型层定义了一套命令 (按功能分类)，客户端应用可以利用这些命令来实现它的业务功能。
2、会话层负责将命令从客户端应用传递给服务器，再将服务器的应答传递给客户端应用，会话层为这个传递过程提供可靠性、同步机制和错误处理。
3、传输层提供帧处理、信道复用、错误检测和数据表示。
实现者可以将传输层替换成任意传输协议，只要不改变 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
- 客户端和服务端对等
- 可扩展
2、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。
3、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) ）
- 客户端和服务端不对称
- 不能扩展
四、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）来实现这种模式。