持久化传输¶
持久连接允许单个 TCP 连接发送和接收多个请求/响应，而不是为每对请求/响应打开一个新的 TCP 连接。当应用程序打开更少的 TCP 连接并保持它们更长时间的开启状态时，会导致更少的网络流量，减少建立新连接的时间，并允许 TCP 协议更有效地工作。
目前 Zaqar 支持非持久化传输，忽略了一些可以通过更高效和可靠的持久化传输解决方案覆盖的使用场景。
以下使用场景将从这项更改中受益：
与浏览器的通信：WebSocket 将增强浏览器和 Zaqar 之间的通信，这是 Zaqar 与 OpenStack Dashboard (Horizon) 集成的关键因素。
通知：这种类型的传输将构成更好的通知协议，Kilo 版本也计划了此功能。
https://blueprints.launchpad.net/zaqar/+spec/persistent-transport
问题描述¶
目前 Zaqar 中无法建立持久连接。此规范建议通过 WebSocket 实现来添加此功能。
在 Kilo 版本中，我们重构了代码以使添加此驱动程序成为可能，并致力于添加队列端点。
为了完全支持数据平面，我们应该添加消息端点和声明端点。
控制平面操作不需要 WebSocket 驱动程序可以提供的性能，因此我们不会为控制平面添加 WebSocket 支持。
提议的变更¶
如前文所述，拟议的更改是为 Zaqar 添加一种持久化传输替代方案。这可以通过使用 WebSocket 来实现。
WebSocket 提供在单个套接字上运行的全双工通信通道，这将消除开销并显著降低复杂性。
回退¶
如果 WebSocket 不可用，客户端将回退到短轮询 REST API。
WebSocket 不可用的原因包括：
防火墙可以配置为在一定时间后终止 HTTP 连接。
出于安全考虑，任何看起来不像 HTTP 的流量都将被终止，无论是在 80 端口还是 443 端口。
消息序列化¶
为了传输数据，需要一种序列化技术。有几种替代方案，包括 JSON、MsgPack、Protobuf、Apache Avro 和 Cap’n Proto。
在上一轮中，我们注意到虽然 MsgPack 考虑到整体性能、易用性、语言支持和数据结构支持，是最佳候选者，但它对 Javascript 的支持不好。使用 MsgPack 会对 Zaqar 的使用场景施加显著的限制，考虑到现在许多 Web 应用程序都是用 Javascript 编写的。因此，我们决定坚持使用 JSON，并在未来的更改中讨论更高效的序列化技术。
备选方案¶
建立持久连接，启用 WSGI keep-alive
长轮询
实现¶
负责人¶
主要负责人：vkmc
里程碑¶
完成目标里程碑：Liberty-1
工作项¶
实现消息控制器
实现声明控制器
编写消息单元测试
编写声明单元测试
希望拥有：编写功能测试
使用新的驱动程序进行基准测试
WebSocket 库¶
在讨论了几种替代方案，包括 SockJS、SocketIO、Autobahn、ws4py 和 Tornado 之后，已经决定使用 Autobahn 来实现此功能。有关此决定的更多详细信息将在 WebSockets wiki 中提供。
依赖项¶
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
