我正在设计一个API，用于消费来自应用程序的消息，该消息将生成大量数据;即使对于较小的客户，也可能有10+ GB / s。我正在寻找一种协议，允许我以一种易于客户使用的方式提供这些数据。
对我来说，显而易见的答案是：将消息分开，以便它们可以通过多个连接进行消费。每个连接都会占用总负载的一小部分。
但如果我这样做，我需要考虑一些事项：
出于这个原因，我更倾向于已经存在的协议。
如果符合以下条件，该协议将被视为非常棒：
答案 0 :(得分：1)
您所描述的问题几乎与视频流必须处理的问题相同，您可能已经知道了。关键的HTTP友好流媒体协议是HLS（Apple），SmoothStreaming（微软），HDS（Adobe）和MPEG-DASH（开放协议，但是新的）。
在考虑视频流时，还值得了解您的流是否更像“直播”流或“静态”内容 - 前者是即时生成的，并且直播中的任何给定部分可能仅适用于设置时间，而后者完全存储在服务器上，通常任何部分都可以随时使用（直到内容被删除）。如何流式传输和回放这些是微妙的不同。
您可以简单地重复使用上述视频流协议之一，将数据包装为视频（或者甚至可能是视频），并在接收方实现您自己的自定义客户端。
或者，如果您想创建自己的简单协议，这些协议可以提供一个很好的参考点 - 有几个开源流媒体服务器，您可以寻找想法，甚至可以适应您的需求，如果这看起来像一个明智的路线：
视频流非常复杂，您可能已经知道，但如果您的用例更简单，您可能会忽略或消除大部分复杂性 - 例如，您可能不需要搜索，多种格式和比特率流，随附的流（用于字幕等）。如果您无法开箱即用，那么能够像这样进行简化可能有理由根据您的需要修改上述其中一项。
最后一点 - 视频和音频流协议通常具有处理延迟或丢失数据包的内置方式。根据您的应用程序，这些可能不适用于您，因此如果重复使用视频或音频流协议或服务器，您应该仔细查看此方面。例如，音频客户端通常容忍少量数据包丢失，并且通常会丢弃延迟的数据包而不是暂停音频（在“抖动缓冲区”窗口外部接收的数据包）。如果您的应用程序无法容忍任何数据包丢失，那么您需要仔细查看底层解决方案和协议，以确保它真正满足您在所有网络条件下的需求。