ZMTP

ZMTP 连接经历以下主要阶段：

以下 ABNF 语法定义了该协议：

ZMTP 提供非对称版本协商。ZMTP 对等体可能会尝试检测和使用旧版本的协议。它还可能要求其对等方提供 ZMTP 功能。

在第一种情况下，在建立或接收连接后，对等方应向另一方发送足以触发版本检测的部分问候语。这是问候语的前 11 个八位字节（签名和主版本号）。然后，对等方应读取其他对等方发送的前 11 个八位字节的问候语，并确定是否降级。每个较旧的 ZMTP 版本的特定启发式方法在 向后互操作性 一节中进行了说明。在这种情况下，对等方可以使用填充字段进行较旧的协议检测（我们将在下面解释特定的已知情况）。

在第二种情况下，在建立或接收连接后，对等方应发送其整个问候语（64 个八位字节），并应期望匹配的 64 个八位字节问候语。在这种情况下，对等方应将填充字段设置为二进制零。

无论哪种情况，请注意：

默认情况下，ZMTP 是一种对等协议，它不区分客户端和服务器。

但是，安全机制（即扩展协议，如下所述）可以为客户端对等方和服务器对等方定义不同的角色。这种差异反映了将身份验证集中在服务器上的一般模型。

传统上，在 TCP 拓扑中，“服务器”是绑定的对等体，“客户端”是连接的对等体。ZMTP 允许这样做，但也允许客户端绑定和服务器连接的相反拓扑。

如果所选的安全机制未指定客户端和服务器角色，则 as-server 字段没有意义，并且对于所有对等方都应为零。

ZMTP 通过使用松散地基于 IETF 简单身份验证和安全层 （SASL） 的协商安全机制来提供可扩展的身份验证和机密性。对等方可以支持以下任何或所有机制：

安全机制是一个 ASCII 字符串，根据需要填充 null 以容纳 20 个八位字节。实现可以定义自己的机制用于实现和内部使用。所有用于公共互操作性的机制都应定义为 ZMQ RFC。 机制名称应以先到先得的方式分配。机制名称应仅由大写字母 A 到 Z、数字和嵌入的连字符或下划线组成。

与 SASL 不同，对等方只宣布一种安全机制，SASL 允许服务器宣布多种安全机制。ZMTP 中的安全性是断定的，因此给定套接字上的所有对等方都具有相同的所需安全级别。这样可以防止降级攻击并简化实施。

每种安全机制都定义了一个协议，该协议由任一对等体向另一方发送的零个或多个命令组成，直到握手完成或任一对等体拒绝并关闭连接。

command 是由 8b flag 字段、大小字段和正文组成的单个帧。如果正文为 0-255 个八位字节，则该命令应使用短大小字段（%x04 后跟 1 个八位字节）。如果正文为 256 个或更多八位字节，则该命令应使用长大小字段（%x06 后跟 8 个八位字节）。

flag 八位字节和大小字段始终为明文。正文可以部分加密或完全加密。ZMTP 不定义命令的语法或语义。这些完全由安全机制协议定义。

支持的机制不被视为敏感信息。读取完整 greeting（包括机制）的对等节点也必须发送完整的问候语（包括机制）。这避免了两个对等方各自等待对方发送其问候语的其余部分的僵局。

如果对等方收到的机制与其发送的机制不完全匹配，则必须关闭连接。

ZMTP 允许在机制握手期间使用 ERROR 命令进行显式致命错误响应。对等方应将传入的 ERROR 命令视为致命命令，并通过关闭连接而不是使用相同的安全凭据重新连接来执行操作。

实现应通过关闭连接来发出任何其他错误的信号，例如过载、暂时拒绝连接等。对等方应将意外关闭的连接视为临时错误，并应重新连接。

为避免连接风暴，对等体应在较短且可能随机的间隔后重新连接。此外，如果对等体多次重新连接，则应增加重新连接之间的延迟。各种策略是可能的。

在发送了 64B 固定大小的 greeting 后，所有的数据都以帧的形式发送，帧携带了 commands 或 messages。帧由一个 flags 字段、一个 size 字段和正文构成。帧被设计为既能有效传输小数据，也能传输非常大的数据。

一个帧的构成如下：

Commands 由 ZMTP 实现使用，除了部分情景外，对用户是不可见的。Commands 总是由一个帧构成。包含了一个可打印的命令名、一个空字节分隔符和数据。

此规范定义了下面的命令：

ZMTP 支持可拓展的安全机制，他们可能定义他们自己的命令。安全机制可以根据需要定义任意的命令名。

message 携带了用户数据，除了部分情景下一般不会被 ZMTP 创建、修改或者过滤。消息由一个或多个帧构成。一个消息要么所有的帧都到，要么一个帧也不会到。

NULL 不实现身份验证和加密。NULL 机制不应当用于没有传输安全性的公共基础设施（例如通过 VPN）。

当对等方使用 NULL 安全机制是，as-server 必须为零。绑定的对等方为服务器，连接的对等方为客户端。

要完成 NULL 安全握手。客户端应发送 READY 命令，然后等待 READY 命令作为回复。服务器应当解析并验证 READY 命令。如果没有错误，必须发送 READY 命令作为回复。如果验证成功，则必须发送 READY 命令作为回复，如果失败，则任意一方都可以选择关闭连接。对等方可以在完成握手后立即开始发送消息。即发送和接收 READY 命令。

以下使用 ABNF 语法定义 NULL 握手机制：

message 和 command-size 由前面解释的 ZMTP 语法定义。

READY 命令的正文由一个属性列表组成，该列表由 name 和 value 组成，这些属性是大小指定的字符串。

名称应为 1 到 255 个字符。零大小的名称无效。名称的大小写（大写或小写）不应重要。

值应为 0 到 2,147,483,647（2^31-1 或 C/C++ 中的 INT32_MAX）不透明二进制数据的八位字节。允许使用零大小的值。值的语义取决于属性。值大小字段应为四个八位字节，按网络字节序排列。请注意，此大小字段在内存中大多不会对齐。

ERROR 命令的正文包含可以记录的错误原因。它没有定义的语义值。

安全机制提供了交换字典形式的元数据，元数据的具体编码形式取决于机制。

元数据的键是大小写不敏感的。

默认定义了下面的元数据属性：

实现可能定义其它的元数据属性，比如实现名、平台名等。为了互操作性，所有的元数据和语义也需要被定义为 RFCs。

以 "X-" 开头的元数据属性被保留给应用使用。

实现应当遵循 [./pubsub] 中规定的 PUB/XPUB, SUB/XSUB 中的语义。

使用 ZMTP 的时候，过滤可能发送在发送端（PUB/XPUB 套接字）。要创建一个订阅，SUB/XSUB 需要发送 SUBSCRIBE 命令，其语法如下：

要取消订阅，SUB/XSUB 需要发送 CANCEL 命令：

subscription 是一个二进制字符串，匹配所有订阅者想要的消息。例如订阅 'A' 匹配所有以 'A' 开头的消息，空的订阅匹配所有的消息。

订阅是累加的而不是幂等的。也就是说两个相同的订阅 'A' 需要两次取消才能撤销。