处理流媒体服务器答案

【问题标题】：Handling a streaming server处理流媒体服务器
【发布时间】：2012-03-27 15:34:03
【问题描述】：

我有一个服务器，它可以尽可能快地发送数据并通过套接字发送数据。服务器使用队列，并有一个生产者线程和一个消费者线程，将生产的数据从套接字发送到客户端。

问题是在客户端读取数据。如何设计客户端来处理数据而不会不同步？如果我从客户端向服务器发送确认，我会失去服务器端的并发速度。如何编写/设计客户端以足够快地处理传入数据？需要在客户端实现队列吗？

【问题讨论】：

【解决方案1】：

除非您要求必须使用 TCP 以外的其他东西，否则只需让 TCP 为您完成流量控制工作。让客户端尽可能快地消费数据，当服务器发送的数据超过客户端准备消费的数据并填满 TCP 窗口时，服务器将阻塞。

TCP 永远不会失去同步，因为套接字上的数据将始终按顺序传递。但是服务器发送的数据肯定比客户端消耗的多，因此它可能已经继续发送下一批数据，而客户端仍在使用前一批数据。这就是不同步的意思吗？

您不想让客户端在服务器开始执行下一个任务之前发送确认，因为这将花费 RTT（往返时间，即一批数据中的最后一个到达客户端的时间并确认返回），这将减慢您在高延迟链接上的协议。

如果您不想要这个 RTT 价格，您将不可避免地不得不允许：

客户端一次请求多个批次。为此，您可以使用 IMAP 之类的标记协议：客户端一次在一个套接字上提交多个作业，每个作业都有自己的标记。服务器响应每个请求，并在每个响应的标头中使用标签，以便客户端知道哪个响应与哪个请求一起出现。当客户端看到“足够”的响应时，它会提交更多请求。客户端可以控制同时进行多少请求。如果客户端一次只允许一个，这将退化为具有 RTT 成本的简单 ACK 情况。
为了让服务器在客户端之前工作一点，在客户端确认第一个响应之前向客户端发送多个响应。在管道填充到服务器愿意允许的最大未确认作业数后，它等待确认，并为从客户端收到的每个确认发送一个额外的作业响应。如果服务器只允许一个未完成的工作，这将退化为上面的简单 ACK 情况。如果服务器一次允许太多未确认的作业，这将退化为只是填满 TCP 的缓冲区并依靠 TCP 流控制来阻塞服务器，直到客户端准备好接受更多数据。

【讨论】：

嗯，我发送的数据是由一个标题构成的。如何构建数据由我决定。我遇到的问题是数据的解析与服务器不同步，因为它移动得太快了。
你还没有说你是否会使用 TCP。如果使用 TCP，为什么会不同步？如果你不这样做，为什么不呢？
我正在使用 TCP。它不同步是因为服务器在客户端完成处理前一组数据之前发送下一组数据。我可以让客户端在两者之间发送一个确认，但是我失去了并发服务器的好处。我正在尝试像音频/视频一样制作流媒体服务器和客户端。
它不会不同步。 TCP 保留从一端到另一端的数据序列。但是让我看看你和我是否理解“不同步”的不同含义。我会在答案中添加更多内容。