通过多个套接字发送流数据的协议

Question

我正在设计一个 API 来使用来自应用程序的消息，该应用程序将生成大量数据；即使对于较小的客户端，也可能达到 10+ GB/s。我正在寻找一种协议，它允许我以一种易于客户使用的方式传递这些数据。

对我来说显而易见的答案是：拆分消息，以便它们可以在多个连接上使用。每个连接将消耗总负载的一小部分。

但如果我这样做，我需要考虑以下几点：

• 用户如何知道他们落后并需要启动更多连接？
  • Twitter 说 consumers should check timestamps，这可能对我们有用
• 当他们启动新连接以消耗更多数据时，他们如何指定这是同一消耗会话的一部分？
  • 我们可以为会话命名，将其与 "direct" amqp queue 关联起来，然后让我们的队列完成这项艰巨的工作
• 我是否遗漏了一些非常重要的东西。
  • 可能。

出于这个原因，我更喜欢已经存在的协议。

该协议将被视为非常棒如果它：

• 对 websocket 或流式 HTTP 友好
• 支持数据压缩

Answer 1

您所描述的问题与视频流必须处理的问题几乎相同，您可能已经知道了。主要的 HTTP 友好流协议是 HLS (Apple)、SmoothStreaming (Microsoft)、HDS (Adobe) 和 MPEG-DASH（开放协议，但新的）。

在考虑视频流时，还值得了解您的流更像是“实时”流还是“静态”内容 - 前者是动态生成的，并且实时流的任何给定部分可能仅适用于set tine，而后者完全存储在服务器上，通常任何部分都可以随时使用（直到内容被删除）。您流式传输和播放这些内容的方式略有不同。

您可以简单地重复使用上述视频流协议之一，方法是将数据包装成视频（或者甚至是视频），并在接收端实现您自己的自定义客户端。

或者，如果您想创建自己的更简单的协议，这些协议可以提供一个很好的参考点 - 如果这看起来是一条合理的路线，您可以寻找一些开源流媒体服务器，甚至可以适应您的需求：

• http://gstreamer.freedesktop.org
• http://icecast.org

您可能已经知道，视频流非常复杂，但如果您的用例更简单，您可以忽略或消除大部分复杂性 - 例如，您可能不需要搜索、多种格式和比特率流，伴随的流（用于字幕等）。如果您无法开箱即用地使用它们，那么能够像这样进行简化可能会证明根据您的需要修改上述其中一项的努力是合理的。

最后一点 - 视频和音频流协议通常具有处理延迟或丢失数据包的内置方法。根据您的应用程序，这些可能不适用于您，因此如果重用视频或音频流协议或服务器，您应该仔细查看这方面。例如，音频客户端通常可以容忍少量的数据包丢失，并且通常会丢弃延迟的数据包而不是暂停音频（在“抖动缓冲区”窗口之外接收到的数据包）。如果您的应用程序不能容忍任何数据包丢失，那么您将需要仔细查看底层解决方案和协议，以确保它真正满足您在所有网络条件下的需求。