sockets - 通过多个套接字发送流数据的协议(protocol)

Question

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

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

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

用户如何知道他们落后并需要启动更多连接？

推特说 consumers should check timestamps ，这对我们有用

当他们启动一个新连接来消费更多数据时，他们如何指定这是同一个消费 session 的一部分？

我们可以为 session 命名，将其与 "direct" amqp queue 关联起来, 让我们的队列干活

我错过了什么非常重要的东西。

大概。

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

该协议(protocol)将被视为 super 棒如果它:

websocket 或流式 HTTP 是否友好

支持数据压缩

Answer 1

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

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

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

或者，如果您想创建自己的更简单的协议(protocol)，这些协议(protocol)可以提供一个很好的引用点 - 如果这看起来是一个明智的路线，您可以寻找一些开源流媒体服务器，甚至可以适应您的需求:

http://gstreamer.freedesktop.org

http://icecast.org

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

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