Zaqar/specs/Protocols/Wire Transport

线传输协议

Zaqar 目前有一个定义良好的协议，该协议在 HTTP 上运行良好。作为项目，我们期待欢迎更多适用于不同用例的传输方式，但我们没有支持它们的方法。本文档旨在定义此类协议，以建立对上述传输方式的支持的基础。

消息格式

通常，线传输协议不会定义消息外观的高级抽象。在此，我们设计自己的格式，该格式试图尽可能地符合 HTTP 结构。

序列化

Zaqar 的持久化传输将使用 JSON 作为序列化格式。使用更高效的序列化格式（例如 Protobufs）正在讨论中。

结构

    {
        "action": "",
        "headers": {},
        "body": {
            ...
        }
    }

头部

尽管 Zaqar 的端点试图尽可能相似，但它们之间存在一些细微的差异。请注意，线传输不实现某些 HTTP 头部，因为它们对此毫无意义，例如

• Host
• Content-Length
• Accept-Encoding
• Content-Type

头部	描述
User-Agent	Zaqar 客户端的名称和版本，以及该客户端的 UUID。Zaqar 使用 UUID 来区分发布者和订阅者，即避免将代理自己的消息回传给它。
日期	当前日期和时间，使用标准的 RFC 1123 HTTP 日期格式
Accept	所需的媒体类型。`application/json`。
X-Auth-Token	Keystone 身份验证令牌
X-Project-ID	一个项目 ID，X-Auth-Token 的值授予对其的访问权限。队列将在该项目下创建。
Client-ID	每个客户端实例的唯一 ID。在 Zaqar 中，这用于避免将发送者的消息回传到同一实例，并且服务器可能会将其记录以供将来使用。应生成一次并在客户端重启之间持久保存。

示例

    {
        "action": "post_message",
        "headers": {
            "User-Agent": "python/2.7 killer-rabbit/1.2",
            "Date": "Wed, 2    8 Nov 2012 21:14:19 GMT",
            "Accept": "application/x-msgpack",
            "Client-ID": 30387f00-39a0-11e2-be4d-a8d15f34bae2,
            "X-Project-ID": 518b51ea133c4facadae42c328d6b77b,
            "X-Auth-Token": "7d2f63fd-4dcc-4752-8e9b-1d08f989cc00"
        },
        "body": {
            ...
        }
    }

Connection (连接)

线传输协议还必须定义在 TCP 连接时 peers 相互识别的方式。鉴于我们愿意为不同的实现提供支持，我们决定这必须由线传输实现本身来描述。例如，对于 websockets，连接机制如 RFC6455 中所述那样工作。

安全

用于数据传输的安全模型也是线传输协议需要关注的问题。如前一节所述，我们决定将此任务委托给线传输实现，以便能够支持多种实现。例如，对于 websockets，使用的安全模型如 RFC6455 中所述。