使用 websockets 对 IPC 来说是个好主意吗？答案

【问题标题】：Is using websockets a good idea for IPC?使用 websockets 对 IPC 来说是个好主意吗？
【发布时间】：2017-10-04 17:46:57
【问题描述】：

我有一个“主”进程和几个“工作”进程，我想在它们之间传递一些消息。消息可以是二进制 blob，但每个都有固定的大小。我想要一个抽象，它可以为我巧妙地缓冲和分离每条消息。我不想在 TCP 之上发明自己的协议，而且我找不到任何可跨语言移植的简单+轻量级解决方案。（截至目前，“主”进程是 Node.js 服务器，“工作”进程计划使用 Python。）

【问题讨论】：

标签： python node.js websocket ipc

【解决方案1】：

这个问题纯粹是基于意见，但我还是会试一试：

WebSocket 是一个矫枉过正的 imo。首先，为了让 WebSockets 工作，你必须实现 HTTP（或者至少是它的一些基本形式）来进行握手。如果你这样做，那么最好坚持“正常”HTTP，除非有全双工通信的原因。到处都有很多工具可以通过（unix 域）套接字处理 HTTP。

但这也可能是矫枉过正。如果您有工人，那么我认为绩效很重要。最简单和（可能）最有效的解决方案是以下协议：每条消息以 1-8（选择一个数字）字节开始，这些字节确定以下内容的大小。内容是您想要的任何内容，例如protobuf 消息。例如，如果您想发送foo，那么您发送0x03 0x00 0x66 0x6f 0x6f。前两个字节对应内容的大小（为3），后三个字节对应foo。

【讨论】：

您建议的协议的问题（我也想到了）是，如果其中一个端点有问题并且发送的消息比它所说的更大或更小，我将如何检测错误，恢复然后处理下一条消息？我想知道是否有任何为这个简单目的而编写的好的协议。（也许它值得自己提出一个问题。）
另外，我认为 WebSockets 的开销比 HTTP 少。我错了吗？（虽然我确实需要某种全双工通信，而不是我目前计划的简单请求-响应。）
@John 对于比预期大的消息，您可以添加校验和（作为消息的一部分，例如“大小标头”之后的 8 个字节）以进行验证。对于小于预期的消息，您需要超时（请注意，您不能假设您收到了所有内容，这可能是通信延迟）。另请注意，WebSockets 不会让您摆脱这些问题（有问题的端点可能仍会发送包装在适当的 websocket 框架中的部分内容）。
至于开销：由于帧屏蔽，WebSockets 可能具有更大的开销。对于小消息，它们确实比 HTTP 更有效。对于全双工通信，我会使用自定义协议。
这就是为什么我尽量不重新发明轮子。我不明白为什么没有标准的简单库，但有几个“标准”且经过良好测试的复杂库。在这种情况下，您对 nanomsg 有意见吗？

【解决方案2】：

听起来您需要某种消息代理。

您对“缓冲”的要求将排除，例如，ZeroMQ（它是进程间通信的理想选择，但没有内置的消息持久性）。

如果您碰巧在 AWS 上，这将为您提供 RabbitMQ 或 SQS 等选项。您还可以查看 Kafka（AWS 上的 Kinesis）。这些服务都提供了消息的“缓冲”，RabbitMQ 提供了最大范围的配置，但可能是最大的实现障碍。

另一种选择是将 Redis 用作简单的消息传递服务。

有许多选项，所有选项都适合不同的用例和环境。我应该补充一点，虽然“简单和轻量级”并不真正适合除 - 也许 - ZeroMQ 之外的任何解决方案

【讨论】：

我试图避免使用外部代理进行简单的消息传递。我考虑过 nanomsg（0MQ 的继任者），但对我来说感觉有点矫枉过正，因为只有少数工作人员，因此可扩展性不是问题。
老实说，我会将进程间通信描述为一个潜在的雷区（尤其是在一端或两端使用 Python）。我显然在 ZeroMQ / nanomsg 上稍微落后了一点，但我肯定更愿意走那条路：至少你知道可以依赖通信/协议。