兼容性和合规性

RabbitMQ 核心代理实现了 AMQP 1.0 规范和 AMQP 0-9-1 规范，并带有若干 AMQP 0-9-1 扩展。

AMQP 1.0 与 AMQP 0-9-1 是完全不同的协议，两者使用不同的客户端库集。RabbitMQ 将无限期地继续支持 AMQP 0-9-1，同时继续并行进行 AMQP 1.0 的实现工作。

为了方便您查阅，0-9-1（带扩展和不带扩展）规范链接如下。要了解更多关于 AMQP 0-9-1 的信息，请参阅 AMQP 0-9-1 概述指南、AMQP 0-9-1 规范 PDF、AMQP 0-9-1 参考 PDF，以及其他 文档以获取更多信息。

协议版本	文档 (PDF)	机器可读规范 (XML)
AMQP 1.0	规范	完整
AMQP 0-9-1 加上 RabbitMQ 扩展	规范 | 勘误文档 生成的参考	完整参考 | BSD 许可的 XML

AMQP 0-9-1 规范中的类

下表描述了各种 AMQP 协议消息类的当前实现状态。

当前状态	类	备注
ok	connection
ok	channel
ok	exchange
ok	queue
ok	basic
partial	tx	请参阅 tx 支持说明

AMQP 0-9-1 规范中的方法

下表描述了每个类中各种 AMQP 协议方法的当前实现状态。

当前状态	方法	备注
ok	connection.start
ok	connection.start-ok
ok	connection.secure
ok	connection.secure-ok
ok	connection.tune
ok	connection.tune-ok
ok	connection.open
ok	connection.open-ok
ok	connection.close
ok	connection.close-ok
ok	channel.open
ok	channel.open-ok
partial	channel.flow	服务器不支持 active=false。使用 basic.qos 限制预取可以提供更好的控制。
ok	channel.flow-ok
ok	channel.close
ok	channel.close-ok
ok	exchange.declare
ok	exchange.declare-ok
partial	exchange.delete	我们将 exchange.delete 做成了一个幂等断言，即交换器必须不存在，就像 exchange.declare 断言它必须存在一样。
ok	exchange.delete-ok
ok	queue.declare
ok	queue.declare-ok	consumer-count 参数是所有消费者的计数，而不是像规范所要求的那样仅限于活动消费者。前者对应用程序更有用。
ok	queue.bind
ok	queue.bind-ok
partial	queue.unbind	我们将 queue.unbind 做成了一个幂等断言，即绑定必须不存在，就像 queue.bind 断言它必须存在一样。
ok	queue.unbind-ok
ok	queue.purge
ok	queue.purge-ok
partial	queue.delete	我们将 queue.delete 做成了一个幂等断言，即队列必须不存在，就像 queue.declare 断言它必须存在一样。
ok	queue.delete-ok
partial	basic.qos	服务器支持每个消费者和每个通道的限制。与规范中的 global 标志不同，该标志具有不同的语义。有关更多信息，请参阅 消费者预取。预取大小限制未实现。
ok	basic.qos-ok
partial	basic.consume	no-local 参数未实现。该参数的值将被忽略，并且不会尝试阻止消费者接收从同一连接发布的同一消息。
ok	basic.consume-ok
ok	basic.cancel
ok	basic.cancel-ok
ok	basic.publish
ok	basic.return
ok	basic.deliver
ok	basic.get
ok	basic.get-ok
ok	basic.get-empty
ok	basic.ack
partial	basic.reject	服务器在 requeue=false 时丢弃消息，在 requeue=true 时重新排队。不会尝试阻止同一客户端重新投递。服务器不会中断已拒绝消息的内容发送，即消息始终完整地投递给客户端。
partial	basic.recover	不支持 requeue=false 的恢复。
ok	tx.select
ok	tx.select-ok
ok	tx.commit
ok	tx.commit-ok
ok	tx.rollback
ok	tx.rollback-ok

AMQP 0-9-1 规范中的规则

“参考”列包含类或域、方法、字段和规则名称（如果存在）。

当前状态	类型	Actor	Reference	Text
ok	MUST NOT		delivery-tag / channel-local	投递标签仅在消息接收的通道内有效。即，客户端 MUST NOT 在一个通道上接收消息，然后在另一个通道上确认它。
ok	MUST NOT		delivery-tag / non-zero	服务器 MUST NOT 对投递标签使用零值。零保留给客户端使用，表示“至今收到的所有消息”。
does	SHOULD		redelivered / implementation	服务器 SHOULD 在可能的情况下尝试标记已重新投递的消息。当重新投递一条未成功确认的消息时，服务器 SHOULD 在可能的情况下将其投递给原始客户端。
planned	MUST NOT		redelivered / hinting	客户端 MUST NOT 依赖 redelivered 字段，而应将其视为消息可能已处理的提示。一个完全健壮的客户端必须能够跟踪在非事务性通道和本地事务性通道上接收到的重复消息。 注释: 客户端已经符合要求，因为它不依赖 redelivered 字段，并且我们计划在未来的版本中添加重复跟踪。
ok	MUST	client	connection / start / protocol-name	如果服务器无法支持协议头中指定的协议，它 MUST 返回一个有效的协议头，然后关闭套接字连接。
ok	MUST	client	connection / start / server-support	服务器 MUST 提供低于或等于客户端在协议头中请求的协议版本。
ok	MUST	client	connection / start / client-support	如果客户端无法处理服务器建议的协议版本，它 MUST 关闭套接字连接，而不再发送任何数据。
does	SHOULD	client	connection / start / server-properties / required-fields	属性 SHOULD 至少包含以下字段：“host”，指定服务器主机名或地址；“product”，给出服务器产品的名称；“version”，给出服务器版本的名称；“platform”，给出操作系统的名称；“copyright”，如果适用；以及“information”，给出其他一般信息。
ok	MUST	client	connection / start / locales / required-support	服务器 MUST 支持至少 en_US 区域设置。
does	SHOULD	server	connection / start-ok / client-properties / required-fields	属性 SHOULD 至少包含以下字段：“product”，给出客户端产品的名称；“version”，给出客户端版本的名称；“platform”，给出操作系统的名称；“copyright”，如果适用；以及“information”，给出其他一般信息。
ok	SHOULD	server	connection / start-ok / mechanism / security	客户端 SHOULD 使用其能够处理的最高安全配置文件进行身份验证，该配置文件来自服务器提供的列表。
ok	MUST	server	connection / start-ok / mechanism / validity	如果 mechanism 字段不包含服务器在 Start 方法中提出的安全机制之一，服务器 MUST 关闭连接，而不再发送任何数据。
ok	MUST	client	connection / tune / frame-max / minimum	在 frame-max 协商完成之前，双方 MUST 接受最大为 frame-min-size 字节的帧，并且 frame-max 的最小协商值为 frame-min-size。
planned	MUST	server	connection / tune-ok / channel-max / upper-limit	如果客户端指定的 channel max 高于服务器提供的值，服务器 MUST 关闭连接，而不再尝试协商关闭。服务器可以以某种方式报告错误以协助实现者。
ok	MUST	server	connection / tune-ok / frame-max / minimum	在 frame-max 协商完成之前，双方 MUST 接受最大为 frame-min-size 字节的帧，并且 frame-max 的最小协商值为 frame-min-size。 注释: frame-min-size 为 4KB。
ok	MUST	server	connection / tune-ok / frame-max / upper-limit	如果客户端指定的 frame max 高于服务器提供的值，服务器 MUST 关闭连接，而不再尝试协商关闭。服务器可以以某种方式报告错误以协助实现者。
ok	MUST	server	connection / open / virtual-host / separation	如果服务器支持多个虚拟主机，它 MUST 对每个虚拟主机强制实施交换器、队列以及所有相关实体的完全分离。连接到特定虚拟主机的应用程序 MUST NOT 能够访问其他虚拟主机的资源。
does	SHOULD	server	connection / open / virtual-host / security	服务器 SHOULD 验证客户端是否有权访问指定的虚拟主机。
ok	MUST	client	connection / close / stability	发送此方法后，除 Close 和 Close-OK 外，所有接收到的方法都 MUST 被丢弃。发送 Close 后收到 Close 的响应是发送 Close-Ok。
does	SHOULD	client	connection / close-ok / reporting	检测到套接字关闭但未收到 Close-Ok 握手机制的对等方 SHOULD 记录错误。 注释: 只有服务器维护错误日志。
ok	MUST NOT	server	channel / open / state	客户端 MUST NOT 在已打开的通道上使用此方法。
doesn't	MAY	server	channel / flow / initial-state	当打开一个新通道时，它处于活动状态（flow is active）。某些应用程序假定通道在启动之前处于非活动状态。为了模拟此行为，客户端 MAY 打开通道，然后暂停它。
doesn't	SHOULD	server	channel / flow / bidirectional	发送内容帧时，对等方 SHOULD 监控通道以接收传入方法，并尽快响应 Channel.Flow。 注释: 服务器不支持 active=true 的阻塞流。使用 basic.qos 限制预取可以提供更好的控制。
ok	MAY	server	channel / flow / throttling	对等方 MAY 使用 Channel.Flow 方法来限制传入的内容数据，以实现内部原因，例如，当通过较慢的连接交换数据时。 注释: 服务器或客户端都不会自动发出 Channel.Flow。
doesn't	MAY	server	channel / flow / expected-behaviour	请求 Channel.Flow 方法的对等方 MAY 断开并/或禁止不遵守请求的对等方。这是为了防止行为不良的客户端压垮服务器。
ok	MUST	client	channel / close / stability	发送此方法后，除 Close 和 Close-OK 外，所有接收到的方法都 MUST 被丢弃。发送 Close 后收到 Close 的响应是发送 Close-Ok。
does	SHOULD	client	channel / close-ok / reporting	检测到套接字关闭但未收到 Channel.Close-Ok 握手机制的对等方 SHOULD 记录错误。 注释: 只有服务器维护错误日志。
ok	MUST		exchange / required-types	服务器 MUST 实现这些标准交换器类型：fanout、direct。
does	SHOULD		exchange / recommended-types	服务器 SHOULD 实现这些标准交换器类型：topic、headers。
ok	MUST		exchange / required-instances	服务器 MUST 在每个虚拟主机中，为它实现的每种标准交换器类型预先声明一个交换器实例，其中交换器实例的名称（如果已定义）是“amq.”后跟交换器类型名称。
ok	MUST		exchange / default-exchange	服务器 MUST 预先声明一个没有公共名称的 direct 交换器，以作为内容 Publish 方法和默认队列绑定的默认交换器。
ok	MUST NOT		exchange / default-access	服务器 MUST NOT 允许客户端访问默认交换器，除非在 Queue.Bind 和内容 Publish 方法中指定空的交换器名称。
does	MAY		exchange / extensions	服务器 MAY 根据需要实现其他交换器类型。
does	SHOULD	server	exchange / declare / minimum	服务器 SHOULD 支持每个虚拟主机至少 16 个交换器，并且理想情况下，除了可用资源定义的限制外，不施加任何限制。
ok	MUST, MAY	server	exchange / declare / exchange / reserved	以“amq.”开头的交换器名称保留给预先声明的标准交换器。客户端 MAY 声明一个以“amq.”开头的交换器，如果 passive 选项已设置，或者交换器已存在。 注释: 服务器不阻止以“amq.”开头的交换器名称被声明。客户端可以在不设置 passive 位的情况下声明以“amq.”开头的交换器。
ok	MUST	server	exchange / declare / exchange / syntax	交换器名称由以下字符组成的一个非空序列：字母、数字、连字符、下划线、句点或冒号。 注释: 服务器不强制执行词汇。
ok	MUST	server	exchange / declare / type / typed	交换器不能以不同的类型重新声明。客户端 MUST 不尝试用与原始 Exchange.Declare 方法不同的类型重新声明已存在的交换器。
ok	MUST NOT	server	exchange / declare / type / support	客户端 MUST NOT 尝试声明服务器不支持的类型的交换器。
ok	MUST	server	exchange / declare / passive / not-found	如果设置了 passive 且交换器尚不存在，服务器 MUST 引发一个具有回复代码 404（未找到）的通道异常。 注释: （指 passive 标志）
ok	MUST	server	exchange / declare / passive / equivalent	如果未设置 passive 且交换器存在，服务器 MUST 检查现有交换器是否具有相同的 type、durable 和 arguments 字段值。如果请求的交换器与这些字段匹配，服务器 MUST 响应 Declare-Ok，否则 MUST 引发通道异常。 注释: （指 passive 标志）
ok	MUST	server	exchange / declare / durable / support	服务器 MUST 支持 durable 和 transient 交换器。
failing	MUST NOT	server	exchange / delete / exchange / exists	客户端 MUST NOT 尝试删除不存在的交换器。 注释: 我们将 exchange.delete 做成了一个幂等断言，即交换器必须不存在，就像 exchange.declare 断言它必须存在一样。
ok	MUST NOT	server	exchange / delete / if-unused / in-use	如果 if-unused 字段为 true，服务器 MUST NOT 删除有绑定在其上的交换器。
ok	MUST	server	queue / declare / default-binding	服务器 MUST 为新声明的队列创建与默认交换器的默认绑定，这是一个类型为 'direct' 的交换器，并将队列名称用作路由键。
does	SHOULD	server	queue / declare / minimum-queues	服务器 SHOULD 支持每个虚拟主机至少 256 个队列，并且理想情况下，除了可用资源定义的限制外，不施加任何限制。
does	MAY, MUST	server	queue / declare / queue / default-name	队列名称 MAY 为空，在这种情况下，服务器 MUST 创建一个具有唯一生成名称的新队列，并在 Declare-Ok 方法中将其返回给客户端。
ok	MUST	server	queue / declare / queue / reserved	以“amq.”开头的队列名称保留给预先声明的标准队列。客户端 MAY 声明一个以“amq.”开头的队列，如果 passive 选项已设置，或者队列已存在。 注释: 服务器不阻止以“amq.”开头的队列名称被声明。客户端可以在不设置 passive 位的情况下声明以“amq.”开头的队列。
does	MAY	server	queue / declare / queue / syntax	队列名称可以为空，或由以下字符组成的序列：字母、数字、连字符、下划线、句点或冒号。 注释: 服务器不强制执行词汇。
does	MAY	server	queue / declare / passive / passive	客户端 MAY 要求服务器断言一个队列存在而不创建它（如果它不存在）。如果队列不存在，服务器将其视为失败。
ok	MUST	server	queue / declare / passive / equivalent	如果未设置 passive 且队列存在，服务器 MUST 检查现有队列是否具有相同的 durable、exclusive、auto-delete 和 arguments 字段值。如果请求的队列与这些字段匹配，服务器 MUST 响应 Declare-Ok，否则 MUST 引发通道异常。 注释: （指 passive 标志）
ok	MUST	server	queue / declare / durable / persistence	服务器 MUST 在重启后重新创建 durable 队列。
ok	MUST	server	queue / declare / durable / types	服务器 MUST 支持 durable 和 transient 队列。
ok	MUST	server	queue / declare / exclusive / types	服务器 MUST 支持 exclusive（私有）和 non-exclusive（共享）队列。
doesn't	MAY NOT	server	queue / declare / exclusive / exclusive	客户端 MAY NOT 尝试使用由另一个仍打开的连接声明为 exclusive 的队列。
ok	MUST	server	queue / declare / auto-delete / pre-existence	如果队列已存在，服务器 MUST 忽略 auto-delete 字段。
ok	MUST	server	queue / bind / duplicates	服务器 MUST 允许忽略重复的绑定 - 即，针对特定队列的两个或多个具有相同参数的 bind 方法 - 而不将这些视为错误。
ok	MUST NOT	server	queue / bind / unique	服务器 MUST 不会向队列投递同一条消息超过一次，即使该队列有多个匹配该消息的绑定。
ok	MUST	server	queue / bind / transient-exchange	服务器 MUST 允许 durable 队列绑定到 transient 交换器。
ok	MUST	server	queue / bind / durable-exchange	durable 队列与 durable 交换器的绑定自动是 durable 的，并且服务器 MUST 在服务器重启后恢复这些绑定。
does	SHOULD	server	queue / bind / binding-count	服务器 SHOULD 支持每个队列至少 4 个绑定，并且理想情况下，除了可用资源定义的限制外，不施加任何限制。
ok	MUST	server	queue / bind / queue / queue-known	客户端 MUST 要么指定一个队列名称，要么在同一通道上预先声明了一个队列。
ok	MUST NOT	server	queue / bind / queue / must-exist	客户端 MUST NOT 尝试绑定一个不存在的队列。
ok	MUST NOT	server	queue / bind / exchange / exchange-existence	客户端 MUST NOT 被允许绑定一个不存在的交换器到一个队列。
doesn't	MUST	server	queue / bind / exchange / default-exchange	服务器 MUST 接受一个空的交换器名称，表示默认交换器。
ok	MUST	server	queue / bind / routing-key / direct-exchange-key-matching	如果消息队列使用路由键 K 绑定到 direct 交换器，并且发布者发送带有路由键 R 的消息给交换器，那么如果 K = R，该消息 MUST 被传递给消息队列。
ok	MUST	server	queue / unbind / 01	如果 unbind 失败，服务器 MUST 引发连接异常。
ok	MUST	server	queue / unbind / queue / queue-known	客户端 MUST 要么指定一个队列名称，要么在同一通道上预先声明了一个队列。
failing	MUST NOT	server	queue / unbind / queue / must-exist	客户端 MUST NOT 尝试解除绑定一个不存在的队列。 注释: 我们将 queue.unbind 做成了一个幂等断言，即绑定必须不存在，就像 queue.bind 断言它必须存在一样。
failing	MUST NOT	server	queue / unbind / exchange / must-exist	客户端 MUST NOT 尝试将一个队列从不存在的交换器中解除绑定。 注释: 我们将 queue.unbind 做成了一个幂等断言，即绑定必须不存在，就像 queue.bind 断言它必须存在一样。
doesn't	MUST	server	queue / unbind / exchange / default-exchange	服务器 MUST 接受一个空的交换器名称，表示默认交换器。
ok	MUST NOT	server	queue / purge / 02	服务器 MUST NOT 清除已发送给客户端但尚未确认的消息。
doesn't	MAY	server	queue / purge / 03	服务器 MAY 实现一个 purge queue 或日志，允许系统管理员恢复意外清除的消息。服务器 SHOULD NOT 将已清除的消息保存在与实时消息相同的存储空间中，因为已清除的消息量可能会非常大。
ok	MUST	server	queue / purge / queue / queue-known	客户端 MUST 要么指定一个队列名称，要么在同一通道上预先声明了一个队列。
ok	MUST NOT	server	queue / purge / queue / must-exist	客户端 MUST NOT 尝试清除一个不存在的队列。
doesn't	SHOULD	server	queue / delete / 01	服务器 SHOULD 使用死信队列来存储已删除队列中待处理的消息，并 MAY 提供设施让系统管理员将这些消息移回活动队列。
ok	MUST	server	queue / delete / queue / queue-known	客户端 MUST 要么指定一个队列名称，要么在同一通道上预先声明了一个队列。
failing	MUST NOT	server	queue / delete / queue / must-exist	客户端 MUST NOT 尝试删除一个不存在的队列。 注释: 我们将 queue.delete 做成了一个幂等断言，即队列必须不存在，就像 queue.declare 断言它必须存在一样。
ok	MUST NOT	server	queue / delete / if-unused / in-use	如果 if-unused 字段为 true，服务器 MUST NOT 删除有消费者的队列。
ok	MUST NOT	server	queue / delete / if-empty / not-empty	如果 if-empty 字段为 true，服务器 MUST NOT 删除有消息的队列。
does	SHOULD		basic / 01	服务器 SHOULD 尊重 basic 消息的 persistent 属性，并且 SHOULD 尽力将 persistent basic 消息保存在可靠的存储机制中。
ok	MUST NOT		basic / 02	在队列溢出时，服务器 MUST NOT 丢弃 persistent basic 消息。
doesn't	MAY		basic / 03	服务器 MAY 使用 Channel.Flow 方法在必要时减慢或停止 basic 消息发布者。
does	MAY		basic / 04	服务器 MAY 将非 persistent basic 消息溢出到 persistent 存储。
doesn't	MAY		basic / 05	如果队列大小超过某个配置限制，服务器 MAY 优先丢弃或将非 persistent basic 消息发送到死信队列。
planned	MUST		basic / 06	服务器 MUST 实现至少 2 个 basic 消息的优先级级别，其中优先级 0-4 和 5-9 被视为两个不同的级别。
doesn't	MAY		basic / 07	服务器 MAY 实现多达 10 个优先级级别。
ok	MUST		basic / 08	服务器 MUST 按顺序投递相同优先级的消息，而不管其各自的持久性。
ok	MUST		basic / 09	服务器 MUST 支持 Basic 内容的未确认投递，即 no-ack 字段设置为 TRUE 的消费者。
ok	MUST		basic / 10	服务器 MUST 支持 Basic 内容的显式确认投递，即 no-ack 字段设置为 FALSE 的消费者。
ok	MUST	server	basic / qos / prefetch-size / 01	当客户端未处理任何消息时，服务器 MUST 忽略此设置 - 即，预取大小不限制单条消息的传输，只限制在客户端仍有一条或多条未确认消息的情况下提前发送更多消息。 注释: （指 prefetch-size）
ok	MUST NOT	server	basic / qos / prefetch-count / 01	服务器可以提前发送的数据量可以小于客户端指定的预取窗口，但 MUST NOT 发送更多。
does	SHOULD	server	basic / consume / 01	服务器 SHOULD 支持每个队列至少 16 个消费者，并且理想情况下，除了可用资源定义的限制外，不施加任何限制。
ok	MUST NOT	server	basic / consume / consumer-tag / 01	客户端 MUST NOT 指定一个指代现有消费者的标签。
ok	MUST	server	basic / consume / consumer-tag / 02	消费者标签仅在创建消费者的通道内有效。即，客户端 MUST NOT 在一个通道上创建消费者，然后在另一个通道上使用它。
doesn't	MAY NOT	server	basic / consume / exclusive / 01	客户端 MAY NOT 获得对已有活动消费者的队列的独占访问权。
ok	MUST	server	basic / cancel / 01	如果队列不存在，服务器 MUST 忽略 cancel 方法，只要消费者标签对该通道有效。
ok	MUST NOT	server	basic / publish / exchange / must-exist	客户端 MUST NOT 尝试向不存在的交换器发布内容。
ok	MUST	server	basic / publish / exchange / default-exchange	服务器 MUST 接受一个空的交换器名称，表示默认交换器。
ok	MUST	server	basic / publish / exchange / 02	如果交换器被声明为内部交换器，服务器 MUST 引发一个具有回复代码 403（拒绝访问）的通道异常。
doesn't	MAY	server	basic / publish / exchange / 03	交换器 MAY 拒绝 basic 内容，在这种情况下，它 MUST 引发一个具有回复代码 540（未实现）的通道异常。
does	SHOULD	server	basic / publish / mandatory / 01	服务器 SHOULD 实现 mandatory 标志。
doesn't	SHOULD	server	basic / publish / immediate / 01	服务器 SHOULD 实现 immediate 标志。 注释: 服务器不支持 immediate 标志。消息 TTL 为 0 提供了一种替代方案。
planned	SHOULD	client	basic / deliver / 01	服务器 SHOULD 跟踪消息投递给客户端的次数，并且当消息被重新投递一定次数 - 例如 5 次 - 而未被确认时，服务器 SHOULD 认为该消息是不可处理的（可能导致客户端应用程序中止），并将消息移至死信队列。
ok	MUST	server	basic / ack / multiple / exists	服务器 MUST 验证非零 delivery-tag 是否引用了已投递的消息，如果不是，则引发通道异常。在事务性通道上，此检查 MUST 立即进行，而不是延迟到 Tx.Commit。特别是，客户端 MUST 不会重复确认同一条消息。
planned	SHOULD	server	basic / reject / 01	服务器 SHOULD 能够接受和处理 Reject 方法，同时发送消息内容与 Deliver 或 Get-Ok 方法。即，服务器在发送输出帧时应读取和处理传入方法。要取消部分发送的内容，服务器会发送一个大小为 1 的内容体帧（即，除了帧结束字节外没有数据）。
ok	SHOULD	server	basic / reject / 02	服务器 SHOULD 将此方法解释为客户端目前无法处理该消息。
ok	MUST NOT	server	basic / reject / 03	客户端 MUST NOT 使用此方法作为选择要处理的消息的方式。
planned	MUST NOT	server	basic / reject / requeue / 01	服务器 MUST NOT 在当前通道的上下文中将消息投递给同一客户端。推荐的策略是尝试将消息投递给另一个消费者，如果不可能，则将消息移至死信队列。服务器 MAY 使用更复杂的跟踪来将消息保留在队列中，并在稍后将其重新投递给同一客户端。
ok	MUST	server	basic / recover-async / 01	服务器 MUST 在所有重新发送的消息上设置 redelivered 标志。
ok	MUST	server	basic / recover / 01	服务器 MUST 在所有重新发送的消息上设置 redelivered 标志。
ok	MUST NOT		tx / not multiple queues	应用程序 MUST NOT 依赖于影响多个队列的事务的原子性。
ok	MUST NOT		tx / not immediate	应用程序 MUST NOT 依赖于包含 immediate 选项发布的包含消息的事务的行为。
ok	MUST NOT		tx / not mandatory	应用程序 MUST NOT 依赖于包含 mandatory 选项发布的包含消息的事务的行为。
ok	MUST NOT	server	tx / commit / transacted	客户端 MUST NOT 在非事务性通道上使用 Commit 方法。
ok	MUST NOT	server	tx / rollback / transacted	客户端 MUST NOT 在非事务性通道上使用 Rollback 方法。

AMQP 0-9-1 规范（PDF）中的规则

下文列出的规则来自 0-9-1 规范的 PDF 版本， wherever MUST, SHOULD or MAY appear in the text.

当前状态	类型	Actor	Reference	Text
does, doesn't	SHOULD, SHOULD		1.4.1	协议常量显示为大写名称。AMQP 实现 SHOULD 在定义和使用源代码和文档中的常量时使用这些名称。属性名、方法参数和帧字段显示为小写名称。AMQP 实现 SHOULD 在源代码和文档中一致地使用这些名称。 注释: 属性名、方法参数和帧字段在某些上下文中可以合法地显示为驼峰式大小写。
ok	MUST		2.2.4	对于尚未完全打开的连接，没有错误握手机制。在成功进行协议头协商之后 [...]，在发送 Open 或 Open-Ok 之前，检测到错误的对等方 MUST 关闭套接字，而不再发送任何数据。
does	MAY		2.3.3	服务器 MAY 在同一端口上托管多个协议。 注释: 服务器在同一端口上支持 0-8、0-9 和 0-9-1。
doesn't	MAY		2.3.3	商定的限制 MAY 使双方能够预先分配关键缓冲区，从而避免死锁。
ok	MUST		2.3.3	每个传入帧要么符合商定限制，因此是“安全”的，要么超出限制，在这种情况下，另一方是错误的，并且 MUST 被断开连接。
ok	MUST		2.3.3	服务器 MUST 告知客户端它提出的限制。
doesn't	MAY		2.3.3	客户端进行响应，并且 MAY 降低其连接的限制。
does	MAY		2.3.5.2	数据（用于内容帧）可以是任何大小，并且 MAY 被分解成几个（或许多）块，每个块构成一个“内容体帧”。
ok	MUST, MUST		2.3.7	对于客户端来说，连接或通道被视为“打开”，当它发送了 Open，对于服务器来说，当它发送了 Open-Ok。从此刻起，希望关闭通道或连接的对等方 MUST 使用握手机制 [...]。当一个对等方决定关闭通道或连接时，它会发送一个 Close 方法。接收方 MUST 对 Close 响应 Close-Ok，然后双方都可以关闭其通道或连接。
does	MUST NOT, MUST NOT		3.1.1	服务器 MUST NOT 修改它接收并传递给消费者应用程序的消息内容体 [...] [服务器] MUST NOT 删除或修改现有信息。 注释: 路由后会从属性中删除“BCC”标题。
doesn't	MAY		3.1.1	服务器 MAY 在内容头中添加信息 [...]
ok	MUST		3.1.2	每个连接 MUST 关联到单个虚拟主机。
doesn't	MAY		3.1.2	[使用的] 授权方案 MAY 为每个虚拟主机独有。
ok	MUST, MUST		3.1.3.1	服务器 MUST 实现 direct 交换器类型，并且 MUST 在每个虚拟主机中预先声明至少两个 direct 交换器：一个名为 amq.direct，一个没有公共名称的，作为 Publish 方法的默认交换器 [...] [所有] 消息队列 MUST 自动绑定到无名交换器，并使用消息队列的名称作为路由键。
ok	MUST		3.1.3.3	用于 topic 交换器的路由键 MUST 由零个或多个由点分隔的单词组成。
does, ok	SHOULD, MUST		3.1.3.3	服务器 SHOULD 实现 topic 交换器类型，在这种情况下，服务器 MUST 在每个虚拟主机中预先声明至少一个 topic 交换器，名为 amq.topic。
does, ok	SHOULD, MUST		3.1.3.4	服务器 SHOULD 实现 headers 交换器类型，在这种情况下，服务器 MUST 在每个虚拟主机中预先声明至少一个 headers 交换器，名为 amq.match。
ok	MUST		3.1.3.4	所有非规范的交换器类型 MUST 以“x-”开头命名。
does	MAY NOT		3.1.4	请注意，在存在多个队列读取器、客户端事务、优先级字段的使用、消息选择器的使用或特定于实现的投递优化的情况下，队列 MAY 不会表现出真正的 FIFO 特性。 注释: FIFO 特性在第 4.7 节中指定的条件下得到保证。
ok	MUST		3.1.10	服务器和客户端 MUST 遵守[指定的命名]约定。
does	SHOULD		3.2.1	AMQP 方法可能定义特定的最小值（例如，每条消息队列的消费者数量）以实现互操作性。这些最小值在每个类的描述中定义。符合 AMQP 标准的实现 SHOULD 为这些字段实现合理慷慨的值，最小值仅用于能力最差的平台。
does, doesn't	SHOULD, MAY		3.2.1	发送方 SHOULD 等待特定的回复方法 [在发送同步请求之后]，但 MAY 异步实现它。
ok	MUST		4.2.2	客户端 MUST 通过发送协议头来启动新连接。
doesn't	MAY		4.2.2	服务器 MAY 接受非 AMQP 协议，如 HTTP。 注释: 核心代理只接受 AMQP。存在用于其他协议的插件。
ok	MUST		4.2.2	如果服务器不识别套接字上的前 5 个字节的数据，或者不支持客户端请求的特定协议版本，它 MUST 向套接字写入一个有效的协议头，然后刷新套接字（以确保客户端应用程序将收到数据），然后关闭套接字连接。
does	MAY		4.2.2	服务器 MAY 打印诊断消息 [在失败的协议协商期间] 以协助调试。 注释: 相关信息将写入服务器日志。
doesn't	MAY		4.2.2	客户端 MAY 通过尝试使用其支持的最高版本连接并根据从服务器收到的信息进行重连（使用较低版本）来检测服务器协议版本。
ok	MUST		4.2.3	帧结束字节 MUST 始终是十六进制值 %xCE。
ok	MUST, MUST, MUST		4.2.3	如果对等方收到类型不是这些定义类型之一的帧，它 MUST 将此视为致命协议错误，并关闭连接，而不再在该连接上发送任何数据。当对等方读取帧时，它 MUST 在尝试解码帧之前检查帧结束符是否有效。如果帧结束符无效，它 MUST 将此视为致命协议错误，并关闭连接，而不再在该连接上发送任何数据。
does	SHOULD		4.2.3	它 SHOULD 记录有关 [帧解码] 问题的信息，因为这表明服务器或客户端帧代码实现中存在错误。
ok	MUST NOT, MUST, MUST, MUST, MUST		4.2.3	对等方 MUST NOT 发送大于商定大小的帧。收到超大帧的对等方 MUST 信号一个连接异常，回复代码为 501（帧错误）。心跳帧的通道号 MUST 为零，对于引用 Connection 类的心跳帧、方法帧、头帧和体帧也是如此。收到这些帧之一的非零通道号的对等方 MUST 信号一个连接异常，回复代码为 503（命令无效）。
ok	MUST NOT		4.2.5.1	实现者 MUST NOT 假设帧中编码的整数是对齐在内存字边界上的。
ok	MUST		4.2.5.5	字段名 MUST 以字母、'$' 或 '#' 开头 [...]
doesn't, doesn't	SHOULD, SHOULD		4.2.5.5	服务器 SHOULD 验证字段名，并在收到无效字段名时，它 SHOULD 信号一个连接异常，回复代码为 503（语法错误）。
planned	MUST		4.2.6	收到不完整或格式错误的内容的对等方 MUST 引发连接异常，回复代码为 505（意外帧）。 注释: 对于内容格式错误的所有可能方式，都不会返回给定的回复代码。
ok	MUST, MUST		4.2.6.1	内容头 [的类 ID] MUST 与方法帧的类 ID 匹配。对等方 MUST 通过引发回复代码为 501（帧错误）的连接异常来响应无效的类 ID。
ok	MUST NOT, MUST		4.2.6.1	内容帧中的通道号 MUST NOT 为零。收到内容帧中零通道号的对等方 MUST 信号一个连接异常，回复代码为 504（通道错误）。
ok	MUST		4.2.6.2	对等方 MUST 处理拆分为多个帧的内容体，方法是将其作为一组存储起来，然后要么按原样重新传输，拆分成更小的帧，要么连接成一个块以交付给应用程序。
ok	MUST		4.2.6.2	心跳帧 MUST 具有零通道号。
ok	MUST		4.2.7	如果对等方不支持心跳，它 MUST 丢弃心跳帧，而不发出任何错误或故障信号。 注释: 代理和支持的客户端确实支持心跳帧。
does, doesn't	MAY, MAY		4.3	AMQP 对等方 MAY 支持多个通道。最大通道数在连接协商时定义，并且对等方 MAY 将此协商至 1。
does, doesn't	SHOULD, SHOULD NOT		4.3	每个对等方 SHOULD 以公平的方式平衡所有打开通道上的流量。这种平衡可以按帧进行，或者基于每个通道的流量量。对等方 SHOULD NOT 允许一个非常繁忙的通道饿死一个不太繁忙的通道的进度。
ok	MUST NOT, MUST		4.6	请求-响应的影响 MUST NOT 在响应方法之前对通道可见，并且 MUST 在之后可见。
ok	MUST		4.7	服务器 MUST 保持通过单个内容处理路径的内容顺序，除非 redelivered 字段在 Basic.Deliver 或 Basic.Get-Ok 方法上设置，并且根据控制该字段可以设置的条件规则。 注释: 代理提供了更强的保证。
does	SHOULD		4.10.2	服务器 SHOULD 记录所有 [连接协商阶段的异常]，并标记或阻止导致多次失败的客户端。

已弃用的类

以下类在 0-9-1 版本中被弃用。RabbitMQ 完全不实现这些类，包括当代理连接到 0-8 客户端时，或当 .NET 客户端配置为使用 0-8 时。

• access
• dtx
• file
• stream
• test
• tunnel

另请参阅下方的详细规范兼容性表。

获取帮助和提供反馈

如果您对本指南的内容或与 RabbitMQ 相关的任何其他主题有疑问，请随时通过 GitHub Discussions 或我们的社区 Discord 服务器 提问。

帮助我们改进文档 <3

如果您想为本网站贡献改进，其源代码可在 GitHub 上找到。 签署贡献者 CLA，然后只需 fork 存储库并提交一个拉取请求。谢谢！