为什么使用服务器发送事件而不是简单的 HTTP 分块流？

Question

我刚刚阅读了RFC-6202，但无法弄清楚使用 SSE 而不是简单地请求分块流的好处。作为一个示例用例，假设您想要实现客户端和服务器，其中客户端想要使用纯 HTTP 技术“订阅”服务器上的事件。服务器保持初始 HTTP 请求打开，然后偶尔在新事件出现时发送新块，会有什么缺点？我发现了一些反对这种流媒体的论点，其中包括以下内容：

• 由于Transer-Encoding是逐跳而不是端到端，因此中间的代理可能会尝试在将响应转发到客户端之前合并块。
• 客户端和服务器之间的 TCP 连接需要始终保持打开状态。

然而，据我了解，这两种论点也适用于上证所。我可以想象的另一个潜在的论点是，JavaScript 浏览器客户端可能没有机会实际获取相应的块，因为重新组合它们是在较低级别上处理的，对客户端来说是透明的。但我不知道事实是否如此，因为视频流必须以某种类似的方式工作，或者不是？

编辑：与此同时，我发现 SSE 基本上只是一个分块流，由更易于使用的 API 封装，对吗？

还有一件事。此页面首先告诉 SSE 不支持流式二进制数据（出于什么技术原因？），然后（在底部），他们说这是可能的，但效率低下。有人可以澄清一下吗？

Answer 1

是的，SSE 是一个在 HTTP 之上工作的 API，为您提供一些不错的功能，例如客户端/服务器端的自动重新连接或处理不同类型的事件。

如果您想使用它来传输二进制数据，那么它肯定不是正确的 API。主要事实是，SSE 是一个基于文本的协议（它由 '\n 分隔，每行都以文本标记开头。如果您仍然想通过 SSE 尝试二进制文件，一个快速而肮脏的黑客可能是提交二进制文件Base 64 中的数据。

如果你想了解更多关于 SSE 的信息，也许你可以看看这个简单的库： https: //github.com/mariomac/jeasse