应用程序使用客户端库与 RabbitMQ 交互。许多编程语言和平台都有客户端库。每个协议都有自己的客户端库。客户端连接并成功验证 RabbitMQ 节点后，就可以发布和消费消息、定义拓扑结构并执行协议中规定的、客户端库和目标 RabbitMQ 节点都支持的其他操作。
RabbitMQ 支持的所有协议都是基于 TCP 的，并假定存在长期连接（每次协议操作都不会打开一个新连接）以提高效率。一个客户端库连接使用一个 TCP 连接。为了让客户端成功连接，目标 RabbitMQ 节点必须允许特定协议端口上的连接。
Resource Usage
每个连接都会消耗目标 RabbitMQ 节点上的内存和一个文件句柄。
操作系统对单个进程可以同时打开的 TCP 连接（套接字）数量有限制（file handle）。该限制通常足以满足开发和某些 QA 环境的需要。生产环境必须配置为使用更高的限制，才能支持更大数量的并发客户端连接。
Safety
Connection Traffic Encryption with TLS
connection churn
由于连接的目的是长期有效，客户端通常通过注册订阅并将消息传递（推送）给他们来消费消息，而不是轮询。无法保持长期连接的客户端可以使用特殊代理来帮助减少连接流失。
Connection Leak
连接泄漏是应用程序重复打开连接而不关闭连接或至少仅关闭其中一些连接的情况。
当不再需要连接时，应用程序必须关闭它们以节省资源。连接泄漏最终会耗尽文件句柄的节点（或多个目标节点），这意味着任何新的入站客户端、对等点或 CLI 工具连接都将被拒绝。并发连接数量的增加也会增加节点的内存消耗。
Much like connections, channels are meant to be long lived. That is, there is no need to open a channel per operation and doing so would be very inefficient, since opening a channel is a network roundtrip.
Connection Churn
Some applications open a new connection for every message published. This is highly inefficient and not how messaging protocols were designed to be used. Such condition can be detected using connection metrics.
Prefer long lived connections when possible.
Concurrency Considerations
Concurrency topics are all about client library implementation specifics but some general recommendations can be provided. In general, publishing on a shared “publishing context” (channel in AMQP 0-9-1, connection in STOMP, session in AMQP 1.0 and so on) should be avoided and considered unsafe.
Doing so can result in incorrect framing of data frames on the wire. That leads to connection closure.
With a small number of concurrent publishers in a single application using one thread (or similar) per publisher is the optimal solution. With a large number (say, hundreds or thousands), use a thread pool.
Producer Flow Control
back pressure mechanism，防止生产者发布消息相对内部某些组件处理速度过快导致资源使用激增。
节点中的某些组件可能落后于特别快的发布者，因为其必须比发布客户端做更多的工作（例如，将数据复制到 N 个对等节点或将其存储在磁盘上）。
会对发布消息的连接进行阻塞限流，详见https://www.rabbitmq.com/docs/flow-control。
推荐：生产者和消费者连接分开使用，避免连接被限流时导致无法及时完成消费者ACK
协议区别
请注意，尽管命名相似，但 AMQP 0-9-1 和 AMQP 1.0 是不同的协议，而不是同一协议的不同版本。
AMQP 0-9-1
AMQP 0-9-1 provides a way for connections to multiplex over a single TCP connection. That means an application can open multiple “lightweight connections” called channels on a single connection. AMQP 0-9-1 clients open one or more channels after connecting and perform protocol operations (manage topology, publish, consume) on the channels.
AMQP 1.0
AMQP 1.0 provides a way for connections to multiplex over a single TCP connection. That means an application can open multiple “lightweight connections” called sessions on a single connection. Applications then set up one or more links to publish and consume messages.
https://www.rabbitmq.com/docs/connections#large-number-of-connections