兼容性和一致性

RabbitMQ 核心 Broker 实现了 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 的规则

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

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

来自 AMQP 规范的版本 0-9-1 的规则 (PDF)

以下列出的规则来自 0-9-1 规范的 PDF 版本，其中 MUST、SHOULD 或 MAY 出现在文本中。

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

已弃用的类

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

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

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

获取帮助和提供反馈

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

帮助我们改进文档 <3

如果您想为站点贡献改进，其源代码 可在 GitHub 上获取。只需 fork 存储库并提交拉取请求。谢谢！